Statement modifiers
Hi all, just dropping in with some thoughts I had while reading the archive of this list. I've tried to search the list but it's difficult with perl keywords being common english words and google unable to search for punctuation; if the stuff below has already been fully resolved, I'd appreciate some pointers to the corresponding messages. :-) Anyway, let me start by adding to the statistics: I very much like method ~ $obj and $arg ~ sub and I like support of Unicode aliases for operators as long as plain ascii versions remain available too. Now the real subject.. has the issue of multiple statement modifiers already been settled? I saw some mention it wasn't going to be supported, but also mentions of how it would be useful; I can think of such a situation myself: .method when MyClass given $obj; as alternative to: $obj.method if $obj.isa(MyClass); except without duplicating $obj, which may be worthwhile if it's a longer expression. If multiple modifiers are really a no-no, then I think at least the conditionals (if, unless, when) could be made lowest-precedence right-associative infix operators, and leave the status of statement modifier for loops and topicalizers. This would mean that the above would be valid, and also things like: .. if .. if .. for ..; But that multiple nested loops would be illegal using modifiers and would require a real block. (which makes some sense, since it's hard to think of a construction where multiple loop-modifiers would be useful: if you have ... for @a for @b then you'd be unable to use the @b-element since $_ would be the loop var of the inner loop) I also think this gives a nice symmetry of various operators that only differ in L2R/R2L and precedence (plus the ability to overload ofcourse): $x and $y $y if $x $x or $y$y unless $x $x . $y $y ~ $x $x ( $y ) $y ~ $x Which I personally think is a Good Thing: I like to structure my code to put the most important part of a statement on the left and exceptional cases and details on the right. Having multiple operators with different precedence (, and, if) also helps avoiding lots of parentheses, which I think is another Good Thing because they make code look cluttered. When I want visual grouping I prefer to use extra whitespace. Perhaps it's not as maintainable, but it is more readable imho. Hmmm.. and I just realized.. is something like 'print while ;' still available in perl 6? And if so, that means the while-loop would topicalize in this case? What would the criterium be for this case? (I hope not the kludge it is right now in perl 5 ;-) -- Matthijs van Duin -- May the Forth be with you!
The Judy algorithm
I think this might be interesting to some of you... Judy is a general purpose dynamic array implemented as a C callable library. Judy's speed and memory usage are typically better than other data storage models and improves with very large data sets. http://judy.sourceforge.net/application/10minutes.htm http://judy.sourceforge.net/application/ http://sourceforge.net/projects/judy I've appended a few extracts from the 10minutes.htm url given above. Tim. A (CPU) cache-line fill is additional time required to do a read reference from RAM when a word is not found in cache. In today's computers the time for a cache-line fill is in the range of 50..2000 machine instructions. Therefore a cache-line fill should be avoided when fewer than 50 instructions can do the same job. (Modern machines tend to pipeline writes to RAM. They often take no additional time in the Judy design.) Some of the reasons Judy outperforms binary trees, b-trees, and skip-lists: * Judy rarely compromises speed/space performance for simplicity (Judy will never be called simple except at the API). * Judy is designed to avoid cache-line fills wherever possible. (This is the main design criteria for Judy.) * A b-tree requires a search of each node (branch), resulting in more cache-line fills. * A binary-tree has many more levels (about 8X), resulting in more cache-line fills. * A skip-list is roughly equivalent to a degree-4 (4-ary) tree, resulting in more cache-line fills From a speed point of view Judy is chiefly a 256-ary digital tree or trie (per D. Knuth Volume 3 definitions). A degree of 256-ary is a somewhat magic N-ary for a variety of reasons -- but mostly because a byte (the least addressable memory unit) is 8 bits. Also a higher degree means reduced cache-line fills per access. You see the theme here -- avoid cache-line fills like the plague. The presence of a CPU cache in modern machines has changed many of the ways to write a performance algorithm. To take advantage of a cache, it is important to leverage as much as possible. In a Judy tree, the presence of a cache results in 1..3 (or more) fewer cache-line fills per lookup than would be possible without a cache. Judy adapts efficiently to a wide range of populations and data set densities. Since the Judy data structure is a tree of trees, each sub-tree is a static expanse that is optimized to match the character or density of the keys it contains. Notice that to insert or delete a key is almost as simple as setting or clearing a bit.
Re: Lua - ParrotVM, question on PMCs
K Stol wrote: PMCs are used to implement typeless languages ... can be used. Coercing values is the way the Perl* classes work. OTOH you could have a PMC, that is a 128bit integer implementation. Is it true, that typeless languages only use PMC for their data, or could an integer in perl6 also be stuffed in an integer register? When the source code says so (my $i is int (or whatever the syntax now is)) - or when the optimizer is clever enough and recognices only simple integer usage of a var, it will be stuffed into an I-register. Am I right about this stuff, or have I misunderstood something? PMCs can/must do coercing, especially for typeless languages. They can implement a total different behaviour - its up to the lanugage. Klaas-Jan leo
Re: Parrot 0.0.10 feature freeze
Steve Fink wrote: As for the code name -- I'm personally leaning towards the Juice suggestion. I'm not sure why, but it just sounds kinda cool. And it does fit well with the -Oj flag. Parrot -- now with extra juice! Or something. Opinions? Too much honor ;) What about one of these: http://www.wordsmith.org/anagram/anagram.cgi?anagram=parrot+teninclude=exclude=d=n=m=source=adva=nl=nlanguage=englishwhere= Starting with Anagram for parrot ten A PENT TORR A TERN PORT A TERN TROP A RENT PORT A RENT TROP A PERT TORN A TERR PONT PARTNER TO ... PAR ROTTEN ... TAT RE PORN TAT ERR PON oops, leo
Re: Parrot 0.0.10 feature freeze
Steve Fink wrote: As for the code name -- I'm personally leaning towards the Juice suggestion. Given that Juice is already the name of an existing (but apparently defunct) virtual machine, you might want to consider another choice. The home page appears dead: http://www.ics.uci.edu/~juice/ but you can find it in the wayback machine: http://web.archive.org/web/*/http://www.ics.uci.edu/~juice/ A brief citation can also be found at: http://cliki.tunes.org/Juice I wasn't paying attention when the original list got submitted, so sorry if these are redundant: Bereft (more Monty Python) Choir Invisible (ditto) Nailed to the Perch (is there an echo in here?) Boutique (ok, it stopped being funny already) Norwegian Blue (all right, I'll stop...) Mister Polly (oops, I did it again.) Lovely Plumage Voom! Just Resting Notlob (ok, that's pretty much the end of the sketch...) Chimera (rejected name of Parrot) Pylon (see above) Perth (urm... see above the above) The Real Macaw (also the name of a bar) The Vaults of Madagascar (more from the O'Reilly book) Fractious Culture (O'Reilly - and would make a good band name, too) Gnope (again, O'Reilly) The Snake That Broke the Camel's Back (slashdot) Jarrot (yes, same book) Your Ad Here! (my favorite!) Pretty Bird (d'oh) -- David Cuny
Re: Objects and classes, try 3
On Sun, Mar 09, 2003 at 02:08:02PM -0500, Dan Sugalski wrote: At 1:52 PM -0500 3/9/03, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS * Objects have properties you can fetch and store by name DS * Objects have methods you can call DS * Objects have attributes you can fetch and store Well... I'm not sure about that. Classes can store data in object attributes, but there isn't necessarily a public API through the PMC to do this. Basically if you can get to it through a PMC's vtable, it was on the Objects have list. I'm not sure that storing into an attribute should be easily doable from the outside. Methods have access to an object's internal bits, so the class methods can poke into slots in the attribute array directly, which is probably how they'll work. Surely thats a high-level restriction that Perl will impose. Why should Parrot impose that restriction ? Other languages may want to access attributes from outside the class. Graham.
Re: languages\BASIC reorg
Clinton A. Pierce wrote:
I re-organized the languages\BASIC tree into compiled and
interpreted sub-trees.
Please, update MANIFEST and s#\#/#g in testrun.pl (the backwards don't
run). Also the quickstart section is misleading.
Could you please include a Makefile{,in}
And another one, did you try to run the PASM through imcc - it does
speed things up drastically:
#!/usr/bin/perl -w
#
my $parpath='../../../languages/imcc/imcc'; # use config, $(EXE) ...
system($parpath @ARGV TARG_test.pasm);
TIA,
leo
Re: [perl #21520] [PATCH] Move print ops to PIO subsystem
Jürgen Bömmels (via RT) wrote: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #21520] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21520 Hello, here is something that sometime needs to be done: Move the IO from mixed stdio/PIO to pure PIO. Great, thanks. All test pass on i386/linux except one: hacks_2.pasm: This tests an open of an filediscriptor and a print to. To get this work open has to be ported from stdio to PIO. I will look into this when this patch is in. Works for me(tm). I had 3 different failing tests: nci_6 - 8. The problem was, that the tests print to stdio too, which get's now mixed up by the bufferd output of PIO_printf. I changed the tests and the shared lib to both print to stderr, so that the output is in sync again. native_pbc/*: These are not really falling, but because of the change in core.ops and io.ops the fingerprint changes and so it fails. So the pbc files need to be regenerated. What is the best way to submit the new pbc-files? I did post a script some time ago. Anyway: I'll commit it as: tools/dev/mk_native_pbc. bye boe leo
Re: Parrot 0.0.10 feature freeze
Steve Fink wrote: [...] does fit well with the -Oj flag. Parrot -- now with extra juice! -Oj Simpson? Parrot -- now get away with murder! :-) A
Re: Lua - ParrotVM, question on PMCs
- Original Message - From: Steve Fink [EMAIL PROTECTED] To: K Stol [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 12:32 AM Subject: Re: Lua - ParrotVM, question on PMCs [Arg. My outgoing mail was messed up last week when I sent out a whole bunch of emails just before leaving for Hawaii, so this message was very delayed.] On Feb-24, K Stol wrote: Hello, As Lua is a typeless language, variables can take values of any type. This has to be checked during runtime, obviously. My guess is that variables should be implemented on parrot as PMC's. I have tried to read as much as possible on PMC's, but it's still a bit unclear. What I have understood is that PMC's are like C unions, but all fields are accessible (or something like that). Not really. PMCs are really anything other than an int, a float, or a string. They all implement a common set of operations in a way that makes sense for the datatype they represent -- so the add operation for a complex number PMC, for example, would add the real and imaginary parts together. I studied some pasm examples more closely, and also I got some more understanding of all this. Now I think it's something like this: PMCs are used to implement typeless languages (most obvious example is, of course, Perl6) So whenever a PerlInt is created to store some integer value, and this PMC is used in some string or something, this PerlInt PMC has some way (=method) to convert the Integer to a String. Also, when a string is assigned to a PerlInt, this PerlInt becomes a PerlString (right?) So for some typeless language L that has for example 3 datatypes (int, float, string) , L's datatypes could be implemented as these PMCs: LInt, LFloat, LString (for example). All coercion rules can be programmed into the PMC, for example, the rule how to convert the integer to a string, can be programmed literally into the int_to_string() method of the LInt PMC. Is it true, that typeless languages only use PMC for their data, or could an integer in perl6 also be stuffed in an integer register? Am I right about this stuff, or have I misunderstood something? Klaas-Jan Are there any good tutorials on PMC's somewhere? I looked in the mailing lists, but I couldn't find much there. The most relevant documentation for PMCs is in docs/vtables.pod. Knowing to look there requires you to know what a PMC is and even something about how it's implemented, which isn't very nice. We really ought to have a pointer to it somewhere. You will want to implement variables and values with PMCs, but the names of the variables will be elsewhere, in a symbol table. The best pointer I can give you for that right now is the Symbol table ops section of docs/core_ops.pod. Although it's possible that you can manage your own compile-time symbol table and never need to look up names at runtime; I'm guessing Lua is too dynamic for that, but I don't know.
Re: Object spec [x-adr][x-bayes]
On Sun, Mar 09, 2003 at 03:46:39PM -0500, Dan Sugalski wrote: Presenting internal state in a rational form is a rather significantly different thing than being able to serialize things, and I don't think it's feasable, unfortunately. It'll require too much consistency to be useful (as I don't think you'll get that consistency) and you'll likely end up just dropping back and grovelling over the internal nasty bits anyway. Serialization is a specific and very useful application, and one that we need in general (otherwise we won't be able to have constant PMCs) so it'll be there, but being able to expect to walk a pool of heterogenous objects from a variety of different object systems is more than I think you're likely to get. More to the point, it's a level of complexity I'm unwilling to commit to, because it's not needed for our required functionality, useful though it might be. (Even in the limited circumstances it's likely to be available in) Forgive me for jumping into the conversation late, but I'm not really sure where this complexity is coming from. I've worked quite a bit with serialization mechanisms in Python and other languages, but maybe I'm missing something. In Python, we just have a method named __getstate__ that must return one of the basic types: dict (hash), list (vector), None, int, string. The marshaller must know how to write these things to a file, send them across a socket via some protocol, or whatever. The dicts and lists can contain other objects, of course, and those will be queried for their state, and so on. This isn't really that hard to implement, IME, and it's never been an issue to put the state of an object into these datastructures. If a method doesn't have a __getstate__, we just grab its attribute __dict__. This bit is obviously not friendly to other languages, but it's also unneccessary - Each language can implement a default `get_state'-type method on its root object PMC that can either return something useful or crash out (Python's would check for self.__getstate__, and if not found, return self.__dict__). Unserializing basically instantiates an object without initializing it and calls __setstate__(data) on it where `data' is what was previously returned from its __getstate__ call. I'm not on a crusade to get a cross-language serialization mechanism, but it would be very convenient and it doesn't seem it would require that much hassle. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: Objects and classes, try 3
At 10:22 AM -0500 3/10/03, Christopher Armstrong wrote: On Sun, Mar 09, 2003 at 01:07:46PM -0500, Dan Sugalski wrote: * Objects have properties you can fetch and store by name * Objects have methods you can call * Objects have attributes you can fetch * You can fetch a hash of all the properties * When fetching or storing a generic property, you may call a method instead, as methods win * You can fetch a method PMC from the object * You can fetch the object's Class PMC All of these have vtable entries in the PMC: get_prop, set_prop, get_attrib, set_attrib, get_prop_hash, get_method, call_method, get_class. (Some already have names, I'm doing this from memory) No, you can't set a method or the property hash from an object PMC. Arguments with good reasons to do so will be cheerfully read and not implemented. :) How about target languages allow you to do this? :) (Python!) Nope! Python's attributes map to Parrot's properties. I'm going to add in a translation matrix/glossary to the PDD when I write it, as I keep getting confused as to who calls which thing what. :) Still, I've given up on enforcing no-outsite-writing to attributes. I'm going to add in a set_attrib vtable method, and let alternate-object systems have at it. (And you're right, I was getting interface and implementation sloppy before, which is a mistake I'm trying not to make in the actual spec) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The Judy algorithm
Tim Bunce wrote: I think this might be interesting to some of you... http://sourceforge.net/projects/judy Indeed. Maybe someone can wrap up list.c and/or hash.c and compare performance for typical usage patterns - however they look like - but mainly linear in arrays I presume. t/src/intlist and t/pmc/intlist have some stress tests. leo
Re: The Judy algorithm
At 10:37 + 3/10/03, Tim Bunce wrote: I think this might be interesting to some of you... Judy is a general purpose dynamic array implemented as a C callable library. Judy's speed and memory usage are typically better than other data storage models and improves with very large data sets. http://judy.sourceforge.net/application/10minutes.htm http://judy.sourceforge.net/application/ http://sourceforge.net/projects/judy I've appended a few extracts from the 10minutes.htm url given above. This looks very interesting (particularly for a project I'm working on now, which was the reason I looked into this right now), but the project really seems quite silent if not dead. Some more info: Only HP-UX and Linux seem to be supported out of the box (only tried Linux and Mac OS X). I adapted the indexSL program to just be a filter and piped /usr/share/dict/words through it. Then let it run with Valgrind. That reports: ==11948== LEAK SUMMARY: ==11948==definitely lost: 11 bytes in 1 blocks. ==11948==possibly lost: 26 bytes in 2 blocks. ==11948==still reachable: 0 bytes in 0 blocks. Not a whole lot of leakage, but still. I got the configure script into believing that MacOS X is really Linux. Compilation then halts on byteswap.h being missing. I didn't look any further then. The forum seems to be missing answers from the primary (only) developer. Bug reports with patches have not been applied (such as trivial bashisms in the configure script). The application directory contains some nice examples that might be applicable to Parrot: especially the best of both worlds approach in which Judy arrays are used to handle hash value collisions on a rather small (256 or 64K keys) hash. Just my 2 eurocents worth (which appear to be worth more than 2.1 US$ cents nowadays ;-) Liz
Re: Objects and classes, try 3
At 8:25 AM + 3/10/03, Graham Barr wrote: On Sun, Mar 09, 2003 at 02:08:02PM -0500, Dan Sugalski wrote: At 1:52 PM -0500 3/9/03, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS * Objects have properties you can fetch and store by name DS * Objects have methods you can call DS * Objects have attributes you can fetch and store Well... I'm not sure about that. Classes can store data in object attributes, but there isn't necessarily a public API through the PMC to do this. Basically if you can get to it through a PMC's vtable, it was on the Objects have list. I'm not sure that storing into an attribute should be easily doable from the outside. Methods have access to an object's internal bits, so the class methods can poke into slots in the attribute array directly, which is probably how they'll work. Surely thats a high-level restriction that Perl will impose. Why should Parrot impose that restriction ? Other languages may want to access attributes from outside the class. The big reason to impose it is because if I do, then parrot doesn't need to expose the details of attributes to user code. That seemed to make sense at the time, but since we're letting user code fetch attributes by name or slot number as it is, I'm not sure that one more vtable entry is a problem. I'll add in update capabilities to the spec. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[RfC] Yet another iterator proposal.
1) Aggregates and Strings implement the nextkey_keyed vtable method/function respectively. This gets one additional parameter: INTVAL what (e.g. 0=first, 1=next, 2=prev, 3=last) to reset the iterator and allow scan in both directions. (Note Pxxx below should indicate the usage of the P-reg) 2) The iterator is a new PMC class which implements these vtables: new PIter, .PIter, PAggregate // create a new iterator and attach the aggregate to it set PIter, 0 // reset iterator, prepare from first shift PVal, PIter // get first value from front This doesn't actually change the aggregate, but should simulate to to so, i.e. PVal is the first value, *and* PIter has the semantics of the aggregate, as if the first value has been shifted off. This should reflect a (car, cdr) which could be handy for functional programming stuff. shift PVal, PIter // get second value set PIter, 3 // reset, prepare from last pop PVal, PIter // pop last val Now, the iterator itself should have the same sematics as the aggregate it points to: assign PIter, PIntArray // attach a different array to iter? set PIter, 0 // reset shift I0, Piter // get PIntArrray[0] set I1, PIter[0] // == PIntArrary[1] set I2, PIter[1] // == PIntArrary[2] This is probably not very meaningful for hashes, but arrays can do it simply. So, the iterator also has all get_x_keyed_* methods implemented, which are passed on to the aggregate, but no set_x_keyed methods, iterators are readonly. This could also catch common errors, where the aggregate is changed during iteration. OTOH perl always gave you enough rope, to shoot yourself in the foot :) 3) The iterator PMC It would need 2 pointers: a KEY * having the state of the current index and the data * pointer to the aggregate. This ought to be enough to implement this functionality. 4) Iterating over strings Should work the same. The iterator holds the COWed substring and the offset in the KEY, the COWed substring should be reused on iterations. Comments welcome leo
Re: Objects and classes, try 3
On Sun, Mar 09, 2003 at 01:07:46PM -0500, Dan Sugalski wrote: * Objects have properties you can fetch and store by name * Objects have methods you can call * Objects have attributes you can fetch * You can fetch a hash of all the properties * When fetching or storing a generic property, you may call a method instead, as methods win * You can fetch a method PMC from the object * You can fetch the object's Class PMC All of these have vtable entries in the PMC: get_prop, set_prop, get_attrib, set_attrib, get_prop_hash, get_method, call_method, get_class. (Some already have names, I'm doing this from memory) No, you can't set a method or the property hash from an object PMC. Arguments with good reasons to do so will be cheerfully read and not implemented. :) How about target languages allow you to do this? :) (Python!) But otherwise, I like this spec much more than your previous ones. It seems more interface-oriented than implementation-oriented. That's crucial for language compatibility, I think. If you stick to an interface-oriented approach, then it should be no problem for Python, Perl, Ruby, etc, to implement all of their wacky object semantics while preventing incompatibility (or even special inter-language glue code). -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: Statement modifiers
I made a mistake in my original post, they definitely need to be left-associative. Your example should obviously be interpreted as: (.method given $x) given $y; # calls $x.method ok. I think this is similar to how I mentioned that a duplicate 'for' is pointless. Just because pointless modifier combinations exist doesn't mean multiple modifiers in general are a problem. Agreed. But is it worth putting them in if they would make a problem so easily, and it can be so easily handled with blocks? since 'if' has a lower precedence than '=', this is: ($x = $y) if $z; or equivalently $z and ($x = $y) duh. ok. print if $x if $y; # ?? Are you saying test $y, and if it's true, test $x, and if it's true then print? Yes ok, but wouldn't it be clearer to say print if $y and $x; # ? It means the left side is not always evaluated; that's short-circuiting and has nothing to do with precedence. Notice how in perl 5 the 'or' operator is in the lowest precedence class, but certainly short-circuits (think foo or die) But that's easier on the brain, becausewe read left-to-right, and it short-circuits left-to-right. z() if $x if $y doesn't. print $x,$y\n for $x - @x for $y - @y; # is that approximate? Syntax error. The - operator doesn't make sense without a block. See http://www.perl.com/pub/a/2002/10/30/topic.html But if() currently takes a block unless it's postfix. I was just extrapolating, though as I said, I'd hate to try and write the parser. print for @x for @y; # @y's topic masked would probably make no sense unless ... Note that I actually *said* it makes no sense. I have to admit that if the conditionals (if, unless, when) would be operators, I'd have trouble to think of a situation where multiple modifiers are useful at all; which I why I said making the conditionals infix-operators would probably suffice. I was just agreeing there. :) Then again, I just thought up (perl 5 style): print for split while ; but I have to admit I can probably live without the ability to write something like that ;-) Dittobut I have *wanted* to do something vaguely like that on *several* occasions! More often it is conditionals, though. I'll leave it to better minds, and use whatever they give me. ;o] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Statement modifiers
On Mon, Mar 10, 2003 at 11:28:41AM -0800, Paul wrote:
Agreed. But is it worth putting them in if they would make a problem so
easily, and it can be so easily handled with blocks?
I don't think they can make a problem so easily, and I think it's worth
putting them in because afaics it's not very complicated. Just make 'em
short-circuiting infix operators, like 'and' and 'or', except it's the
left side that's conditionally evaluated rather than the right side.
print if $x if $y; # ??
Are you saying test $y, and if it's true, test $x, and if it's true
then print?
Yes
ok, but wouldn't it be clearer to say
print if $y and $x; # ?
I think so. Alternatively you can write
$y and $x and print;
or if 'if' is an infix operator even:
($x if $y) and print;
Personally I think 'print if $y and $x' is the clearest indeed, but maybe
otherwise have a different taste.
To be honest, I doubt it'd be useful to stack multiple R2L short-circuiting
operators, but the ability to do so is obviously there. The main reason I
suggested it was because it means that support for multiple statement
modifiers isn't needed to allow:
.method when MyClass given $obj;
because 'when' would just be an operator here, and 'given' the only
modifier. Another reason to make this change is because 'if' and 'unless'
are in fact just 'and' and 'or' with different precedence in behavior.
Short-circuiting operators already exist, so the only new thing would be
R2L short-circuiting instead of L2R, but I doubt that's a problem.
Thus it reserves the title 'statement modifier' for the heavier stuff:
loops (for, while, until) and topicalizers (given).
But that's easier on the brain, becausewe read left-to-right, and it
short-circuits left-to-right. z() if $x if $y doesn't.
So don't stack multiple R2L short-circuiting operators if you think
it's confusing; I'm definitely not going to force you to :-)
Seriously, the nice thing is that the behavior of existing use of the
three modifiers remains exactly the same. Sure, you can write a few
new things that are unintelligable, but I think that perl offers rich
opportunities anyway for people who want to write obfuscated code. If
you don't want to obfuscate, then simply don't.
The when/given construction however is a clear example of a useful new
construction that making if/unless/when operators would allow.
But if() currently takes a block unless it's postfix.
I was just extrapolating, though as I said, I'd hate to try and write
the parser.
I don't see the problem.
The 'if' function takes a block. The 'if' infix operator works like
the 'and' operator except it short-circuits the other way around.
There is no conflict here, think about unary '-' versus infix '-'.
To summarize:
PROPOSAL
Replace the 'if', 'unless', 'when' statement modifiers by identically
named lowest-precedence left-associative operators that short-circuit
from right to left.
This means 'FOO if BAR' is identical to 'BAR and FOO', except it has a
lower precedence, and 'FOO unless BAR' is identical to 'BAR or FOO',
except it has a lower precedence. FOO and BAR are arbitrary expressions.
Because of left-associativity, 'FOO if BAR if BAZ' is identical to
'BAZ and BAR and FOO'.
'FOO when BAR' is similar to 'FOO if BAR' except BAR is matched magically
like the rhs of the ~~ operator and an implicit 'break' occurs if true.
RATIONALE
1. it doesn't hurt anything: existing use of the modifiers (now operators)
remains functionally the same.
2. it allows new useful expressions
3. it's more consistent ('if' has no reason being more special than 'and')
4. it shouldn't make parsing more difficult
--
Matthijs van Duin -- May the Forth be with you!
Re: Statement modifiers
On Mon, Mar 10, 2003 at 01:14:05PM -0700, Luke Palmer wrote: It is nice to see someone who puts as much thought into posting as you do. Unfortunately, your proposal is moot, as we have a definitive No, still can't chain them from Larry. http://archive.develooper.com/perl6-language%40perl.org/msg09331.html Thanks for the reference However, I'm pretty sure he's talking about disallowing multiple modifiers there. My if/unless/when as operator proposal is exactly to avoid having to support multiple modifiers. So I think discussion on this might still be fruitful. I'm actually a bit surprised noone had the idea earlier; to me the if- modifier is so similar to the 'and'-operator to have no reason being a modifier (it's actually implemented using 'and' internally in p5). Contrast that to the 'for'-modifier, which really has an impact on the statement unlike any operator could achieve, and hence really needs to be a statement modifier. -- Matthijs van Duin -- May the Forth be with you!
I'm baaaaaaaaaaaaaaack!
Like the fully-laden Australian swallow that heralds the first Apocalypse of springtime, I'm back. I hope you're all off reading: http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Special thanks to Simon for getting it on-line as quickly as he did. I'll do my best to answer questions about it and respond to other comments, but I still only have the tuits to read specifically A6-related messages. So it would help me enormously if people could include something matching the pattern: m:wi/A[pocalypse ]?6/ in the subject line of any message they'd like me to read and respond to. In other words, I'll be reading this list again, eagerly gathering grist for the forthcoming exegetical mill, but in self defence I'll be pre-filtering only for A6-related subjects. Thanks, Damian
Question for Damian about Apocalypse 6
Oh, goody. In psiglet, is the 's' silent? =Austin --- Damian Conway [EMAIL PROTECTED] wrote: Like the fully-laden Australian swallow that heralds the first Apocalypse of springtime, I'm back. I hope you're all off reading: http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Special thanks to Simon for getting it on-line as quickly as he did. I'll do my best to answer questions about it and respond to other comments, but I still only have the tuits to read specifically A6-related messages. So it would help me enormously if people could include something matching the pattern: m:wi/A[pocalypse ]?6/ in the subject line of any message they'd like me to read and respond to. In other words, I'll be reading this list again, eagerly gathering grist for the forthcoming exegetical mill, but in self defence I'll be pre-filtering only for A6-related subjects. Thanks, Damian
SM vs. BD (apoc6)
But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the SM folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch. shouldn't that be BD and not SM? :-) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Question for Damian about Apocalypse 6
On Mon, Mar 10, 2003 at 01:20:24PM -0800, Austin Hastings wrote: : In psiglet, is the 's' silent? Of course not. That is Greek, not English. Larry
Re: SM vs. BD (apoc6)
--- Uri Guttman [EMAIL PROTECTED] wrote: But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the SM folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch. shouldn't that be BD and not SM? I believe that depends on whether you consider strongly typed compile-time semantics as being restrictive or painful. I also suspect that showing too much acumen about the classification may come back to haunt you at a Perl Conference ... ;- =Austin
Apo 6: Typo in grammar
Larry says that
sub foo { ... }
is equivalent to
sub foo will do {...}
But then goes on to give the grammar for subroutine definitions as:
rule lexicalsub :w {
lexscope type?
subintro subname psignature?
trait*
block
}
rule packagesub :w {
subintro subname psignature?
trait*
block
}
rule anonsub :w {
subintro psignature?
trait*
block
}
which won't match C sub foo will do { ... } . I presume this is
another of those cases where the rules should be:
rule lexicalsub :w {
lexscope type?
subintro subname psignature?
trait*
block?
}
rule packagesub :w {
subintro subname psignature?
trait*
block?
}
rule anonsub :w {
subintro psignature?
trait*
block?
}
and rely on semantic analysis to catch the error and throw a sensible
exception?
--
Piers
Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
Having just read through the declaration bits (not the calling bits, yet): It is explicitly stated that is rw on a slurpy parameter distributes across all the components. Is there some way of differentiating array of const vs. array of rw? That is, creating a hash or array that can be extended without overwriting? =Austin --- Austin Hastings [EMAIL PROTECTED] wrote: --- Uri Guttman [EMAIL PROTECTED] wrote: But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the SM folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch. shouldn't that be BD and not SM? I believe that depends on whether you consider strongly typed compile-time semantics as being restrictive or painful. I also suspect that showing too much acumen about the classification may come back to haunt you at a Perl Conference ... ;- =Austin
Apocalypse 6: Possible file-transfer glitch?
I see e-accent in te/en we can say, below, plus
dhow is ii\ the named-only zone below that.
It survived a few refreshes, so I wonder if it's a file-transfer
problem?
=Austin
If instead we force new parameters to be in named notation, like this:
multi *push (@array, [EMAIL PROTECTED], +$how) {...}
tèen we can say:
push(@foo, how = rapidly, 1,2,3)and it's no longer ambiguous.
Since dhow is iî the named-only zone,
it can never be set positionally, and the old calls to:
Re: A6: Complex Parameter Types
On Tue, Mar 11, 2003 at 01:25:41PM +1100, Damian Conway wrote:
: 3) The edge point between explicitly typed and explicitly non-typed
: variables: If you pass an untyped array (or list?) to an explicitly
: typed array parameter, is the untyped array considered a unique case,
: or will it fail?
:
: multi foo (@a is Array of int) {...}
:
: my int @a = baz(); # is Array of int
: my @b = baz(); # is Array of Scalar
:
: foo(@a);# @a is typed correctly, so OK
: foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
:
: Fails.
:
: Because:
:
: not (Array of Scalar).isa(Array of int)
:
: Which in turn is because:
:
: not Scalar.isa(int)
I dunno. I can argue that it should coerce that. It'll certainly be
able to coerce a random scalar to int for you, so it's not a big stretch
to coerce conformant arrays of them. On the other hand, it's likely
to be expensive in some cases, which isn't so much of an issue for
single scalars/ints/strs.
Larry
Re: A6: Complex Parameter Types
Larry Wall wrote: I dunno. I can argue that it should coerce that. It'll certainly be able to coerce a random scalar to int for you, so it's not a big stretch to coerce conformant arrays of them. On the other hand, it's likely to be expensive in some cases, which isn't so much of an issue for single scalars/ints/strs. If the coercion is lazy, then its not really any more expensive than coercing individual scalars, as needed. Dave.
Re: Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
fail Can't modify existing element
if 0 = $index .length;
.SUPER::STORE($index, $value);
}
}
my @array is AppOnlyArray;
This seems wrong to me... simply because it's easier to do in C++ than
it is in Perl... which has never been the case.
class Object;
void add_stuff(listconst Object) {...}
(Disregarding the fact that listObject doesn't, in fact, convert to
that...)
I would imagine that you could just declare a sub as:
sub add_stuff(@arr of Object is constant) {...}
Where the is constant presumably refers to the Object, not the
Array. Or does that go like this:
sub add_stuff(@arr of (Object is constant) {...}
Or does it go like something else?
Luke
Re: A6: Complex Parameter Types
Larry wrote:
: multi foo (@a is Array of int) {...}
:
: my int @a = baz(); # is Array of int
: my @b = baz(); # is Array of Scalar
:
: foo(@a);# @a is typed correctly, so OK
: foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
:
: Fails.
:
: Because:
:
: not (Array of Scalar).isa(Array of int)
:
: Which in turn is because:
:
: not Scalar.isa(int)
I dunno. I can argue that it should coerce that. It'll certainly be
able to coerce a random scalar to int for you, so it's not a big stretch
to coerce conformant arrays of them. On the other hand, it's likely
to be expensive in some cases, which isn't so much of an issue for
single scalars/ints/strs.
H. I guess it depends whether we treat type specifications as constraining
the actual arguments, or restricting the interface of the formal parameters.
That is, does:
multi foo (@a is Array of int) {...}
mean:
Don't let them pass anything but an
Array of int-or-subclass-of-int
or does it mean:
Let them pass Array of (anything)
and then treat the anythings as ints
For my money, the former (i.e. compile-time type strictness) makes more sense
under pass-by-reference semantics, whereas the latter (i.e. run-time type
coercion) is more appropriate under pass-by-copy.
Damian
A6: Signature zones and such
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
*%named, [EMAIL PROTECTED]) { ... }
I can deal with one really funny character in a signature, but three is
a bit much.
In any case, it looks like it's time to re-work Perl6::Parameters...but
then I knew this was coming anyway.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: A6: Signature zones and such
Brent Dax wrote:
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
*%named, [EMAIL PROTECTED]) { ... }
It's quite possible that the following equivalences might hold:
?$xsame as$x is optional
+%ysame as%y is named
So that you could choose.
I can deal with one really funny character in a signature, but three is
a bit much.
The problem is that if you have multiple optional or named parameters, things
start getting uncomfortably prolix, and default values end up a long way from
their owners:
multi substr(Str $str, $from is optional = $CALLER::_, $len is optional =
Inf, $new is optional) {...}
vs:
multi substr(Str $str, ?$from = $CALLER::_, ?$len = Inf, ?$new) {...}
Damian
A6 and temp/let
First of all, I like where Appendix C is going.
My (small in comparison) problem is with Clet's definition of
failure. The exception bit is neat, and provides for pretty much
out-of-the-box exception safety. But failure based on return value
may not be such a hot idea. Consider:
class DBHandle {
method fetch($key) {
return %.cache{$key} if %.cache.exists($key);
return let %.cache{$key} = .expensive_fetch($key);
}
has %.cache;
}
Presumably, if Cexpensive_fetch throws an exception, C%.cache will
be unchanged. Additionally, if Cexpensive_fetch returns
Cundef... perhaps because the database says the associated value is
undefined (but exists nonetheless), C%.cache will Istill be
unchanged. This results in an expensive fetch operation each time.
There's two solutions that I see. The first is to only rollback
Clets on returning undef or () when Cuse fatal is not in effect.
If one wants to sucessfully return undef in these situations, one
returns Cundef but true or Cundef but defined (!).
Another solution may be to mark Cundefs that signify failure with a
Cfailed property. That way you can return sucessful Cundefs
without fear of contradiction.
But this leads into something related that's been bugging me about
Cuse fatal. What happens in this case?
package Foo {
use fatal;
sub oof() {
try { bar;
CATCH { ... } }
}
sub bar() { baz; }
sub baz() { fail; }
}
no fatal;
Foo::bar // die;
Obviously, Cbaz throws an exception to Cbar. However, if Cbar
subsequently throws an exception, the main module won't be expecting
it. However, Foo::oof will be expecting it, and won't settle for
Cundef.
So, in conclusion, Cuse fatal governs not what subs under its
control Ireturn, but rather what is returned Ito them. This can
be trivially implemented with Ccaller or, if inlined, simple
transformations. Does this idea have any merit?
And I've got lots of nifty ideas about Ccaller, Coming Soon to a
mailing list near you!
Luke
Re: Apocalypse 6: Possible file-transfer glitch?
It survived a few refreshes, so I wonder if it's a file-transfer problem? No, Larry is just presenting additional proof that we need Unicode operators in Perl 6 by using them in English, too. :) Greetings, Christian -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/ The human mind has no more power of inventing a new value than of imagining a new primary color, or, indeed, of creating a new sun and a new sky for it to move in. -- C.S. Lewis, The Abolition of Man
is constant eq pass by value (apoc6)
is constant (default) Every formal parameter is constant by default, meaning primarily that the compiler won't feel obligated to construct an lvalue out the actual argument unless you specifically tell it to. It also means that you may not modify the parameter variable in any way. If the parameter is a reference, you may use it to modify the referenced object (if the object lets you), but you can't assign to it and change the original variable passed to the routine. this confuses me. sometimes i want a simple pass by value param which i can modify locally in the sub. is this the same as the constant above? if so the name is not the best (even if it is the default and won't be explicitly used much). editing suggestion for last sentence: If the parameter is a reference, you may use it to modify the referenced object (if the object lets you). If you assign to a constant param, its value will change inside the sub (like any other lexical variable would) but the original variable passed to the routine is never modified. This behavior is well known as pass by value. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Apocalypse 6: Possible file-transfer glitch?
Christian, [A6, p7] There will be two new operators, called pipe operators, that allow us to hook list generators together with list consumers in either order. So either of these works: stuff @foo == 1,2,3 1,2,3 == stuff @foo [/A6, p7] I don't think that's going to be an issue -- there doesn't seem to be a Unicode Glyph called LEFTWARD-POINTING-PHALLUS, nor correspondingly is there a Unicode Glyph for RIGHTWARD-POINTING-PHALLUS, so I think we're safe on the Unicode front... my multi operator:== is size(bigger than yours); =Austin --- Christian Renz [EMAIL PROTECTED] wrote: It survived a few refreshes, so I wonder if it's a file-transfer problem? No, Larry is just presenting additional proof that we need Unicode operators in Perl 6 by using them in English, too. :) Greetings, Christian -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/ The human mind has no more power of inventing a new value than of imagining a new primary color, or, indeed, of creating a new sun and a new sky for it to move in. -- C.S. Lewis, The Abolition of Man
Re: is constant eq pass by value (apoc6)
On 2003-03-10 at 18:03:12, Uri Guttman wrote: this confuses me. sometimes i want a simple pass by value param which i can modify locally in the sub. is this the same as the constant above? No, that's the same as is copy. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
is copy (was Re: is constant eq pass by value (apoc6))
bah, the is copy is pass by value with local modification (my params in p5). this works as most params should be constant. the few that are copies can be declared that or copied to my vars. i have to wait on posting before i read the whole megilla. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
Austin Hastings wrote: It is explicitly stated that is rw on a slurpy parameter distributes across all the components. Is there some way of differentiating array of const vs. array of rw? That is, creating a hash or array that can be extended without overwriting? I'm not sure I follow what you're asking for. Can you give a hypothetical example? Damian
A6 page 6 formatting problem
Just in case anyone cares, page 6 is requiring that I scroll horizontally. I'll live, but if it can be easily fixed, that's a Good Thing. :) Haven't read the rest yet -- still working on it. Paul --- Damian Conway [EMAIL PROTECTED] wrote: Like the fully-laden Australian swallow that heralds the first Apocalypse of springtime, I'm back. I hope you're all off reading: http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Special thanks to Simon for getting it on-line as quickly as he did. I'll do my best to answer questions about it and respond to other comments, but I still only have the tuits to read specifically A6-related messages. So it would help me enormously if people could include something matching the pattern: m:wi/A[pocalypse ]?6/ in the subject line of any message they'd like me to read and respond to. In other words, I'll be reading this list again, eagerly gathering grist for the forthcoming exegetical mill, but in self defence I'll be pre-filtering only for A6-related subjects. Thanks, Damian __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
On 2003-03-11 at 10:12:17, Damian Conway wrote: Austin Hastings wrote: It is explicitly stated that is rw on a slurpy parameter distributes across all the components. Is there some way of differentiating array of const vs. array of rw? That is, creating a hash or array that can be extended without overwriting? I'm not sure I follow what you're asking for. Can you give a hypothetical example? I think he wants to write a subroutine that takes an array parameter, in which the subroutine is allowed to add elements to the array, but is not allowed to modify any of the elements that are already there on entry to the sub. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
--- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: It is explicitly stated that is rw on a slurpy parameter distributes across all the components. Is there some way of differentiating array of const vs. array of rw? That is, creating a hash or array that can be extended without overwriting? I'm not sure I follow what you're asking for. Can you give a hypothetical example? Sure: How do I specify an array which may be appended/pushed, but whose values cannot change? How do I specify a hash whose current keys/values are fixed, but which can accept new keys/values? Essentially, I'm distinguishing between change-to-object and change-to-container. =Austin
Re: Question (#2) about Apocalypse 6 : Can is properties by specified indirectly?
Austin Hastings asked:
How do I specify an array which may be appended/pushed, but whose
values cannot change?
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
fail Can't modify existing element
if 0 = $index .length;
.SUPER::STORE($index, $value);
}
}
my @array is AppOnlyArray;
How do I specify a hash whose current keys/values are fixed, but which
can accept new keys/values?
Same story.
Damian
Re: Statement modifiers
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
Now the real subject.. has the issue of multiple statement modifiers
already been settled? I saw some mention it wasn't going to be
supported, but also mentions of how it would be useful; I can think
of such a situation myself:
.method when MyClass given $obj;
as alternative to:
$obj.method if $obj.isa(MyClass);
I think this is an unusually clear case, and even then has problems.
The real nightmare tends to show up when you duplicate a modifier.
What does
.method given $x given $y; # which object's .method is called?
mean? It gets worse below
except without duplicating $obj, which may be worthwhile if it's a
longer expression. If multiple modifiers are really a no-no, then
I think at least the conditionals (if, unless, when) could be made
lowest-precedence right-associative infix operators, and leave the
status of statement modifier for loops and topicalizers.
lowest? why lowest? Careful with that If you make it a lowest
precedence operator,
$x = $y if $z; # = is higher precedence
Does it get assigned if $z is undefined?
This would mean that the above would be valid, and also things like:
.. if .. if .. for ..;
I may be missing something, but
print if $x if $y; # ??
Are you saying test $y, and if it's true, test $x, and if it's true
then print? I suppose that might workbut that still makes it high
priority, doesn't it?
But that multiple nested loops would be illegal using modifiers and
would require a real block. (which makes some sense, since it's hard
to think of a construction where multiple loop-modifiers would be
useful: if you have ... for @a for @b then you'd be unable to
use the @b-element since $_ would be the loop var of the inner loop)
Maybe not in p6.
print $x,$y\n for $x - @x for $y - @y; # is that approximate?
Ok, this is hurting my head, and I think I might hurt someone who left
me to maintain it, but I could see how it could be useful, and I think
I see how it could be parsed It would be like
for $y - @y {
for $x - @x {
print $x,$y\n;
}
}
My question is that, though TMTOWTDI is a Good Thing, and in general
dictating style is a Bad Thing, is this much flexibility a Good Thing
or a Bad Thing? And more importantly, will the people writing the
parser become homicidal if it is decided this should be implemented?
Still,
print for @x for @y; # @y's topic masked
would probably make no sense unless it's a rather twisted form of
recursion, and for that I'd recommend writing a function rather than
setting up reference loops
I also think this gives a nice symmetry of various operators that
only differ in L2R/R2L and precedence (plus the ability to overload
ofcourse):
$x and $y $y if $x
$x or $y$y unless $x
$x . $y $y ~ $x
$x ( $y ) $y ~ $x
I have no idea what you mean by this.
Paul
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Statement modifiers
On Mon, Mar 10, 2003 at 08:20:39AM -0800, Paul wrote: The real nightmare tends to show up when you duplicate a modifier. What does .method given $x given $y; # which object's .method is called? mean? It gets worse below I made a mistake in my original post, they definitely need to be left- associative. Your example should obviously be interpreted as: (.method given $x) given $y; # calls $x.method I think this is similar to how I mentioned that a duplicate 'for' is pointless. Just because pointless modifier combinations exist doesn't mean multiple modifiers in general are a problem. lowest? why lowest? Ehm, because that is consistent with current behavior? Careful with that If you make it a lowest precedence operator, $x = $y if $z; # = is higher precedence Does it get assigned if $z is undefined? since 'if' has a lower precedence than '=', this is: ($x = $y) if $z; or equivalently $z and ($x = $y) In either case, the assignment is done if $z is true I may be missing something, but print if $x if $y; # ?? Are you saying test $y, and if it's true, test $x, and if it's true then print? Yes I suppose that might workbut that still makes it high priority, doesn't it? It means the left side is not always evaluated; that's short-circuiting and has nothing to do with precedence. Notice how in perl 5 the 'or' operator is in the lowest precedence class, but certainly short- circuits (think foo or die) print $x,$y\n for $x - @x for $y - @y; # is that approximate? Syntax error. The - operator doesn't make sense without a block. See http://www.perl.com/pub/a/2002/10/30/topic.html Still, print for @x for @y; # @y's topic masked would probably make no sense unless ... Note that I actually *said* it makes no sense. I have to admit that if the conditionals (if, unless, when) would be operators, I'd have trouble to think of a situation where multiple modifiers are useful at all; which I why I said making the conditionals infix-operators would probably suffice. Then again, I just thought up (perl 5 style): print for split while ; but I have to admit I can probably live without the ability to write something like that ;-) -- Matthijs van Duin -- May the Forth be with you!
A6: Pipes
Since noone else has said it yet -- This Apoc looks *great*. The sig
stuff is very, very nice. (The wrapper stuff has interesting
possibilities, too, especially with OO.)
Question on pipes: I like very much the concept of relating them only
to the variadic list, that was the piece we were all missing in the P6L
discussions. After reading that appendix, I'm still a bit murky on the
final decisions as to which of these edge cases will be allowed:
my @out == (1,2,3);
my @out == (my @in = foo());
my @out == foo();
(1,2,3) == my @out;
(my @in = foo()) == my @out;
foo() == my @out;
Are these all valid, or do some of them have to be errors? I got lost
in the appendix explanation of what was confirmed, and what was
wishful-only...
FWIW, stylistically, I'd personally vote for
@in == map {...}
== sort {...}
== map {...}
== @out;
as better than:
@in ==
map {...} ==
sort {...} ==
map {...} ==
@out;
... if we care about such details. :-)
MikeL
Re: A6: Pipes
Michael Lazzaro wrote:
After reading that appendix, I'm still a bit murky on the
final decisions as to which of these edge cases will be allowed:
my @out == (1,2,3);
my @out == (my @in = foo());
my @out == foo();
(1,2,3) == my @out;
(my @in = foo()) == my @out;
foo() == my @out;
These are basically all just two edge-cases. Namely:
@var == LIST
and:
LIST == @var
Larry is still leery, but I suspect they will ultimately be allowed.
Mainly because these:
@in == map {...}
== sort {...}
== map {...}
== @out;
@out == map {...}
== sort {...}
== map {...}
== @in;
are much less annoying than:
@in == map {...}
== sort {...}
== map {...}
== push @out;
push @out == map {...}
== sort {...}
== map {...}
== @in;
And because, as I demonstrated, the necessary overloaded multimethods are so
trivial to implement.
Damian
A6: Complex Parameter Types
In A6, it is confirmed that you can have complex types such as:
my %pet is Hash of Array of Array of Hash of Array of Cat;
It is also confirmed that you can indeed use such types in sub
signatures, e.g.:
sub foo (@a is Array of int) {...}
Confirmations/Questions:
1) Complex types for sub parameters: The above would imply that a sub
can tell the difference between an CArray of int vs an CArray of
str, thank goodness. That also implies that you can use arbitrarily
complex types, and still get the same type checking:
sub foo ( %pet is Hash of Array of Array of Hash of Array of Cat )
{...}
Yes/No?
2) Multimethod dispatch: The text would seem to _IMPLY_ that you can
perform multimethod dispatch based on complex types, but it isn't
actually stated anywhere AFAICT. e.g.
multi foo (@a is Array of str) {...}
multi foo (@a is Array of int) {...}
... is it legal, and DWYM?
3) The edge point between explicitly typed and explicitly non-typed
variables: If you pass an untyped array (or list?) to an explicitly
typed array parameter, is the untyped array considered a unique case,
or will it fail?
multi foo (@a is Array of int) {...}
my int @a = baz(); # is Array of int
my @b = baz(); # is Array of Scalar
foo(@a);# @a is typed correctly, so OK
foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
MikeL
Re: A6: Complex Parameter Types
Michael Lazzaro asked:
1) Complex types for sub parameters: The above would imply that a sub
can tell the difference between an CArray of int vs an CArray of
str, thank goodness. That also implies that you can use arbitrarily
complex types, and still get the same type checking:
sub foo ( %pet is Hash of Array of Array of Hash of Array of Cat ) {...}
Yes/No?
Yes.
2) Multimethod dispatch: The text would seem to _IMPLY_ that you can
perform multimethod dispatch based on complex types, but it isn't
actually stated anywhere AFAICT. e.g.
multi foo (@a is Array of str) {...}
multi foo (@a is Array of int) {...}
... is it legal,
Yes.
and DWYM?
Depends WYM. ;-)
3) The edge point between explicitly typed and explicitly non-typed
variables: If you pass an untyped array (or list?) to an explicitly
typed array parameter, is the untyped array considered a unique case,
or will it fail?
multi foo (@a is Array of int) {...}
my int @a = baz(); # is Array of int
my @b = baz(); # is Array of Scalar
foo(@a);# @a is typed correctly, so OK
foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
Fails.
Because:
not (Array of Scalar).isa(Array of int)
Which in turn is because:
not Scalar.isa(int)
To extend the example a little further:
multi Aoi (int @a){...}
multi AoS (Scalar @a) {...}
multi AoI (Int @a){...}
my int @aoi;
my @aoS;
my Int @aoI;
Aoi(aoi); # Okay because int.isa(int)
Aoi(aoS); # Fails because !Scalar.isa(int)
Aoi(aoI); # Fails because !Int.isa(int)
AoS(aoi); # Fails because !int.isa(Scalar)
AoS(aoS); # Okay because Scalar.isa(Scalar)
AoS(aoI); # Okay because Int.isa(Scalar)
AoI(aoi); # Fails because !int.isa(Int)
AoI(aoS); # Fails because !Scalar.isa(Int)
AoI(aoI); # Okay because Int.isa(Int)
Damian
Re: tinderbox all in flames
Slightly related, I think we could use some more tinderbox testers. Someone was running the tests on Compaq's test drive boxes, but that seems to have stopped? I've restarted my Sparc/Solaris 8 tinderbox. Defining a list of needed test platforms might be a good idea. I have plenty of old sparc and x86 hardware that I'd be more then happy to drag out of mothballs. Cheers, -J __
Parrot for windows?
Does anyone have a precompiled parrot binary for Win32, on an ftp or web
site somewhere?
I'm practicing writing parrot assembler, and I'd like to be able to test
my evil creations on my own machine, without having to go through the
rigmarole of uploading my file to my sourceforge account, then sshing in
to run the scripts. whine(Plus, the long-term quota on my account is
too small to keep around a parrot binary there full time, so I have to
re-download and re-compile it when I want to use it, and erase it when
I'm done. Bleh!)/whine
whine
I suppose if there isn't a windows binary out there, I could try
downloading and installing a C compiler (gcc? djgpp?) and then
compiling my own parrot... but I don't want to do that much work!
/whine
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}# Non-recursive towers of hanoi solution.
# It does use a stack, of course, but with
# significantly fewer pushes and pops than
# a normal recursive subroutine would use.
MAIN:
save 4 # number of disks.
bsr HANOI
end
HANOI:
restore I0
le I0, 0, end_of_sub
save 0 # Sentinel
set S0, a
set S1, b
set S2, c
eq I0, 1, doprint
pushsome:
dec I0
exchange S1, S2
push S2
push S1
push S0
push I0
gt I0, 1, pushsome
doprint:
print Move from tower
print S0
print to tower
print S2
print .\n
dec I0
if I0, justswitch
restore I0
eq I0, 0, end_of_sub # sentinel?
restore S0
restore S1
restore S2
branch doprint
justswitch:
exchange S0, S1
gt I0, 1, pushsome
branch doprint
end_of_sub:
ret
tinderbox all in flames
The tinderbox is all in flames. http://xrl.us/dxm (Link to tinderbox.perl.org) At least the miette, moof and rh80smoketest boxes should be okay; and they are not. :-) Sunday afternoon (PST) seems to be the hour of the big arson. However there are also indications that it started Friday night. :-) Slightly related, I think we could use some more tinderbox testers. Someone was running the tests on Compaq's test drive boxes, but that seems to have stopped? - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
