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: 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
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: 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: 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: 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
[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.
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. Cgiven, 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 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: 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:
Richfoo[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] URL: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 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
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: 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
