Re: Should @x be defined after only "my @x"? (RT #64968)
>>>>> "KH" == Kyle Hasselbacher writes: KH> use v6; KH> my $s; # ! $x.defined KH> my @a; # @a.defined KH> That's the current Rakudo behavior. RT #64968 suggests that this is a KH> bug. In Perl 5, @a would not be defined until something was put into KH> it. Which should it be? I'd like to write a test for this. i am not even sure why defined is a method on aggregates. it is a known issue in p5 that you shouldn't test aggregates with defined since it tests whether anything has ever been allocated for it vs being empty. this comes from newbies seeing undef $foo and then some do undef @bar and then think defined @bar makes sense. so maybe there is a new reason to support defined on arrays and hashes but i think it should be disallowed. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: The game of life
>>>>> "y" == yary writes: y> If anyone wants to try tackling this, a longer APL one-liner is y> referenced on the APL wikipedia page and discussed in length here: y> http://catpad.net/michael/apl/ y> As an aside, APL was the first computer language I was exposed to. y> When I was around 7 years old my aunt (who lived in Boston near MIT, y> Harvard) had a computer scientist friend who gave her the "APL: A y> Programming Language" book, after she bragged to him about a smart y> nephew who liked typewriters... I liked all the symbols and sort of y> understood a few bits of it... you must not realize that we have our own conway (part of the p6 design cabal) in the perl world who has coded up in perl5 something that should not have been released on a unsuspecting world. it is a monster called selfgol and it not only plays life, it does much more. here is a wiki entry about it. read the code at your own peril. if this gets translated to p6 (and probably become much shorter too), i suspect the heavens will fall, the sun will burn out and python will take over the universe! :) http://www.perlfoundation.org/perl5/index.cgi?selfgol from that page: * Its a quine (typo - should be It's - uri) * Turns other programs into quines * Plays Conway's Game of Life * Animates a marquee banner It does so without importing any modules, and without using a single if, unless, while, until, for, foreach, goto, next, last, redo, map, or grep. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Amazing Perl 6
>>>>> "DC" == Damian Conway writes:
DC> * Grammars built into the language:
DC> grammar Expr::Arithetic {
DC> rule Expression { ** $=< + - > }
DC> rule Mult { ** $=< * / % > }
DC> rule Pow{ ** $=< ^ > }
DC> token Term {
DC>
DC> | '('')'
DC> }
DC> token Literal { <[+\-]>? \d+ [ \. \d+ ]? }
DC> }
DC> * Grammar inheritance:
DC> grammar Expr::Algebraic is Expr::Arithetic {
DC> token Literal {
DC> +
DC> |
DC> }
DC> }
when i promote p6, the first and biggest thing i talk about
grammars. many of the other neat things (and damian listed a good bunch)
can be found in other langs or are nice but focused and small. p6
grammars are like nothing out there especially in any mainstream lang
today. and they are BIG in scope of what they can do. also they are very
accessible to newbies as they are based on the familiar regexes we all
use (and in almost all modern langs too). the mapping of grammar rules
to methods/subs and inheritance (which i generally despise but is
totally appropriate in grammars) is also amazing. now you can use
grammar libs and customize them as desired with little effort. before
this if you did have a grammar/parser (in any lang/system) you had to
learn its guts in detail before you dared to touch it. also grammars can
do dynamic things like build up a parsed data tree on the fly. you will
get what you expect (DWIM) with arrays of repeated grabbed sections
(properly nested as it follows your grammar). these are holy grails of
parsing and they come built in with incredible ease of use. note how
every other lang claims a perl5 compatible regex engine (and they lie as
none can do s///e among other things :). now with p6 they will never be
able to copy its grammars as it is a core part of p6 and not some regex
lib.
so you can talk about this amazing feature and be assured that the
audience will be amazed. :)
thanx,
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Which brackets should @a.perl use?
>>>>> "ML" == Markus Laker writes:
ML> Adding a single backslash before `eval' pushes an anonymous array on to
ML> @b, as you envisage wanting to do:
ML> # Imagine that @a.perl has produced this:
ML> my $p = "('blue', 'light', 'hazard')";
ML> my @b;
ML> @b.push(\eval $p);
but that is manual code. what about a larger tree?
>> a more useful example would be serializing data trees. if you dump @b
>> with .perl do you want the current dumper output of a anon array or your
>> list of values? when serializing a tree, you must get the ref version so
>> that is the common and default usage. your version isn't DWIMmy there at
>> all.
ML> I think Perl 6's automatic reference-taking (though we don't call them
ML> references any more) solves that problem for us.
ML> If you say
ML> my @c = eval '(1, 2, 3)';
ML> then @c has three elements. If you say
ML> my $c = eval '(1, 2, 3)';
ML> then Perl constructs (if I've got the Perl 6 lingo right) an Array object
ML> and stores it in $c. So the round brackets DTRT whether you're storing
ML> into an array like @c or into a scalar like $c.
that fails with nested arrays. we don't want them to flatten.
my $c = eval '(1, (4, 5), 3)';
will that work as you envision? in perl5 with [] it works fine. i know
there are contexts that flatten and others that don't. but a larger tree
with assignments like that are harder to read IMO as lists inside lists
are not nesting but flattening in p5 all the time.
ML> We serialised an array of three elements; we got back an array containing
ML> just one. Round brackets would have solved that. (Actually, we don't
ML> need any brackets at all, because Perl 6's list constructor is a comma,
ML> not a set of brackets. But round brackets would be no-ops, and they
ML> arguably make the output more human-readable.)
try that again with my example above. in p5 the structure would be this:
my $c = [1, [4, 5], 3] ;
how should .perl serialize that so that eval will give back the same
structure? unless () are nesting and not flattening then you can't do it
without a \() which is longer (and uglier IMO than []).
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Which brackets should @a.perl use?
>>>>> "m" == moritz writes:
m> S02 says:
m> "To get a Perlish representation of any object, use the .perl method. Like
m> the Data::Dumper module in Perl 5, the .perl method will put quotes around
m> strings, square brackets around list values,"
m> So according to this, Rakudo has it right.
m> But I think that a .perl()ification as ("blue", "light", "hayard",) would
m> make much more sense, because simple thing like
m> @a.push eval(@b.perl)
m> would then DWIM.
for your def of DWIM. i can see wanting an anon array to be pushed onto
@a building up a structure. your example is too simple to really cover
this as you could just push @b or a ref to @b (damn, i need to learn
more basic p6 syntax! :).
a more useful example would be serializing data trees. if you dump @b
with .perl do you want the current dumper output of a anon array or your
list of values? when serializing a tree, you must get the ref version so
that is the common and default usage. your version isn't DWIMmy there at
all.
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: What does a Pair numify to?
>>>>> "mab" == mark a biggar writes: mab> -- Original message -- mab> From: Larry Wall >> On Thu, Dec 11, 2008 at 02:24:54PM +0100, TSa wrote: >> > My idea is to let a pair numify to whatever the value numifies to. >> > Same thing with stringification. In general I think that a pair should >> > hide its key as far as possible if used as non-pair. >> >> This makes sense to me, but I'd like to see any use cases to the >> contrary, if anyone can think of one. mab> The only use case I can think of is sorting a list of pairs; mab> should it default to sort by key or value? the default should be sort by key since that is used way more often than sort by value. well, at least it seems that way to me. but if you use a key description sort it may be trivial either way. something like (broken p6): @pairs.sort( .key ) ; @pairs.sort ; # same thing if key is the default @pairs.sort( .val ) ; or even using the single letter method names (i dunno what is supported now): @sorted = @pairs.sort(.k) ; @sorted = @pairs.sort(.v) ; and if i am correct, no assignment would mean in-place sorting which is wanted. so you could default to sorting pairs by keys and not bother too many. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: r24325 - docs/Perl6/Spec
>>>>> "LW" == Larry Wall writes: >>> infix: does numeric comparison if both operands are numbers, and >>> string comparison otherwise. LW> That is a bit of an oversimplification. LW> Any type may define infix: however it likes for two arguments of LW> its own type. It may also define multis with other types that define LW> desirable coercions. The infix::(Any,Any) routine is what would LW> be providing the default string coercion, so it would succeed for LW> any two different types that match Any and have string coercions. LW> Outside of Any are the Object and Junction types; I suppose cmp can LW> thread on junctions, but trying to sort junctions might well result LW> in aberrant behavior, especially if we choose a sort algorithm that LW> coredumps on circular ordering relations. :) this means cmp still does a string compare as long as it can coerce its args to strings. this means the shorter sort ideas being bandied about still have a major weakness - specifying the sort comparison. you can default to string like p5 sort which is fine. but how do you pass in <=>? or handle multiple keys with different comparison ops? this is why damian and i agree that a key description style works best for a sorter. the short versions i have seen are useful for string sorts of a single key. there are plenty of uses for that and those would be a good short cut. but there still needs to be a full sort signature of the kind damian proposed and we have both built in different modules. there is plenty to steal from there so don't go reinventing this wheel just yet. :) thanx, uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Working with files wish list
>>>>> "LT" == Leon Timmermans writes:
>> e) When dealing with files in directories in perl5 under linux, I need
>>
>> opendir(DIR,'./path/') or die "cant open ./path/\n";
>>
>> my @filelist = grep { /^.+\.txt/ } readdir(DIR);
>>
>> I would prefer something like
>>
>> my Location $dir .= new(:OSpath<'./data'>);
>>
>> and without any further code $dir contains an Array ($d...@elems) or Hash
>> ($dir.%elems) (I dont know which, maybe both?) of File objects. If a Hash,
>> then the keys would be the stringified .name attribute of the files.
>>
>> No need to opendir or readdir. Lazy evaluation could handle most
situations,
LT> I agree there should be a single function that combines opendir,
LT> readdir and closedir. Scalar readdir can be useful in some context,
LT> but in my experience it's the less common usage of it. From a
LT> programmers point of view lazy operation would be convenient, but from
LT> a resource management point of view that may be a bit complicated.
as another responder mentioned File::Slurp, i want to say it contains a
read_dir function (note the _ in the name). it does a slurp of a dir and
always filters out . and .. . i have plans to have it take an optional
qr and grep the dir list for you. something like this:
my @dirs = read_dir( $dirpath, qr/\.txt$/ );
again, i agree these functions should not be named new() as open and
readdir have more meaning. how could you tell you were opening a file vs
a dir with just open? many coders may not even know that open in p5 will
work on a dir! you just open the file and can read the raw dir data
which will likely look like garbage unless you have the correct
filesystem c structures to decode it. so you must have some way to
designate to the open/new that this is a dir.
the whole issue of portable paths is another problem but i can't address
that.
thanx,
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: r24325 - docs/Perl6/Spec
>>>>> "p" == pugs-commits writes: p> This document attempts to document the list of builtin functions in Perl 6. p> It assumes familiarity with Perl 5 and prior synopses. p> @@ -870,6 +870,10 @@ p> comparisons. C<@by> differs from C<$by> in that each criterion is p> applied, in order, until a non-zero (tie) result is achieved. p> +If C<$by> is a code object of arity zero or one, it is applied on each item p> +of C<@values>, and C<@values> is sorted by comparing the result values with p> +C<< &infix: >> (Schwartzian Transform). p> + the ST is a specific implementation of this optimization. the concept is caching key extractions and expressions so they become O(N) and not O(N log N) which saves tons of cpu in larger complex sorts. but how the caching is done is really independent of the sort API/signature. as perl6 synopses aren't supposed to discuss implementation (they are language specs) calling it the schwartzian transform is somewhat out of place. the ST caches the extracted keys in arrays but the GRT caches them in a single byte string which can be even faster. all the api/sig is doing is removing the redundant key extract code for both $a and $b. so say that the sort sig is easier to use for simple sorts as you don't need to express the extract code on $a/$b but it is implied to do it given the sort code block. and some other questions: and how does that style handle multiple keys? how is sort ordering specified? how does it know to do string vs numeric sorting? damian's Perl6::Sort and my Sort::Maker address those issues but this SIG short cut doesn't (yet). also Sort::Maker generates sorts in 4 styles which may be of use to any implementors of perl6's sort. and it has an old (prize winner at TPC4) article on this topic that may be of some interest. and it only won a technical award because damian withdrew as he was the winner the previous two years in a row! :) thanx, uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Better "sort" spec?
>>>>> "TSN" == Timothy S Nelson writes:
TSN> Hi all. I saw the new "sort" idea on the Rakudo blog:
TSN> http://www.rakudo.org/2008/12/its-sort-of-like.html
TSN> ...and wondered if we can get it in the spec, as I haven't
TSN> seen any discussion on it or anything.
well, it is sort (sic) of just like what damian posted almost 5 years
ago. i found this post covers something very similar to the rakudo
implementation. i can't seem to find this proposal in any of the
synopses (at least a quick google search found nothing) so maybe it
needs to be put in the specs/synopses.
http://groups.google.com/group/perl.perl6.language/msg/728e7246c0c6b95f
there was a whole series of threads about sorting at that time.
the end of that post has this:
@sorted = sort {(%M{$^a}//-M $^a) <=> (%M{$^b}//-M $^b)} @unsorted;
@sorted = map $_[1], sort {$^a[0] <=> $^b[0]}, map [-M,$_], @unsorted;
would both become:
@sorted = sort {-M} @unsorted;
Damian
so you can see a similar single extract code for both $^a and $^b. and
this exists in perl5 in Sort::Maker (mine) and i think also in Perl6::Sort
(which is damian's).
so you have not discovered something new in perl or perl6 regarding
sorting. it has been covered and in depth but never properly integrated
into the p6 docs.
thanx,
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Rakudo test miscellanea
>>>>> "RR" == Ryan Richter <[EMAIL PROTECTED]> writes: RR> On Thu, Jun 26, 2008 at 09:55:09AM -0700, Larry Wall wrote: >> We could go as far as to guarantee that Nums do rational arithmetic >> out to a certain point, but probably what the financial insitutions >> want is special fixed-point types that assume a divisor anyway. >> Would any financial institution care to comment? RR> IANAFI, but I think that's more or less right. I think they actually RR> tend to use BCD. RR> http://www2.hursley.ibm.com/decimal/decifaq1.html#inexact but a rat with a divisor of 100 (or 1000 even) should be fine for their needs. bcd is a pain (i write one in the distant past for PL/I). i once even offered to redo it (and i partially started it) for parrot. so if anyone really wants a fast bcd math lib which can handle arbitrary size and precision, and wants to take it over, let me know. i already have add/subtract working and the designs for * and / are there. just needs more coding in c. i don't have the time, focus and incentive to work on it. a fun and smallish project for anyone with the right interest. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Perl 6 fundraising and related topics.
>>>>> "RH" == Richard Hainsworth <[EMAIL PROTECTED]> writes: RH> Consider the position you put me, or another sponsor, in. You mention RH> a specific person, someone who is highly respected and extremely RH> talented. You ask if I consider this person to be as flaky as a RH> character that was a figment of my imagination, and if I say 'no he is RH> not so flaky', then the implication is I will provide sponsorship. And RH> if I demur, you might say 'put up or shut up' and I feel under RH> pressure to do something I might not really want to. i am sorry if i caused you any concern or confusion. i didn't mean to put you under any pressure in any way. my goal was to inform anyone here about another way to help with supporting perl6 (and perl5 cpan) developers, in particular damian. as for damian being flaky or not, that is a great question! :). RH> The whole point about having an institutional channel for sponsorship RH> is to remove the need for personal judgments, for sponsors to specify RH> exactly how their money should be used, for the procedures to be in RH> place to cover shortfalls from a central budget, for rules to be clear RH> about what happens to money that is in excess of earmarked programmes, RH> and for there to be clarity in all possible grey areas that happen in RH> life. i agree about needing better institutional channels for sponsorship. i am just offering a small side channel for those who would like to support damian. RH> I have absolutely no issues with the excellent series of courses RH> you run, especially if they are taught by Damian. But where do RH> they fit into the general scheme of things? Are they essential to RH> the development of perl6, or do they only benefit a small group of RH> regional companies. Do they benefit me (bear in mind that the RH> company I run is based in Moscow, Russia)? i didn't aim this at companies in moscow. you had the last best email on this thread which inspired me to respond. note that i replied to the lists as well directly to you. it was a purely informational post for the perl 6 community. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Perl 6 fundraising and related topics.
>>>>> "RH" == Richard Hainsworth <[EMAIL PROTECTED]> writes: RH> No one likes bureacracy. But I feel much happier about handing over RH> money, or persuading someone else to hand over money, to a group of RH> people with established procedures and collective responsibility, than RH> to some enthusiatic individual who promises the earth and whose the RH> world-number-one genius at code writing, but might also go and blow RH> the whole lot on girls and booze cos his cat died. would you think damian has enough anti-flake genome in him to qualify for a more direct donation? :) if you do and agree that damian is worth supporting, i have an opportunity to propose. i am producing the perl college which is a set of classes taught by damian in boston, aimed at junior perl hackers. the college is sponsored by companies looking to hire intermediate level perl developers. your company or you as an individual, can be a sponsor which will support damian to come to the states for this set of classes and also for the conferences (which he missed last year because his funding came up short). if you are interested contact me off list at uri AT perlhunter.com. for more info on the perl college go to: http://perlhunter.com/college.html thanx, uri, dean of the perl college. -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Perl 6 fundraising and related topics.
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> By the way, it's possible that I might deserve a little more money, LW> because *my* cat died last year, and as near as I can tell, I didn't LW> spend any money on girls and booze because of it... :) i will donate to get larry a new cat. in fact we can probably find a free stray or extra kitten somewhere near him. will this make perl 6 happen before christmas? :-) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Architecture, Development, Training, Support, Code Review -- --- Search or Offer Perl Jobs - http://jobs.perl.org - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: [svn:perl6-synopsis] r14376 - doc/trunk/design/syn
>>>>> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> On 4/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Note that unless no longer allows an else
LP> Hmm, that's interesting. I don't _think_ I'm opposed, but maybe I am.
LP> The main case that I can see this limiting me is where I like to put
LP> my error conditions at the end of my code, out of the way, like so:
LP> unless $.something {
LP> $.something = UsefulData.new;
LP> }
LP> else {
LP> die "Something exists!";
LP> }
LP> I don't want to switch the order of those blocks, and switching the
LP> condition to "if !$.something" defeats the whole purpose of unless.
in perl5 i like to get the quick stuff like next/last/die out of the
way. it saves a block, indents and else clauses. something like this in
p6 (just your code edited):
die "Something exists!" if $.something ;
$.something = UsefulData.new;
i don't like unnecessary blocks and indents if i can help it. unless
with else is very confusing and i never used that. i try to keep my
unless clauses to be very simple. anything complex and i revert to if.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Should a dirhandle be a filehandle-like iterator?
>>>>> "JL" == Jonathan Lang <[EMAIL PROTECTED]> writes: JL> Well, I did suggest that "openfile" and "opendir" exist alongside JL> "open", with "openfile" being more akin to Perl 5's "open" or JL> "sysopen", and "open" being a bit more dwimmy. JL> But in general, most of the differences that you mention are things JL> that ought to be addressed in the resulting iterators, not in the JL> creating statement. No, a "directory handle" will not behave exactly JL> like a "file handle". But then, a file handle doesn't behave exactly JL> like "standard in" or "standard out", either (last I checked, Perl 5 JL> won't do anything useful if you say "seek STDIN, 0, SEEK_END"). well, that seek failure is a result of the stream nature of stdin and not a failure of perl. remember that open and much of the i/o layers (regardless of perl I/O's rewrite) are just wrappers around the OS and libc calls. i don't see how to dwim them all together (but IO::All does that in a wacky dwim way). i have never felt the need for super smart iterators so i can change looping over lines to looping over a dir. maybe you might have a set of filenames in file vs a dir of names. but i just don't run into that need. sometimes mappings like that are just overkill IMO. enough from me on this. as with the rest of p6 i will work with whatever is decided by @larry. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Should a dirhandle be a filehandle-like iterator?
>>>>> "JL" == Jonathan Lang <[EMAIL PROTECTED]> writes: JL> Please. I've always found the "opendir ... readdir ... closedir" set JL> to be clunky. JL> Also: why distinguish between "open" and "opendir"? If the string is JL> the name of a file, 'open' means "open the file"; if it is the name of JL> a directory, 'open' means "open the directory". If it's the name of a JL> pipe, it opens the pipe. And so on. maybe this won't help you but if you did open on a dir in perl5 you can read the raw directory data which is pretty useless in most cases. so with open working as opendir on directories, what is the op/method to get the next directory entry? that isn't the same as reading a line. there won't be any trailing newlines to chomp. marking a location is not the same with tell and telldir (one is a byte offset, the other a directory entry index). and since dirs can reorder their entries (especially hash based dirs) the ordering and seek points may move. not gonna happen on text files. there are many differences and the only one you seem to see is a linear scan of them (which is just the most common access style). the operations you can do on the handles are very different as well. you can't write to a dir. dirs have no random access (you can lookup by a name with open but you can't go to the nth entry). and on OS with extra stuff like version numbers, then all bets are off. yes, you can tell the dir is such by doing a stat and then open can dwim but i don't see the overlap as you do. dirs generally are ordered lists of strings and have many different underlying formats based on their file systems. mapping that to a text file of lines doesn't work for me. this may all be obvious stuff but i think it deserves mentioning. if dirs mapped well onto file handles they would have been mapped that way long ago in the OS. in 30+ years that hasn't happened afaik. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: request new Mapping|Hash operators
>>>>> "AC" == Aaron Crane <[EMAIL PROTECTED]> writes: AC> That's easy even in Perl 5. This modifies %hash in-place: AC> my @values = AC> @[EMAIL PROTECTED] = @values; you can even do: @[EMAIL PROTECTED] = delete @[EMAIL PROTECTED]; and i am sure a simple p6 thing can be written which takes pairs of old/new names and loops over them. someone wanna rewrite that here in p6 and we can see how complex it would be? a rename method might not be so important then. as for rename on hash keys, why not call it rekey? also even if it is called rename as a hash method it is different than rename as a function to rename a file so there is no ambiguity. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Y not
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> On 21/02/07, Damian Conway <[EMAIL PROTECTED]> wrote: >> [Off-list] DC> Apparently not. DC> Just pretend I'm not here. DC> ;-) we can't pretend as we can sense your mad scientist brain across the big waters. there ain't enough aluminum foil to protect us all! :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
DOC: glossary
hi to all docathon hackers (and others too), one idea we came up with during the docathon is that perl6 needs a glossary. would the terms autobox or mixin make any sense to a newcomer who didn't know any OO theory? so this is a proposal to start a glossary as a new S\d+ or other document. here are some ideas i have been bouncing in my skull that i would like to see in it: the list of terms should include all of perl6's special variable names, namespaces (including the term namespace! :), keywords, OO theory terms (like autobox). i think it should also include many/most of parrot's terms as there is some overlap. stuff like haskell, pugs, PGE, and others should also be included. i don't think perl6 ops should be included. each term should have a pronunciation if it isn't obvious. of course there should be a succinct definition of no more than a couple of sentences. a reference to the S\d+ docs that discuss the term in depth links/references to longer definitions on the web for non-perl specific terms like autobox. a 'see also' section referring to other terms. i think a pumpking should be annointed to own the master doc. this would be a great job for anyone who wants to help as you don't even need to understand all the terms or be a core perl6 hacker. you just need to know how to alphabetize, format and handle patches, google a bit for external links, track xrefs and see also's and such. this is basically an ongoing editor job. a first task would be to create this doc and to create a pod template for entries. then others can submit entries in that format or the pumpking can edit them into that format. we can start with just a list of terms and they can be filled out incrementally. i do expect this to be fairly large with several hundred terms. i will post a starter list of terms soon. it will just be words i have been seeing in S02 which is the spec i have been editing. all the other docathon hackers (and anyone else) can submit lists as well. when we have a pumpking, then the glossary doc itself can be started. if you want to submit entries do that too. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Docathon (was Re: State of Perl 6 Backends)
>>>>> "AT" == Audrey Tang <[EMAIL PROTECTED]> writes: AT> Indeed. So instead of having the implementions define the language, AT> this time around the specs, and tests, and API documentations, need AT> to be adhered closely by implementors, which is why we're all talking AT> together in #perl6 in the past few months or so. :-) that was a good leadin for me to remind anyone at the chicago hackathon that we are going to also do a docathon. i actually printed up (double sided to save trees) the full set of synopses from perl.org. (not the most up to date but good enough). i will be marking it up as i read it. i would like to get some of you to do more proofreading at the docathon and we can integrates our patches, rewrites, questions while a large corps of p6 hackers will be around. take a break from hacking p6 and hack the p6 docs! sign up and post your ideas at: http://yapcchicago.org/wiki/index.cgi?SynopsisEdit (i should have called it DocAthon. maybe i will rename it) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
YAPC::NA Synopsis Hackathon
I have proposed a synopsis edit hackathon subproject at YAPC::NA. read my ideas at: http://yapcchicago.org/wiki/index.cgi?SynopsisEdit feel free to edit and add your own comments. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r9310 - doc/trunk/design/syn
>>>>> "l" == larry <[EMAIL PROTECTED]> writes: l> Log: shouldn't that be "grandpa's log, earth date 200605252055"? l> Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in. l>Ref: http://www.wall.org/cgi-bin/photo/index.cgi?mode=view&album=/pix/Julian so when does he get his commit bits? :) congrats, grandpa! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: A rule by any other name...
>>>>> "AR" == Allison Randal <[EMAIL PROTECTED]> writes: AR> Including :skip(//). Yes, agreed, it's a huge AR> improvement. I'd be more comfortable if the default rule to use AR> for skipping was named instead of . (On IRC was AR> also proposed, but the connection between :skip and is more AR> immediately obvious.) a small point but why not have both and be aliased to each other? i like the connection but is (usually) about skipping white space which is likely the most commonly skipped text. both names have value so we should have both. and i think in most cases you won't see many explicit or as they will be implied by the whitespace in the rule/term/whatever that has skipping enabled. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8899 - doc/trunk/design/syn
>>>>> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes: JSD> On Fri, Apr 21, 2006 at 11:06:20AM -0700, Larry Wall wrote: >> On Fri, Apr 21, 2006 at 12:45:13PM -0500, Jonathan Scott Duff wrote: >> : According to S05, "a /.../ matches immediately in a value context >> : (void, Boolean, string, or numeric)" and since >> : >> : (state $x) ||= / pattern /; >> : >> : is very much the same as >> : >> : state $x; $x = $x || /pattern/; >> : >> : I'd say that's a "boolean context" and thus matches against $_ instead >> : of assigning the Regex object to $x. >> >> Except the right side of || isn't in boolean context till you evaluate >> $x that way, so it probably wants to be written with m//: JSD> I almost added a little bit of text to the end of that other message JSD> but didn't. I think it's most appropriate now: JSD> I must say that I have trouble distinguishing when using // gives you JSD> a Regex object and when it actually does pattern matching, so I intend JSD> on always using m// when I want a match, and some form of rx// when I JSD> want an object. having read S05's take on that i agree in general. i will probably always use rx// the way you had to use qr// in p5. i may drop the m in // as that is the classic 'match this now'. but i think it is good style to mark these as to what you mean and not let the DWIM rule for you. but then i also rarely use $_ in p5 so i would be using ~~ as i use =~ now and that always means match so the m wouldn't be needed for clarification. but the way p6 uses $_ in some places is much better than p5 so that rule may need changing too. oy! the habits to be broken and relearned! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8899 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> * S05: Oops, turns out I entirely read perlop.pod incorrectly; a> "it matches once only" means "it matches successfully once only", a> not "it performs the match once only". Sorry, TimToady++'s a> original example of: a> (state $x) ||= / pattern /; a> was correct. a> +To reset the pattern, simply say C<$x = 0>. i did a fresh read of S05 due to all the recent activity (i will post some edits and questions soonish), but that example baffles me. how does it emulate the (never used by me) // of p5? my take would be that the rx would be or-assigned to $x and it would remain set through repeated calls to the outer sub (assuming a sub). what is the context that makes it match against $_ vs returning an rx. wouldn't the assignment bleed into the the //? or is $x || /pattern/ going to do a match if it $x is false? in any case, one quick comment on S05 is it needs some more examples and some explanations of how the examples do what they are claimed to do. i know this is a synopsis/spec but some places do go into more explanation with examples than others. i would like to see it more consistant at that level. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Another dotty idea
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Okay, after attempting and failing to take a nap, I think I know LW> what's bugging me about "long dot". It seems just a little too LW> specific. does this mean you are at the dawning of your dot.age? i couldn't resist! :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8572 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> +In numeric context (i.e. when casted into C or C), a Hash object s/casted/cast/. i caught this one the other day. looks like the lesson didn't take so we will have to punish you. you must rewrite pugs in python! MUAHAHAHAHAH!!! a> +becomes the number of pairs contained in the hash. In a boolean context, a a> +Hash object is true if there are any pairs in the hash. In either case, a> +any intrinsic iterator would be reset. (If hashes do carry an intrinsic a> +iterator (as they do in Perl 5), there will be a C<.reset> method on the h dangling 'h'. a> +hash object to reset the iterator explicitly.) uri, the very punishing grammar nazi. -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8570 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> -The C is expected to return a reference to an inner a> -container object of the proper sort (i.e. a variable, subroutine, a> -or method reference), or to a proxy object that can "autovivify" a> -lazily, or undef if that name is not to be considered declared in the a> -namespace in question. The declaration merely defines the interface a> -to the new object. That object need not be completely defined yet, a> -though the C routine is certainly I to define it a> -eagerly, and even install the inner object into the outer container a> -(the symbol table) if it wants to cache the declaration. a> +The C is expected to return an inner container object of the proper a> +sort (i.e. a variable, subroutine, or method object), or to a proxy a> +object that can "autovivify" lazily, or C if that name is not to be a> +considered declared in the namespace in question. a> + a> +The declaration merely defines the interface to the new object. a> +That object need not be completely defined yet, though the a> +C routine is certainly I to define it eagerly, and a> +even install the inner object into the outer container (the symbol a> +table) if it wants to cache the declaration. in both versions 'The C is expected' doesn't say what CANDO is until later. so i would also put 'routine' or sub (or whatever we call those upper case special subs - do we have a generic name for them?) after C. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8569 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> Sigils are now invariant. C<$> always means a scalar variable, C<@> a> an array variable, and C<%> a hash variable, even when subscripting. a> -Array and hash variable names in scalar context automatically produce a> -references. a> +Variables such as C<@array> and C<%hash> in scalar context simply a> +returns themselves Array and Hash objects. ^as i think you wanted to say 'as' after themselves. and returns should be return (yes, english is wacky with plural nouns and verbs). When in scalar context, aggregate variables such as C<@array> and C<%hash> simply return themselves as Array and Hash objects respectively. a> =item * a> -Unlike in Perl 5, the notation C<&foo> merely creates a reference a> -to function "C" without calling it. Any function reference may a> -be dereferenced and called using parens (which may, of course, a> -contain arguments). Whitespace is not allowed before the parens, a> -but there is a corresponding C<.()> operator, which allows you to a> -insert optional whitespace before the dot. a> +Unlike in Perl 5, the notation C<&foo> merely returns the C a> +function as a Code object without calling it. You may call any Code a> +object parens (which may, of course, contain arguments). Whitespace a> +is not allowed before the parens, but there is a corresponding C<.()> a> +operator, which allows you to insert optional whitespace before the dot. Unlike in Perl 5, the notation C<&foo> merely returns the C function as a Code object without calling it. You may call any Code object with parentheses (which may, of course, contain arguments). Whitespace is not allowed before the open parenthesis, but there is a corresponding C<.()> operator, which allows you to insert optional whitespace before the dot. a> -A hash reference in numeric context returns the number of pairs a> -contained in the hash. A hash reference in a boolean context returns a> -true if there are any pairs in the hash. In either case, any intrinsic a> -iterator would be reset. (If hashes do carry an intrinsic iterator a> -(as they do in Perl 5), there will be a C<.reset> method on the hash a> -object to reset the iterator explicitly.) a> +In numeric context, a Hash object returns the number of pairs contained a> +in the hash. Hash in a boolean context returns true if there are any pairs a> +in the hash. In either case, any intrinsic iterator would be reset. (If a> +hashes do carry an intrinsic iterator (as they do in Perl 5), there will a> +be a C<.reset> method on the hash object to reset the iterator explicitly.) In numeric context, a Hash object returns the number of pairs contained in the hash. A Hash in a boolean context returns true if there are any pairs in the hash. In either case, any intrinsic iterator would be reset. (If hashes do carry an intrinsic iterator (as they do in Perl 5), there will be a C<.reset> method on the hash object to reset the iterator explicitly.) is Hash the same as Hash object? i know %hash is both but is it ok to change the name in mid paragraph like that?? just the usual minor cleanup of audrey's english. hell, she has to have SOME flaws! :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8532 - doc/trunk/design/syn
>>>>> "AT" == Audrey Tang <[EMAIL PROTECTED]> writes:
AT> Uri Guttman wrote:
>> one of these days when i have tuits of large circumference, i will do a
>> nit pass over as much of the A/E/S as i can handle before my brain
>> explodes. having done tech editing for perl books is good training for
>> this. in fact it would be a good idea to have several such passes by
>> those with editing skill before those docs are 'released'. some of the
>> concepts are so new to so many and are bleeding edge that the wording
>> used has to be extra clean of nits and such stuff as dangling pronouns
>> and other common flaws of technical writing.
AT> Indeed. If we can arrange to have a "docathon" of factoring S* via such
AT> reviewing passes into Perl6::Doc::{Spec,Overview,Tutorial} documents,
AT> that can greatly speed up Perl 6 adoption.
AT> Got some cycles at YAPC::NA::Chicago? :)
i dunno now. is there going to be a hackathon like last year before
toronto? i could possibly get there early for some of that and get some
of that manic group energy focused on the docs. hell, i would do it just
to try to grok some of the stuff that is flying around. :)
so is anyone going to volunteer their place for this?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8532 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> Author: autrijus a> Date: Sat Apr 1 20:10:15 2006 a> New Revision: 8532 a> Modified: a>doc/trunk/design/syn/S02.pod a> Log: a> * upper/lowercase English nit fix for the last patch as suggested a> by TimToady you might as well attribute the s:g/Into/into/ to dr. ruud. all timtoady did was correct dr. ruud's p5 s///g into p6's s:g///. if we are going to pick nits this small, then the tiny amount of credit is worth bestowing upon the correct contributor. :) one of these days when i have tuits of large circumference, i will do a nit pass over as much of the A/E/S as i can handle before my brain explodes. having done tech editing for perl books is good training for this. in fact it would be a good idea to have several such passes by those with editing skill before those docs are 'released'. some of the concepts are so new to so many and are bleeding edge that the wording used has to be extra clean of nits and such stuff as dangling pronouns and other common flaws of technical writing. speaking of bleeding edge? what do you call the opposite of that? the coagulated edge. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
>>>>> "a" == autrijus <[EMAIL PROTECTED]> writes: a> +You may cast C to other types with a prefix sigil operator: a> + a> +$args = \3; # same as "$args = \(3)" a> +$$args; # same as "$args as Scalar" or "Scalar($args)" a> +@$args; # same as '$args as Array" or "Array($args)" a> +%$args; # same as '$args as Hash" or "Hash($args)" a> +&$args; # same as '$args as Code" or "Hash($args)" a> + a> +Casted as an array, you can access to all positionals. Casted as a> +a hash, all nameds. As a scalar, the invocant. As a code, the a> +slurpy nameless block. s/casted/cast/g and i would word those as 'cast into an array'. here is my rewrite: When cast into an array, you can access all the positional arguments; Into a hash, all named arguments; Into a scalar, the invocant; Into code, into slurpy nameless block. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
>>>>> "RLS" == Randal L Schwartz writes: >>>>> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> i will let damian handle this one (if he sees it). but an idea would be Uri> to allow some form ofkey extraction via a closure with lazy evaluation Uri> of the secondary (and slower) key. RLS> I still don't see that. I understand about the lazy key RLS> evaluation. However, the sort block in Perl5 contains more than RLS> just two key computations: it also contains the logic to decide RLS> *how* to compare the keys, and *when* more information is needed RLS> (a secondary key step, for example). Not sure how you're going RLS> to replace that with just information about how to compute "a RLS> key". I think you've had your head inside GRT for too long. :) because the key description also specifies the comparison style. and it would even be possible to pass in a closure (with $^a and $^b) to do the actual comparison which gets you the p5 sort style that way. the determination if you need more info would normally be when the previous key sorts the same and that can be handled. the only odd case is when you have a very bizarre set of comparison rules where simple == and cmp don't work for this data. then the custom compare closure can also be used. RLS> So, for the simple case (string sort against some function of each item), RLS> I can see the need for a good shortcut. However, the general case (let RLS> me tell you how to sort two items), you'll still need a very perl5-ish RLS> interface. i don't see why you need that except for the odd cases. but as i said supporting custom compares is fine and can be done in a p6 way with a comparison closure. but even for simple sorting of two items, i would prefer to use a key extraction as that means you don't have redundant code and you describe the comparison as numeric or string which i think it better than cmp or ==. and at least in sort::maker you don't need to do more than say number or string which is simple enough. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
>>>>> "RLS" == Randal L Schwartz writes: >>>>> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> sorting in p6 is not at all like in p5. instead of coding up an explicit Uri> comparison code block and duplicating all the key access code (for $a Uri> and $b), you will specify how to extract/generate each key for a given Uri> record. this new syntax was posted by damian (who else) and it is very Uri> similar to the api in my p5 module sort::maker (we did discuss this Uri> api). i don't know if any A/E/S doc covers it but it is definitely in Uri> the archives. RLS> I hope the old (perl5) way is still available as well. There are times RLS> when parts of the comparison should be done lazily. Consider two RLS> objects that have a value for a primary sorting order, but only RLS> for those which the value is the same, we fall back to a secondary RLS> sort key that is expensive to compute (like maybe calling a database). RLS> For these scenarios, specifying the sort comparison will be simpler RLS> and cheaper than specifying the sort key. RLS> So, we need both, but if we get only one, the Perl5 way is superior. i will let damian handle this one (if he sees it). but an idea would be to allow some form ofkey extraction via a closure with lazy evaluation of the secondary (and slower) key. and if you need that feature then you can't use the standard ST or GRT which preextract the keys. you could mung the ST to do this with lazy eval support but not the GRT since it packs the keys and there is no place to put in code for lazy keys. note that the API damian proposed did not specify an implementation so this could be supported internally at some point. and supporting the old simple p5 sort shouldn't be a problem and is probably a good idea anyhow. but the $a and $b will have to become $^a and $^b and be proper params of a closure. i dunno if that will cause a speed hit as $a/$b we designed to bypass the normal slow arg passing in p5. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef - second draft
>>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes: PS> I have occasionally felt it would be nice to be able to PS> distinguish between shifting an explicit undef value off an array PS> and calling shift() on an empty array without having to test the PS> length of the array. Is that likely to fall out of any of the PS> current thinking? I do not want shift() on an empty array to die PS> by default. that could easily be done with a property on the shifted value like undef but 'Empty'. an undef from an element is shifted as is. so it is more a feature to add to shift than to undef. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
>>>>> "DD" == Darren Duncan <[EMAIL PROTECTED]> writes:
DD> At 9:30 AM + 12/17/05, Luke Palmer wrote:
>>
>> You're actually saying that undef either compares less than or greater
>> than all other objects, which contradicts your earlier point. I'd say
>> it just fails.
DD> At the time I wrote this, I had been thinking that having a list of
DD> array values where some were undefined was still not unreasonable to
DD> be sorted. And in that case, since undef's can't sort by normal means
DD> (value comparisons don't work on them), we have to do something with
DD> them so the sorted array has all the elements of the original, hence
DD> group them at one end.
DD> However, perhaps it does make better sense for wider consistency that
DD> a sort needs to have an explicit handler that says what to do with
DD> undefs, or otherwise the sort fails.
sorting in p6 is not at all like in p5. instead of coding up an explicit
comparison code block and duplicating all the key access code (for $a
and $b), you will specify how to extract/generate each key for a given
record. this new syntax was posted by damian (who else) and it is very
similar to the api in my p5 module sort::maker (we did discuss this
api). i don't know if any A/E/S doc covers it but it is definitely in
the archives.
so you could easily handle undefs by converting them to the sort value
you want. using // it would be trivial to do (assume an array ref record
is passed in $_ and the key is the second element). these are code
blocks to extract and generate a key.
{ $_->[1] } # sort undef as 0 with lotsa warnings
{ $_->[1] // 0 }# sort undef as 0 with no warnings
{ $_->[1] // -Inf } # sort undef to bottom
{ $_->[1] // Inf } # sort undef to top
damian take note!
i dunno if +/- Inf are available/useable for sorting. it would be a
useful feature regardless of how undef behaves. sometimes you need to
force certain values to the top or bottom of sorts and this would make
it very easy to do.
so again, i am on the side of leaving undef's default behavior alone and
using a stricture to get your desirec behavior.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
>>>>> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Actually, you can think of undef pretty much as defining
LP> autovivification. "If you use it as a number, it becomes a number; if
LP> you use it as a string, it becomes a string; if you use it as a hash,
LP> it becomes a hash; ..."
LP> However, that's not really accurate, because:
LP> # perl 5
LP> my $x;
LP> $x->{4} = 1;
LP> print $x; # "HASH(...)"
LP> my $x;
LP> my $y = $x + 1;
LP> print $x; # not "0"
those aren't the same either. in p5 only undef when used as a ref gets
autovivified to the appopriate anon ref. undef when used as a regular
scalar value stays undef. the deref thing was created to handle
assigning to multilevel structures without needing to explicitly set
each of the upper levels (think about how much extra code this one
little feature has saved us all!). since in p5 undef coerces to 0 or ''
as needed (wherever the undef came from), it doesn't change the value of
the undef.
and i agree with luke that the idea is interesting but it should be a
stricture. it is not a good idea for default as it ruins
autovivification. also it would ruin many one liners and short scripts
which don't even use regular strict. perl's ability to dwim undef and
not carp or croak is a good default. just use pragmas to make it
stricter in larger programs.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl grammar for Perl5 -> Perl6
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> And if I were Jewish I'd've said "Oy vey" many times over. :-) or if you were a lazy jewish perl6 hacker you would code: say "Oy Vey!" for 1 .. ; :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: type sigils redux, and new unary ^ operator
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> One of the other reasons I like ^5 is that the uparrowness of it LW> naturally reads as "up to 5". But for containers we could certainly LW> abstract it out to the domain. it also harkens back to apl's iota op which did similar things. iota is an integer range generation operator which returned 1 .. N in monadic (prefix) mode and M .. N in dynadic (infix) mode. and ^ used to be a full up arrow with a shaft (teletypes) and that is vaguely similar to the iota char. but given larry's stretchable imagination i don't think this mnemonic would hurt anyone. you just need to know some computer history. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Hyphens vs. Underscores
>>>>> "DB" == Daniel Brockman <[EMAIL PROTECTED]> writes: DB> You may be right about this. I would be happy if the DB> standard distribution came with a package that enabled the DB> hyphenated identifiers syntax in the lexical block: DB>use hyphenated_identifiers; DB> Hopefully the name of that package won't actually have DB> any underscores in it. this idea would need to be worked out in much greater detail. there are many different identifiers in perl. would all of them be subject to this change? how would a global work if some other module refered to it using underscores but your module used hyphens? would your pragma just do a compile time translation of - to _ when inside identifiers? what about in eval or symrefs? would the translation be done at runtime then? how could that be handled in a lexical way if the foo-name is passed to another module which hadn't used the pragma? or would all symbol lookups just tr/-/_/ beforehand? but that can't be easily controlled in a lexical scope. and i know how you feel about wanting - vs. _ but i have it the other way around. i much prefer _ since it maked the words more readable as _ sorta disappears in the baseline. but then i hate list too so that influences me a trifle. :) but the sickest thing i have done is to remap _ to - and back inside emacs. this was so typing -> is done with both keys shifted and i typed that too often. also that made writing foo_bar easier. so my brain has to swap then when inside emacs vs everywhere else. makes for some odd homicidal twitching sometimes (especially when anyone else dares to type into my emacs :). anyhow, my main point is that IMO this has too many problems with both syntax and unknown semantics that are sure to make some large fraction of us very mad. perl has its style and that it _ for word separation. the evil studly caps is used for module names only (where it does seem to work better than _ would. or maybe we are just so used to it by now). trying to change that in a scoped way will only cause pain somewhere else. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Why submethods
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> But factoring method implementations out into a subroutines is DC> also extremely annoying, because a subroutine doesn't provide the DC> internal conveniences that a method does. In particular, it DC> doesn't have an invocant and so you can't call $.attrs or DC> &.methods. Instead you would have to pass the invocant to the DC> subroutine call as an argument and then call accessors and methods DC> explicitly through that argument. DC> So we need a mechanism that is externally (i.e. from a class DC> interface point-of-view) a subroutine, but internally has the DC> features of a method (i.e. has an invocant). Since it's externally DC> sub-like but internally method-like, we call this useful construct DC> a submethod. so it sounds like to me these are methods private to this class. they can't found by any other class (via inheritance). so what is the external sub interface for? we can see the need for private worker methods and even p5 has a convention of marking such subs with a leading _. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Ways to add behavior
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> One wants to coin a word like "Qlass". Unfortunately "qlass" is LW> too easy to misread as "glass". Oy veh, I'm getting notions of LW> "the qlass is half empty" for a partially instantiated object. [EMAIL PROTECTED], i think you need some immediate mental help. please step back from the keyboard before you commit such a sin again. the next time, i will ask gloria to stick you with a knitting needle. is the smiley :) or (: ? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Fwd: top 5 list needed
>>>>> "RK" == Rob Kinyon <[EMAIL PROTECTED]> writes:
>> > Text-substitution macros would have to be handled in an earlier pass,
>>
>> I still don't see evidence for this. Or maybe I do, but I don't see
>> any reason that the preprocessing pass must finish before the parsing
>> begins.
RK> Mixing C and Perl ...
RK> my $foo;
RK> BEGIN { $foo = '}'; }
RK> #define OPEN {
RK> #define CLOSE $foo
RK> void main (void)
RK> OPEN
RK> BEGIN { $foo = '{''; }
RK> printf( "I don't work\n" );
RK> CLOSE
RK> How does that work out? The issue is that you can interrupt the
RK> parsing process with executable code that can affect the parsing.
RK> That's a good thing. It doesn't work so well with text-substitution,
RK> though. Hence, I would argue it should be disallowed.
from S06:
Macros (keyword: macro) are routines whose calls execute as soon
as they are parsed (i.e. at compile-time). Macros may return
another source code string or a parse-tree.
i see uses for text macros. sure they can trip you up but that is going
to be true about AST macros as well. macros are inherently trickier than
plain coding as you are dealing with another level at the same time. so
the author of your bad example should learn how to do that correctly and
not expect perfect DWIMMERY with an advanced technology.
and that excerpt also means that p6 macros are not done in a
preprocessing pass but at normal compile time as soon as the macro call
is fully parsed. so a text returning macro would run and the compiler
will replace the text of the parsed macro call and start reparsing with
the returned text. there may be some juggling of the main parse tree to
deal with this but it can be done without going too insane. :)
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: top 5 list needed
>>>>> "SL" == Stevan Little <[EMAIL PROTECTED]> writes: SL> On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: >> On 10/18/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: >> >>> 3) Macros. Nuff said. >>> >> >> Not quite. Lispish macros, that is, macros that let you look at what >> you're expanding. SL> To further expand on this, they will be AST-manipulating macros (LISP SL> style) rather than text-replacing macros (C style). my impression is that both styles are supported as you can return either text or an AST (compiled code) from a macro. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
top 5 list needed
i have an opportunity to get an email sent to the faculty of a top CS dept. my goal is to get internal support for a potential YAPC to be hosted there. so i want to present perl 6 to them in a way which will sell them on its academic and cutting edge aspects. your mission is to write some short (2-3 sentence) bullet items that highlight some major area of interest to ivory tower types. some rules: no marketspeak. write it as if you know what you are talking about! :) refer to interesting langs and what we stole from them (and made better) use academic buzzwords! some obvious topics are: grammars (better than anything since snobol :) the new OO design (stole the best from the rest and perlized it) continuations and stuff parrot (a new vm to run and bind them all) so have at it and sell perl 6 to the professors. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Sane (less insane) pair semantics
>>>>> "J" == Juerd <[EMAIL PROTECTED]> writes: J> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200): >> my @args = ( (a => 1), b => 2 ); # is sugar for >> my @args = ( (a => 1), (b => 2) ); J> Please, no. Please let the pair constructor be =>, not (=>). There is J> really no need for this operator to consist of both infix and circumfix J> parts. Please leave the parens for grouping (and in calls: breaking J> recognition). he isn't saying that. the example shows the b => 2 is fine and will be parsed as if it were ( b => 2 ). the point is how pairs in an array are splatted or not to names args. and if i get it right, *hash( @args ) is what is needed to convert an array of pairs to be used as named params. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Sane (less insane) pair semantics
>>>>> "SC" == Stuart Cook <[EMAIL PROTECTED]> writes:
SC> The think I don't like about `foo( *$bar )` is that it's not clear
SC> whether you're splatting a pair, or a hash, or an array, or a complete
SC> argument-list object. This is probably fine for quick-'n'-dirty code,
SC> but I'd like to encourage a more explicit style:
but perl will know the type of the value in $bar and expand/splat it
accordingly.
SC> my $pair = a=>'b';
SC> foo( *%$pair ); # view the pair as a 1-elem hash, and splat that
the % there isn't a hash. perl can see the single pair and deal with
that. the way to make this more readable is to use better variable
names. $pair here is fine and *$pair would mean to splat it into the
named arguments.
SC> my $href = \%hash; # or just %hash
SC> foo( *%$href ); # view the hashref as a hash, and splat that
same as above. perl sees the href and will just DWIM.
SC> sub returns_a_hash { ... }
SC> foo( *%{returns_a_hash} ); # call the sub, view the result as a
SC> hash, and splat that
isn't that what hash() is for? what is returns_a_hash really returning,
a list or a hash ref because you can't return a hash (or can you this
week? :).
SC> my $aref = [EMAIL PROTECTED]; # or just @array
SC> foo( [EMAIL PROTECTED] ); # view the arrayref as an array, and splat
that
again, autoderef would work fine here. i don't see the benefit of the
extra @.
SC> sub returns_an_array { ... }
SC> foo( [EMAIL PROTECTED] ); # call the sub, view the result as a
SC> hash, and splat that
where is the hash? wouldn't you want %{} in your system? and %{} derefs
a hash and doesn't convert a list to a hash. that is what hash() does.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Sane (less insane) pair semantics
>>>>> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> On 10/9/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
>> >>>>> "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
IB> sub foo ($a) {...}
>>
>> works for me. but what about lists and arrays?
>>
>> my @z = ( 'a', 1 ) ;
>> foo( @z ) # $a = [ 'a', 1 ] ??
LP> Yep.
>> my @z = ( a => 1 ) ;
>> foo( @z ) # $a = pair( a => 1 ) or does that need * too?
LP> $a = [ a => 1 ]
LP> You passed an array. The parameter gets an array.
right. and it has one pair inside.
>> same questions for lists (this shows a nested sub call)
>>
>> sub bar { return ( a => 1 ) }
>> foo( bar() )# i would expect $a == ( a => 1 ) since there is
>> # no *
>>
>> foo( *bar() ) # i would expect $a == 1
LP> Yeah, I think your expectations are correct.
LP> Basically, * takes whatever kind of object it is (array, hash, pair)
LP> and pretends that you wrote its contents literally into the argument
LP> list.
that is a succinct statement of how * work but you also have to describe
the cases with pairs and such and no *. and what about the case that
ingo said needed *hash()? i think a list of all the know variations (*
and no *) should be done to keep the behavior clear to all. just more of
the examples we have so far and what gets set in the args for each. it
will also make it easier to create tests for these and to get this into
pugs.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Sane (less insane) pair semantics
>>>>> "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
IB> * "(key => $value)" (with the parens) is always a positionally passed
IB> Pair object. "key => $value" (without the parens) is a named
IB> parameter:
IB> sub foo ($a) {...}
IB> * Unary "*" makes a normal pair variable participate in named binding:
IB> foo(*$pair); # named parameter "a", $a will be 42
IB> * Same for hashes:
IB> my %hash = (a => 1, b => 2, c => 3);
IB> foo(%hash); # positional parameter, $a will be \%hash
IB> foo(*%hash); # three named parameters
IB> Opinions?
works for me. but what about lists and arrays?
my @z = ( 'a', 1 ) ;
foo( @z ) # $a = [ 'a', 1 ] ??
my @z = ( a => 1 ) ;
foo( @z ) # $a = pair( a => 1 ) or does that need * too?
same questions for lists (this shows a nested sub call)
sub bar { return ( a => 1 ) }
foo( bar() )# i would expect $a == ( a => 1 ) since there is
# no *
foo( *bar() ) # i would expect $a == 1
i think i covered most/all of the variations. but this needs to be
hammered down for all of them.
thanx,
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: k, v
>>>>> "J" == Juerd <[EMAIL PROTECTED]> writes: J> Hashes are full of convenience, and Huffman would be proud: J> %hash.keys %hash>>.key J> %hash.values%hash>>.value J> %hash.kvzip(%hash.keys, %hash.values) J> One thing occurred to me: if hashes are worth all this, then why not J> abbreviate "keys" further to "k" (as in "kv"), and "values" to "v" (as J> in "kv"). This would allow us to rename "key" to "k" and "value" to "v" J> too, resulting in: J> %hash.k %hash>>.k J> %hash.v %hash>>.v J> %hash.kvzip(%hash.k, %hash.v) huffman has its limits too. in general having single letter names for anything is a poor idea. it makes it hard to search for, you limit it to only one thing that can use that letter, it isn't always easy to remember what a given letter is, etc. keys and values are short enough and read much better. kv works because keyvalues is clunky and too long. i wouldn't have minded .pairs or .each instead of kv. but alias methods are easy to add. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Who is @Larry?
>>>>> "MF" == Matt Fowles <[EMAIL PROTECTED]> writes:
MF> All~
MF> I have a simple question. Who comprises @Larry? I am fairly sure
MF> that I know a few people in it, but I am highly doubtful that I know
MF> all of them.
if $you_have_to_ask ~~ @Larry {
say 'you are not in @Larry' ;
}
i think i am getting the syntax right.
also i think it should be %Larry since there is no inherent order in the
members and all of them are randomly located. but @Larry is easier to
say out loud.
:)
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Hoping that Params::Validate is not needed in Perl6
>>>>> "DR" == Dave Rolsky <[EMAIL PROTECTED]> writes: DR> Mandatory vs. Optional Parameters DR> This is a pretty straightforward one in P6, I think. Parameters can DR> be marked as required with "is required" like this: DR> sub date ($year, ?$month, ?$day) # positional DR> sub date (+$year is required, +$month, +$day) #named DR> This is ok but frankly I'm not too keen on the fact that for DR> positional subs, the default is required, but for named params it's DR> the other way around. DR> Wouldn't it clearer to just use a leading "?+" for optional named params? there are usually more optional params than required ones when doing named params. so that makes sense to make the default optional. with positional params usually more of them are required (on the left) and some optional ones can be on the right. so marking those optional ones makes more sense. this is all huffman stuff IMO. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: execution platform object? gestalt?
>>>>> "DS" == David Storrs <[EMAIL PROTECTED]> writes:
DS> On Jul 27, 2005, at 6:18 PM, Uri Guttman wrote:
>> this thingy should encompass all about this perl and the world it
>> is in and the shell env is part of that.
DS> How about *?PERL ?
DS> if ( *?PERL.COMPILED_OS eq 'Unix') {...}
DS> if ( *?PERL.CURRENT_OS eq 'Unix') {...}
DS> *?PERL.Grammars{Regex} = $my_bizarre_new_regex_grammar;
i like that choice. all perl knows about itself is in *?PERL.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: execution platform object? gestalt?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Wed, Jul 27, 2005 at 04:27:15PM -0400, Uri Guttman wrote: LW> : then why not name it something like *?ENV (not to be confused with the LW> : shell/exec env which is still %ENV i assume)? LW> Of course, the fact that you have to say "not to be confused with" LW> can be taken as indicating that people will in fact confuse them... you could do it even worse by making the shell env be a method/entry of the perl env (bad syntax ahead): *?ENV.ENV<> but my original point stands in that all this is should be under one builtin and it shouldn't be OS or VM. those should be parts of it and maybe shell env should be part of it too. this thingy should encompass all about this perl and the world it is in and the shell env is part of that. so other choices are the common and lame INFO and CONF. too bad ENV was taken already. i wish we could invent new words. :) bad idea: call it *?WALL cause everything is hanging on the wall. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: execution platform object? gestalt?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Yes, but we just need to be careful not to recreate The Registry. LW> We're looking more for "a place for everything and everything in LW> its place", but we're still trying to understand what that means. LW> As you say, whatever we end up with does have to be extensible, LW> since we don't know all the "places" we'll want ten years from now. LW> It seems to me that the more places we can come up with now, though, LW> the less likely we are to have collisions later, unless our categories LW> are artificial. That tends to argue for separating out VM from OS, LW> and maybe COMPUTER, and NET, unless you think that NET =:= COMPUTER. then why not name it something like *?ENV (not to be confused with the shell/exec env which is still %ENV i assume)? then under that there are methods/hash entries like OS, VM, etc. it is the sum of all the (reasonably) known external things about this perl. OS seems too specific as does VM. they should just be subparts of the full env. this is also more like an intelligent Config.pm it seems. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: method calls on $self
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> to go with everyone else's preferences: LW> use self "." LW> use self "`" LW> use self "·" LW> use self ".." LW> use self "^." LW> use self "i." LW> use self "o." LW> use self "¤." LW> use self "me." LW> use self "self." LW> use self "this." LW> Did I leave anyone out? use self "that." use self "over_there." use self "where_am_i." use self "dis." use self "dat." use self "you." :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: What the heck is... wrong with Parrot development?
>>>>> "SV" == Sam Vilain <[EMAIL PROTECTED]> writes: SV> Please honour his decision to bow out gracefully without turning it into SV> a childish battle of egos. SV> In the meantime let us celebrate 5 years of Dan Sugalski's contribution SV> to the Parrot and Perl 6 project. SV> Three cheers for Dan! hear! hear!! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: (1,(2,3),4)[2]
>>>>> "w" == wolverian <[EMAIL PROTECTED]> writes: w> On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote: >> please don't use <== for simple assignments as it will confuse too many >> newbies and auch. it (and its sister ==>) are for pipelining ops like >> map/grep and for forcing assignment to the slurpy array arg of funcs >> (hey, i think i said that correctly! :). = is still fine for basic >> assignment and everyone will understand it immediately. w> I thought the op is visually so obvious it wouldn't need any w> explanation, even for newbies. w> Too bad what I _think_ is often not what actually _is_. well, = has massive history on its side and almost all commonly used languages use it for assignment (pascal is NOT common anymore, thankfully and lisp isn't common enough :). so there is zero learning curve for that. you do need to learn about perl's precedences which need () for assigning a list. but <== may seem obvious to you and for sure to anyone here but imagining what newbies would make of it boggles me. if there is a way to misunderstand it and abuse it, it will happen. :) so consider it just a style rule that i would encourage. damian should add it to his P6BP book when it comes out next christmas. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: (1,(2,3),4)[2]
>>>>> "w" == wolverian <[EMAIL PROTECTED]> writes: w> On Wed, May 25, 2005 at 01:38:27PM -0500, Rod Adams wrote: >> Or use >> >> @a <== 1,2,3; w> I would just like to say that I like this idiom immensely. w> my @foo <== 1, 2, 3; w> reads extremely well to me, especially since I've always disliked the w> usage of '=' as an operator with side effects. (I'm strange like that.) please don't use <== for simple assignments as it will confuse too many newbies and auch. it (and its sister ==>) are for pipelining ops like map/grep and for forcing assignment to the slurpy array arg of funcs (hey, i think i said that correctly! :). = is still fine for basic assignment and everyone will understand it immediately. the only advantage in the above case is the different prececences of = and <== which allows dropping of parens with the latter. i don't consider that so important a win as to be used often. and they are at equal huffman levels as the =() is matched in length by <==. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: hyperoperators and multi-dimensional datastructures
>>>>> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: LP> On 5/18/05, Anthony Heading <[EMAIL PROTECTED]> wrote: >> Is there a way to target hyperoperators at different axes of a >> multi-dimensional array? This is an attractive feature of >> various APL-like languages, viz. e.g. in J: >> >> a =. 2 5 $ i. 7 - a simple 2-by-5 array >> a >> 0 1 2 3 4 - like this >> 5 6 0 1 2 >> >> >> +/"1 a - sum reduce over axis 1 >> 10 14 LP> [+]<< @a >> +/"2 a - sum reduce over axis 2 >> 5 7 2 4 6 LP> Can't think of any for this one. Or maybe it's this one that I can LP> think of it for, and the other one which I can't. i can't spit out the syntax but here is the conceptual way i would do it. we do have multidimensional slices so we could grab each slice (maybe with zip?) and pass that to [+] and then grab the list of results back into a array/matrix with one less dimension than the original. so it would be something like this: (very wacko pseudo code): @in[ * ; 2 ; * ] ==> map [+] ==> @out that was an (bad) attempt to slice the third entry in the second dimension to be summed. LP> I think we're beginning to re-invent PDL. Poorly. but is there a p6 pdl yet? they may not need much with multi-dim ops, slices, hyper and reduce all built in! also with type int (patform ints), they can get the dense storage needed (but losing any dimensional flexibility). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Plethora of operators
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Here are a few of the things I'll be using reductions for in Perl 6...
DC> 3. To drill down a hierarchical data structure, following the path
DC> specified by a list of keys:
DC> $leaf_value = [.{}] %hash, @keys;
so that would be expanded how? i read it as:
[EMAIL PROTECTED]@keys[1]} ...
but how is . being used? how does the {} wrap each key instead of being
between each one? also can it be used as an lvalue (that would be useful
too in setting a hash from a list of keys)?
DC> 4. To compute RMS values:
DC> $RMS = sqrt [+] @samples »** 2
are those RMS values under the GPL? :)
DC> 6. As a cleaner form of C<< join.assuming(:sep<>) >>:
DC> $joined = [~] @strings;
i like that. can that be done in a "" string (without $() or whatever
the expression interpolator is now)?
DC> 9. To retrieve the first defined value in a list:
DC> $first_def = [//] @list;
that is a good one for initializing stuff. it should become an idiom
like ||= is now.
for those single ops it reads pretty well. if you choose to use it with
multiple levels of hyper/reduce, it should be well commented.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: C<::> in rules
>>>>> "PRM" == Patrick R Michaud <[EMAIL PROTECTED]> writes: PRM> On Thu, May 12, 2005 at 12:33:59PM -0500, Jonathan Scott Duff wrote: >> >> > > /[:w\bfoo bar]/# not exactly the same as above >> > >> > No, I think that's exactly the same. >> >> What does \b mean again? I assume it's no longer backspace? PRM> For as long as I can remember \b has meant "word boundary" in PRM> regular expressions. :-) :-) except in char classes where it gets its backspace meaning back. :-) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: split /(..)*/, 1234567890
>>>>> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> To bring this back to perl6, autrijus' original query was regarding
JSD> $ pugs -e 'say join ",", split /(..)*/, 1234567890'
JSD> which currently generates a list of ('','12','34','56','78','90')
JSD> In perl5 it would generate a list of ('','90') because only the last
JSD> pair of characters matched is kept (such is the nature of quantifiers
JSD> applied to capturing parens). But in perl6 quantified captures put all
JSD> of the matches into an array such that "abcdef" ~~ /(..)*/ will make
JSD> $0 = ['ab','cd','ef'].
JSD> I think that the above split should generate a list like this:
JSD> ('', [ '12','34','56','78','90'])
i disagree. if you want complex tree results, use a rule. split is for
creating a single list of elements from a string. it is better keep
split simple for it is commonly used in this domain. tree results are
more for real parsing (which split is not intended to do) so use a
parsing rule for that.
also note the coding style rule (i think randal created it) which is to
use split when you want to throw things away (the delimiters) and m//
when you want to keep thinks.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> Uri Guttman wrote: DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a DC> shorthand for $/. >> but then what about the different index bases for $42 and $/[42]? i >> don't think that has been resolved (nor has mixing the $1.1 and $1[1] >> syntaxes). DC> Bear in mind that that reply was posted in haste, late at night, after DC> a long day of teaching. We're lucky it as only off by one! %-) DC> But it does raise an important point: the discrepancy between $42 and DC> $/[41] *is* a great opportunity for off-by-on errors. Previously, DC> however, @Larry have tossed back and forth the possibility of using $0 DC> as the first capture variable so that the indices of $/[0], $/[1], DC> $/[2] match up with the "names" of $0, $1, $2, etc. DC> I think this error--unintentional, I swear!--argues strongly that DC> internal consistency within Perl 6 is more important than historical DC> consistency with Perl 5's $1, $2, $3... i would like them to be consistant too. you could also make $/[1] be the same as $1 and not use $/[0] for a regular grab. then $0 and $/[0] could be used for something special. but just 0 basing them both is fine with me. the key is to align them. we all seem to agree this is a massive off by 1 error waiting to happen. we still haven't seen what @larry has to say about mixing $1[$j] and $1.1 syntaxes (let's assume they both use the same index base). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> rule mv { $lastcmd:=(mv) $:=[ ]+ $:= }
DC> rule cp { $lastcmd:=(cp) $:=[ ]+ $:= }
DC> sub lastcmd { return $lastcmd }
DC> }
DC> while shift ~~ m// {
DC> say "From: @{$}";
DC> say " To: $";
DC> }
>> since files and dirs are internal aliases (their names are in <>),
>> shouldn't those match accesses be $/ and $/?
DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
DC> shorthand for $/.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has mixing the $1.1 and $1[1]
syntaxes).
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> grammar Shell::Commands {
DC> my $lastcmd;
DC> rule cmd { $/:= | $/:= }
DC> rule mv { $lastcmd:=(mv) $:=[ ]+
$:= }
DC> rule cp { $lastcmd:=(cp) $:=[ ]+
$:= }
DC> sub lastcmd { return $lastcmd }
DC> }
DC> while shift ~~ m// {
DC> say "From: @{$}";
DC> say " To: $";
DC> }
since files and dirs are internal aliases (their names are in <>),
shouldn't those match accesses be $/ and $/?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote: LW> : On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote: LW> : : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ? LW> : LW> : Ouch. LW> Maybe that's a good reason to switch from 1-based to 0-based LW> $ vars. Not sure what that would do to the current $0 though. LW> Most of the time $/ can stand in for it, I guess, though s/.../$// LW> is visually problematic. We could maybe resurrect $&. or do what i mentioned, not allow mixing of the two styles of match access. i don't see any real win for mixing them. indexing into matched arrays will not be so common to deserve conflating the 0 and 1 based indexing as well as the notations. leave it with $1.1 and $1[0] as being the two styles. you must use literal integers with the former and it is 1 based. you can use any expressions with the latter and it is 0 based. by allowing $1[$j].1 you save only 1 char over $1[$j][0] and would cause major confusion IMO. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
>>>>> "PRM" == Patrick R Michaud <[EMAIL PROTECTED]> writes: PRM> After thinking on this a bit, I'm hoping we don't do this -- at least not PRM> initially. I'm not sure there's a lot of advantage of C< $1.1 > over PRM> C< $1[0] >, and one starts to wonder about things like $1.$j.2 and PRM> $1[$j].2 and the like. i would say that you can use .1 only when all the indexes are literals like $1.2.1. anything else must be a proper index expression on $1 like $1[$j][1]. mixing those would scare me more than anything and it isn't much of a hardship to use the full expression form when you need it. also in perl, indexing isn't used nearly as often as for loops, so if you did grab something that was in a array in some match value, you would more likely loop over it than index into it. so again, the hardship of the index syntax isn't a big deal as it should be rarely needed. just my $1.02. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
>>>>> "J" == Juerd <[EMAIL PROTECTED]> writes: J> Rob Kinyon skribis 2005-05-04 11:20 (-0400): >> $h.print() goes to $h.out >> $h.readline() goes to $h.in >> $h.warn() goes to $h.err >> Making the tri-directional trifecta complete. J> It's sort-of consistent, but I don't like it, because warnings are much J> more complicated than just things that are printed to stderr. also you have the .err backwards. in the case of running a subprocess, the err handle is readonly (the subprocess writes to ITS stderr with warn). so you need another method to make a easy read of the err handle. and you need ways to get at the handles themselves so you can use sysread/write, select/poll and event loops. but i like the idea of returning a single smart object which returns reasonable things in appropriate contexts. remember at all times when discussing i/o for p6 that the goals are to support all forms of i/o in a consistant manner. it is much more than just a polymorphic open or io::all. they only address one aspect of i/o (initiating an i/o request) and that skips read/write/fcntl/event loops and more. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: reduce metaoperator
>>>>> "J" == Juerd <[EMAIL PROTECTED]> writes: J> Juerd skribis 2005-05-04 14:53 (+0200): >> @foo ==> zip <== @bar J> H... J>@quux J> || J> || J> \/ J> @foo ==> zip <== @bar J> /\ J> || J> || J> @xyzzy you are brainfucking me! stop it now!! :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: reduce metaoperator
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> I propose that reduce become a metaoperator that can be applied to LW> any binary operator and turns it syntactically into a list operator. LW> I am currently thinking that the metaoperator is a prefix spelled \\ LW> (though there are certainly lots of other possibilities that I've laid LW> awake all night thinking about). There are the usual suspects like: LW> $sum = \\+ @array; LW> $fact = \\* 1..$num; shouldn't that be s/fact/prod/ ? sure the input makes it a factorial but the general case would be a product. not that what var names you choose matters but i think it would be clearer if used as a real example in some future docs. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
>>>>> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes: AS> On Mon, 2005-05-02 at 22:51, Uri Guttman wrote: >> >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: >> LW> multi sub opensocket ( LW> Str +$mode = 'rw', LW> Str +$encoding = 'auto', LW> Str [EMAIL PROTECTED]) returns IO; >> >> and how will that support async (non-blocking) connects? or listen >> sockets? AS> This is why named aliases for constructors are a bad idea. Nice theory, AS> but bad idea. i am in agreement there. but i am advocating for a proper set of args for socket connections regardless of the name of the sub/method. it could even be in io() provided there is a way to note it is a socket connect/listen and also pass it named args. larry already agreed with the named arguments point. AS> Unless the language allows us to specify that a sub IS an alias for a AS> constructor, e.g.: AS> sub opensocket := IO::Socket.new; 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. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
a or semaphore or what) that internally does a blocking call to select/poll/whatever. this can also have a timeout which can be used too. i think a 'wait' func should be in the language as well as a basic event loop type of thing. they should be standard (at worst core modules) so we don't get different incompatible event loops and related stuff. 'nuff for now. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
>>>>> "MF" == Matt Fowles <[EMAIL PROTECTED]> writes: MF> All~ MF> On 5/2/05, Uri Guttman <[EMAIL PROTECTED]> wrote: >> >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: >> LW> multi sub opensocket ( LW> Str +$mode = 'rw', LW> Str +$encoding = 'auto', LW> Str [EMAIL PROTECTED]) returns IO; >> >> and how will that support async (non-blocking) connects? or listen >> sockets? i assume this is sorta the replacement for IO::Socket which is >> a pure key/value api (except for the shortcut single arg host:port >> which is nice to also support). for async you need to provide a callback >> in the signature (beyond all the other socket args), an optional timeout >> (with its own callback). the callbacks could be defaulted to subs in the >> current module/namespace but the coder may also want an OO callback >> which needs an object and method. another little optional argument is a >> private data field. sure an object callback could handle on a per object >> basis. but what if one object wanted to manage multiple async socket >> connections? each one needs to be identified in the callbacks which is >> what the private data is for. it is passed as an arg to the callback >> sub/method. MF> Currying obviates the need for everything but a sub callback. If you MF> want a callback to a method, curry the object. If you want private MF> data, curry the data. After you are done currying you will have a MF> simple sub to pass in as the callback, the peasants rejoice, and MF> libraries will have a simpler interface. i like the concept but how would that work without actually creating closures? to convert a sub call to a method on an object is code, not just presetting args (which is what i gather currying is). now just using a closure would work but i am not in favor of allocating them just for this when other optional args can do the job. even with the full interface as i want it, you can use closures as your callbacks and keep it shorter. i just don't see the win of more code vs more args. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> multi sub opensocket ( LW> Str +$mode = 'rw', LW> Str +$encoding = 'auto', LW> Str [EMAIL PROTECTED]) returns IO; and how will that support async (non-blocking) connects? or listen sockets? i assume this is sorta the replacement for IO::Socket which is a pure key/value api (except for the shortcut single arg host:port which is nice to also support). for async you need to provide a callback in the signature (beyond all the other socket args), an optional timeout (with its own callback). the callbacks could be defaulted to subs in the current module/namespace but the coder may also want an OO callback which needs an object and method. another little optional argument is a private data field. sure an object callback could handle on a per object basis. but what if one object wanted to manage multiple async socket connections? each one needs to be identified in the callbacks which is what the private data is for. it is passed as an arg to the callback sub/method. LW> We should probably reserve io() for the overdwim and sysopen() for the LW> underdwim, and then not sweat the middle so much. :-) then io would be common blocking connects (which is what most socket connections are) and sysopen is for sockets. why not just support the standard socket subs as in perl5? they could be in a module but they are just simple wrappers around the system calls. i would prefer if opensocket's signature were fully fleshed out with named args (with some defaults). just passing in an extra list is a poor api as there are so many socket options. just read PBP (when it comes out) for damian's take on long arg lists. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Threading in Parrot vs Perl
>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes: RA> I would be dismayed if autothreading used threads to accomplish it's RA> goals. Simple iteration in a single interpreter should be more than RA> sufficient. how autothreading is implemented is distinct from the language feature. a simple version is the iteration mentioned above. but on a multiprocessor with (poosibly prespawned) threads on a large junction, it could be much faster to use parrot threads. but that is just an optimization which uses parallel processing and is not needed for working junction semantics. larry has hinted that autothreading could be parallel underneath if that is supported. maybe choosing the desired implementation would be a pragma. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: alarm() and later()
useful for i/o activity monitoring), disable/enable it and shut it down. so i would say the returned thing should be an event object with those (and other) methods. this implies a core Event class to handle this common stuff. and integrating with other event loops (GUI ones in particular) is handled by creating Event::EventLoopofChoice wrapper modules with the same api as the core perl event class. related topics include using events and continuations/coroutines instead of callbacks. this means a yield type of func is needed (return is yeild in typical event loops). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Unknown level of hash
>>>>> "ZL" == Zhuang Li <[EMAIL PROTECTED]> writes:
ZL> Hi, given an array: @a = ('E1', 'E2', ..., 'En');
ZL> Is there an easy way, hopefully one liner, to do the following without a
ZL> loop? If not, will Perl support this in Perl 6?
ZL> $hash->{E1}->{E2}->...->{En} = 1;
i think perl6 plans to have a way to do this. there is a dim operator to
set dimensions. so it would be something like this:
%hash{ dim @a }
or is $hash has a hash ref:
$hash{ dim @a }
i cc'ed p6l so i can/will be corrected.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> : then how would you assign undef to the only element of the LW> array? would this : be needed: LW> : LW> : @a = ( undef ) ;# same as p5? LW> : LW> : vs. LW> : @a = undef ;# like undef @a in p5? LW> Those would do the same thing under the current proposal, since LW> they're both in list context. If you really, really want a scalar LW> undef value in list context, you could always say LW> @a = scalar(undef); that works. i am starting to see what you mean by undef knowing about context. LW> : in fact i would like to LW> : stop allowing undef as a function with args and have it only return a LW> : scalar undef value. there should be a different op to truly make an LW> : aggregate undefined (and i still don't see a need for that, emptying it LW> : is all that i ever think is needed). LW> We could certainly split out a separate undefine() function. We could LW> even give it an optional argument that says *why* it's undefined, turning LW> it into an unthrown exception, basically. We could use such a function LW> to create interesting values of undef that are context sensitive. that split makes sense as you are now using undef as a special (or as you say below unexpected) value. so it shouldn't also be overloaded as a function operating on variables. just doing the split will make me happier (if you are so benevolent as to care about my happiness :). LW> : in my world undef is a scalar value and nothing else. how do you see it LW> : in p6? LW> undef is not a scalar value, it is the explicit *absence* of a value LW> where you expected one. In Perl 6, undef is the Bearer of Bad News. oy! i feel the pain of the late night phone call. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> As I mentioned in my other message, I think we should not assume that
LW> Perl 6 works the same in this regard as Perl 5 does. There needs to be
LW> something we can return that not only means (), but means also means
LW> "You're hosed! (And here's why.)" And I think we can make undef mean
LW> that if we make it lazily sensitive to scalar/list context (much like @a
LW> itself can be lazily sensitive to context).
LW> Hmm, maybe it would simpler to just tell everyone undef is a special empty
LW> lazy array that refuses to produce a value no matter how you ask.
why use undef for the error code? isn't this what exceptions are for? or
setting $!? i actually use naked return as a postive thing in stem
(string return values are bad and have the error string. it is
consistant so it works). the problem with returning undef (or naked
return) is that it is in-band data. now you could do a naked return but
error thing. and then the called has to check for that property each
time. but what does that mean when you do this (bad p6 code):
sub return_error { return but error }
my @a = return_error() ;
is @a empty or what? how do you see the error in @a?
i just don't like seeing undef used for error handling as it has too
many other uses (even if i did it in stem). just make undef a scalar
value and not a function nor a error marker.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> That being said, in Perl 5, if you say LW> @a = undef; LW> you don't get an undefined array. I'd like to make undef smart enough LW> about list contexts that @a actually does end up undefined in Perl 6. LW> That is, in scalar context, undef is a scalar value as in Perl 5, but LW> in Perl 6, undef in list context means "there isn't anything here if LW> you try to look for it", so it's more like () in Perl 5, except that LW> it also undefines the array if it's the only thing in the array. then how would you assign undef to the only element of the array? would this be needed: @a = ( undef ) ;# same as p5? vs. @a = undef ;# like undef @a in p5? i have always railed against undef on aggregates as it leads to using defined on them which is not the same as checking if an aggregate has any elements. i see that often in newbie code. in fact i would like to stop allowing undef as a function with args and have it only return a scalar undef value. there should be a different op to truly make an aggregate undefined (and i still don't see a need for that, emptying it is all that i ever think is needed). in my world undef is a scalar value and nothing else. how do you see it in p6? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: New S29 draft up
>>>>> "MD" == Matt Diephouse <[EMAIL PROTECTED]> writes: MD> Uri Guttman <[EMAIL PROTECTED]> wrote: >> >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> oct and hex are arguably misnamed, since most functions are named by LW> what they produce, not by what they take as input. I don't know what LW> the replacement should be, though. Maybe it's not worth fixing. >> >> from_oct, from_hex which state what they do? or a more general >> from_base( 16, $hex )? and that could be curried into from_hex(). MD> 0xFF.dec() MD> $num.dec() MD> $num.hex() MD> $num.base($n) MD> ? MD> I believe that some of these can already be handled by C<.as()>. MD> I would like for this to be addressed. This is one item that has MD> always confused me about Perl 5. wrong direction. p5's hex and oct parse strings into numbers. .as converts numbers to string format. larry's point was that the p5 names were misleading as they didn't return what their names implied they did. my suggestions were to add 'from' to make that conversion explicit. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: New S29 draft up
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> oct and hex are arguably misnamed, since most functions are named by LW> what they produce, not by what they take as input. I don't know what LW> the replacement should be, though. Maybe it's not worth fixing. from_oct, from_hex which state what they do? or a more general from_base( 16, $hex )? and that could be curried into from_hex(). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: reset() and S29 -- obsoleted?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: LW> : One function I noticed on the S29 list was reset(). With lexically scoped LW> : variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely LW> : deprecated". Can we remove the vagueness and deprcate it completely? LW> Yes, please. i have seen p5 newbies ask about using it. oy!! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: The S29 Functions Project
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> I can tell you that I want both selects to be dead, but again, I'll LW> have to translate Perl 5 to something. But some of these things LW> can probably be translated to things like LW> Perl5DeprecatedEmulationDoNotUseEverEverAgain::select(MyHandle); LW> Though we might just be able to resurrect the other select through LW> the magic of MMD. Bitmaps of file descriptors just aren't the wave LW> of the future though. with parrot supporting real async i/o (file and network) and a core event loop, we can allow those features to be exposed in perl6. this means dropping 4 arg select is easy. in some rfc's of mine (i have to look them up) i proposed some event stuff but as you state that hasn't been addressed in any A's yet. this could be loaded from modules and be written in parrot/perl6 so it doesn't be in the core lang but it still would be useful to spec it out so that we have a good api that is easy to use. LW> Given the example of select above, I guess for things like the LW> OS dependent calls, we also have the option of demoting them to a LW> global module that you *can* import but can also get at through the LW> package name. That is, the package is automatically there. Arguably, LW> a lot of these should be in POSIX:: or some such. Maybe we want to LW> hide abstractions like "POSIX" though in favor of sorting out the LW> functionality some other way. i am not sure if posix has an event api. but there is event.pm to look at, as well as the libevent library (which wraps several different kernel event api's). but they probably won't be compatible with parrot's event core (which is designed by dan). anyhow this area needs to be addressed from the api point of view and then it can be decided where it resides, in a module (best bet IMO) or core language. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: "The fate of reduce() in Python 3000"
>>>>> "AP" == A Pagaltzis <[EMAIL PROTECTED]> writes: AP> [Prime quote: "I think having the two choices side-by-side just AP> requires programmers to think about making a choice that's AP> irrelevant for their program; not having the choice streamlines AP> the thought process."] it just proves that guido doesn't like to think more than he has too :). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctions - feedback and desires
>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes: >> >> My understanding is that all lists are conceptually >> lazy. "any(2..Inf)" is perfectly valid. >> >> RA> The list being fed into the junction can be lazy. But I believe that RA> the list gets iterated over completely in the creation of the RA> junction, so C< any(2..Inf) > is valid, but melts your processor RA> similar to C< sort 2..Inf >. i was under the impression that junctions could be smart about ranges like that and do it correctly. sort can't possibly handle that but some junctions and ranges would work fine. it isn't hard to convert that (with the proper boolean) to a boolean expression internally. RA> My impression has been that after the creation of a junction, the RA> values that junction has are set in stone. Allowing some form of lazy RA> list to add values at will seems a bit counter to me. But if @Cabal RA> think it's okay to have lazy junctions, I won't argue with them. lazy only when you can actually cheat IMO. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: finding the name of &$SUB ?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Tue, Mar 08, 2005 at 01:55:07AM -0500, Uri Guttman wrote: LW> : why not leave it as $?SUB but it is an object and you use the .name LW> : method? LW> Uh, yeah. Obviously, 11 pm is still to early in the day for me... ^^ or too late? :) (i wouldn't normally spellcheck you but you are usually very accurate and this must mean something) and 2am is bedtime for me now. LW> : this way you won't clutter the namespace and you can add more LW> : methods like .signature, .returns, etc. LW> In which case $?SUB and &?SUB are probably just different names for LW> the same object, or we just go with &?SUB, and assume people will be LW> able to figure out from the lack of parens that &?SUB.name is not LW> calling the subroutine. Or I suppose we could go with straight $?SUB. LW> Or both. Or one. Or the other. Or both. Or... burble! i know how you feel. now slowly back away from the keyboard and say nighty night to us all. we need a refreshed larry and not one who pulls all nighters like some college kid (or damian :). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: finding the name of &$SUB ?
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Mon, Mar 07, 2005 at 09:49:04PM -0800, David Storrs wrote: LW> : Is there a way to find the name of &?SUB ? It would be useful for LW> : error-logging and -reporting. LW> $?SUBNAME, I think, unless &?SUB just stringifies to that. I guess LW> it's a good question whether &foo should stringify to "foo" or LW> "&foo" or something else including the signature. In which case, LW> &?SUB might stringify to a lot of info, and $?SUBNAME would more LW> reliably be just the short name. Maybe we also need a way to get LW> the long name explicitly. why not leave it as $?SUB but it is an object and you use the .name method? this way you won't clutter the namespace and you can add more methods like .signature, .returns, etc. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: S06: Pairs as lvalues
>>>>> "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes: IB> Hi, IB> quoting http://dev.perl.org/perl6/synopsis/S06.html: >> Pairs can be used as lvalues. The value of the pair is the >> recipient of the assignment: >> >> (key => $var) = "value"; >> >> When binding pairs, names can be used to "match up" lvalues ^^^ >> and rvalues: >> >> (who => $name, why => $reason) := (why => $because, who => "me"); note the binding := which is not the same as =. binding is similar to aliasing. in the above case it matches the names and assigns the new values accordingly. i am not sure what happens if you have more pairs on one side or the other (does it behave as hashes would and just overwrite the common keys and assign new ones as needed?) IB> that's really convenient, but what will the following code do? IB> my $x = (a => 42); # $x is a Pair. IB> $x = 13; # Is $x now the Pair (a => 13) or IB> # the Int 13? $x is 13 now as you assigned it. to assign the value of the pair as an lvalue i think you would do: $x.value = 13 ; uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
>>>>> "PRM" == Patrick R Michaud <[EMAIL PROTECTED]> writes: PRM> On Fri, Feb 25, 2005 at 12:54:20AM -0500, Uri Guttman wrote: >> >>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes: >> RA> Uri Guttman wrote: >> >> that fixes Stéphane's problem with my yall proposal. and yall solves the >> >> unary my problem. :) >> >> RA> Stop misusing "y'all" before this Texan has to hurt you. RA> And y'all wonder why we hate you damn yankees. Can't even speak RA> properly up there. >> RA> :-) >> >> be glad your (losing) battle with damian was on email. between his VERY >> southern accent and yours ... :) PRM> Indeed, Damian might just say that the answer to this problem is PRM> to *again* use junctions, and eliminate the 'm' in C, leaving: PRM>y all($x, $y, $z) = 1..3; PRM> Sorry, couldn't help myself. :-) :-) :-) AAGG!! but the () snuck back in and one of the goals is to remove them. actually i like the () to mark a list context. so would it be: y all $x, $y, $z <== 1..3; and all() doesn't have ordering since it is set-like (hi rod! :), so how do 1..3 get assigned? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes: RA> Uri Guttman wrote: >> that fixes Stéphane's problem with my yall proposal. and yall solves the >> unary my problem. :) >> >> RA> Stop misusing "y'all" before this Texan has to hurt you. RA> And y'all wonder why we hate you damn yankees. Can't even speak RA> properly up there. RA> :-) be glad your (losing) battle with damian was on email. between his VERY southern accent and yours ... :) you should try to meet him at a conf this spring/summer. RA> We should instead have a list attribute, so we can say: RA> $x, $y, $z are mine! mine! mine!; RA> (Must be spoken like a three year old when read.) but what does unary postfix ! mean? and does are distribute across mines? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
>>>>> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: LP> Rod Adams writes: >> Luke Palmer wrote: >> >> >We have discussed making equals low precedence enough to eliminate the >> >parentheses in the standard swap: >> > >> > $x, $y = $y, $x; >> > >> $x, $y <== $y, $x; LP> Heh, oh yeah. I guess I wasn't so off suggesting <-, then. LP> Well, there's half the problem. Now we just need to determine if LP> 'my' can leave its post as a unary declarator. that fixes Stéphane's problem with my yall proposal. and yall solves the unary my problem. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
>>>>> "SP" == Stéphane Payrard <[EMAIL PROTECTED]> writes: SP> On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: >> >> Giving scoping functions the status of list operators >> would allow to drop parentheses when not used in conjunction >> with initializer so one could write: >> >> my $a, $b, $c; >> >> instead of >> >> my ($a, $b, $c); SP> Too bad that in English there is no plural for my. SP> In French it would work fine SP> mon $a; # French for C, singular SP> # C as a list operator SP> mes $a, $b, $c; # French for C, plural well, our is a form of a plural my but it is not a plural of the things that are mine/ours but rather the group owning it (which is the namespace). so we can try: all, mine, these, those, them and the brooklynese variants: dese, dose, dem. :) southern variant: y'all or yall. maybe yall is expanded as yall mine! yall $a, $b, $c = 1 .. 3 ; larry? uri PS if this gets in, i will stop being so bigoted against southern accents! :) -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctions, Sets, and Threading.
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> my %seen is shape(IO) of Bool; # %seen maps IO objects to boolean
values
DC> while get_next_input_stream() -> $in {
DC> next if %seen{$in};
DC> $text ~= slurp $in;
DC> %seen{$in} = 1;
DC> }
but that is doable in perl5 as well. $in would stringify to a unique key
and you can test for it. better is if you used those keys as io handles
and that is where perl5 loses. say you had to process a bunch of handles
(say sockets which aren't going to be closed) and wanted to pass the
ones that still need processing. then you would do something like this
(perl5ish syntax which won't really work):
my %handles = map { open( $_, '<' ) or die "foo" => 1 } @files ;
later on some code could clear a handle's flag but leave the file open
and you can find the handles you want easily.
process_handles( grep( $handles{$_}, keys %handles ) ) ;
my current workaround for this problem is to have a hash that maps a ref
to itself! the key is a stringified ref and the value is the real
ref. having the key be any value (but internally strringified for
hashing) is very needed.
>>> But, y'know, this one almost convinces me. Especially when you consider:
>>>
>>> sub func ($i, $j, $k) {...}
>>>
>>> @x = func($a, [EMAIL PROTECTED], @z);
DC> Which would again be more obvious as:
DC> @x = func($a, every(@y), @z);
i agree. i like the names there as it reads better.
DC> PS: I'll be away for the rest of the week, but will happily continue to
DC> argue when I return. ;-)
so where do you go for an argument when you are away?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Octals
>>>>> "J" == Juerd <[EMAIL PROTECTED]> writes: J> And for symmetry, can we get 0d and \d for decimal, for those cases J> where you want to be explicit? in a regex \d is a digit, so that isn't a good idea. it would be better to require \0d. the others also need a base designator character so decimals don't need a shortcut. and why would we need 0d123 as a literal? there are no ambiguities and decimal is the simple and obvious default. i just don't think we need symmetry in all possible cases. J> I think \777 should be chr(777). As should \0d777, should you want to J> document that it's really not octal. (Important mostly the first year J> after the first release.) too much history with \777 being octal. i think that should be a compile time error (die) as it is illegal. but p5 currently just stops parsing when it sees an out of range char. this is a silent bug IMO. at least a warning should be generated. but the other side will want support for a single char value and not requiring leading pad 0's. perl -e'print "\xQW"' | od -c 000 \0 Q W perl -e'print "\xaQW"' | od -c 000 \n Q W perl -e'print "\777"' | od -c 000 307 277 i don't know what is happening there. so if you have no valid value chars or are out of range (as with \777), then i would want to know as i made a mistake. leading pad 0's can be skipped if some legal value is found. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junction Values
>>>>> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote: NC> Given this: >> my $x = set(1..3); >> my $y = set(1,3,5,7,9); >> my $n = 2; >> >> $x | $y # set(1,2,3,5,7,9) >> $x & $y # set(1,3) >> $x - $y # set(2) >> !$x # set(none(2));-) NC> I don't understand this last line, even given the context of the NC> preceding three. Why is it none of 2, rather than none of NC> something else? my guess is a typo and $x should be $n. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Fun with junctions
>>>>> "DW" == David Wheeler <[EMAIL PROTECTED]> writes: DW> On Feb 15, 2005, at 11:06 AM, Larry Wall wrote: >> So maybe the actual pragma name is >> >> use qubits; >> >> Note: the pragma is not "use junctions", since they're already allowed >> to use junctions, as long as they don't try to observe them. :-) DW> To quote Noah, what's a qubit? RGGTTT :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Closure trait for loop entry
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> : JG> The first time use_first is called it will print LW> : JG> entering loop LW> : JG> 1 LW> : JG> 2 LW> : JG> leaving loop LW> : LW> : JG> but subsequently it will print LW> : JG> 1 LW> : JG> 2 LW> : JG> leaving loop LW> : LW> : that seems to imply that FIRST is a program level first time action. i LW> : think it does what you want and is executed on the first iteration of a LW> : loop, each time the loop is started up. it is symmetrical to LAST in LW> : that way. it should print the former text each time the sub is called. LW> What's going on here is that the loop body is a closure that is LW> cloned upon entry to the loop (you're logically passing a closure LW> to the "for()" function that implements the loop), so if there's a LW> FIRST inside, it runs each time the loop is initialized. Likewise LW> state variables are logically regenerated for closure clones, so if LW> use_first() above wants to have a state variable that is maintained LW> from call to call, it must put it *outside* the loop. i am not clear on the actual answer. my take on what you said is that i was right, FIRST will execute at the beginning of each time the loop is entered which is what joe wants. am i correct? LW> Also, note that a LAST block, if any, has to be called from within LW> the implementation of for(), since only for() knows when it's done LW> with the loop as a whole. similarly for FIRST as only for() knows when it starts up the loop again and reinitializes the counter. LW> It will be an interesting problem for the optimizer to figure out LW> how to avoid cloning closures that are passed only to synchronous LW> loop-controller functions such as for() and not otherwise used LW> asynchronously. Perhaps the signature of for() can make some LW> guarantees about not squirreling away the closure pointer in LW> some weird place. This is perhaps related to the issue of timely LW> GC on pointers you know haven't been copied into outside storage. i see the problem. if the loop body refers to lexicals declared outside it, it looks like a classic perl5 closure and would need to be cloned. what about the fact that for() will be called in effectively a void context? a classic closure makes sense only when the code ref is saved or possible called immediately via (p5) ->. for() is called immediately but with a different signature as you said. the void context would help the optimizer since you don't save the code block for later reuse, no cloning should be done. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
