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 C 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 C 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 C is as fundamental to Perl 6 as C or C, 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 I 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 C 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 C is as fundamental to Perl 6 > as C or C, 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
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 t
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: 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
how to code a lazy pipeline?
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? -- ralph
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. 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? *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: 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 "grep"s and "map"s 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 C of C 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 C 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 I 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: Stringification of references (Decision, Please?)
On 12/11/02 2:04 PM, Michael Lazzaro wrote: > On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote: >> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"? >> Are we married to the "AS_*" thing? > > Not really -- whatever works. We also had .debug, .identity, and .id > proposed, for example. I like the CAPS since it provides some semblance of naming isolation, but I'm not sure what the convention is in Perl 6. All lowercase with no prefix is out of the question, I think. I already have many, many Perl 5 objects with "id" and "debug" methods, for example. -John
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
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 C (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?))
There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal C method is *for*. Damian
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 C 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 C 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. -- 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 C 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 C 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.
On Wednesday, December 11, 2002, at 03:27 PM, Michael G Schwern wrote: 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. I agree 98% with your argument (especially re: grammar extensions), and it was very well explained. The 02% is this: First, universal operators and universal methods both pollute the useful (programmer) namespace to nearly the same extent. It's just one pollution is alphanumeric, the other is punctuational. For example, '.eq' and '==' are (abstractly) just multimethods upon their invocant/arguments, tho one has a funny-charactered name. Either way, you're defining something that everyone has to remember, and that people can't use for their own purposes. Second, one person's trivial feature is another person's dream come true. C, for example, or vectorops. So the object-based argument can be used to support or crush pretty much *anything*, depending solely on POV. Or put any feature in or out of the "builtin" list, for that matter. It's only our opinions, we can't really justify them except through our own experiences. So I don't think we have an alternative to just plain arguing over each such proposal as it arrives, which we *hope* will produce the overall correct results as a sheer accident of demographics. MikeL (I don't *really* think '===' is critically important, though as an obviously symmetric binary operation it has some minor charm. I tend to use the concept somewhat frequently, but others don't, so it probably doesn't pass the bar.)
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: 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
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes: 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 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. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
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 C 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: REs as generators
> "Rich" == Rich Morin <[EMAIL PROTECTED]> writes:
Rich> On occasion, I have found it useful to cobble up a "little language"
Rich> that allows me to generate a list of items, using a wild-card or some
Rich> other syntax, as:
Rich>foo[0-9][0-9] yields foo00, foo01, ...
Rich> I'm wondering whether Perl should have a similar capability, using REs.
Well, here's a cheap way:
my @list = glob ('foo{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}');
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: superposed parsers (was: right-to-left pipelines)
> "Simon" == Simon Cozens <[EMAIL PROTECTED]> writes: Simon> [EMAIL PROTECTED] (Damian Conway) writes: Damian> But in Perl 6, the consistency between a method's parameter Damian> list and its argument list *is* checked at run-time, so Damian> passing the wrong number of arguments is (quite literally) Damian> fatal. Simon> But wait! If we can check how many parameters to pass, we know Simon> how many parameters to pass; problem solved. Sure, the parser Simon> has to stay in a superposition of states until the check is Simon> made, but we're close to requiring quantum supercomputers to Simon> run this thing anyway. Simon> I'm afraid I can't tell whether or not I'm being serious any Simon> more. I don't know if this has been discussed before, but there are completely serious parsing algorithms that work this way, "forking" into conceptually separate parsers that parse the input in parallel before either vanishing or collapsing back together. The best known of these is the Generalized LR algorithm (GLR), in which the individual parsers can be like the well-known yacc/bison LALR(1) parsers, except they split whenever there's a conflict in the parse table. When the input has relatively few ambiguities, GLR parsers can be competitive with LALR(1) ones in performance, and if they're implemented right, their worst-case performance can also be tractable. (Cubic in the input length, which is essentially tight for general context free grammars. This holds even when there are exponentially many possible parses, though obviously you only get an implicit representation of them). GLR parsing was originally designed for natural language parsing, but there's been research in the last few years on using it for programming languages[*], and support for it was recently added to Bison. The snag I can see with using GLR parsing for Perl 6 is that it's based on a model where you preprocess the grammar once at compile time into a big fixed table, while Perl 6 would like to have a grammar that can easily be changed on the fly. [*] Disclaimer: some of which I was involved in. A useful link: http://www.cs.berkeley.edu/~smcpeak/elkhound/ -- Stephen
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 C 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 C 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
Cs, 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 C (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: 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 C 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
