Re: Dallas.p6m
On Mar 18, 2009, at 5:26 PM, fREW Schmidt wrote: s1n and I decided that we would start Dallas.p6m as we are close to each other geographically speaking. We are meeting tomorrow (Thursday, March 19, 7:00PM) at a coffee shop with free wifi. The address is 985 W Bethany Dr Allen, TX 75013. I live in Allen, so might be there. That address is where Market Street is right? What is the name of the coffee shop? Graham.
Re: Temporal changes
On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote: Instant Moment Point PointInTime Timestamp Event Jiffy Time Juncture
Re: fetching module version from the command line
David Wheeler wrote:
> On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
>
>> perl -MModule -e'print $Module::VERSION'
>
> I have this alias set up:
>
> function pv () { perl -M$1 -le "print $1->VERSION"; }
>
> I think that calling ->VERSION is more correct.
I am sure this discussion has happened in the past and in the archive
you could probably find what was suggested last time.
perl -MDBI\ 999
DBI version 999 required--this is only version 1.50.
BEGIN failed--compilation aborted.
Which is the same as writing
use DBI 999;
and perl will call DBI->VERSION(999);
Graham.
Re: Minimum modules for Production?
On Jun 1, 2006, at 11:37 AM, Josh Wilmes wrote: At 12:00 on 06/01/2006 BST, David Cantrell <[EMAIL PROTECTED]> wrote: Basic I/O is talking to filehandles and nyetwork sockets. Anything above the UDP / TCP level should not, IMO, be included. I agree. I'd respectfully disagree. Just like text isn't just ascii any more, content isn't just on local filesystems. HTTP has become pretty much "basic". If you use it. When my work involved a lot of internet related stuff I would have agreed. But with the work I do now my use of HTTP with perl is at 0%. Everyone has a bias in their own thoughts of what the minimum is. "basic" should only be the common subset of them. Graham.
Re: CPAN Testers results
On Wed, November 2, 2005 11:48 am, Christopher H. Laco wrote: > Ovid wrote: >> Hi all, >> >> I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/, >> amongst other modules, has no CPAN test results appearing even though >> CPAN tester reports are coming in. I've seen this for other modules, >> too. >> >> Is there an announced reason for this I missed or is something down? >> > I've often wondered this myself. It seems like it builds up some sort of > delta or count of reports, then does a build; as to avoid rebuilding > stats for every report email that comes in. testers.cpan.org provides an SQLite database of the result. search.cpan.org checks this file for changes once an hour and if it has changed it downloads it and used the new data. I do not know how ofter testers.db is updated though. Graham.
Re: WTF? - Re: method calls on $self
On Thu, July 14, 2005 10:47 am, Autrijus Tang said: > If this were a straw poll, I'd say... > > 1. Meaning of $_ > > .method should mean $_.method always. Making it into a runtime > error is extremely awkward; a compile-time error with detailed > explanataion is acceptable but suboptimal. > > 2. Topicalization of $?SELF > > Neutral on this -- I can argue bothways. in my limited experience > of writing p6 code, it is convenient but somewhat confusing > to topicalize the invocant. > > 3. Shorthand of $?SELF.method > > I find ./method to be very useful in practice, and my brain > gets use to it rather quickly. The association to pattern > matching and division gradually fades away, at which time > its novelty cease to be a problem. I have been watching perl6-language from afar and not really contributing. But I have to say that in this case I do agree with Autrijus Graham.
Re: Open and pipe
On May 4, 2005, at 8:13 AM, Uri Guttman wrote: AS> Why? Because IO::Socket.new takes parameters that are built out of its AS> entire inheritance tree, so a change to IO::Handle might radically AS> modify the signature of the constructor. makes sense. we should look at the p5 IO:: tree and see what we want to salvage/savage from it as well as io::all. each has its good and bad points and hopefully we can figure out which is which. :) Yes. p5 IO:: has evolved a bit over time and some things have turned out to be bad choices in hindsight. For example, one thing I am still not convinced was the right thing was to create a hierarchy such that a given class only had methods that were valid for it. For example the recent issue on p5p with seek etc not being in IO::Handle but IO::Seekable and the core using IO::Handle. Also the way IO::Socket::* was done instead of all sockets created by IO::Socket->new these are all things that should be reconsidered and I am sure in all cases there will be people on both sides of the fence Graham.
Re: use English
On Apr 27, 2005, at 6:39 AM, Aaron Sherman wrote: On Tue, 2005-04-26 at 10:48, Luke Palmer wrote: Aaron Sherman writes: The reasons I don't "use English" in P5: * Variable access is slower Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually they're the same: on each run a different one won, but just barely like this). Remember that I'm a Perl 3 programmer who has just gotten used to this "5" thing... ;-) I sometimes lose track of the ugly hacks that have been rationalized into workable practice over the versions. "use English" used to require an extra level of indirection in the implementation, but clearly no longer does. I don't have a perl older than 5.6.1 to test against, but this was probably back in the 5.002 or 5.003 timeframe. I'm guessing. It is also the fact that English.pm mentions $' and $` and that any mention of those variables flips a global switch inside perl which causes *every* regex with capturing parens to be slower. See http://search.cpan.org/~nwclark/perl-5.8.6/pod/perlvar.pod#BUGS Graham.
Re: [Devel::Cover] @INC at Runtime?
On 17 Sep 2004, at 15:48, Ricardo SIGNES wrote: * David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] So, what's to be lost by having the inc directories default to the contents of @INC when you load Devel::Cover rather than at install time? Presumably the problem is that by runtime, lib and blib directories are already in @INC, so the things in your ./distro/lib/ won't be covered, defeating the point. As to whether there is a simple way to resolve this, I haven't thought about it. You could use the values from Config.pm Graham.
Re: Return with no expression
On 24 Aug 2004, at 22:14, Aaron Sherman wrote:
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words -> $word {
given ($chars($word) > 70) -> $toolong {
say abbreviate($word) ?? $word;
}
}
But, I find:
for @words -> $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C<$_> as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C<$_> in the
general case now that we have that is kind of a step backwards.
But you are re-creating the same problem that we had in Perl 5.
By only allowing $_ to decide which expression to evaluate you are
prohibiting the use of anything that acts on the default topic of
the enclosing block in those expressions. This is exactly the problem
of nested maps etc. in Perl 5.
Don't get me wrong, I like the idea. But it does not come without its
own set of limitations.
Graham.
Re: The Pie-thon benchmark
On 24 Jun 2004, at 21:49, Piers Cawley wrote: Dan Sugalski wrote: it's not exactly exciting watching two people hit return three times in front of a roomful of people. Although watching two people hit each other in the face with custard pies three times in front of a roomful of people may be a lot more fun. Mutter. Mutter. Lack of bloody money. Mutter. Not coming to OSCON. Mutter. Hope someone videos it. Mutter. And sticks it on the web. Mutter. Likewise as I will not be at OSCON this year either. Graham.
Re: Testers & PASS
On Wed, 2003-08-13 at 17:20, Leon Brocard wrote: > Graham Barr sent the following bits through the ether: > > > > http://testers.cpan.org/search?request=dist&dist=MIME-Lite-HTML > > > keeps on timing out, so I don't know what it does. Graham? > > > > I just added a new index to the database. It should be much quicker now. > > Wow, that's like a 100x speedup. Can you speed up > http://testers.cpan.org/search?request=by-dist&letter=M too? ;-) Try now. It should be a little faster Graham.
Re: Testers & PASS
On Wed, 2003-08-13 at 19:06, Leon Brocard wrote: > Graham Barr sent the following bits through the ether: > > > > Now maybe I should ignore the version numbers and instead sort using > > > the dates that the module was uploaded to CPAN, but that's external > > > information, bah. > > > > That is what search does because guessing at peoples versioning was to > > unpredictable. However using upload dates is also problematic for some > > distributions (eg mod_perl and perl) > > It does? The order of the MIME-Lite-HTML page and the backpan dates > don't agree: > http://testers.cpan.org/search?request=dist&dist=MIME-Lite-HTML Oops. When I said search I meant search.cpan.org. I used to refer to search.cpan.org as s.c.o but those letters leave a bad taste these days :-) and I am too lazy to type search.cpan.org every time. Graham.
Re: Testers & PASS
On Wed, 2003-08-13 at 12:30, Leon Brocard wrote: > http://dellah.org/testers/MIME-Lite-HTML gets the version sorting > wrong but "right". How do you sort, Iain? > > http://testers.cpan.org/search?request=dist&dist=MIME-Lite-HTML > keeps on timing out, so I don't know what it does. Graham? I just added a new index to the database. It should be much quicker now. > Now maybe I should ignore the version numbers and instead sort using > the dates that the module was uploaded to CPAN, but that's external > information, bah. That is what search does because guessing at peoples versioning was to unpredictable. However using upload dates is also problematic for some distributions (eg mod_perl and perl) Graham.
Re: Testers & PASS
On Monday, Aug 4, 2003, at 08:15 US/Pacific, Leon Brocard wrote: alian sent the following bits through the ether: But there is a serious problem with CPAN test database. There is like 100 000 reports in the CPAN db. This is not a big problem. 100_000 reports is a very small database and I still don't know why the testers.cpan.org site is so slow. I got annoyed about it and wrote my own as it wasn't open source. It is much much faster. http://search.cpan.org/author/LBROCARD/CPAN-WWW-Testers/ http://testers.astray.com/ The source for the site has been available to anyone who asked for it. It is slow because it was written when testers first started and has never really been updated. If you want to redo the site then go ahead. It needs to be redone for performance and also to allow users to filter out reports they dont want to see. Graham.
Re: DoD ordering (was Re: Timely object destruction)
On Wed, Jun 04, 2003 at 11:05:34AM +0200, Leopold Toetsch wrote: > Graham Barr <[EMAIL PROTECTED]> wrote: > > > I ask becasue what happens if an object actually wants > > to use its contents during its DESTROY ? > > > For example Net::POP3::DESTROY will send a reset command to its > > server if the user did not call the quit method first. But how > > could it do this if the socket PMC was already freed ? > > PMCs which have their own resources have the active_destroy_FLAG set > (this is done during init/clone). Now when such an object is found > unreferenced during a DOD run, the destroy() vtable method is called for > this object. The object should now cleanup itself (close sockets, free > system memory, ...). Thereafter the object is put onto the free list. I may be missing something here. But within the resources of an object may be other PMCs. As those PMCs will not be referenced from anywhere else what is to stop the DoD run from freeing those before it freed the object ? Graham.
DoD ordering (was Re: Timely object destruction)
On Tue, Jun 03, 2003 at 07:24:04PM -0400, Benjamin Goldberg wrote:
> IIRC, DoD normally happens something vaguely like this:
>
>for my $p (@all_pmcs) {
> clear_is_live_flag($p);
>}
>our $traverse;
>sub set_is_live_flag($p) {
> if( !test_is_live_flag($p) and test_is_agregate($p) ) {
> $traverse = [$p, $traverse];
> }
> really_set_is_live_flag($p);
>}
>set_is_live_flag($_) for @rootset;
>while( $traverse ) {
> ((my $p), $traverse) = splice @$traverse;
> $p->set_live_flag_on_contained_objects();
>}
>for my $p (@all_pmcs) {
> next if test_is_live_flag($p);
> free_pmc($p);
>}
This is something that has concerned me for a while. But does DoD
ensure any kind of ordering for the destruction ?
I ask becasue what happens if an object actually wants
to use its contents during its DESTROY ?
For example Net::POP3::DESTROY will send a reset command to its
server if the user did not call the quit method first. But how
could it do this if the socket PMC was already freed ?
Graham.
Re: Multimethod dispatch?
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote: > What it seems you're wanting is it to be in the core. And I'm saying > that's irrelavent. There are thousands of great ideas out there, and > they can't all fit into Perl's core. That's why there's thousands of > modules on CPAN. Have you looked at the perl5 distribution lately :-) Graham.
Re: Objects and classes, try 3
On Sun, Mar 09, 2003 at 02:08:02PM -0500, Dan Sugalski wrote: > At 1:52 PM -0500 3/9/03, Uri Guttman wrote: > > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > > > > > DS> * Objects have properties you can fetch and store by name > > DS> * Objects have methods you can call > > DS> * Objects have attributes you can fetch > > > >and store > > Well... I'm not sure about that. Classes can store data in object > attributes, but there isn't necessarily a public API through the PMC > to do this. Basically if you can get to it through a PMC's vtable, it > was on the "Objects have" list. I'm not sure that storing into an > attribute should be easily doable from the outside. > > Methods have access to an object's internal bits, so the class > methods can poke into slots in the attribute array directly, which is > probably how they'll work. Surely thats a high-level restriction that Perl will impose. Why should Parrot impose that restriction ? Other languages may want to access attributes from outside the class. Graham.
Re: Objects, methods, attributes, properties, and other related frobnitzes
On Fri, Feb 21, 2003 at 04:34:42PM -0500, Dan Sugalski wrote: > If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a > method before we looked to see if B had a concrete instance of that > method. Right. The best you could probably do is note where you found the first AUTOLOAD so that when you do reach the end of the ISA search you don't need to do the whole search again. But is this programming for the common case ? or is it premature optimization. Graham.
Re: Objects, methods, attributes, properties, and other related frobnitzes
On Fri, Feb 07, 2003 at 09:39:14AM -0800, Dan Sugalski wrote: > It's a little more confusing that that. When I said only one foo > method, it was in contrast to attributes, where an attribute of a > particular name may appear in an object multiple times--since > attributes are class-private, each class in an object's inheritance > hierarchy can safely have an attribute named "foo". > > Methods and properties, being global, override each other--a child > class' foo overrides its parent's foo. If the child's foo has > multiple definitions based on signature, or we have foo that crosses > class lines, then the multiple dispatch logic comes online and does > its Weird Magic. > > Rereading that, it still doesn't make much sense, but there you go... :) Just to confuse things more, there is a question I have reguarding multi-methods and inheritance. Consider class A defines foo() as a multi-method with 3 different signatures If class B then sub-classes A and defines a method foo() does it 1 override all foo() methods in A 2 get added to the foo() methods in the dispatch, so we now have a multi-method with 4 signatures 3 override only the method in A that has the same signature My guess would be (1) and that multi-method distpatch would only happen if B called ->SUPER::foo In which case you could consider that there is only one method named foo(). That method does the dispatch to the others. Now I am probably not making sense :) Graham.
Re: [perl #20597] [PATCH] packfile #6
On Wed, Jan 29, 2003 at 03:41:33PM +, Nicholas Clark wrote: > On Wed, Jan 29, 2003 at 07:36:07AM -0800, Robert Spier wrote: > > > Also I can't work out how to search the list archive at develooper.com. > > > > Patches welcome. > > > > (Really. I have several archive management tasks that need to get > > done, and if anyone wants to volunteer) > > I'm quite happy to search the archives with google, providing I can > work out the correct special gizmos in the search string to limit it > to URLs down the correct path on the specific host. Just add site:archive.develooper.com to limit your seach to the archive site. I am not sure you can limit it to search only within a given path but if you include the list name it works well. Graham.
Re: L2R/R2L syntax
On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote: > > On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote: > > If the function form of map/grep were to be removed, which has been > > suggested, > > and the <~ form maps to methods. How would you go about defining a > > utility > > module similar to List::Util that uses the same syntax as map/grep but > > without making the subs methods on the global ARRAY package ? > > If you want the method to be available everywhere, But I don't > you probably > _should_ make it a method of the global Array class. Thats like trying to wite a whole perl5 application in main without any packages > More typically, > perhaps, you'd only be using your new method to operate on certain > arrays that you use, in which case you would make a new class for those > particular arrays, so your new method would work only on the specific > arrays you intended it to: Thats not always possible. Those Arrays may be passed to me from somewhere else, so I have no control over thier class. > I don't see any problem (other than maybe a philosophical objection) > with making them methods of Array, though, if they're valuable enough. > That certainly would seem the common Perl thing to do. No, namespaces were invented for a reason. Graham.
Re: L2R/R2L syntax
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
> > What benefit does C<< <~ >> bring to the language?
>
> Again, it provides not just a "null operator" between to calls, but
> rather a rewrite of method call syntax. So:
>
> map {...} <~ grep {...} <~ @boing;
>
> is not:
>
> map {...} grep {...} @boing;
>
> But rather:
>
> @boing.map({...}).grep({...});
This is not a for or against, but there is something that has been
bugging me about this.
Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util
If the function form of map/grep were to be removed, which has been suggested,
and the <~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
Graham.
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Mr. Nobody) writes: > > I have to wonder how many people actually like this syntax, and how many only > > say they do because it's Damian Conway who proposed it. And map/grep aren't > > "specialized syntax", you could do the same thing with a sub with a prototype > > of (&block, *@list). > > Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, > adding syntax for the sake of syntax, doesn't do anything for the readability > of code, and doesn't really actually gain very much anyway. That I will agree with to some extent. But mainly because I think that IF a pipe-like syntax is added then it should do just that, pipe. What has been proposed is not a pipe, unless each part gets converted to a co-routine and its arguments are really an interator that calls the previous stage to get the next argument. > But even so I dare say it'll go in because Damian likes it. That statement I dont agree with. Yes Larry has put a lot of trust in Damian, but that has not resulted in Damian always getting what he wants, just most of the time :-) Graham.
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: > For example, suppose I want to separate a list of people into people who > have never donated money and those who have. Assuming that each person > object has a donations property which is an array reference, I would want > to classify them in this manner: > > (@nevers, @donors) := classify($_->[donations]) @people; > > According to the C model, that would give me people who have donated > zero times, and people who have donated once, and the people who have > donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_->[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: Literals, take 2
On Mon, Nov 18, 2002 at 10:59:07AM -0800, Larry Wall wrote:
> On Thu, Nov 14, 2002 at 07:40:38PM +0100, Angel Faus wrote:
> : I would preferer to limit the usage of "letter notation" to just base
> : 11-36, and have n:F = n:f for every n.
> :
> : It is simpler, and we can always use de "dot notation" for bigger
> : bases.
>
> I'm thinking at the moment that I'd like to go back to the Ada notation
> and use # for the radix, and rather that using dots, use colons. So
> an IP address would actually look like
>
> 256#192:168:1:1
>
> (But only on a big-endian machine! Use v-strings instead!)
Why only on big-endian ? This is a just a number. To use it
as an IP address you would need to pack it with pack("N",256#192:168:1:1)
which should work on any endian machine. Or am I missing something
Graham.
Re: Numeric Literals (Summary)
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote: > Hmm, interesting. Just as an aside, this gives me an idea: would it be > feasible to allow the base to be specified as an expression instead of > a constant? (I'm pretty sure it would be useful.) For example: > > 4294967296:1.2.3.4 # working with a really big base, hard to grok > 2**32:1.2.3.4 # ah, much better > > 24*60*60:10 # one day in seconds, easy representation And the advantage of that over 24*60*60*10 would be ? > Or how about run-time evaluated versions? > > # Set a timer to run for either a day or an hour, depending > $timer = 60*60*($use_days ? 24 : 1):10 Then it is no longer a literal is it. Are we not just getting too carried away with all this base of literals. I also think -documentation is the wrong place to discuss this. Graham.
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: > Yesterday Aaron Crane wrote: > > > Jonathan Scott Duff writes: > > > > > @a `+ @b > > > > In my experience, many people actually don't get the backtick > > character at all. > > Yes. I think that might be a good reason _for_ using backtick in vector > operators: > A pair of backticks could be used if the vector-equals distinction is > required: > > @a `+`= @b; > @a `+=` @b; Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham.
Re: plaintive whine about 'for' syntax
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: > *shrug* You may not like the aesthetics, but my point still > stands: "is rw" is too long for something we're going to do fairly often. I am not so sure. If I look back through a lot of my code, there are more cases where I use the variable in a read-only fashion than I do for modifying the value. Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: > --- Larry Wall <[EMAIL PROTECTED]> wrote: > > > Do these French quotes come through? > > > > @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote: > unary (prefix) operators: > >\ - reference to >* - list flattening >? - force to bool context >! - force to bool context, negate >not - force to bool context, negate >+ - force to numeric context >- - force to numeric context, negate >+^- force to numeric context, complement >~ - force to string context >~^- force to string context, complement Noe that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. Graham.
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 03:30:54PM -0600, Jonathan Scott Duff wrote: > On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote: > > > > On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: > > > No. "unless" reads well in English. How do your read $a ! $b ! $c? > > > > "nor"? Maybe it's "$a nor $b"? > > oh no! You've said "nor", so now I have have to ask about "nand" ... > > and the next thing you know perl takes over the world of circuit > design. :-) Then dont forget full tristate logic too :) Graham.
Re: C# and Parrot
On Fri, Oct 18, 2002 at 05:54:08PM +0100, Leon Brocard wrote: > It looks like the DotGNU weekly IRC meeting will be discussing > Parrot. Could be interesting: > http://www.dotgnu.org/pipermail/developers/2002-October/008345.html The author of that mail needs to learn the difference between GMT and UTC Note: the times are UTC, not GMT. That is, they do not include daylight savings adjustments during the northern summer. If you have a Unix system, then the command "date; date -u" will give you your current time in both local and UTC, allowing you do determine when the next meeting will occur. GMT does not have daylight savings adjustments. Graham.
Re: Private contracts?
On Fri, Oct 11, 2002 at 05:50:55PM -0700, Larry Wall wrote: > On Sat, 5 Oct 2002, Allison Randal wrote: > : use Acme::N-1_0; # or whatever the format of the name is > > I don't see why it couldn't just be: > > use Acme::1.0; I agree thats better. But why not separate the version more by using a different separator than :: between the module name and the version. Or even something like use Acme[1.0]; > After all, we don't have package names starting with numbers right now... Er, we do. http://search.cpan.org?perldoc?Pod::Simple::31337 It would seem that (currently) only the top-level namespace may not start with a number. But I would also not that CPAN only has 3 such modules, all by the same author and all ::31337 Graham.
Re: [RFC] How are compound keys with a PerlHash intended to work?
On Wed, Sep 18, 2002 at 10:15:20AM +0200, Dan Sugalski wrote:
> I've been thinking that we do need to have an extra flag to note
> whether a key element should be taken as an array or hash lookup
> element. The integer 1 isn't quite enough, since someone may have
> done a %foo{1} and we only have that in as an integer key.
I agree. Using integer key == array and string key == hash is not
enough imo. What about a hash that is index by object, not a string.
What about an array that is index by strings ? ie
my @array is indexed('a'..'z');
So if parrot wants to provide a method for compound keys, then the
HL should be able to specify what type it is expecting each level
to be.
But the question also exists how this flag should be used/checked.
For example, does the op use it to test the PMC type before calling
the method to fetch the contents, or does it just pass it to the
method and let the PMC do what it wants with it.
I would suggest it gets passed to the method as an argument. That
would allow a PMC to be written that does not care how it is accessed.
But it would also allow the PMC class to do something different
depending on how it is accessed.
Graham.
Re: chr, ord etc
On Tue, Sep 10, 2002 at 06:01:23PM +0200, Peter Gibbs wrote: > Attached is a sample implementation of a minor subset of > pack/unpack functionality. Code is not optimised in any way, > and error checking is basically non-existent. > > Opcodes are: > convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz > convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz > > Currently supported types are: > 0 = 8-bit > 1 = 16-bit little-endian > 2 = 16-bit big-endian > 3 = 32-bit little-endian > 4 = 32-bit big-endian As well as supporting big/little endian specifically, should we support "native" ie packed in the same endian as the machine the code is being run on. Graham.
Re: auto deserialization
On Sat, Aug 31, 2002 at 01:52:18PM +, Damian Conway wrote:
> I'd suggest that redundancy in syntax is often a good thing and
> that there's nothing actually wrong with:
>
> my Date $date = Date.new('June 25, 2002');
I would say it is not always redundant to specify the type on both
sides
my Dog $dog = Greyhound.new('black');
> And, furthermore, that you could easily define special semantics
> for void-context constructor calls via undef'd but typed variables,
> so that you could just write:
>
> (my Date $date).new('June 25, 2002');
So that would be creating special case syntax for
a specific case of a general issue.
Graham.
Re: [perl #16690] Disable t/src under testj
On Wed, Aug 21, 2002 at 07:17:22AM -0700, Michael G Schwern wrote: > On Wed, Aug 21, 2002 at 02:11:29PM +, Daniel Grunblatt wrote: > > Apart from that, does anyone know why test doesn't run on OpenBSD? > > I get: > > > > ar: illegal option -- s > > Gnu-ism? What ar does OpenBSD use? Obviously and older version with less options http://www.openbsd.org/cgi-bin/man.cgi?query=ar >s Write an object-file index into the archive, or update >an existing one, even if no other change is made to >the archive. You may use this modifier flag either >with any operation, or alone. Running ar s on an >archive is equivalent to running ranlib on it. Perhaps we should be using ranlib instead of ar -s Graham.
Re: perl6-language@perl.org
On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
> This is a small collection of ideas for the Perl6 language. Think of this
> posting as a light and refreshing summer fruit salad, composed of three
> ideas to while away the time during this August lull in perl6-language.
>
>
>
> Give split an option to keep the delimiters in the returned array
>
> I often find that I want to split an expression, but I don't want to get rid
> of the delimiters. For example, I've been parsing a lot of SQL lately, and
> I find myself needing to split expressions like this:
>
>rank=?
>
> It would be really groovy if that expression could be split with the
> delimiters in place, something like this:
>
>@tokens = split _/[?=*-+]/, $sql, keep=>'all';
Try using
@tokens = split /([?=*-+])/, $sql;
> and get back an array with these values: ('rank', '=', '?')
>
> But that raises a problem: what if the expression is this (note the spaces):
>
>rank = ?
>
> In that case I would want the = and ? but I wouldn't want the spaces. A
> slightly different option could keep just stuff in parens:
>
>@tokens = split /\s*([?=*-+])\s*/, $sql, keep=>'parens';
@tokens = split /\s*([?=*-+])\s*/, $sql;
already does, in perl 5, what you want.
Graham.
Re: negative index in arrays
On Thu, Aug 01, 2002 at 05:42:12PM -0400, Dan Sugalski wrote: > At 10:24 PM +0100 8/1/02, Graham Barr wrote: > >On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote: > >> > It should pass them on to the PMC directly, which > >> > should then handle them properly. > >> > >> So, if ix < -SELF->cache.int_val then the code tries > >> to use a negative value to access the array element in > >> the C code. This is obviously wrong. My question is > >> should this raise an internal exception, or should > >> there be some DWIMery inside PerlArray.pmc. > > > >Well in perl today. > > > > print $a[-2]; > > > >just gives undef and @a is unchanged > > > > $a[-2] = 1; > > > >dies with > > > >Modification of non-creatable array value attempted, subscript -2 at > >-e line 1. > > > >But it seems to me that parrot has not concept of lvalue/rvalue use > >when fetching an element from an aggregate. > > Not with fetching, no. Hm, That may result in arrays being extended unnecessarily, which would also be a change in semantics, or array access for rvalues being multiple ops, checking the array length first. > The second example would be something like: > > set P0[-2], 1 > > in assembly. Right, which would raise an exception if the array had less than 2 elements. Graham.
Re: negative index in arrays
On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote: > > It should pass them on to the PMC directly, which > > should then handle them properly. > > So, if ix < -SELF->cache.int_val then the code tries > to use a negative value to access the array element in > the C code. This is obviously wrong. My question is > should this raise an internal exception, or should > there be some DWIMery inside PerlArray.pmc. Well in perl today. print $a[-2]; just gives undef and @a is unchanged $a[-2] = 1; dies with Modification of non-creatable array value attempted, subscript -2 at -e line 1. But it seems to me that parrot has not concept of lvalue/rvalue use when fetching an element from an aggregate. Graham.
Re: resize_array (PerlArray)
On Thu, Aug 01, 2002 at 03:42:19PM -0400, Dan Sugalski wrote: > At 5:28 PM +0200 8/1/02, Aldo Calpini wrote: > >fetching an element out of bound changes the > >length of the array. but should this really happen? > >why does perlarray.pmc act like this: > > Because that's the way Perl's arrays work. Joys of autovivification. Only if the element fetched is being used in an lvalue context. Just reading an array element will result in undef and no change to the array internals Graham.
Re: I'm back...
On Tue, Jul 30, 2002 at 11:08:46AM -0700, Sean O'Rourke wrote: > On Tue, 30 Jul 2002, Dan Sugalski wrote: > > I need to get Larry to nail some things down. On the one hand, he's > > said that chained comparisons evaluate their parameters just once. > > That argues for moving the values to N or S registers. > > I read that as "expressions are evaluated once", not "PMC's are accessed > once". That was my understanding too. Graham.
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > > > languages/perl6/README sort of hides it, but it does say that "If you have > > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > > that to "if you have < 5.6, you lose". > > I notice that DBI no longer supports Perl releases <5.6. Seems enough > people are happy that 5.005 is obsolete. I am not sure I agree with that. I have been met with a lot of resistance from users todo the same with my modules. Some even still want 5.004, but thats asking too much IMO. Graham.
Re: Copy-on-write strings
On Fri, May 10, 2002 at 12:12:41PM -0400, Dan Sugalski wrote: > At 5:38 PM +0200 5/10/02, Peter Gibbs wrote: > >The result is that the last header of a COWed string will still believe that > >the buffer is shared until a GC collection run occurs, and therefore could > >result in buffers being copied unnecessarily. Your system eliminates this > >problem; however, I believe that Dan may be averse to using a linked list - > >we'll see. > > As long as there's no externally visible signs of the COW stuff, I > don't care as long as the code's commented well enough to be > maintained. I'd prefer commits of the code to be done only when > there's a demonstrable win to the committed code, though. (Which is > to say "No checking in code that slows things down") > > If you want to take an intermediate step, it's fine to mark > substrings that don't start at the beginning of a buffer with an > extra flag of some sort (BUFFER_COW_substring_FLAG or something) that > caused the GC system to make a clean copy when it ran through the > buffer pool and collected, though that has issues of properly gaguing > how much memory's needed for the new pool. One of the performce benefits in perl is that it holds a pointer to the start of the buffer and an offset to the statr of the string data. This is a great benefit when trimming the start off strings. Why would parrot not need this ? And if it did, could you not use it for COW substrings ? Graham. [You has a lot of catching up todo]
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
> On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
> >
> > LAST Executes on implicit loop exit or call to last()
> > Loop variables may be unknown
>
> Not exactly "unknown". It's just that, in a few cases, their values may
> have changed by the time the LAST block is executed.
OK, unspecified.
>
> > And I think this thread is proposing
> >
> > FIRST A PRE block that is executed only on the first itteration
> > of the loop
> >
> > BETWEEN A PRE block that does not execute for the first iteration
> > of the loop.
> >
> > So FIRST and BETWEEN are just shorthand for
> >
> > my $count;
> > loop {
> >PRE {
> > if ($count++) {
> ># BETWEEN code here
> > }
> > else {
> ># FIRST code here
> > }
> >}
> > }
>
> Almost. What people are pushing for is more like:
>
> BETWEEN A NEXT block that does not execute for the last iteration
>of the loop.
IMO, it cannot. That is because you cannot always know if you are at
the end of a loop until you have executed the condition. Therefore BETWEEN
would have to be a PRE block.
> This may seem like a trivial difference at first glance, but it's a
> matter of scope. The latter interpretation means that code such as:
>
> for 1..3 -> $thing {
> print $thing _ ", ";
>
> BETWEEN {
> print $thing _ "\n";
> }
> }
>
> Will output:
> 1, 1
> 2, 2
> 3,
>
> Not:
> 1, 2
> 2, 3
> 3,
But consider when this is a while loop, how do you stop BETWEEN being
called before the last iteration.
> Which seems intuitively right.
Not to me :-)
Graham.
FIRST, BETWEEN, etc.. (was Re: Loop controls)
I have been following this thread, but I would just like to inject a summary
of the various related UPPERCASE blocks
PREExecutes on block entry.
Loop variables are in a known state
POST Executes on block exit.
Loop variables are in a known state
NEXT Executes on implicit block exit or call to next()
Loop variables are in a known state
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
And I think this thread is proposing
FIRST A PRE block that is executed only on the first itteration
of the loop
BETWEEN A PRE block that does not execute for the first iteration
of the loop.
So FIRST and BETWEEN are just shorthand for
my $count;
loop {
PRE {
if ($count++) {
# BETWEEN code here
}
else {
# FIRST code here
}
}
}
Graham.
Re: // in Perl 5.8?
On Wed, May 01, 2002 at 01:53:24PM -0700, Brent Dax wrote: > Graham Barr: > # On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote: > # > On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > # > > # > > It's far too late to make it into 5.8, but it looks like > # it'll be in > # > > 5.10 when that comes out (in a year or two). > # > > # > I figured. Too bad. ;-) A year or two is long time to wait! > # > # Well if the patch maintains binary compatability, I dont > # see why it would not go into 5.8.1. But who knows when that will be. > > I thought they don't introduce new features in point releases... Who is they ? I am sure I did in 5.005_03 and I think 5.6.1 did also. Graham.
Re: // in Perl 5.8?
On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote: > On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > > > It's far too late to make it into 5.8, but it looks like it'll be in > > 5.10 when that comes out (in a year or two). > > I figured. Too bad. ;-) A year or two is long time to wait! Well if the patch maintains binary compatability, I dont see why it would not go into 5.8.1. But who knows when that will be. Graham.
Re: // in Perl 5.8?
On Wed, Apr 17, 2002 at 01:09:43PM -0700, David Wheeler wrote: > Anyone know what the chances are that some enterprising C hacker > can/will/did get the // and //= operator into Perl 5.8? Seems like it > wouldn't be a huge deal to add, and I'd love to have it sooner rather than > later. It is not hard todo. If you look in the archives you can probably find it, although it will be there as ?? The problem with // is that it already has a meaning and although perl6 will redefine it can we do so in perl5 ? I don't think we can. Graham.
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
> Trey Harris <[EMAIL PROTECTED]> writes:
>
> > I think I've missed something, even after poring over the archives for
> > some hours looking for the answer. How does one write defaulting
> > subroutines a la builtins like print() and chomp()? Assume the code:
> >
> > for <> {
> > printRec;
> > }
> > printRec "Done!";
> >
> > sub printRec {
> > chomp;
> > print ":$_:\n";
> > }
>
> You could take advantage of subroutine signatures and multi-dispatch
>
> sub printRec() { printRec($_) } # No args, therefore no new topic.
> sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Graham.
Re: Unary dot
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2; # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class method with no invocant? If the former, how would you
> do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
Graham.
Re: PMCs, setting, and suchlike things
On Thu, Feb 14, 2002 at 02:10:20PM +, Dave Mitchell wrote: > 2. If so, how do we distinguish between two PMCs, both of whose > vtable pointers currently point to the 'Dog' vtable, but one of whom has > been delared as type Dog and so should never have it's vatble pointer > updated, and the other which started off as a 'plain' PMC, has temporariky > becomes a Dog by beeing assigned to from a Dog value, but will change > again the next time we assign something to it? I may be way off here, but why does Parrot need to know its a Dog ? Thats a perl level thing. To Parrot the PMC is an object, Dog would be a property of the value, not the variable. At the Parrot level the difference between my Dog $spot = new Dog; my $scalar = new Dog; is that the prior would have an extra vtable entry to handle assignment. That vtable method only needs to check that what is being assigned is a PMC of the right type. Graham.
Re: parrot rx engine
On Thu, Jan 31, 2002 at 11:18:58AM -0800, Hong Zhang wrote: > > Because parts of an rx can be case-insensitive while other parts > > are case-sensitive, we will probably need two sorts of ops anyway > > (or a way to tell the op to be case-insensitive). And you will > > only be able to do the case folding when the whole rx is > > case-insensitive. > > I don't like your suggestion. I think we should have one set of > ops, but two input strings: one is the original, the other is case- > folded. Rx chooses the right one depending on the current > case-sensitivity. 2 regex opcodes will be used for this purpose, > op-case-sensitive-start and op-case-insensitive-start. The opcode > will switch strings begins, ends, positions etc. > > > It also means creating a copy of the input string, which is something > > the current rx engine in perl5 tries to avoid. And while I will agree > > that it is often faster todo lc($str) =~ /.../ than $str =~ /.../i > > that is normally only the case for small-ish strings. > > I don't think the perl5 approach is the best choice. Unicode case folding > is much much more expensive than malloc/free. And we can always use > per-thread free list, unless the regex is nested or the string is very > big, we don't need to allocate any memory. But as you say, case folding is expensive. And with this approach you are going to case-fold every string that is matched against an rx that has some part of it that is case-insensitive. The case-folding should be done in the rx itself, at compile time if possible. Then it is only done once, which will save a lot of time if the rx happens to be used in a loop or something. Graham.
Re: parrot rx engine
On Thu, Jan 31, 2002 at 08:54:21AM -0800, Brent Dax wrote: > Peter Haworth: > # On Wed, 30 Jan 2002 17:45:58 +, Graham Barr wrote: > # > On Wed, Jan 30, 2002 at 09:32:49AM -0800, Brent Dax wrote: > # > > # rx_setprops P0, "i", 2 > # > > # branch $start0 > # > > # $advance: > # > > # rx_advance P0, $fail > # > > # $start0: > # > > # rx_literal P0, "a", $advance > # > > # > # > > # First, we set the rx engine to case-insensitive. Why is > # that bad? It's > # > > # setting a runtime property for what should be compile-time > # > > # unicode-character-kung-fu. Assuming your "CPU" knows > # what the gritty > # > > # details of unicode in the first place just feels wrong, > # but I digress. > # > > > # > > That "i" does a once-off case-folding operation on the > # target string. > # > > All other input to the engine MUST already be case-folded > # for speed. > # > > # > Hm, is that going to work ? What about a rx like > # /^a(?i:b)C/ where the > # > case insensitivity only applies to part of the pattern ? > # > # Or worse, in /^a(b)c/i, where you want to capture the > # original character, > # not the case-folded version? > > Parentheses just record a pair of indices, not a string. Yes, I was assuming that. However what is to be gained by case folding the input string ? Because parts of an rx can be case-insensitive while other parts are case-sensitive, we will probably need two sorts of ops anyway (or a way to tell the op to be case-insensitive). And you will only be able to do the case folding when the whole rx is case-insensitive. It also means creating a copy of the input string, which is something the current rx engine in perl5 tries to avoid. And while I will agree that it is often faster todo lc($str) =~ /.../ than $str =~ /.../i that is normally only the case for small-ish strings. Graham.
Re: parrot rx engine
On Wed, Jan 30, 2002 at 09:32:49AM -0800, Brent Dax wrote: > # rx_setprops P0, "i", 2 > # branch $start0 > # $advance: > # rx_advance P0, $fail > # $start0: > # rx_literal P0, "a", $advance > # > # First, we set the rx engine to case-insensitive. Why is that bad? It's > # setting a runtime property for what should be compile-time > # unicode-character-kung-fu. Assuming your "CPU" knows what the gritty > # details of unicode in the first place just feels wrong, but I digress. > > That "i" does a once-off case-folding operation on the target string. > All other input to the engine MUST already be case-folded for speed. Hm, is that going to work ? What about a rx like /^a(?i:b)C/ where the case insensitivity only applies to part of the pattern ? > # Mostly, I'd like to hear how either Unicode character-ranges aren't > # deterministic at compile-time (I doubt that) or how crippling to > > One word: locale. How did I know you would say that :) Graham.
Re: Some Apocalypse 4 exception handling questions.
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote: > I think you just said the same thing I did. To be more explicit, using > the terminology you seem to want to use, I'll point out that I was only > talking about the case of an inherited method, not a _replacement_ > method. In other words, when you inherit a method, you are taking the > base implementation for that method. But if you replace a method, you > are not inheriting that method, but rather replacing it; yes, the > replacement method may choose to call the base implementation's method > as part of the replacement implementation. When you replace a method, > you have 2 subroutines, the base implementation, and the replacement > implementation, but when you inherit a method, you have only 1 > subroutine, which may be called 2 different ways. But the base class may be just an interface class. And thus by inheriting the pre conditions you are enforcing the API. So I can see a use for it, but I can also see where you don't want it too. Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 01:38:39PM -0800, Larry Wall wrote:
> Graham Barr writes:
> : On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
> : > Graham Barr writes:
> : > : But are we not at risk of introducing another form of
> : > :
> : > : my $x if 0;
> : > :
> : > : with
> : > :
> : > : if my $one = {
> : > : ...
> : > : }
> : > : elsif my $two = {
> : > : }
> : > :
> : > : if ($two) {
> : > : ...
> : > : }
> : >
> : > Then it's just undefined. It's no different from how &&, ||, or ??::
> : > work when you put a declaration in something that's conditionalized.
> :
> : Right. So we need to make sure that the implementation does that. In Perl5
> : my has a runtime part, so if it is not actually run then the lexical
> : can hold the value of the previous time it was executed.
>
> Well, true enough. Perhaps "undefined" is too meaningful. We could
> borrow a phrase from Ada culture and just call it "erroneous".
Either that, or instead of my having a runtime element, we just initialize
all lexicals at the start of the block in which they are declared. So the
initialize step is not controlled by runtime effects.
I guess whether or not this (bug?) arises again depends on how parrot
implements lexicals.
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
> Graham Barr writes:
> : But are we not at risk of introducing another form of
> :
> : my $x if 0;
> :
> : with
> :
> : if my $one = {
> : ...
> : }
> : elsif my $two = {
> : }
> :
> : if ($two) {
> : ...
> : }
>
> Then it's just undefined. It's no different from how &&, ||, or ??::
> work when you put a declaration in something that's conditionalized.
Right. So we need to make sure that the implementation does that. In Perl5
my has a runtime part, so if it is not actually run then the lexical
can hold the value of the previous time it was executed.
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
> On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
> > Casey wrote:
> >
> > > So you're suggesting that we fake lexical scoping? That sounds more
> > > icky than sticking to true lexical scoping. A block dictates scope,
> > > not before and not after. I don't see ickyness about making that so.
> >
> > Exactly!
> >
> > What we're cleaning up is the ickiness of having things declared outside
> > the braces be lexical to the braces. *That's* hard to explain to beginners.
>
> In this case I'll take long-term simplicity over short-term
> easy-to-explain rules. Otherwise we'll be writing this all over the
> place til Kingdom come.
>
> do {
> if my $foo = bar() {
> ...
> }
> }
If that is what you want then fine. But I have lost count of the number
of times I have wanted to do
if ((my $foo = bar()) eq 'foo') {
...
}
if ($foo eq 'bar') {
...
}
Personally I really don't see it as a problem.
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
> : What's the chance that it could be considered so?
>
> In most other languages, you wouldn't even have the opportunity to put
> a declaration into the conditional. You'd have to say something like:
>
> my $line = <$in>;
> if $line ne "" { ... }
>
> Since
>
> if my $line = <$in> { ... }
>
> is Perl shorthand for those two lines, I don't see how one can say that
> the variable is more related to the inside than the outside of the block.
> One can claim that the code after the C may not be interested in
> C<$line>, but the same is true of the block itself! The conditional
> only decides whether the block runs. It's not part of the block.
But are we not at risk of introducing another form of
my $x if 0;
with
if my $one = {
...
}
elsif my $two = {
}
if ($two) {
...
}
Graham.
Re: [A-Z]+\s*\{
On Sun, Jan 20, 2002 at 05:29:39AM -0800, Damian Conway wrote: > On Saturday 19 January 2002 22:05, Brent Dax wrote: > > > Is this list of special blocks complete and correct? > > Close and close. As of two days ago, Larry's thinking was: > > BEGIN Executes at the beginning of compilation > CHECK Executes at the end of compilation > INITExecutes at the beginning of run > END Executes at the end of run > PRE Executes at block entry. > Inherited if block is a method. No side-effects >allowed. > POSTExecutes at block exit. > Inherited if block is a method. No side-effects >allowed. > NEXTExecutes on (explicit or implicit) call to next() > within current block If a POST is inside a loop, is it executed at the end of each iteration or only when the loop exits ? If it is only when the loop exits, will it be possible to designate a block to be multiple (eg both POST and NEXT) Graham. > CATCH Executes on exception within current block > LASTExecutes on any form of block exit. > Not inherited (c.f. POST), even if block is a method. > Side-effects allowed. > KEEPSpecialized form of CATCH. > Executes on "control" exception in the current block > UNDOSpecialized form of CATCH. > Executes on non-"control" exception in the current >block > > Damian > >
Re: on parrot strings
I belive IBM use inversion lists in thier ICU library for sets of unicode characters. Graham. On Sat, Jan 19, 2002 at 07:08:25PM +0200, Jarkko Hietaniemi wrote: > Honour where honour is due: I've got some questions about inversion > lists. Where I saw them mentioned by that name were some drafts of > this: > > http://www.aw.com/catalog/academic/product/1,4096,0201700522,00.html > > The book looks really promising-- unfortunately it's not yet published. > > -- > $jhi++; # http://www.iki.fi/jhi/ > # There is this special biologist word we use for 'stable'. > # It is 'dead'. -- Jack Cohen
Re: Some random design notes
On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote: > ># Attributes are done as a hash of hashes. Each interpreter has a > ># pointer to an attribute hash, whose keys are the attribute names. The > ># values will be hash pointers. Those hashes will each have a key which > ># is a PMC pointer (hashed up somehow) and the value is the attribute > ># value. > > > >If you're talking about 'is'-style attributes, why not have them be > >attached to the PMCs themselves? > > D'you want an attribute pointer for each PMC? (I've considered it, but for > the moment I think it'll be too expensive. Might be wrong) On the other hand when a variable is garbage collected you have to walk the hash of hashes to clear out the attributes. Also what happens when you move the PMC during garbage collection, will the key in the hash change ? A PMC may have a flag to show if it has any entries in the global table, but it is probably just a trade off between space and performance. Graham.
Re: Apropos of nothing...
On Fri, Dec 14, 2001 at 06:39:02AM +1100, Damian Conway wrote: > >> In the following code fragment, what context is foo() in? >> >> @ary[0] = foo() > > Scalar context. @ary[0] is a single element of @ary. > > To call foo() in list context use any of the following: > > (@ary[0]) = foo(); # Assign @ary[0] the first element returned > @(@ary[0]) = foo(); # " " "" " " > @ary[@(0)] = foo(); # " " "" " " > @ary[0,] = foo(); # " " "" " " > @ary[[0]] = foo(); # " " "" " " > > @ary[0] = @(foo()); # Assign @ary[0] a ref to the elems returned > @ary[0] =()= foo(); # " " " " " "" " Hm, thats a change from perl5. In perl5 that would assign the number of elements returned from foo(). Is there a good reason for this change ? Graham. > @ary[0] = [foo()]; # " " " " " "" " > > Damian
Re: flex perl mess
On Wed, Oct 24, 2001 at 09:06:14AM -0400, Aaron Sherman wrote:
> On Tue, Oct 23, 2001 at 02:53:19PM +0200, Nadim Khemir wrote:
>
> > > Don't we already have that in Perl 5?
> > >
> > > if ( /\G\s+/gc ) {# whitespaces }
> > >elsif ( /\G[*/+-]/gc ) { # operator }
> > >elsif ( /\G\d+/gc ) {# term }
> > >elsif ( /\G.+/gc ) { # unrecognized token }
> > >
> > > Tad McClellan
> >
> > The answer is NO, regexes and a lexer are totally different. I would
> > recommend Tad to study a bit more what parsing is before thinking it's jut
> > about writing regexes. Having a lexer allows perl do some kind of text
> > processing (raw lexing and parsing) at a much faster. If it is of some
> > interest I could benchmark a simple example.
>
> So, aren't you saying, "yes, but it would be slow"? I can't think of
> anything a lexer is capable of that I can't (and probably haven't) done
> in Perl with relative ease.
>
> Now, if you want a PARSER, that's a different matter, but a simple
> lexical scanner is trivial to write in Perl with logic and regular
> expressions.
>
> In terms of speed, this is particularly ideal because you can identify
> what parts of your Perl code slow the lexer down, and re-code those
> using C/XS. The best of all 2,384 worlds... that's Perl!
I have always found that the perl output from byacc (with a few tweaks)
generates a sufficient parser. The addition of a switch statement
will hopefully make it more efficient.
For a lexer I try to use a single regex with /g, but that does require the
text being parsed to be all in a single scalar. Although that could be
worked around if needed.
For an example, take a look at Convert::ASN1
Graham.
Re: An overview of the Parrot interpreter
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > Can you see any use of a sub knowing it was called via a method call?
> >
> >So that attributes which cause code to be executed before or after a
> >subroutine implementation's execution might behave differently depending on
> >whether the sub were executed as a function or a method?
>
> Okay. I'll see about finding a spot to squirrel away call type somewhere.
Hm, interesting. Is this a method or function call ?
$ref = $obj.can('foo');
$ref.($obj);
Graham.
Re: explicitly declare closures???
On Tue, Aug 21, 2001 at 09:21:35AM -0400, Eric Roode wrote: > John Porter wrote: > > > >Dave Mitchell wrote: > >> ie by default lexicals are only in scope in their own sub, not within > >> nested subs - and you have to explicitly 'import' them to use them. > > > >No. People who write closures know what they're doing. > > > >When's the last time someone "accidentally" wrote a closure? > > People using mod_perl do it all the time: > http://www.perlreference.com/mod_perl/guide/obvious.html > > I don't agree with the original proposal, since 'use diagnostics' > will tell you about closures -- but people DO create closures by > mistake, and it can be a very difficult bug to trace if you aren't > used to closures. You are refering only to one type of closure, nested subroutines. And if people make these by mistake then perl will tell them with a warning like Variable "$x" will not stay shared Graham.
Re: Perl 6 modules plan
On Mon, Aug 13, 2001 at 04:38:43PM -0700, Nathan Wiger wrote:
> And allow flexible calling styles. For example, you might say:
>
># import args() for argument validation
>use Module::Interface qw/args/;
>
>sub my_func (@) {
>my %args = args({ positional => [qw/name email phone/] }, @_);
>}
>
> Which would allow you to call your function two different ways:
>
>my_func($name, $email, $phone);
>my_func(name => $name, email => $email, phone => $phone);
This is the king of thing that CGI does, and IMO is exactly what we don't want.
There should be ONE calling style for each sub/method. Allowing this _will_
cause different people to use different calling styles and also possible
confusion.
Graham.
Re: Perl 6 modules plan
On Sat, Aug 11, 2001 at 03:51:22PM -0400, Kirrily Robert wrote: > [ moving to perl6-stdlib only; -meta doesn't need this. ] > > Jarkko wrote: > >> Sys:: should be declared redundant and silly. Sys::Syslog simply > >> hurts my teeth. > > > >Text:: is another silliness, though from for slightly different > >reasons. The problem with Text:: is that it awfully vague, and thusly > >carries almost no information. > > Yup, to both points. > > While we're at it, I think that ExtUtils:: really needs renaming. > Nobody talks about "Perl extensions", they talk about modules. Or > possibly just about Perl. I actually think the stuff in ExtUtils would > be better off in Devel:: with the other developer tools. While you are at it you should consider redoing the APIs etc. so that they match. ie some consistency between method names and variable names, calling conventions etc... Also the PODs should be all written in the same style. Very early on in the perl6 process I did some analysis of the current standard library and it is surprising how inconsistent it is. With perl6 being distributed with very few modules and SDKs it should open the doors for us to do this. That is have one SDK that is 100% compatible with the perl5 library, but another which is considered better (or more consistent) IMO with a more consistent library more companies are likely to give perl a closer look. The way things are now I think perl suffers because it does not present itself as a single product, but an app with a lot of libraries thrown around it. Graham.
Re: Perl 6 modules plan
On Sat, Aug 11, 2001 at 07:20:11PM -0400, [EMAIL PROTECTED] wrote: > On Sat, Aug 11, 2001 at 02:16:49PM -0500, Jarkko Hietaniemi wrote: > > One silliness is that the implementation "style" of the module > > seems to creep to the naming: > > > > (1) Foo vs Foo_XS > > Well then, how do you name it? For example, Text::CSV. There's a > pure perl implementation and an XS implementation. If they're both in > the same tarball, it should probably be Text::CVS::Perl and > Text::CVS::XS with Text::CSV acting as a little wrapper to choose > which one. Simple enough. > Why do they need to be named differently ? Only one will be installed. I did this with the Scalar-List-Utils distribution. It contained both a perl implementation and an XS implementation. But decided which to install at build time. Graham.
Re: PDD 4, version 1.2.
On Tue, Jul 03, 2001 at 10:15:02AM -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> We're going to use a copying collector. When the string gets > DS> copied as part of a compaction run things'll get cleaned up > DS> appropriately. (Not that there's really any cleanup to do in that > DS> case) Granted the destination string buffer will only be as big as > DS> the source buffer 'really' is (which is to say the amount of > DS> memory actually in the string plus the extra bit at the end, if > DS> there is any) but that's fine. > > ok. i didn't realize the GC design was that far along. IIRC copying > collectors need to have double the used space at all times to make a > copy. is that ram tradeoff for speed? again IIRC copying is much simpler > than mark/sweep but the ram does cost. Ouch. I have quite often had applications that would use several hundred MB now. If I would need double that, then that is going to hurt. I am not familiar with copying collector GC, does anyone have a pointer to any papers etc. Graham.
Re: PDD 4, version 1.2.
On Mon, Jul 02, 2001 at 04:12:31PM -0400, Dan Sugalski wrote: > At 09:07 PM 7/2/2001 +0100, Graham Barr wrote: > >On Mon, Jul 02, 2001 at 03:52:34PM -0400, Dan Sugalski wrote: > > > At 08:36 PM 7/2/2001 +0100, Simon Cozens wrote: > > > >On Mon, Jul 02, 2001 at 03:00:54PM -0400, Dan Sugalski wrote: > > > > > >what about starting offset? that is used now to shorten a string from > > > > > >the left side. > > > > > > > > > > D'oh! In. Out goes the unused. > > > > > > > >Whoa there. Do we still actually want to do this? It's unclear whether > > > >or not it's actually a net win. > > > > > > A valid point. It doesn't seem to be used at all often, but it's always > > > tough to equate frequency of appearance to frequency of usage. > > > >I for one use s/^...// quite often in the knowledge that it is optimized to > >just move a pointer and not cause a copy of the string. > > We'll still be doing that. Then I misread the mails, ignore me. > (The leftover memory will get cleaned up when we > GC) The bigger issue is when we need to move the pointer back because we've > stuck something back on the front of the string. Surly the buffer holding the string would just be a malloc'd buffer and not GC'd (I was assuming GC would only be for the PMC) In which case you need to remember the start of the buffer for free. But if the string buffer is to also be GC'd then I would agree that there is little benefit from trying to reuse memory at the front of the buffer. Graham.
Re: PDD 4, version 1.2.
On Mon, Jul 02, 2001 at 03:52:34PM -0400, Dan Sugalski wrote: > At 08:36 PM 7/2/2001 +0100, Simon Cozens wrote: > >On Mon, Jul 02, 2001 at 03:00:54PM -0400, Dan Sugalski wrote: > > > >what about starting offset? that is used now to shorten a string from > > > >the left side. > > > > > > D'oh! In. Out goes the unused. > > > >Whoa there. Do we still actually want to do this? It's unclear whether > >or not it's actually a net win. > > A valid point. It doesn't seem to be used at all often, but it's always > tough to equate frequency of appearance to frequency of usage. I for one use s/^...// quite often in the knowledge that it is optimized to just move a pointer and not cause a copy of the string. Graham.
Re: Per-object inheritance in core a red herring?
On Fri, Jun 29, 2001 at 08:59:59AM -0400, John Porter wrote: > Michael G Schwern wrote: > > Second, and perhaps more importantly, we can do this perfectly well > > with a module. No hacks, no tricks, no filters. > > Class::Object uses the mini-class technique (ie. auto-generated > > classes > > Sorry, that sounds like a hack/trick if ever there was one. > I would sure hope there would be a cleaner way to do it in > perl6, if it's not part of the core language. Maybe, but I think it is the way to do it, even if it is behind the scenes. My reason for that is method lookup. Right now we use the package (class) stash as a cache so we don't have to search @ISA for every method call. But if there is a case where not all objects that inherit from a given class have the same superclasses, you cannot do this. This means that we will either burn a lot more memory for the caches or method lookup will take longer. > It's also not without its faults. Having every instance of a > class have different values of ref() could be obnoxious, for > example. That could be preserved by the object holding a pointer to it's blessed stash and its method stash, which for the most case will be the same. Graham.
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
On Thu, Jun 21, 2001 at 01:41:28PM -0700, Nathan Wiger wrote: > * Simon Cozens <[EMAIL PROTECTED]> [06/14/2001 15:16]: > > > > OK, I've been teasing people about this for weeks, and it's time to stop. > > This is the current state of the Perl 6 emulator; it applies most things > > that Damian talked about in his keynote yesterday, and most of the things > > I've picked up in perl6-language. It does: > > > > $a ~ $b for concat > > ^ $afor negation > > I just want to briefly register a formal complaint that I do not like > this, and I suspect I'm not the only one. I just think many have stopped > trying to fight it out of exhaustion. I agree too, for many of the same reasons. And I am sure that Larry knows many share your thoughts. We can have a huge thread, just like before, but until we see any kind of update from Larry as to if he has changed his mind it is all a bit pointless. > I don't like ~ for binary concat. For one thing, it means that the > equivalent of .= is now: > >$a ~= $b > > Does anyone else see a problem with =~ ? Plus, it makes the > pre-plus-concat that many desire impossible, since =~ is taken. Yes, I am sure that will lead to a lot of confusion. You will always have to look twice when reading someones code. > Second, even if ~ *is* used for concat, then I *still* don't think that > ~ should be changed from unary negation. There's no reason for it. Every > other major modern language I can think of uses ~ for unary negation. An > operator can change its meaning based on context, just consider <<. << ? I would have thought - would be a better example Graham.
Re: Coupla Questions
On Mon, Jun 11, 2001 at 10:39:51PM -0500, David L. Nicol wrote:
> Hopefully, we'll get a "with" operator and everything:
>
> with %database.$accountnumber {
>
> .interestearned += $interestrate * .balance
>
> }
>
> anything short of that, in my opinion, is merely trading old ugly for
> new ugly.
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
In which case you could do
for (%database.$accountnumber) {
.interestearned += $interestrate * .balance
}
Graham.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:42:53PM +0100, Simon Cozens wrote: > On Mon, Jun 11, 2001 at 01:31:36PM +0100, Graham Barr wrote: > > On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: > > >$input = 4; > > >$bool = $input < 22;# $bool = 1 is valueR(22) > > >print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR > > > > Well perhaps $input < 22 should yield 22 is true > > Or perhaps you should have said "my bit $bool;" :) Um, perhaps I was no clear. I meant $bool to get 22, which now I read goes against the previous message :) But if < returns RHS is true when the LHS is less than the RHS you can do 6 < $var < 10 as long as precedence means that is (6 < $var) < 10 and perl uses the truth to determine when to stop as this would expand to (6 < $var) and ($var < 10) And of course if it actually returned LHS is false when the LHS is greater, then $c = max($a,$b) is simply $c = $a < $b Graham.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: > > For the record, bwarnock pointed out to me that damian allready proposed > this behavior in RFC 25... > > http://dev.perl.org/rfc/25.html > > That RFC doesn't suggest having the comparison operators set properties > on their result -- instead it recomends that "multiple chained comparisons > should be automagically expanded to the equivalent binary conjunction." > ... I think I like his way better. Mainly because I didn't consider the > ramifications of scenerios like this... > >$input = 4; >$bool = $input < 22;# $bool = 1 is valueR(22) >print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR Well perhaps $input < 22 should yield 22 is true Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
> On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> > Damian Conway wrote:
> > > $ref.{a}can be $ref{a}
> > which can also be
> > $ref.a
>
> Dereferencing a hashref is the same as accessing a property?
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like
sub a(Foo $self) :lvalue { $self->{a} }
(Did I get that syntax right ? probably not :)
Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote: > On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: > > Can someone post a few ? I am open to what are the pros/cons > > but right now my mind is thinking " Whats the benefit of making > > $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something > > different, ie what it does in perl5" > > A reason against making the behaviours ($foo=array vs. $foo=list) > different would be that you're then making lists and arrays more > distinct than necessary. Does this make $foo a reference, or the number > of elements: But if you change () consider, how do you do $min = (localtime(time))[1]; and if () creates a reference what does $x = (1 + 2) * 3; it's still () in a scalar context. IIRC when Larry covered this, he did not suggest changing (), but changing the meaning of the , in the scalar context. () is a grouping contruct, not a list generator. Graham.
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > :> What should $foo = (1,2,3) do now? Should it be the same as what > :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what > :> $foo = \@INC; does now.) Putting it another way: does a list in scalar > :> context turn into a reference, or is it just arrays that do that? > : > : Just arrays, I believe. > > That hasn't actually been decided yet. There are good arguments on > both sides. Can someone post a few ? I am open to what are the pros/cons but right now my mind is thinking " Whats the benefit of making $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something different, ie what it does in perl5" Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: >> But with the above you still have abiguity, for example what does this do >> >> $bar =~ /$foo.colour($xyz)/; > > "Looks like a method call with parens, so *is* a method call with parens." > > >> I may be remembering about interpolation into strings as "$file.ext" is >> going to be common. But I do think the $() approach is clean and >> unambiguous > > I agree wholeheartedly. Good. > But it's not as *convenient* as "unadorned" interpolation. Sometimes convenient has to give way > Expecially if we expect method calls to be frequently interpolated. I don't hear people screaming because it's difficult in perl5, so I doubt it will be very frequent. But even the $() is easier than the current perl5 way to do it. Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote: > >> >> So, to match $foo's colour against $bar, I'd say >> >> >> >> $bar =~ /$foo.colour/; >> > >> > No, you need the sub call parens as well: >> > >> > $bar =~ /$foo.colour()/; >> >> Hm, I thought Larry said you would need to use $() to interpolate >> a method call. So this would be >> >> $bar =~ /$($foo.colour)/; > > That was not my understanding. At least not for (pseudo-)method calls. But with the above you still have abiguity, for example what does this do $bar =~ /$foo.colour($xyz)/; I may be remembering about interpolation into strings as "$file.ext" is going to be common. But I do think the $() approach is clean and unambiguous Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote: > >> So, to match $foo's colour against $bar, I'd say >> >> $bar =~ /$foo.colour/; > > No, you need the sub call parens as well: > > $bar =~ /$foo.colour()/; Hm, I thought Larry said you would need to use $() to interpolate a method call. So this would be $bar =~ /$($foo.colour)/; Graham.
Re: Stacks, registers, and bytecode. (Oh, my!)
On Tue, Jun 05, 2001 at 03:31:24PM -0500, David L. Nicol wrote: > Graham Barr wrote: > > > I think there are a lot of benefits to the re engine not to be > > separate from the core perl ops. > > > So does it start with a split(//,$bound_thing) or does it use > substr(...) with explicit offsets? Eh ? Nobody is suggesting we implement re's using the current set of perl ops, but that we extend the set with ops needed for re's. So they use the same dispatch loop and that the ops can be intermixed Graham.
Re: Stacks, registers, and bytecode. (Oh, my!)
On Mon, Jun 04, 2001 at 06:04:10PM -0700, Larry Wall wrote:
> Well, other languages have explored that option, and I think that makes
> for an unnatural interface. If you think of regexes as part of a
> larger language, you really want them to be as incestuous as possible,
> just as any other part of the language is incestuous with the rest of
> the language. That's part of what I mean when I say that I'm trying to
> look at regular expressions as just a strange variant of Perl code.
>
> Looking at it from a slightly different angle, regular expressions are
> in great part control syntax, and library interfaces are lousy at
> implementing control.
Right. Having the regex opcodes be perl opcodes will certainly make
implementing (?{ ... }) much easier and probably faster too.
Also re references that we have now will become similar to subroutines
for pattern matching.
I think there are a lot of benefits to the re engine not to be
separate from the core perl ops.
Graham.
Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
> On Wed 30 May 2001 16:12, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> > > > "K&R" style for indenting control constructs: ie the closing C<}> should
> > > > line up with the opening C etc.
> > > >
> > > > =item *
> > > >
> > > > When a conditional spans multiple lines, the opening brace must line up
> > > > with the "if" or "while", or be at the end-of-line otherwise.
> > >
> > > I certainly will not change existing code that's written like this, but -
> > since
> > > IMHO this is *poor* GNU coding style - I will submit /new/ code snippets
> > > formatted my own way: the right way. It's then up to the pumpking to accept or
> > > reject it.
> >
> > The above two are essentially just rehashes of what's already in
> > Porting/patching.pod, and seems to reflect existing practice (loosely
> > speaking).
> >
> > What do you regard as the 'right' way?
> >
> > Just to check you're not being mislead by poor wording, the above is
> > supposed to propose
> >
> > if (...) {
> > ...
> > }
>
> if (func (arg)) {
> :
> }
>
> > and
> >
> > if (...
> > .
> > .)
> > {
> >
> > }
>
> if (...
> ...
> ...) {
> :
> }
>
> But I know I'm rather alone on this, though I'm not just someone saying: "Cause
> that looks nice". I have several reasons for dong so and can defend my stance.
Maybe and I am not going to get into a discussion of which is best,
but the community has decided to follow the perl5 style (I say that
as you seem to be the only one objecting). So saying that you will
disregard the preference of the community and do what you like is
being less than helpful IMO.
As being a past pumpking I know how much work there is involved,
and the last thing they want to be doing is spending time reformatting
other people code.
So please play nicely and at least try to work with others.
Graham.
Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code
On Tue, May 29, 2001 at 04:48:59PM -0400, Dan Sugalski wrote: > 1) The indentation should be all tabs or all spaces. No mix, it's a pain. > (As has been already pointed out) 4 column indent per level, all spaces. Can you explain why you think it is a pain. I would say converting between all tabs and all spaces is a pain too. Most editors I know of that do the tabs automatically would fill the start of the line with tabs and then add 4 spaces. So the indent would be either all tabs, or tabs plus 4 spaces Graham.
Re: perl 6 mailing lists status
On Sun, May 27, 2001 at 02:24:13PM -0600, Nathan Torkington wrote: > I'd like to see activity on the topics behind: > * perl6-stdlib > * perl6-build > Dan, Graham--should these lists persist in their current form? Well I thonk that there should eventually be a perl6-stdlib, but I think more needs to be known about potential new features before much talk can begin. I mean, first we must protect compatability, but if perl6 does have the ability for mutiple versions of a module then we have the oportunity to design a consistent library. Graham.
Re: Stacks & registers
On Wed, May 23, 2001 at 10:30:32AM -0700, Hong Zhang wrote: > I think "stack based =~ register based". If we don't have Java-like "jsr" That comment reminds me of how the register file is implemented in a sun sparc. They have a large register file, but only some are accessable at any given time, say 16. When you do a sub call you place your arguments in the high registers, say 4, and shift the window pointer by 12 (in this case). What was r12-r15 now becomes r0-r3. On return the result is placed into r0-r3 which are then available to the caller as r12-r15. This allows very efficient argument passing without having to save registers to a stack and restor them later. Graham.
Re: Stacks & registers
On Wed, May 23, 2001 at 06:06:26PM +0100, Simon Cozens wrote: > On Wed, May 23, 2001 at 12:59:01PM -0400, Dan Sugalski wrote: > > Should Parrot be a register or stack-based system, and if a register-based > > one, should we go with typed registers? > > Register based. Untyped registers; I'm hoping that the vtable stuff can be > sufficiently optimized that there'll be no major win in storing multiple > copies of a PMC's data in different types knocking around. I would agree with that too. Graham.
Re: properties
On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
>> if so, then wouldn't it be safer to put properties inside a special object
>> associated with each object (the 'traits' object) so there would be little
>> namespace collision?
>
> We actually want the possibility of that kind of namespace collision:
> for polymorphism.
Many people keep bringig this up as a confusion and you give the same reply.
However there has not yet, AFAIK, been any description of how having a method
overload a property is useful.
If there is some compelling reason that this is a must, then fine. But many
people seem to be finding this a point of confusion.
Personally I don't see that the gain is greater than the confusion. I would
rather see properties be accessed via a different operator other than dot (.)
If a class wants to manipulate a property via a method they still can, the user
just has to call the method instead of accessing the property directly
With the current approach I can see most code accessing properties with $var.prop{name}
because they want to make sure they get the property and not a method, whereas
it would be shorter, in the common case, to have something like $var'name
Graham.
Re: properties
On Sun, May 20, 2001 at 06:19:35PM -0400, Uri Guttman wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
>
> DC> return undef Because($borked);
>
> hmm, that is poor code as returning a real undef will break in a list
> context.
I always balk when I see someone say that. This is perfectly valid thing todo.
If the sub is defined to return a single scalar value then C is
the WRONG thing todo as it will cause problems if the result is used directly
into a list.
> so how would a value property be attached passed back to an
> empty list? what happens below:
Thats a good point. But on the other hand an empty list is neither
a variable or a value. You are returning nothing, so there is nothing
to attach it too.
But with the ability to return arrays in perl6 you should probably return
an empty array with a property attached.
> perm_props( $foo, 'SortCode' ) = 'ST' ;
>
> the last one assigns the prop value with an lvalue call.
If perm_props returns a hash, then you could also do
perm_props( $foo ){'SortCode'} = 'ST' ;
Graham.
Re: properties
On Sun, May 20, 2001 at 01:24:29PM +0100, Simon Cozens wrote: > On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote: > > my $a is true = 0; # variable property > > my $a = 0 is true; # variable property > > my ($a) = 0 is true;# value property > > Wow. Totally ETOOCONFUSING. That has been exactly my thought as I have been reading this thread. I have been trying to think what properties would make sensible variable or value properties. So far all I can think of for variable properties are actually compile time properties like constant etc. So I am left wondering how much of an issue this really will be ? Graham.
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote: > > Graham wrote: > >> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: >> > > print keys $foo.prop; # prints "NumberHeard" >> > > print values $foo.prop; # prints "loneliestever" >> >> This is an example of one of my concerns about namespace overlap >> with methods. What would happen if there was a method called prop ? >> Have we basically said that there cannot be a method called prop ? > > No, we have basically said that there cannot be a method called prop if you > want to access the object's properties through its prop property. Which mean that any class which defines a method prop, prevents any user from determining the properties of any of its object instances. I am not saying that this is a bad thing, but it will need to be docuemnted that doing this has such consequences. Unless there is another syntax for determining all the properties of a value. >> Personally I would rather see something other than . for accessing >> properties. As things stand the functionality of a working >> program can be completely changed/broken by defining a sub that >> conflicts with a property. > > Er...yes...that's rather the point of the exercise: to be able to > polymorphically override the behaviour of properties by defining > methods. I am just not conviced that it is a good thing todo. methods and properties are different things. Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: > > print keys $foo.prop; # prints "NumberHeard" > > print values $foo.prop; # prints "loneliestever" This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
> On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
> >
> > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> > > It's probably just a matter of coding what you actually mean.
> > > In Perl 5 and 6 your version means "if $fh is true in *any*
> > > possible way...", whereas you seem to want "if $fh is defined",
> > > which is:
> >
> > Hmm. I can easily see this producing incomprehensible code when spread
> > across large systems. To wit, those developers used to "0 means false"
>
> Any feature is incomprehensible if one is not used to it. Pointers
> in C are incomprehensible if one has never met the concept before.
Right, consider overloading.
> As far as I understand one rationale behind the "false (in Perl 5 terms)
> but true (in Perl 6 terms)" is that you can write code like this
>
> if ($retval = func(@args)) {
> # it worked ...
Right. Which of course can be done in Perl 5 with either "0 but true" (or "0E0")
or if the value is an object, the use of overloading.
Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote: >> Also, what's the difference between a 'property' and an >> 'attribute', ie, are: >> >>$fh is true; >> >> and >> >>$fh.true(1); >> >> synonyms? > > No. The former means: > > "Set the true property to 1 and return an alias to $fh" > > The latter means: > > "Attempt to call the C method of $fh. If there is no such > method, set the true property to 1 and return that value" This is something that concerns me. There is no real separation between methods and properties. I can see it causing problems due to them sharing namespaces. But I have not thought about it enough to say how much of a concern. Graham.
