Re: REs as generators
Luke Palmer wrote: LP my $foos = 'foo' ~ any(0..9) ~ any(0..9); Actually $foos will be a junction. You could use Cstates to get each state out of the junction in an array. my @foos = states $foos; Luke's right on target (as usual :-). Just one slight niggle. I suspect Cstates may be a method only, so that would be either: my @foos = states $foos:; or: my @foos = $foos.states; Though, I suppose we might argue that Cstates is as fundamental to Perl 6 as Cgrep or Csort, and so ought to have a built-in as well. Hmmm. Damian
Re: REs as generators
At 10:37 PM -0700 12/10/02, Luke Palmer wrote: Why use regexen when you can just use junctions? my $foos = 'foo' ~ any(0..9) ~ any(0..9); ... We have a Ipowerful language on our hands, people. Agreed, but this solution doesn't work well for all cases. For example, what if I want to iterate through the values foo01 .. foo99, breaking out when some limit condition is reached. Generating and sorting the entire list seems a bit wasteful... -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: right-to-left pipelines
Ken Fox [EMAIL PROTECTED] writes: Damian Conway wrote: For that reason, even if we can solve this puzzle, it might be far kinder just to enforce parens. I might be weird, but when I use parens to clarify code in Perl, I like to use the Lisp convention: (method $object args) Hopefully that will still work even if Perl 6 requires parens. I think it'd become (method $object: args) I confess I found myself thinking along similar lines when I read Damian's post. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: REs as generators
Date: Wed, 11 Dec 2002 19:15:53 +1100 From: Damian Conway [EMAIL PROTECTED] I suspect Cstates may be a method only, so that would be either: my @foos = states $foos:; or: my @foos = $foos.states; Though, I suppose we might argue that Cstates is as fundamental to Perl 6 as Cgrep or Csort, and so ought to have a built-in as well. Hmmm. Can junctions have methods? How do you tell the difference between calling a junction's method and calling a method on each of its states? Luke
[perl #19031] [PATCH] befunge's Makefile autogenerated by configure
# New Ticket Created by Jerome Quelin # Please include the string: [perl #19031] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19031 Thanks to bf's example, I'm now writing Befunge Makefile while configuring Parrot. I hope that I did not miss sthg important. Please note that $PARROT/languages/befunge/Makefile should go (the patch only empties it AFAICT) - and I removed it from MANIFEST. Jerome -- [EMAIL PROTECTED] -- attachment 1 -- url: http://rt.perl.org/rt2/attach/44730/35353/797778/befunge_makefile_autogen.patch diff -urbN parrot.old/config/gen/makefiles/befunge.in parrot/config/gen/makefiles/befunge.in --- parrot.old/config/gen/makefiles/befunge.in 1970-01-01 01:00:00.0 +0100 +++ parrot/config/gen/makefiles/befunge.in 2002-12-11 09:19:27.0 +0100 @@ -0,0 +1,16 @@ +RM_F = ${rm_f} +PERL = ${perl} + +ASSEMBLE=$(PERL) ../../assemble.pl +PARROT=../../parrot + +all: build + +test: build + $(PARROT) befunge.pbc test.bef + +build: befunge.pasm debug.pasm flow.pasm io.pasm load.pasm maths.pasm stack.pasm + $(ASSEMBLE) befunge.pasm befunge.pbc + +clean: + $(RM_F) core *.pbc *~ diff -urbN parrot.old/config/gen/makefiles.pl parrot/config/gen/makefiles.pl --- parrot.old/config/gen/makefiles.pl 2002-12-11 09:16:59.0 +0100 +++ parrot/config/gen/makefiles.pl 2002-12-11 09:18:09.0 +0100 @@ -29,6 +29,8 @@ commentType = '#'); genfile('config/gen/makefiles/bf.in','languages/bf/Makefile', commentType = '#'); + genfile('config/gen/makefiles/befunge.in', 'languages/befunge/Makefile', + commentType = '#'); } 1; diff -urbN parrot.old/languages/befunge/Makefile parrot/languages/befunge/Makefile --- parrot.old/languages/befunge/Makefile 2002-12-11 09:17:13.0 +0100 +++ parrot/languages/befunge/Makefile 1970-01-01 01:00:00.0 +0100 @@ -1,17 +0,0 @@ -ASSEMBLE=perl ../../assemble.pl -PARROT=../../parrot - -test: build - $(PARROT) befunge.pbc test.bef - -build: befunge.pasm flow.pasm io.pasm load.pasm maths.pasm stack.pasm - $(ASSEMBLE) befunge.pasm befunge.pbc - -clean: - rm -f core *.pbc *~ - -dist: clean - rm -f befunge.tgz - ( cd .. ; tar cvf befunge.tar Befunge-93 ) - gzip ../befunge.tar - mv ../befunge.tar.gz befunge.tgz diff -urbN parrot.old/MANIFEST parrot/MANIFEST --- parrot.old/MANIFEST 2002-12-11 09:16:59.0 +0100 +++ parrot/MANIFEST 2002-12-11 09:17:33.0 +0100 @@ -1289,7 +1289,6 @@ languages/BASIC/tokenize.pasm languages/BASIC/wumpus.bas languages/befunge/Changes -languages/befunge/Makefile languages/befunge/README languages/befunge/befunge.pasm languages/befunge/debug.pasm
This week's summary
The Perl 6 Summary for the week ending 20021208 Another Monday evening. Another summary to write. Starting, as is becoming tediously predictable, with perl6-internals. Another JIT discussion Toward the end of the previous week, Leopold Tötsch posted something about the latest round of changes to the JIT core. Daniel Grunblatt was concerned that the current JIT wasn't doing the right thing when it came hardware register allocation and wanted to remove a some conditional logic. Leo didn't agree at first, but became convinced and Daniel's requested change was applied. http://makeashorterlink.com/?P4AB24AB2 Fun with IMCC Lots of things happened with IMCC this week: * David Robins posted a list of minor niggles (For instance, it turns out you can't ret early from a .sub) and suggested some remedies. Leo Tötsch mentioned that the IMCC Cabal (which would consist of Melvin Smith, Sean O'Rourke, Angel Faus and Leo if there were a Cabal. But, as everyone knows, There Is No Cabal) have been discussing several of these issues. http://makeashorterlink.com/?Q1BB22AB2 http://makeashorterlink.com/?W1CB43AB2 * Art Haas had problems building IMCC, apparently bison didn't like the imcc.y file. Leo tracked down the problem (at the second time of asking, I think he might be slipping) and checked in a working fix. * Leo Tötsch made a pile of changes to IMCC to eliminate clashes between Parrot's PASM language and IMCC's PIR syntax, which had made it hard to mix the two. Full details of the changes are in his post. Gopal V wondered if there was any way of feeding code to IMCC beyond simply writing to a file and running IMCC. He'd had to make a bunch of changes to the IMCC files that he used, and wondered if there was a Better Way. Actually he didn't so much wonder as propose the aforementioned Better Way, lifting ideas from DotGNU's treecc. He and Leo discussed things, worked out an interface and Gopal went off to implement something (Yay Gopal!) http://makeashorterlink.com/?Y1DB21AB2 http://makeashorterlink.com/?A6EB42AB2 * Steve Fink posted a patch implementing a first cut at namespace support in IMCC. He wasn't at all sure that what he'd implemented was the Right Thing, but it supplied what he needed for the time being (if that makes sense) in the regex engine. Leo reckoned that it looked okay, and promised to apply it if nobody hollered. He also pointed out some problems with the current regex implementation to do with reentrancy and memory leakage. It turns out that Steve was working on languages/regex rather than the rx_* ops, which are the ones that have the problems. http://makeashorterlink.com/?P2FB16AB2 * Gregor N. Purdy had some problems with IMCC's syntax, a fragment of code that he thought should work fell over in a heap. Both Mr. Nobody and Leo pointed out that IMCC expects subroutines, and you should wrap your code in a .sub/.end pair. Once Gregor had that straight he posted a Jako program and the IMCC code he thought the Jako compiler should generate from it and asked for any feedback before he went to change the compiler. Leo Tötsch provided some (I assume) useful feedback. A little later Gregor posted again, he was still having problems with IMCC not quite behaving as he wanted for the Jako compiler. He and Leo thrashed it out over a few messages and, to cut a long story short, IMCC looks like it won't be changing. I'm not sure whether Gregor is happy about this... http://makeashorterlink.com/?X30C22AB2 http://makeashorterlink.com/?J51C32AB2 * Mr Nobody posted a patch to get IMCC to compile under windows. Apparently the OUT label clashes with something in the windows header files. The patch got applied. * Gregor N. Purdy got a little confused by how IMCC generates PASM code, and posted some sample code, interspersed with questions. Which Leo answered. It's worth looking at this; it shows off the kind of optimization that IMCC gets up to. http://makeashorterlink.com/?E22C25AB2 http://makeashorterlink.com/?Y53C22AB2 PMCs are the thing Dan announced that he's finally stopped waffling and frozen the PMC structures `modulo the odd twiddling to it.' He's added a pmc.ops file, and has started adding in ops to manipulate PMC internals. Leo asked for some clarifications, got some, and then wondered what the final 'Parrot Object' will look like. http://makeashorterlink.com/?Z34C23AB2 logical_not issue David Robins is having fun with logical_not and Ruby. The issue is that *all*
Re: right-to-left pipelines
[EMAIL PROTECTED] (Damian Conway) writes: *Why* do methods need their parens? Because calls to them are not resolved until run-time and because methods can be overloaded by signature, so we can't tell at parse time what the parameter list of the called method will be (i.e. where it will end), so we can't determine how to parse the arguments... I'm just talking about passing a block to a method. You think I'm talking about a clever way of specifying a method's argument signature. I'm not. -- No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication- applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. - Algol 68 Report
Re: [INFO] Buffer/PMC unification
Changes #6. - PMC_*_FLAGs are history. - I did remove the bogus looking, unused, untested and superfluous destroy from core.ops All access to PMC/Buffer-flags has to be done via the accessor macros in pobj.h. If some are missing, please add them, when needed. Next will be hiding other Buffer/PMC structure members that might conflict, like buffer and buflen. leo
Re: Parrot v0.0.9 code freeze
I'm still not sure what the problem is...but if you turn --gc-debug off, then the array diminsions are correct...e.g., 10 for the first dimension. Therefore, the calculation of the array index is performed correctly. However, with --gc-debug on, the array dimension is correct for the first dimension (0,0 - 0,20) as well as the first element of the first dimension...(1,0). But it is wrong for all of the others. It becomes 1 instead of 10. I have no clue yet why...still looking into it. However, all tests pass on Tru64 if --gc-debug is off. - Original Message - From: Tanton Gibbs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 7:13 PM Subject: Re: Parrot v0.0.9 code freeze I'm looking at the Tru64 problem. The manifest problem is trivial: languages/jako/docs/jako.pod needs to be added to the MANIFEST The multiarray problem only occurs if you turn on --gc-debug...still looking at it Tanton - Original Message - From: Steve Fink [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 4:45 PM Subject: Parrot v0.0.9 code freeze Heads up. The weather report indicates a feature freeze on Sat 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to a release on Wed 2002-Dec-18. So if you have any feature changes that you want to get into 0.0.9 (and it isn't too destabilizing), please commit them before Saturday. Sometime between now and then, I'll compile a list of changes since 0.0.8. This release will go out even if the tinderbox isn't completely green, because I don't want to delay it any further, but I would greatly appreciate any improvements in that area. Feel free to use http://foxglove.dnsalias.org/parrot/ to get a snapshot view of what tests are failing.
[INFO] Buffer/PMC unification - #7 and finito for now
Done. Buffers and PMCs are Parrot Objects now, sharing a common header, PObj. The struct members: - buffer - buflen - cache - version (for GC_DEBUG) are actually #defines now. This implies that the usage of these names is forbidden in the whole parrot tree. This rule will last until the final structures are fixed, and somone changes all usage of above data members to the real thing. Finally I was to lazy to change all -flags in keys.c and list.c, a macro in these files is used to access flags directly. make quickfulltest doesn't show any error, nor do perl6 tests. After the feature freeze/release, we can have a look at DOD/GC Buffer/PMC memory management functions to look, what can be simplified then. Please do a make clean after checkout. Have fun, leo
Re: Curses Life
On Tue, Dec 10, 2002 at 06:04:44PM +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) I've suggested he work on getting Readline working next. Then, once he's done the zmachine loader and got a zmachine opcode set up and running... and then all get digressed into playing http://astray.com/Bookshop.z5 (see http://london.pm.org/pipermail/london.pm/Week-of-Mon-20010924/005441.html ) Nicholas Clark
Re: right-to-left pipelines
On Wed 11 Dec, Simon Cozens quoted: No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication- applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. - Algol 68 Report My father in law (Charles Lindsey) says that para in the Algol 68 Report is not his. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: REs as generators
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote: On occasion, I have found it useful to cobble up a little language that allows me to generate a list of items, using a wild-card or some other syntax, as: foo[0-9][0-9] yields foo00, foo01, ... I'm wondering whether Perl should have a similar capability, using REs. Will Perl6 still have the increment a string ability? I can't count the number of times that's been my saving grace when I needed to portably and easily generate a unique filename. --Dks
is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote: From: Dave Storrs [EMAIL PROTECTED] My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? By default they're keyed by strings. You can smack a property on them to key them by something else, though: my %sparse is keyed(Int); my %anything is keyed(Object); # or UNIVERSAL Hmmm...maybe this is a good time to bring up something that's been bothering me for a while. It seems like Perl6 is moving farther and farther away from Perl5's (almost) typelessness. All of a sudden, we are getting into ints, Ints, Objects, Strs, etc...more and more of the code examples that are being posted to these lists use type declarations in method signatures, variable declarations, and anywhere else that they might squeeze in. It isn't clear to me if this is being done because we are currently discussing the new types and type-safety mechanisms--all of which are optional, and only come into play when you request them--or if it is expected that this will be the new paradigm for Perl programming. So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? --Dks
Re: REs as generators
On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote: Why use regexen when you can just use junctions? my $foos = 'foo' ~ any(0..9) ~ any(0..9); At what moment does a junction actually create all of its states? Hmm...perhaps a clearer way to say that is At what moment does a junction allocate memory for, and initialize that memory with, all of its states? I would hope that we could simply store the defining conditions of a junction without having to generate all possible states at the moment the junction is declared. optimizations. MODE=wild speculation I wonder if junctions could support the following: - lazy generation...when one of the calls (e.g. any, one) which requires that only one value (or one value that satisfies the condition) be generated, we would not need to generate the whole list. I would hope this would be the default, but I'm not assuming anything. - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. /MODE --Dks
Stringification of references (Decision, Please?)
Piers wrote: Stringification of references Joseph F. Ryan kicked off a discussion of the stringification of objects and references and offered his suggestions. Joseph leans towards having the default stringifications of objects and references provide information useful to the programmer. I agree with him (so, if you spot any bias in the upcoming summary that'd be because I'm biased). Michael Lazzaro explicitly brought up the distinction between stringification for output and stringification for debugging, and came down in favour of stringification for output (heck, he even wanted references to be invisible to stringification). Piers Cawley told him he was very wrong and appealed to the authority of Kent Beck (a Smalltalk and Java programmer, possibly not the *best* authority to choose). Michael then proposed a scheme involving subclasses of String, to provide cues for different stringifications, which John Siracusa thought was going rather a long way too far, coming down in favour of the stringify for debugging position. I'm not sure anything has actually been *decided* yet though. Tune in next week. We still need this decided, ASAP, so that doc can be completed. I doggishly maintain my preference for treating stringification for output and stringification for debugging differently, but as long as I can specify an AS_STRING (sp?) method for a class, and _still_ get at a debugging version to print to other (debugging-related) strings, I think we're all basically happy. That implies, however, that we need at least two methods per type/class: AS_STRING, and AS_DEBUG, for lack of better names. By default, the first calls the second. (I also beg people to stop thinking about testing for equality/equivalence between two objects as being related to their stringification. You shouldn't be stringifying objects merely to test if they're the same object -- yuck. It was an artifact of Perl5 that we should be replacing.) of stringification for output (heck, he even wanted references to be invisible to stringification). Piers Cawley told him he was very wrong Especially need to decide this. When last we joined our heroes: On Fri, Dec 06, 2002, Dan Sugalski wrote: If an aggregate and a reference to an aggregate are going to behave the same, which is what Larry's indicated in the past, then stringifying a reference should be the same as stringifying its referent. Larry wrote: This is a bit of an oversimplification. snip But it's probably fair to say that $foo and @foo always behave identically in a scalar context. (Which sortof _implies_ the answer to the question, but only indirectly.) MikeL
Re: how to code a lazy pipeline?
On Tuesday, December 10, 2002, 1:26:41 PM, you (mailto:[EMAIL PROTECTED]) wrote: On 12/10/2002 4:54 AM, Me wrote: How would one most nicely code what I'll call a lazy pipeline, such that the first result from the final element of the pipeline can appear as soon as the first result has been processed from the intervening elements? I belive the short answer is make sure all elements of your pipeline return a lazy list. Exactly how one does this, and the distinction between a lazy list and an iterator, I belive is still somwhat up in the air. I think the answer here will be make a lazy list an iterator constructor. This would also be the case for something like a grep in the pipeline (in effect an iterator adaptor -- to use a C++ term -- on the previous iterator). I.e. in a lazy context, grep would return an object with implementation something like: sub GrepIterator.atEnd { return $inputIt.atEnd; } sub GrepIterator.Next(): boolean { while ($inputIt.Next() and $inputIt.Value() !~ $myPattern) {} if .atEnd() { return 0; } $myCurrent = $inputIt.Value(); return 1; } sub GrepIterator.Value() { return $myCurrent(); } (Which of course misses all the edge cases.) -- Richard mailto:[EMAIL PROTECTED]
Re: Stringification of references (Decision, Please?)
On 12/11/02 1:10 PM, Michael Lazzaro wrote: I doggishly maintain my preference for treating stringification for output and stringification for debugging differently, but as long as I can specify an AS_STRING (sp?) method for a class, and _still_ get at a debugging version to print to other (debugging-related) strings, I think we're all basically happy. That implies, however, that we need at least two methods per type/class: AS_STRING, and AS_DEBUG, for lack of better names. By default, the first calls the second. Can we at least get something about strings in the name of the debug method? AS_STRING is pretty clear, but AS_DEBUG could mean a lot of things...and at first glance, it doesn't seem related to AS_STRING at all. Maybe AS_STRING and AS_STRING_DEBUG? Too long? DEBUG_STRING? Are we married to the AS_* thing? That naming scheme always seems too cute to me... (I also beg people to stop thinking about testing for equality/equivalence between two objects as being related to their stringification. You shouldn't be stringifying objects merely to test if they're the same object -- yuck. It was an artifact of Perl5 that we should be replacing.) So, what is the Perl 6 way to test this? -John
Re: right-to-left pipelines
On Tuesday, December 10, 2002, at 02:50 PM, Damian Conway wrote: Simon Cozens asked: *Why* do methods need their parens? examples snipped *All* of them might be valid interpretations, and *none* of them might be known to be valid (or even knowable) at the point where the code is parsed. Throw multimethods into the mix and things get an order of magnitude worse. Incidentally, the indirect object syntax will suffer from exactly the same problems in Perl 6. All subroutines with multiple signatures would have this problem, right, even normal non-method subs? foo $a, $b, $c, $d; # how many args? So could a general rule be that multimethods (subs or methods with more than one possible variant) require the parens, but subs with one known signature do not? To solution in both cases is to defer the parameter/argument type checking and the method dispatch until run-time. That works fine, but only if the compiler can determine exactly how many arguments to pass to the method call. For that, it needs either explicit parens, or a default rule. Oof. I had been (foolishly?) hoping that if argument types were known at parse time (due to previous declarations), it would frequently be possible to resolve the multimethod variant during compilation. Now I'm wondering -- because of Perl's ability to add classes/methods at runtime, for example -- if there are _any_ circumstances in which that would be true. How much overhead do we expect (runtime) multimethods to have? I would guess it to be nontrivial, e.g. substantially worse than normal methods... MikeL
Re: how to code a lazy pipeline?
Richard J Cox wrote: On Tuesday, December 10, 2002, 1:26:41 PM, you (mailto:[EMAIL PROTECTED]) wrote: On 12/10/2002 4:54 AM, Me wrote: How would one most nicely code what I'll call a lazy pipeline, such that the first result from the final element of the pipeline can appear as soon as the first result has been processed from the intervening elements? I belive the short answer is make sure all elements of your pipeline return a lazy list. Exactly how one does this, and the distinction between a lazy list and an iterator, I belive is still somwhat up in the air. I think the answer here will be make a lazy list an iterator constructor. This would also be the case for something like a grep in the pipeline (in effect an iterator adaptor -- to use a C++ term -- on the previous iterator). I.e. in a lazy context, grep would return an object with implementation something like: code snipped Not to rain on the parade, but doesn't there also need to be some sort of global analysis of the whole pipe line before making any of it lazy. For example, if the pipeline contains a sort or reduce it can't be evaluated lazily, so why go to all the bother of transforing the greps and maps to lazy iterator forms? -- Mark Biggar [EMAIL PROTECTED]
Re: Stringification of references (Decision, Please?)
(BOn Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote: (B Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"? (B Are we married to the "AS_*" thing? (B (BNot really -- whatever works. We also had .debug, .identity, and .id (Bproposed, for example. (B (B You shouldn't be stringifying objects merely to test if they're the (B same object -- yuck. It was an artifact of Perl5 that we should be (B replacing.) (B So, what is the Perl 6 way to test this? (B (BI was hoping someone would ask that. :-) We don't _have_ a way, (BAFAIK. It was discussed briefly during the operator thread, but (Bwithout decision. We know: (B (B $obj1 == $obj2; # compares them numerically (B $obj1 eq $obj2; # compares them stringically (B (BWe could override either C== or Ceq of CObject to do it. Then we (Bhave to ask what happens if you say: (B (B $obj == 5; (B $obj eq 'foo'; (B (BThat would hopefully *not* compare the identity of $obj to either 5 or (B'foo', but instead Do The Right Thing (numerify or stringify $obj). So (Bpresumably, this is a job for multimethod variants of class-specific (BC== or Ceq operators. Well, sortof. (B (BOR, you just explicitly compare the identities, e.g. (B (B$obj1.identify == $obj2.identity; # yuck (B (BOR, we have a third kind of comparision operator, like perhaps '==='. (B (B$obj1 eq $obj2;# are their stringifications identical? (B$obj1 == $obj2;# are their numifications identical? (B$obj1 === $obj2; # are they in fact the same object? (B (BThe triple '===' being vaguely reminiscent of Unicode '$B"a(B'. (B (BMikeL
Re: is it required to use type declarations? (was Re: 'hashkey context/Str context')
Date: Tue, 10 Dec 2002 08:04:46 -0800 From: Dave Storrs [EMAIL PROTECTED] On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote: From: Dave Storrs [EMAIL PROTECTED] My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? By default they're keyed by strings. You can smack a property on them to key them by something else, though: my %sparse is keyed(Int); my %anything is keyed(Object); # or UNIVERSAL Hmmm...maybe this is a good time to bring up something that's been bothering me for a while. It seems like Perl6 is moving farther and farther away from Perl5's (almost) typelessness. All of a sudden, we are getting into ints, Ints, Objects, Strs, etc...more and more of the code examples that are being posted to these lists use type declarations in method signatures, variable declarations, and anywhere else that they might squeeze in. It isn't clear to me if this is being done because we are currently discussing the new types and type-safety mechanisms--all of which are optional, and only come into play when you request them--or if it is expected that this will be the new paradigm for Perl programming. You'll note that in my code sample the hash values had no type. What I specified is no more restrictive than Perl 5, just using something other than a string for the hash key. But I know what you mean as far as the rest of it. There will certainly be no Imandatory typing in Perl 6 where there wasn't in Perl 5. As far as what people will do, well, that's up to people. They're not going to set social standards. But my guess would be that the standards would converge to some moderate between strongly typed and typelessness. You might see things like this: my Int $count = 0; while (...) { ... } But probably nothing C++ish: my LinkedList::iterator_type $iter = new LinkedList::iterator; People would probably leave that one untyped, because it's such a pain. I'm reminded of several Perl mottos simultaneously... So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? Optional by request, but not explicit request. If you type a variable, you're asking for type checking on that variable. Luke
Re: Stringification of references (Decision, Please?)
Date: Wed, 11 Dec 2002 10:10:05 -0800 From: Michael Lazzaro [EMAIL PROTECTED] (I also beg people to stop thinking about testing for equality/equivalence between two objects as being related to their stringification. You shouldn't be stringifying objects merely to test if they're the same object -- yuck. It was an artifact of Perl5 that we should be replacing.) This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? Luke
Re: Naiive .const directive for imcc
[EMAIL PROTECTED] wrote: Leo -- I tried my hand at adding a naiive (that is, incorrect) version of .const type ident = literal I'll implement such a thing based on your patch and on the recent lexical changes. Constants declared like above will be real constants without register usage. Syntax will be like in your patch. leo
Jako and Native Calls
Dan -- We were talking earlier about Jako supporting native calls. I have looked at PDD 6 and PDD 3, and here's what I think so far... I don't think I can get the native call stuff working until I have IMCC support for PDD 3. IMCC is totally in charge of what goes into each register, and I like it that way. I think I'd need something like this: .pcall .parg ... .parg ... call _whatever .pend (prefix P for Parrot standard convention). The .pcall directive resets any IMCC bookkeeping about any previous calls and what registers were in use. The .parg directives plop things where they go and increment the counters. The .pend directive means done with this call. Free up registers for other stuff, since I've got what I need. This would be enough, I think, for me to create Jako calls out to native stuff. Assuming the native stuff plops its return value according to PDD 6, then we'll need the IMCC support for that, too. It might be handy for the entire (1) set up args (2) call out (3) deal with returned values sequence to be wrapped between .pcall and .pend: loadlib $P38, libsdl dlfunc $P39, $P38, SDL_BlitSurface, i .pcall .parg $P33 .parg $P34 .parg $P35 .parg $P36 invoke $P39 .pres $I100 .pend jakoc would have to know what virtual register types to use for this to work out. It would probably look something like this in Jako: sub int SDL_BlitSurface : libsdl:SDL_BlitSurface:i (obj src, obj, srcrect, obj dst, obj dstrect); Where the third colon-separated field is redundant in this case and can become the empty string. Or possibly (a call without a previous declaration): var int foo = SDL_BlitSurface : libsdl:SDL_BlitSurface:i (a, b, c, d); (although please don't hold me to these syntax ideas -- they are only my first ones). Things that would make this nice: * Multiple loadlibs for the same lib don't cause trouble and are fast. * Same for multiple dlfunc calls for the same thing. Anyway, more thinking and talking is probably in order. I'd love to see an imcc implementation of PDD 3 like or better than the above sketch, so I can rely on IMCC to keep all the register stuff straight. After that, I don't think the incremental effort in jakoc creates a high barrier. Regards, -- Gregor
Re: right-to-left pipelines
At 10:41 AM -0800 12/11/02, Michael Lazzaro wrote: How much overhead do we expect (runtime) multimethods to have? I would guess it to be nontrivial, e.g. substantially worse than normal methods... I'd expect a non-trivial overhead to start, declining with time, only paid when calling methods or subs that could be potentially multimethod. I know a number of techniques to make the cost smaller, and they'll get implemented over time, but it'll likely never be free, at least not for perl. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote: This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. $obj1 eq $obj2;# [1] are their stringifications identical? $obj1 == $obj2;# [2] are their numifications identical? $obj1 === $obj2; # [3] are they in fact the same object? The reason being that you could in fact want to say any of [1], [2], and [3] as separate, useful concepts. So merely overloading '==' or 'eq' would not be sufficient, as it would hide the previous, still useful meanings. MikeL
Properties
Are in. You can now get, set, delete, and get a hash of PMC properties. (Hopefully) Alas, no tests. Working on that, but if someone wants to beat me to it, feel free. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote: On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote: This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Given that this will not be a commonly used feature, I wouldn't give it a special operator. Just use a method. $foo.sameas $bar; %foo.sameas %bar; @foo.sameas @bar; $obj1 eq $obj2;# [1] are their stringifications identical? $obj1 == $obj2;# [2] are their numifications identical? $obj1 === $obj2; # [3] are they in fact the same object? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Funny thing about weekends when you're unemployed. They don't mean quite so much 'cept you get to hang out with your workin' friends. - Primus Spaghetti Western
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. This is used in various other languages. $obj1 eq $obj2;# [1] are their stringifications identical? $obj1 == $obj2;# [2] are their numifications identical? $obj1 === $obj2; # [3] are they in fact the same object? The reason being that you could in fact want to say any of [1], [2], and [3] as separate, useful concepts. So merely overloading '==' or 'eq' would not be sufficient, as it would hide the previous, still useful meanings. There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). Unfortunately, this concept gets fuzzy because there may be multiple equivalence classes that define different values of same-ness for a given pair of objects. As a trivial example, consider the equivalence class of case insensitivity, applied to strings. The current way of defining this is to say: ($a.lc eq $b.lc) # assuming lc is a member, not a sub But this requires us to create two new strings before we can compare them. Whilst there might be optimizations for special cases, the general problem remains: its not nice to define equivalence classes as conversions to strings/numbers. Another way of expressing the above example, is: $a.compare_case_insensitive($b) or compare_case_insensitive($a, $b) This is a general solution, but it seems a bit heavyweight for many/most specific cases. It seems to me that most objects/classes have a default definition of sameness. For this, it'd be nice to use a simple operator (e.g. '==' or 'eq') If I defined my Str $a is CaseInsensitive = hELLO; then I would like C $a eq Hello to DWIM. Can this be applied to other objects? If I have a class named PostalAddress, then I'd expect to compare them as addresses, not as strings. Instead of $a.canonical_value eq $b.canonical_value. I just want to use Ceq (or, if you insist, a new operator that currently has no name). Sameness is probably a more common operator then identical-ness (I use the latter frequently: but I write a lot of code for testing and debugging -- its my job). So perhaps the C=== operator could be used for comparison under the default equivalence-class of the operands. I'd find it unintuitive, but I'm could get used to it. Dave.
RE: Stringification of references (Decision, Please?)
Michael Lazzaro: # Piers wrote: # I doggishly maintain my preference for treating stringification for # output and stringification for debugging differently, but # as long as # I can specify an AS_STRING (sp?) method for a class, and # _still_ get # at a debugging version to print to other (debugging-related) # strings, I # think we're all basically happy. That implies, however, that we need # at least two methods per type/class: AS_STRING, and # AS_DEBUG, for lack # of better names. By default, the first calls the second. I stick with .str and .id. If you're worried about namespace pollution, maybe prefix:~ and prefix:id can be used instead. --Brent Dax [EMAIL PROTECTED] @roles=map {Parrot $_} qw(embedding regexen Configure) If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible. --Ayn Rand, explaining how today's philosophies came to be
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 2:28 PM -0800 12/11/02, Michael G Schwern wrote: On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote: On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote: This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Given that this will not be a commonly used feature, I wouldn't give it a special operator. Just use a method. $foo.sameas $bar; %foo.sameas %bar; @foo.sameas @bar; I'd have to agree. Testing for this sort of thing seems relatively uncommon, and wasting punctuation on it doesn't seem worth it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Dave Whipp wrote: Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. I could also see :== or =:= as well. If we have $obj1 = $obj2; then presumably, ($obj1 == $obj2) is true (using '==' for your value comparison you discuss below). But ($obj1 === $obj2) is not necessarily true, becasue $obj1 could be a copy of $obj2, not an alias thereof. However, if you do $obj1 := $obj2; then not only is ($obj1 == $obj2) true, but so is ($obj1 === $obj2) So I could see = leading to == for comparison, and := leading to =:= for comparison. There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). Sameness is probably a more common operator then identical-ness (I use the latter frequently: but I write a lot of code for testing and debugging -- its my job). So perhaps the C=== operator could be used for comparison under the default equivalence-class of the operands. I'd find it unintuitive, but I'm could get used to it. If we wanted to test equivalence... I see === as OK, since (to me, at least) is is suggestive of the three-line equivalence symbol used mathematically. Of course, using Unicode, we could get away with using that symbol (which I don't know how to type...) Dave.
Re: right-to-left pipelines
Michael Lazzaro asked: All subroutines with multiple signatures would have this problem, right, even normal non-method subs? foo $a, $b, $c, $d; # how many args? Yep. Can't be known unless predeclared and hence compile-time discernible. And methods can't be discerned in the presence of run-time dispatch. Oof. I had been (foolishly?) hoping that if argument types were known at parse time (due to previous declarations), it would frequently be possible to resolve the multimethod variant during compilation. That would be a very rare case. The whole point of late dispatch is that it's the *run-time* types of the object(s) that determine which method is called. Even if you write: my Foo $foo; # and later in the same lexical scope... $foo.bar(); there's no way at compile time of knowing what class of object $foo contains. It could be a Foo object, or it could be an object of any class that inherits from Foo. So there's no way of knowing which class's Cbar method to invoke. Damian
Re: REs as generators
Luke Palmer asked: Can junctions have methods? If we decide they can, yes. ;-) How do you tell the difference between calling a junction's method and calling a method on each of its states? If it's a method of the class Junction (or one of its four subclasses) then it's a method call on the junction itself. If it's not defined in the built-in class, then it's a method call distributed over the states of the junction. Damian
Everything is an object.
This is just your friendly neighborhood curmudgeon reminding you that in Perl 6, everything is an object. This is a concept that, as Perl programmers, we're not familiar with. What are the consequences of this in language design? Well, it means not every new piece of functionality requires a new operator. Instead, consider a method. Its an actual word. Stemming the tide of new grammar and operators heads off another problem, typos becoming meaningful. The more operators you have, the more chance that this sort of thing: if $num1 === $num2 { ... will be hard to find. Was it a typo or did they really mean to do a shallow object comparison? Instead of introducing new built-in functions they can be done as methods. This reduces core namespace pollution. Think of the core like a big CPAN module. Every built-in is like an exported function. Every word used as a built-in is one that noone else can safely use for something else in their own code. If you want a tactile grasp of the Everything is an object concept, try some Ruby. Many pieces of edge functionality which are useful but would have been rejected because they don't really warrent a new built-in or operator can be put in as methods. For example, in Ruby you can alter the default value of a hash like so: h = {foo = 42}; h.default = wibble; # Prints 'wibble' rather than undef. print h[bar]; Isn't that neat? Not important enough to warrent a new built-in, but something nice to have in your toolbox. How many times have you done this in perl: print grep defined, @array; in Ruby, its just this: print array.compact I find myself doing this alot: $string =~ s/^\s+//; $string =~ s/\s+$//; in Ruby: string.strip! Ruby can add neat little features without long deliberations about the impact on language growth and backwards compatibilty because they have the ability to add methods to core types. A flip through the Ruby builtin methods is nice for building up some envy. :) http://www.rubycentral.com/book/builtins.html Sometimes you do need to use an operator or built-in. Usually to make data transformations flow nicely: @foo = join \n, map { ... } grep { ... } sort @bar; the concept can be reversed: @foo = @bar.sort.grep(...).map(...).join(\n); but is that Perlish? Or you will commonly use the operator on expressions rather than variables. 1 + 2 == 3 would suck as: (1 + 2).eq 3 There's lots of reasons to use an operator or built-in instead of a method, but remember to make the consideration first. Don't go grammar happy. In closing: Consider a method rather than a built-in or operator. Everything is an object. Tattoo it on your forehead today. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do you actually think about what you are saying or is it an improvisational game of Mad Libs that you play in your head?
Re: right-to-left pipelines
Simon Cozens wrote: *Why* do methods need their parens? Because calls to them are not resolved until run-time and because methods can be overloaded by signature, so we can't tell at parse time what the parameter list of the called method will be (i.e. where it will end), so we can't determine how to parse the arguments... I'm just talking about passing a block to a method. You think I'm talking about a clever way of specifying a method's argument signature. I'm not. You underestimate your ability to communicate, Simon. I understood exactly what you wanted: pass a closure to a method without needing to wrap the closure in parens. I was explaining why I think we ought to keep the parens. And that is because, without them, we can't tell how many arguments to pass to the method. And because the default (pass all of 'em) isn't a good enough answer. Damian
Re: REs as generators
Dave Storrs wrote: On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote: Why use regexen when you can just use junctions? my $foos = 'foo' ~ any(0..9) ~ any(0..9); At what moment does a junction actually create all of its states? Hmm...perhaps a clearer way to say that is At what moment does a junction allocate memory for, and initialize that memory with, all of its states? That will have to be done lazily in some cases at least: if $input == any(13...); so maybe it should be done lazily in all cases. - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. Junctions don't collapse. They distribute. Remember: Junctions Aren't Quantum. Damian
Re: Everything is an object.
[EMAIL PROTECTED] (Michael G Schwern) writes: If you want a tactile grasp of the Everything is an object concept, try some Ruby. If you want a tactile grasp of Perl 6, try some Ruby. But I'll be saying a lot more on that later... A flip through the Ruby builtin methods is nice for building up some envy. :) http://www.rubycentral.com/book/builtins.html I vaguely object to calling them builtins, as I've objected to similar concepts in Perl 6. They aren't *built in* to the language - you could add another method and the parser wouldn't give a damn - they are methods of the standard libraries that ship with Ruby. This distinction is important, despite what Damian would have you believe. In the same way, the specification of C-as-a-language, its syntax and operators and the stuff that makes it look, act and feel like C, is agnostic of the C standard library. (Even though ANSI C specifies both, they are seperable.) This seperability is something I'd like to see thought about a lot more in Perl 6. There's lots of reasons to use an operator or built-in instead of a method, but remember to make the consideration first. Don't go grammar happy. Yes, yes, yes. This is what I've been trying to say for a while. -- If that makes any sense to you, you have a big problem. -- C. Durance, Computer Science 234
Re: right-to-left pipelines
* Damian Conway ([EMAIL PROTECTED]) [12 Dec 2002 10:32]: [...] You underestimate your ability to communicate, Simon. I understood exactly what you wanted: pass a closure to a method without needing to wrap the closure in parens. Simon appears to want to have closures as params just like Ruby. As in: array.each { |x| puts x } rather than @array.each({ print $_[0]\n }) (or however the syntax would currently be) I was explaining why I think we ought to keep the parens. And that is because, without them, we can't tell how many arguments to pass to the method. And because the default (pass all of 'em) isn't a good enough answer. So why does Ruby have so little trouble with it? cheers, -- Iain.
Re: right-to-left pipelines
[EMAIL PROTECTED] (Damian Conway) writes: You underestimate your ability to communicate, Simon. I understood exactly what you wanted: pass a closure to a method without needing to wrap the closure in parens. Fair enough. I was explaining why I think we ought to keep the parens. And that is because, without them, we can't tell how many arguments to pass to the method. Not if it is specified that a block comes after the final argument. But then I am aware that I'm possibly subconsciously trying to make Perl 6 look like a certain other language. And because the default (pass all of 'em) isn't a good enough answer. So will we need parens around the arguments of the indirect object : form? Also, how is this different from the problems Perl 5 currently has - and solves - in determining which arguments to pass? -- In this talk, I would like to speculate a little, on ... the development of intelligent life. I shall take this to include the human race, even though much of its behaviour throughout history has been pretty stupid... - Stephen Hawking
RE: right-to-left pipelines
Damian Conway: # that determine which method is called. Even if you write: # # my Foo $foo; # # # and later in the same lexical scope... # # $foo.bar(); # # there's no way at compile time of knowing what class of # object $foo contains. It could be a Foo object, or it could # be an object of any class that inherits from Foo. So there's # no way of knowing which class's Cbar method to invoke. Your point being...? Shouldn't it only dispatch to methods defined in Foo? If it's typed as Foo, you shouldn't be using any methods that aren't in Foo, IMHO. --Brent Dax [EMAIL PROTECTED] @roles=map {Parrot $_} qw(embedding regexen Configure) If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible. --Ayn Rand, explaining how today's philosophies came to be
Re: right-to-left pipelines
[EMAIL PROTECTED] (Iain 'Spoon' Truskett) writes: So why does Ruby have so little trouble with it? Because the Ruby designer(s) don't have fifteen years of Perl experience muddling up their heads. :) But seriously, Ruby does something a little tricky here that Perl 6 should probably *not* follow, despite my protestations: it treats a block (essentially) as a special, seperate type of argument. You have a receiver, than a mmethod, then its arguments, then an optional block. This is syntactically beautiful if you're just passing a single block, (such as to map, grep, sort, etc.) mildly ugly if you want to pass some arguments and a block, and really very ugly indeed if you want to pass two blocks. And that's probably something we would want to do. Hmm. But we'd want to be throwing multiple blocks around only in rarer cases, so maybe we should optimize for beautifying the common cases at the risk of ugliness in the less common cases. Or maybe we should take the path of least overall ugliness. I don't know. -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: right-to-left pipelines
[EMAIL PROTECTED] (Brent Dax) writes: # my Foo $foo; # # # and later in the same lexical scope... # # $foo.bar(); Your point being...? Shouldn't it only dispatch to methods defined in Foo? Are you taking full account of what sort of magic may be performed between the two statements? :) Urgh: my Foo $foo; my Bar $bar; $foo := $bar; # Compile-time error? Also, Foo might change its nature, be replaced, import new methods from somewhere else, change its inheritance tree, or ... This is Perl - anything could happen, and often does. -- A word to the wise: a credentials dicksize war is usually a bad idea on the net. (David Parsons in c.o.l.development.system, about coding in C.)
Re: right-to-left pipelines
Simon Cozens wrote: I was explaining why I think we ought to keep the parens. And that is because, without them, we can't tell how many arguments to pass to the method. Not if it is specified that a block comes after the final argument. The only way that this could be specified is with a signature on the method. Which is exactly the problem it outlined in my original answer. And because the default (pass all of 'em) isn't a good enough answer. So will we need parens around the arguments of the indirect object : form? In the same circumstances, yes. Also, how is this different from the problems Perl 5 currently has - and solves - in determining which arguments to pass? Perl 5 doesn't have the problem. That's because Perl 5 totally ignores any prototype you place on a method, and just passes every argument it can find. Nor does it complain when that argument list doesn't match the method's prototype. But in Perl 6, the consistency between a method's parameter list and its argument list *is* checked at run-time, so passing the wrong number of arguments is (quite literally) fatal. Damian
RE: right-to-left pipelines
Simon Cozens: # Are you taking full account of what sort of magic may be # performed between the two statements? :) # # Urgh: # my Foo $foo; # my Bar $bar; # $foo := $bar; # Compile-time error? Eww, gross. # Also, Foo might change its nature, be replaced, import new # methods from somewhere else, change its inheritance tree, or # ... This is Perl - anything could happen, and often does. Fine. In Perl 5 we have a restriction on when you can and can't use parens on a subroutine--you can omit them when the sub is predeclared, and Perl will assume that no magic is going on. I see nothing wrong with this rule. --Brent Dax [EMAIL PROTECTED] @roles=map {Parrot $_} qw(embedding regexen Configure) If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible. --Ayn Rand, explaining how today's philosophies came to be
Re: right-to-left pipelines
[EMAIL PROTECTED] (Damian Conway) writes: But in Perl 6, the consistency between a method's parameter list and its argument list *is* checked at run-time, so passing the wrong number of arguments is (quite literally) fatal. But wait! If we can check how many parameters to pass, we know how many parameters to pass; problem solved. Sure, the parser has to stay in a superposition of states until the check is made, but we're close to requiring quantum supercomputers to run this thing anyway. I'm afraid I can't tell whether or not I'm being serious any more. -- gnat TorgoX: you're rapidly learning, I see, that XML is a fucking piece of festering shit which has no more justification for walking God's clean earth than a dung beetle with diarrhoea.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ More generally, I really don't want to have too many (any?) system object method names squatting in my all-lowercase object method namespace. It's not hard to think of many kinds of objects that would naturally have an id attribute, but must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. (The more I think about it, the more I like some kind of reserved prefix like _ or even perl_...but I'd accept oid :) -John
Re: Everything is an object.
Michael G Schwern [EMAIL PROTECTED] wrote: This is just your friendly neighborhood curmudgeon reminding you that in Perl 6, everything is an object ... Instead of introducing new built-in functions they can be done as methods. The problem with this worldview is that you end up with horrible asymmetries suh as: 1 + 2 == 3 would suck as: (1 + 2).eq 3 There is a difference between verbs and noun. Sometimes you don't want to associate a verb with an object: you want to associate it with the subject: the cat sat on the mat is that the_mat.sat_on(the_cat) or the_cat.sat_on(the_mat) or sat_on(the_cat, the_mat) All of those seem to loose the preposition. Are sat_on and sat_beside really completely independent things? Under perl's grammar: yes. Seems to me that identifiers have a complex fusional word-structure, which is opaque to the grammar of the language. The more structure you can expose into the parse tree, the more powerful will be manipulations on that tree. Perl6 allows there different worldviews, but we need to make sure that verbs are as entensible as nouns. Multimethods are wonderful things. Don't add something as a method if it makes more sense as a multi-method. Don't use an asymmetric method syntax for a symmetric concept. To say everything is an object: extend by adding methods elevates Nouns over Verbs. And it completely ignores all the other parts of the language. Sometimes people seem to think that the only alternative is to add built-ins: but this really shouldn't be the case -- not in a language as powerful as Perl6. Dave.
Re: Comparing Object Identity
On Wednesday, December 11, 2002, at 02:54 PM, Dave Whipp wrote: There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). I think that is covered by C~~. As long as we can create class-specific variants of smart matching, we're fine. I don't know that I'd want to use Ceq for this. It's possible that you want stringification to do something not entirely normalized/canonical. MikeL
Re: Everything is an object.
[EMAIL PROTECTED] (Dave Whipp) writes: There is a difference between verbs and noun. Sometimes you don't want to associate a verb with an object: you want to associate it with the subject: Verbs are almost always associated with their subject in OO languages, so I don't see where you're coming from. the cat sat on the mat is that the_mat.sat_on(the_cat) Nope. or the_cat.sat_on(the_mat) This one. If you called $cat-sit_on($mat); in Perl 5, who would you expect to be sitting on what? All of those seem to loose the preposition. Are sat_on and sat_beside really completely independent things? $x.sat_beside($y); $y.sat_beside($x); Hey, it's just like English, but with more punctuation! And we know how well people deal with punctuation! Under perl's grammar: yes. Well, no, as I've just demonstrated. -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
Re: Comparing Object Identity
[EMAIL PROTECTED] (Michael Lazzaro) writes: I think that is covered by C~~. As long as we can create class-specific variants of smart matching, we're fine. If we can't, case^Wgiven statements become very boring indeed. For reference, and purely for reference, Ruby has four object comparators: a == b # They have the same value a.equal?(b) # They are utterly the same object in memory a === b # They are equivalent (class-specific comparator and case # statement comparison operator) a =~ b # They match (class-specific comparator) -- Pretty, smart, sane:Pick two. - Ron Echeverri
Re: Everything is an object.
Simon Cozens [EMAIL PROTECTED] wrote Verbs are almost always associated with their subject in OO languages, so I don't see where you're coming from. Actually, the important part of it was the 3rd option (the multimethod): sometimes the association is symmetrical. I was pointing out that the concept - OO mapping is very lossy. All of those seem to loose the preposition. Are sat_on and sat_beside really completely independent things? Under perl's grammar: yes. Well, no, as I've just demonstrated. I must have missed it in your post. I saw no Perl grammar that sees the commonality between .sit_on and .sit_beside. Perl thinks of them as two independent methods (The programmer can choose to implement them with some commonality). We seem happy to structure objects (using attributes, etc.), but verbs remain flat and uninteresting: just arbitrary names. As a result of this lack of expressiveness in the grammar, we find ourselves saying that if a concept doesn't fit the everything is an object worldview, then it needs to be a built-in. I'm not saying that I have an alternative: just explaining why we keep proposing built-ins instead of using the methods on objects. Dave.
Re: Properties
On Wed, 11 Dec 2002, Dan Sugalski wrote: Are in. You can now get, set, delete, and get a hash of PMC properties. (Hopefully) Alas, no tests. Working on that, but if someone wants to beat me to it, feel free. I would expect this: new P0, .PerlInt new P1, .PerlInt set S0, Brown set P0, Yes setprop P1, S0, P0 set S0, Black set P0, No setprop P1, S0, P0 new P2, .PerlString getprop P2, Brown, P1 print P2 print \n getprop P2, Black, P1 print P2 print \n end to print: Yes No In fact, it prints: No No Is this a bug, or am I misunderstanding how properties are supposed to work? Simon
Re: Properties
On Wed, 11 Dec 2002, Simon Glover wrote: Is this a bug, or am I misunderstanding how properties are supposed to work? Well, there's definitely a bug somewhere, as the previously posted example causes a segfault if run with --gc-debug. Backtrace follows: #0 0x08075bb1 in hash_lookup (interpreter=0x813a8f0, hash=0x0, key=0x813d528) at hash.c:355 #1 0x08075bff in hash_get (interpreter=0x813a8f0, hash=0x0, key=0x813d528) at hash.c:363 #2 0x080d8ff8 in Parrot_PerlHash_get_pmc_keyed (interpreter=0x813a8f0, pmc=0x8147928, key=0x81479dc) at perlhash.pmc:181 #3 0x080d30a1 in Parrot_default_getprop (interpreter=0x813a8f0, pmc=0x8147970, key=0x813d528) at default.pmc:54 #4 0x080bc0ee in cg_core () at core.ops:3873 #5 0x08074144 in runops_cgoto_core (interpreter=0x813a8f0, pc=0x813f618) at runops_cores.c:52 #6 0x08049730 in runops_generic (core=0x8074130 runops_cgoto_core, interpreter=0x813a8f0, pc=0x813f618) at interpreter.c:46 #7 0x08049e45 in runops (interpreter=0x813a8f0, code=0x813ac88, offset=0) at interpreter.c:372 #8 0x080a63b5 in Parrot_runcode (interpreter=0x813a8f0, argc=1, argv=0xbfffe4bc) at embed.c:308 #9 0x080e217e in main (argc=1, argv=0xbfffe4bc) at test_main.c:51 #10 0x400b4647 in __libc_start_main (main=0x80e20e8 main, argc=3, ubp_av=0xbfffe4b4, init=0x8048f78 _init, fini=0x80e2790 _fini, rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xbfffe4ac) Simon
[perl #19059] [PATCH] jako.in portability
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19059] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19059 Attached, please find a patch that makes jako's makefile slightly more portable. It adds in the appropriate ${exe}, and removes the dependency on ln -s to have a local copy of the executable. Tested, works on cygwin. If it doesn't break gregor Perhaps now I can get around to seeing why jako's make test is dying... Enjoy. -- Will Coke Coleda -- attachment 1 -- url: http://rt.perl.org/rt2/attach/44940/35429/90428e/jako.in.patch --- jako.in Wed Dec 11 18:53:52 2002 +++ jako.in_new Wed Dec 11 20:36:17 2002 @@ -10,7 +10,7 @@ DIR=languages/jako TOOL_DIR=../.. ASM=$(PERL) -I ../../lib ../../assemble.pl -IMCC=imcc +IMCC=../imcc/imcc${exe} JAKOC=$(PERL) -I lib jakoc INTERP=../../${test_prog} @@ -64,11 +64,8 @@ .imc.pasm: $(IMCC) -o $@ $ || (rm -f $@ false) -../imcc/imcc: - @cd ../imcc make - -imcc: ../imcc/imcc - ln -s ../imcc/imcc imcc +imcc: ../imcc/imcc${exe} + @cd ../imcc make examples/bench.pasm: examples/bench.imc imcc examples/euclid.pasm: examples/euclid.imc imcc @@ -110,7 +107,7 @@ # clean: - $(RM_F) imcc examples/*.imc examples/*.pasm examples/*.list examples/*.pbc + $(RM_F) examples/*.imc examples/*.pasm examples/*.list examples/*.pbc over: @$(MAKE) clean
Re: Everything is an object.
On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote: First, universal operators and universal methods both pollute the useful (programmer) namespace to nearly the same extent. Most of the methods are not universal. For example: $foo.compress would be in the String class, not Object (or whatever we're calling the equivalent of UNIVERSAL today), and only inherited by those objects which wish to masquerade as strings. %hash.default is in the Hash class. The sameas example: $obj.sameas $obj2 would be in the Object class and would pollute. Using Ruby as a rough guide, there aren't many of those. http://www.rubycentral.com/book/ref_c_object.html -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One One disease, long life. No disease, short life.
Re: Everything is an object.
On Wednesday, December 11, 2002, at 05:21 PM, Michael G Schwern wrote: On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote: First, universal operators and universal methods both pollute the useful (programmer) namespace to nearly the same extent. Most of the methods are not universal. For example: $foo.compress would be in the String class, not Object (or whatever we're calling the Right, I just wanted to clarify. Because deciding between, say: $foo.sameas($bar);# universal method $foo === $bar;# universal operator would be a false savings. If a method _is_ universal, especially if it's symmetric, it might be an OK candidate for a builtin or operator. And if it isn't universal, I can see (almost) no justification for wasting an op on it, no matter how common it is. (Again, though, C$foo.id == $bar.id is OK by me.) MikeL
Re: Everything is an object.
[EMAIL PROTECTED] (Michael Lazzaro) writes: would be a false savings. If a method _is_ universal, especially if it's symmetric, it might be an OK candidate for a builtin or operator. And if it isn't universal, I can see (almost) no justification for wasting an op on it, no matter how common it is. Bingo. And things like purge only apply to arrays and lists, hence... -- MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. (By [EMAIL PROTECTED])
Re: right-to-left pipelines
[EMAIL PROTECTED] (Damian Conway) writes: But in Perl 6, the consistency between a method's parameter list and its argument list *is* checked at run-time, so passing the wrong number of arguments is (quite literally) fatal. But wait! If we can check how many parameters to pass, we know how many parameters to pass; problem solved. Sure, the parser has to stay in a superposition of states until the check is made, but we're close to requiring quantum supercomputers to run this thing anyway. That works, with one big proviso. You have to have predeclared all possible methods in the class to which the object belongs, AND each method in that class (and all defined subclasses) has to have a unique signature. All right, that's two provisos, but the first is probably already a given. Consider: # Excuse my crummy Perl6 syntax, but you know what I mean. class B { method bar($x, $y) { # mumble . . . } method bar($z) { # note 1 # different mumble . . . } # . . . other methods such as new . . . } my B $foo .= new(); # With parens, these are unambiguous. @abc = ($foo.bar(3, 4)); @abc = ($foo.bar(3), 4); # So which is this? @abc = ($foo.bar 3, 4); Now this case might be manageable, but what if the two-argument bar() is in class D instead, and D inherits from B? My point is that in this case parentheses are needed to disambiguate which method needs to be called. You could avoid the parentheses if you made the above example illegal by requiring that all methods with the same name in a class hierarchy have the same signature (specifically, the same number of arguments), but that seems somewhat unPerlish, and even more restrictive than C++ (not a good thing). The fact that parentheses are not needed when passing arguments to regular household functions seems to imply to me that it isn't possible to declare two functions with the same name and different signatures (like C++ function overloading). Otherwise the ambiguity would strike again. I'm uneasy about how the whole parentheses thing sits when multimethods are brought into the equation, but then I'm uneasy about multimethods in the first place. I don't mind if people practise that kind of thing in the privacy of their own homes, but not out in public, please. I'm afraid I can't tell whether or not I'm being serious any more. Damian, you broke Simon! How could you? -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] My words, your expression. My land, always your possession. My song, your production. My expense is always your deduction. - _You Don't Believe_, The Alan Parsons Project
Re: right-to-left pipelines
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes: That works, with one big proviso. You have to have predeclared all possible methods in the class to which the object belongs, AND each method in that class (and all defined subclasses) has to have a unique signature. No! No, no, no! You're missing the beauty of runtime dispatch. Because the method will be located at runtime, you only need that particular method (which ever class in may happen to be in) to know how many arguments it wants, (which I think was stipulated in Damian's message but I could be mistaken) and it can all be resolved at run time. If you keep around the n possible parses. Which you can do. It just shortens Dan's lifespan. class B { method bar($x, $y) { method bar($z) { # note 1 Oh, bringing in multimethods Just Isn't Fair. I'm uneasy about how the whole parentheses thing sits when multimethods are brought into the equation, but then I'm uneasy about multimethods in the first place. I don't mind if people practise that kind of thing in the privacy of their own homes, but not out in public, please. Well, you know, you brought them up, you get to mop away the issue. Damian, you broke Simon! How could you? Oh, be fair, I was broken long before Perl 6 appeared on the scene. -- Contrariwise, continued Tweedledee, if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic! -- Lewis Carroll, Through the Looking Glass
Re: Everything is an object.
On Wednesday, December 11, 2002, at 05:39 PM, Simon Cozens wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: would be a false savings. If a method _is_ universal, especially if it's symmetric, it might be an OK candidate for a builtin or operator. And if it isn't universal, I can see (almost) no justification for wasting an op on it, no matter how common it is. Bingo. And things like purge only apply to arrays and lists, hence... Wel... yes and no. You can make the same argument for operators upon scalars, for example, since 'scalar' is arguably no more universal than 'array'. And we could easily use that argument to remove *all* builtins, period: print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?) reverse @a; # ILLEGAL; use @a.reverse; map {...} @a; # ILLEGAL; use @a.map({...}); sort {...} @a; # keys %h;# ...etc... in which case right-to-left pipes go away entirely, if we want them to. But if we decide to allow _some_ array-based builtins (or even if we just make them all methods of Array and Hash) then deciding _which_ ones to include falls under the YMMV argument -- we have to guess. So purge or Cpart is valid to at least *consider* for inclusion. My point was that in lang design it's possible to make a convincing but purely philosophical argument for or against anything (postmodernism?), and as such it will never be possible to declare hard-and-fast rules for what should or should not be a builtin. We just have to fight it out on a case-by-case basis. MikeL
Re: Everything is an object.
On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote: print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?) reverse @a; # ILLEGAL; use @a.reverse; map {...} @a; # ILLEGAL; use @a.map({...}); sort {...} @a; # keys %h;# ...etc... (And yes, I'm aware that (1 = N = 5) of those are going away already.) MikeL
Re: Everything is an object.
[EMAIL PROTECTED] (Michael Lazzaro) writes: Wel... yes and no. You can make the same argument for operators upon scalars, for example, since 'scalar' is arguably no more universal than 'array'. And we could easily use that argument to remove *all* builtins, period: Now you're getting the idea. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
RE: right-to-left pipelines
Uri Guttman: # BD Fine. In Perl 5 we have a restriction on when you can # and can't use # BD parens on a subroutine--you can omit them when the sub # is predeclared, # BD and Perl will assume that no magic is going on. I see # nothing wrong # BD with this rule. # # but you are conflating plain subs and method calls. perl6 can # deal with predeclared subs and fixed argument signatures at # compile time like perl5 can. but the same is not true in # either 5 nor 6 with method calls as they can only be looked # up at run time. the arguments passed to a method can be I'm speaking to the very specific case where the invocant is typed, so we know the (base) type at compile time. # checked then against know method signatures and maybe # multimethods could (dunno who or when that is decided. i # think the class has to be declared as having multimethods) be # invoked based on the arguments. # # so the need for parens on method calls is there if you have # any possible compile time ambiguity of how many arguments to pass in. But when you know the type beforehand, there shouldn't *be* any ambiguity. You can see the methods in that class, and you know how many arguments the biggest implementation of a multimethod[1] takes. Just assume that that's the one being called. Just to make things clear: class X { method x($a, $b) { } method x($a) { } } my $obj1 = X.new; my X $obj2 .= new; $obj1.x $a; # syntax error (missing parentheses on # untyped method call, or something like that) $obj2.x $a; # OK, like $obj2.x($a) $obj1.x $a, $b, $c; # syntax error $obj2.x $a, $b, $c; # OK, like $obj2.x($a, $b), $c I do *not* expect Perl to do the impossible or even the very difficult. This isn't even very difficult. [1] Is there a word for the chunk of code associated with a certain signature? --Brent Dax [EMAIL PROTECTED] @roles=map {Parrot $_} qw(embedding regexen Configure) If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible. --Ayn Rand, explaining how today's philosophies came to be
Re: right-to-left pipelines
Simon Cozens wrote: [EMAIL PROTECTED] (Deborah Ariel Pickett) writes: That works, with one big proviso. You have to have predeclared all possible methods in the class to which the object belongs, AND each method in that class (and all defined subclasses) has to have a unique signature. Oh boy, that was badly worded on my part. Still, I hope I got my point across that having same-method-name, different-signatures is Bad from the perspective of havving DWIM bracketing. No! No, no, no! You're missing the beauty of runtime dispatch. Because the method will be located at runtime, you only need that particular method (which ever class in may happen to be in) to know how many arguments it wants, (which I think was stipulated in Damian's message but I could be mistaken) and it can all be resolved at run time. If you keep around the ^^ n possible parses. Which you can do. It just shortens Dan's lifespan. ^^ About this point was when my brain when a ha!. But I'm not yet convinced that generating all possible parses is (a) of sane time complexity, and (b) a little *too* DWIM for its own good. class B { method bar($x, $y) { method bar($z) { # note 1 Oh, bringing in multimethods Just Isn't Fair. Those are multimethods? Migod, I feel like a person who's just discovered for the first time in their life that the plate that gets passed around in church is for putting money *onto*. (Seriously, my OO is heavily C++-influenced, so I just think of the above as function overloading. I thought multimethods existed in a sort of parallel universe to regular class-and-method hierarchies, like friend functions done right.) (And where did my note 1 go in my original email? Perhaps it had all the answers I was looking for.) I'm uneasy about how the whole parentheses thing sits when multimethods are brought into the equation, but then I'm uneasy about multimethods in the first place. I don't mind if people practise that kind of thing in the privacy of their own homes, but not out in public, please. Well, you know, you brought them up, you get to mop away the issue. Lucky me. Let's try and be pragmatic[*] here. If we stick to the following subset of the problem space: - no multimethods - all method signatures known through predeclaration - no method name has two different signatures in the same class hierarchy (all of which can be determined at compile-time), then there should only be one possible legal parsing for any particular method call or pipeline of method calls. Yes, the ACTUAL methods called may not be knowable at compile time (due to polymorphism), but at least the syntax tree has only one valid shape. Personally I think that this subset forms the vast majority of normal OO designs, in any case. Can we dictate that parentheses are optional in this case, and demand parentheses in all others? Would that make everyone happy? (Except multimethod freaks, but then, I've already said enough about you (or is that us?).) [*] Tough on a list like this, I know, but bear with me. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] My words, your expression. My land, always your possession. My song, your production. My expense is always your deduction. - _You Don't Believe_, The Alan Parsons Project
Re: right-to-left pipelines
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes: About this point was when my brain when a ha!. But I'm not yet convinced that generating all possible parses is (a) of sane time complexity, and (b) a little *too* DWIM for its own good. As I said, I wasn't sure whether or not I was being serious at this point. method bar($x, $y) { method bar($z) { # note 1 Oh, bringing in multimethods Just Isn't Fair. Those are multimethods? Migod, I feel like a person who's just discovered for the first time in their life that the plate that gets passed around in church is for putting money *onto*. Oh, if you have a method which does X when it gets one argument and does Y when it gets another, I'd call that a multimethod. But then, I am no OO wizard. Let's try and be pragmatic[*] here. If we stick to the following subset of the problem space: - no multimethods - all method signatures known through predeclaration - no method name has two different signatures in the same class hierarchy (all of which can be determined at compile-time), then there should only be one possible legal parsing for any particular method call or pipeline of method calls. Yes! I agree! However, there is a problem. We have determined that, in a dynamic language, the actual method lookup is done at runtime. That is, we don't know what method we're going to call until runtime. That is, we don't know what method we're going to call until well after the method call statement has been parsed. If your head isn't spinning yet, remember that some evil coder may (conditionally) replace the method during the program's run, leaving us with the halting problem. Can we dictate that parentheses are optional in this case, and demand parentheses in all others? You see, the problem is that if we don't know what method we're going to call until way after we've parsed the code, (which I hope we've just proved above) we don't know how many parameters it's going to take. And if we don't know how many parameters it's going to take until we run it, we have next to zero chance of working out how many parameters it's going to take when we compile it. Which was the basis of my semi-serious notion of caching the whole set of possible parses. Which means that parens really can't be optional in this case. Except that this all sprung from my idea of having a block passed directly to a method without the other arguments being involved. (Which would work without parens, optional or otherwise. (because it works exactly this way in languages like Ruby (but most Perl 5 people can't get their heads around that (which is why this idea is facing a dead end. [*] Hey, what *was* note 1, anyway? -- LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly. - Red Drag Diva
Re: right-to-left pipelines
As I said, I wasn't sure whether or not I was being serious at this point. method bar($x, $y) { method bar($z) { # note 1 Oh, bringing in multimethods Just Isn't Fair. Those are multimethods? Migod, I feel like a person who's just discovered for the first time in their life that the plate that gets passed around in church is for putting money *onto*. Oh, if you have a method which does X when it gets one argument and does Y when it gets another, I'd call that a multimethod. But then, I am no OO wizard. I would just call that overloading based on number of arguments A multimethod is a mehtod that is overloaded based on types of arguments. Moreover, the types of the arguments are based on the dynamic, not static, type. method foo( Derived1 $x, Derived2 $y ) { } method foo( Derived2 $x, Derived1 $y ) {} my Base $x = new Derived1; my Base $y = new Derived2; foo( $x, $y ); foo( $y, $x ); Since foo is a multimethod, the correct foo gets chosen each time, even though the static type of $x and $y is Base.
Re: right-to-left pipelines
On Wed, Dec 11, 2002 at 07:08:58PM -0800, Brent Dax wrote: But when you know the type beforehand, there shouldn't *be* any ambiguity. You can see the methods in that class, and you know how many arguments the biggest implementation of a multimethod[1] takes. Just assume that that's the one being called. Just to make things clear: [ snip ] $obj2.x $a, $b, $c; # OK, like $obj2.x($a, $b), $c I do *not* expect Perl to do the impossible or even the very difficult. This isn't even very difficult. What you continue to make clear to me is that this is a maintenance nightmare without the parentheses. Even rules like always use the one with the biggest matching signature don't help. What happens when a developer multies your method by adding another parameter? It seems to me that the simplest disambiguating rule is to require the parentheses on methods. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 11 Dec 2002 19:21:35 -0500 From: John Siracusa [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ Well I use .str all the time, an .eq is one of my favorites! Don't take those, put a prefix on them! Theoretically, there are sufficiently few Object methods to warrant normal names. Also, when I write programs, I tend to design things to look as built in as possible. Once I've got a 500-line system going, I don't have to make the distinction between built in and my code, and modules' code. It's all part of the language, once I've put it there. In summary, my world view is that the language isn't there to help you code your own things; rather, you're extending the language constantly until the program can look like this: process for ; More generally, I really don't want to have too many (any?) system object method names squatting in my all-lowercase object method namespace. It's not hard to think of many kinds of objects that would naturally have an id attribute, but must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. I'd argue that you'd better pick a better name than .id anyway. You wouldn't use .foo_id and .bar_id, you'd use .descriptor or .index (though that one's not too much more descriptive than .index). I'd say .id should be kept short and sweet, because it's going to be used on a wider variety of objects than your database .id. (The more I think about it, the more I like some kind of reserved prefix like _ or even perl_...but I'd accept oid :) die $human.oid; Luke
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sent: 11 Dec 2002 23:16:30 GMT Date: Thu, 12 Dec 2002 10:16:26 +1100 From: Damian Conway [EMAIL PROTECTED] X-Accept-Language: en, en-us X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I rather like that. It's used for hashing by default (in absence of a stringification or .hash (?) method), yes? Luke
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm From: Dave Whipp [EMAIL PROTECTED] Date: Wed, 11 Dec 2002 14:54:18 -0800 Organization: Fast-Chip inc. X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Posted-By: 64.161.209.178 Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. This is used in various other languages. $obj1 eq $obj2;# [1] are their stringifications identical? $obj1 == $obj2;# [2] are their numifications identical? $obj1 === $obj2; # [3] are they in fact the same object? The reason being that you could in fact want to say any of [1], [2], and [3] as separate, useful concepts. So merely overloading '==' or 'eq' would not be sufficient, as it would hide the previous, still useful meanings. There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). So do 0123 and 123 represent the same value? Sometimes. Unfortunately, this concept gets fuzzy because there may be multiple equivalence classes that define different values of same-ness for a given pair of objects. As a trivial example, consider the equivalence class of case insensitivity, applied to strings. The current way of defining this is to say: ($a.lc eq $b.lc) # assuming lc is a member, not a sub But this requires us to create two new strings before we can compare them. Whilst there might be optimizations for special cases, the general problem remains: its not nice to define equivalence classes as conversions to strings/numbers. Another way of expressing the above example, is: $a.compare_case_insensitive($b) or compare_case_insensitive($a, $b) This is a general solution, but it seems a bit heavyweight for many/most specific cases. In general, there is no, um, general solution. Another equivalence class is whether two strings are equal when you change there first character to 'R'. cat and hat share this. But you wouldn't want a method for it. It seems to me that most objects/classes have a default definition of sameness. For this, it'd be nice to use a simple operator (e.g. '==' or 'eq') If I defined my Str $a is CaseInsensitive = hELLO; then I would like C $a eq Hello to DWIM. class CaseInsensitiveString is Str; sub operator:eq (CaseInsensitiveString $a, Str $b) { lc $a eq lc $b } sub operator:eq (Str $a, CaseInsensitiveString $b) { $b eq $a } (Technical detail: What would $a eq $b choose if both $a and $b are CCaseInsensitiveStrings, as both methods are equidistant from that expression?) Can this be applied to other objects? If I have a class named PostalAddress, then I'd expect to compare them as addresses, not as strings. Instead of $a.canonical_value eq $b.canonical_value. I just want to use Ceq (or, if you insist, a new operator that currently has no name). Sure. Just overload it. That's what overloading is for. Sameness is probably a more common operator then identical-ness (I use the latter frequently: but I write a lot of code for testing and debugging -- its my job). So perhaps the C=== operator could be used for comparison under the default equivalence-class of the operands. I'd find it unintuitive, but I'm could get used to it. I'm in favor of just using $a.id == $b.id. But the idea of === was to override what the object thought of as equal, and find out whether it is precisely the same object. Luke
Re: Parrot v0.0.9 code freeze
On Dec-10, Tanton Gibbs wrote: I'm looking at the Tru64 problem. Yay! Thank you.
Re: Parrot v0.0.9 code freeze
On Dec-11, Tanton Gibbs wrote: I'm still not sure what the problem is...but if you turn --gc-debug off, then the array diminsions are correct...e.g., 10 for the first dimension. Therefore, the calculation of the array index is performed correctly. However, with --gc-debug on, the array dimension is correct for the first dimension (0,0 - 0,20) as well as the first element of the first dimension...(1,0). But it is wrong for all of the others. It becomes 1 instead of 10. I have no clue yet why...still looking into it. However, all tests pass on Tru64 if --gc-debug is off. Are the Tru64 registers scanned for live PMCs/Buffers? I don't know what things would typically get missed that way, but it's a known problem for most architectures (or was until recently? What's the status on this?) Does Tru64 have hardware breakpoints? They're nice for this sort of thing -- find a value that eventually becomes incorrect, take the address of it at a point when it is still correct, then watch what it points to: (gdb) p interpreter-ctx.pmc_reg.registers[0]-cache.int_val $6 = 1 (gdb) p interpreter-ctx.pmc_reg.registers[0]-cache.int_val $7 = (INTVAL *) 0x810c904 (gdb) watch *$7 Hardware watchpoint 2: *$7 (gdb) continue . . . Except that the garbage collector tends to move stuff around, which can defeat this scheme. I doubt any of this was useful, but just in case...
Re: right-to-left pipelines
At 3:24 AM + 12/12/02, Simon Cozens wrote: [EMAIL PROTECTED] (Deborah Ariel Pickett) writes: Can we dictate that parentheses are optional in this case, and demand parentheses in all others? You see, the problem is that if we don't know what method we're going to call until way after we've parsed the code, (which I hope we've just proved above) we don't know how many parameters it's going to take. And if we don't know how many parameters it's going to take until we run it, we have next to zero chance of working out how many parameters it's going to take when we compile it. Which was the basis of my semi-serious notion of caching the whole set of possible parses. It's even more interesting when you add function calls into things, like: $foo = bar $x, $y, foo(); Since that may be either: $foo = bar($x, $y), foo() in which case it's in scalar context, or $foo = bar($x, $y, foo()) in which case it's in list context (sort of) The fun thing is that, potentially, you need to actually *call* foo() to figure out what context to call foo in. (Since, depending on what it returns, you may dispatch to different bar subs, which may or may not actually need what foo returns, thus changing its context) Except that this all sprung from my idea of having a block passed directly to a method without the other arguments being involved. (Which would work without parens, optional or otherwise. (because it works exactly this way in languages like Ruby (but most Perl 5 people can't get their heads around that (which is why this idea is facing a dead end. Ruby blocks that get passed to functions can only appear in a few well-known places, and always at the end of the parameter list. (Something's twigging my brain to make me think that the syntax for those blocks is distinct enough to tell at compile time what block type it is, but it's late and I may be mis-remembering) It still can't handle the infix block stuff that sort/map/grep want. Still, since all blocks are closures, it's not actually a problem for parrot, since this: foo $x, $y, {some_code()}; isn't a big deal--the only question is whether we pass in the PMC for that closure to foo, or call it and pass in the results. (Or, I suppose, figure out whether foo should do something bizarrely multimethod) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 9:43 PM -0700 12/11/02, Luke Palmer wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sent: 11 Dec 2002 23:16:30 GMT Date: Thu, 12 Dec 2002 10:16:26 +1100 From: Damian Conway [EMAIL PROTECTED] X-Accept-Language: en, en-us X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I rather like that. It's used for hashing by default (in absence of a stringification or .hash (?) method), yes? Not for string key hashes, no. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk