Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 10:13:28PM -0800, Vijay Singh wrote: Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? In Me's defence, at least they do occasionally produce some useful thoughts about Perl 6, and are not here simply for personal attacks on one particular contributor. The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* You know they say Publish and be damned! :) -- The primary difference between a teenage male and an adult man is that a man has learned to think of something else *while* he's thinking of sex. - Mark Atwood
Re: suggested properties of operator results
For the record, bwarnock pointed out to me that damian allready proposed
this behavior in RFC 25...
http://dev.perl.org/rfc/25.html
That RFC doesn't suggest having the comparison operators set properties
on their result -- instead it recomends that multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction.
... I think I like his way better. Mainly because I didn't consider the
ramifications of scenerios like this...
$input = 4;
$bool = $input 22;# $bool = 1 is valueR(22)
print ok! if $bool == 1; # whoops, '==' is looking at $bool.valueR
But as long as we're on the subject, dstorrs raises some good issues on
should we do it at all...
: someone (was it tchrist?) pointed out, beginners don't stay beginners for
: long, so writing a language for beginners may cost you people when they
: grow out of your language. I don't this we should do this just because
I agree with that sentiment, but I don't think it applies in this case.
We're not talking about a feature that will be usefull for beginers, and
a hinderence to experienced users who move on to to another language
because being able to write 1 $val 10 is making more work for them.
: 2) This feature would be very prone to abuse (makes it easier to
: obfuscate code), but that isn't a reason to disqualify something either.
I disagree, I think that this...
if (1 = $x = 10 and 1 = $y = 10) { # inside grid?
is much less obfuscated then this...
if (1 = $x and $x = 10 and 1 = $y and $y = 10) { # inside grid?
--
---
Oh, you're a tricky one.Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Re: Multi-dimensional arrays and relational db data
OK. My last addition to this painful thread. Your position depends on having a syntax so simple that it is somehow worth implementing as a native capability instead of the tied modules others have pointed out. No it does not. I am not suggesting that a rdb modelling tied version of MD arrays would be in core. Of course it would not. I am suggesting that a rdb modelling tied version of MD arrays might be nice. And that for it to be its nicest: A) the general mechanisms that these tied arrays would need to work adequately will need to be in place in core; and B) the syntax and behaviors chosen for the core MD array features shouldn't jar with what makes sense for the db modelling tied version of MD arrays. I'll wrap with a final thought. I think there's scope for a simple generalized relational model (Nd arrays, joins between arrays, and Nd discontiguous slice subsets across joined arrays) to be a powerful yet simple general purpose algebra for creating normalized tabular datastructures. This has nothing to do with dbs, even less to do with SQL, and everything to do with general purpose programming expressiveness. OK. No more from me on this topic, at least not in the perl world.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: For the record, bwarnock pointed out to me that damian allready proposed this behavior in RFC 25... http://dev.perl.org/rfc/25.html That RFC doesn't suggest having the comparison operators set properties on their result -- instead it recomends that multiple chained comparisons should be automagically expanded to the equivalent binary conjunction. ... I think I like his way better. Mainly because I didn't consider the ramifications of scenerios like this... $input = 4; $bool = $input 22;# $bool = 1 is valueR(22) print ok! if $bool == 1; # whoops, '==' is looking at $bool.valueR Well perhaps $input 22 should yield 22 is true Graham.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:31:36PM +0100, Graham Barr wrote: On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: $input = 4; $bool = $input 22;# $bool = 1 is valueR(22) print ok! if $bool == 1; # whoops, '==' is looking at $bool.valueR Well perhaps $input 22 should yield 22 is true Or perhaps you should have said my bit $bool; :) -- When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, comp.lang.c++
Re: Multi-dimensional arrays and relational db data
Sam Tregar wrote: Perl 6 will allow you to mutate your syntax at runtime any way you want. At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Daniel
Re: Multi-dimensional arrays and relational db data
Me wrote: I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it. Considering how something will be used is often a good idea. What syntax do you propose as being SQL-friendly? This is a sure way to find out if your syntax looks strange for other purposes as well. Daniel
Re: Multi-dimensional arrays and relational db data
At 10:26 PM 6/10/2001 +0100, Simon Cozens wrote: It doesn't matter, because the user can redefine the syntax anyway. I'm staying completely out of the argument that spawned this (Though the idea of welding SQL directly into perl has some appeal--it was one of the few (okay, the only one I can think of, but there must have been others) nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. Just because things are possible doesn't make them easy and, while they'll be easier in perl 6 that still doesn't mean they'll be easy. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. -- I think i'll take my girlfriend to vegas for a win'98 burn/upgrade -- Megahal (trained on asr), 1998-11-06
Re: Multi-dimensional arrays and relational db data
At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. Hah! Wimp. After it executes, retroactively. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote: nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. OK, I'll put it another way: domain-specific syntax modifications are something we want to encourage in all cases, not just in the case of databases. (There's that generalisation thing again.) On the other hand, I don't think it's worth getting bogged down in argument at this stage over how people can apply that concept - specific applications don't necessarily go in core, they're an external thing; (and certainly don't help us get the Perl 6 language itself designed) it's just as useless as discussing not only what modules should be in the Perl 6 equivalent of CPAN but what their interfaces should be. -- I don't think so, said Rene Descartes. Just then, he vanished.
Re: Multi-dimensional arrays and relational db data
Simon Cozens wrote: scream This is the kind of thing that can be dealt with perfectly satisfactorily with external modules; ergo, it does NOT need to be in the core. Ergo, it probably *does* *not* *need* *discussing* *here*. Much of the discussion on this list seems to concern what will be the syntax for expressing common semantics, such as array references or properties, to name a few recent ones. This thread seems to be another one such: what will be the default syntax for multidimensional arrays and how will that syntax hamper or encourage mapping it to SQL semantics. You're (that's to say, the person at self-reference.com who is not prepared to reveal their real name) exhibiting a common trait amongst perl6-language people, and that's to concentrate on a specific application *of* the language, and then from there making the bizarre leap of logic to believing that it needs to be *in* the language. I think his point was simply that you should keep this example in mind as you design the language. While one may build a general tool or product, people invariably fall on their face if they don't keep in mind the use or customer of the tool or product as they build it. This is hugely bogus and leads very quickly to second system effect, as the RFC process has shown us. Don't do it. Focus on the bigger picture instead. Good language design starts when you stop thinking I want this and this and this and start thinking how can we solve all these problems in one generalized way? Examples of successful people in the field of theoretical work point to the conclusion that the only way to achieve good abstractions is to 1 - start with lots of examples, work them out, and then 2 - try to find what they had in common and thereby generalize from them. Halmos' answer to how to learn mathematics: examples. Feynman's answer to how to do physics: examples. More than any other language I've ever seen, Perl seems to be designed by making sure that the most common 2 000 things someone has ever needed a computer to do real quick are expressible in the least amount of typing. While this leads to the funny car of programming languages, its a pretty useful funny car. Screaming at people however, is not terribly funny. But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here. Right? Somehow this comment seems to apply to all of us on this list, including you. How dare we to think for ourselves! Don't you need a license for that? /scream
Re: suggested properties of operator results
Dave Storrs wrote: 2) This feature would be very prone to abuse (makes it easier to obfuscate code), Whoa! Never thought I'd hear that! And computed function calls/adding things to the namespace at runtime/rearranging the inheritance tree at runtime aren't very prone to abuse !? :-) but that isn't a reason to disqualify something either. Clearly hasn't been so far anyway. Why stop now? :-) Chris's proposed feature seems much less prone to abuse than many others. I myself have wanted this feature, but never thought to ask for it. Thanks Chris. Not clear on how it should be actually implemented though. Daniel
Re: Multi-dimensional arrays and relational db data
Dan Sugalski wrote: At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. Hah! Wimp. After it executes, retroactively. I was trying to remain well-defined. I'm sure its possible if you can modifiy it *as* it executes, and certainly possible if you can modify it *after* it executes, to define semantics that have *no* value at all. For example, the going back in time and preventing your grandparents from having sex situation. Daniel
re: time travel paradoxes (was Re: Multi-dimensional arrays andrelational db data)
On Mon, 11 Jun 2001, Daniel S. Wilkerson wrote: For example, the going back in time and preventing your grandparents from having sex situation. Bah, who needs sex these days? A little in vitro here, a little cloning with genetic tweaking there...a whole new person, no sex involved! ... [freeze some eggs, then] Whenever you wish You thaw them out to romance wigglies In a Petrie Dish Then plant the little goober in a girl of seventeen Who's into natural living And prevention magazine No fuss, no muss, no stretch marks (Well not on *you*) Maternal instinct satisfied The modern thing to do. ... --Christine Lavin, Biological Time Bomb
Re: Multi-dimensional arrays and relational db data
At 04:43 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote: nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. OK, I'll put it another way: domain-specific syntax modifications are something we want to encourage in all cases, not just in the case of databases. That's a much better way. :) On the other hand, I don't think it's worth getting bogged down in argument at this stage over how people can apply that concept - specific applications don't necessarily go in core, they're an external thing; That's fine as far as it goes, but it is a good thing to examine likely candidate applications to find out what support might be handy to have available. (It'd kinda suck to have Unicode support without normalization built-in, for example...) On the other hand, I don't know that anything beyond: tie @foo, SQLish, select name, age from personnel; would be rational--DB work tends to be either simple or wildly odd, at least in my experience, which is why I've not gotten involved. (I don't think there's anything that really warrants Nifty Builtin Features, but I could be wrong) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Social Reform
Previously, on St. Elsewhere... Simon(e) writes... But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here... Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* Actually, Simon's not that bad. We don't always get along, and sometimes disgree less than quietly, but he generally makes sense. I HAVE NOT followed this thread, so I'm only talking in generalities. When trouble strikes, the type you're talking about, within a Perl forum, it has been my experience that it has the appearance of ignoring an issue and attacking a person regardless of what that person said. The more true the person's statements, the more aggressively people, specifically referring to Jan Dubois and Tom Christiansen in my own personal experience, attack the person with complete and utter nonsense, usually personal, usually untrue, apparently in order to avoid having to answer to anything or anyone. I have seen these attacks come in such a way as to specifically shut a person up by provoking him to wrath, then pointing out that he is impossible to have a discussion with... and quiet resumes with the issues still in place. This was a huge problem in the Perl 5 Porters, and it has recently begun coming into the Perl 6 groups. This is why I've been distancing myself from this group, including your previous call to arms. We will achieve social reform only by refusing to conduct ourselves in this manner, and without social reform, Perl 6 may as well not exist for all the good it does us as a community. Sure, it gives some overbrained geeks a chance to play around with language design for a while, but that's about it. And, frankly, I think Simon's been a bit nicer since his book came out. I'm just happy that it's red and doesn't have a trademarked animal on the front. ;-) Me may be s/wrong/clueless/... but I don't think any one of you has actually understood what he/she is talking about. Me is at least one level of abstraction higher than all of the rebuttals that have been fired back in this thread. HOWEVER, (again, not reading OR caring about this thread), my first reponse to me since his initial barrage a couple of months ago was that he had no good intention. He(?) has since changed his attitude somewhat, but that initial impression may be getting in the way for him. Right or wrong, Me or *you* for that matter...has the same right to post to this list...Otherwise, it should be a private list, perhaps: Unfortunately, if we keep going in the way we're going, this will eventually be a semi-private list the same what that P5P became one in order to keep from having to take responsibility for their own actions or lack thereof. This coin has two sides, Vijay. Larry Wall, Damian and the Acolytes of Doom debating Perl6 This particular acolyte (the writer of this email - I would say 'me' but that would make no sense in this context) just calls 'em as he sees 'em, nothing to hide, no book rights or contracts to protect, no financial reason to speak any way other than truth as best I know it. Just how much $foo can dance on the head of a dot operator Is that you really want? Why can't we (cough...) just get along? Think about it (for a change...). I read somewhere about the different stages of an online group. I believe it was referring to IRC channels or newsgroups, but this applies here as well. It describes that at first there is a lot of public interest because people discuss without being told to shut up. They address problems, and discuss things openly. In a later stage (there are several stages, but I forget what they all are), ego, conceit, and bad attitude creep in. You can see such attitudes on the P5P, EFNet #linux, and a few other places where people have gotten stuck in this trap. The final stage, which I believe that EFNet #perl has begun to achieve to some degree, and which we must strive to achieve, is an equilibrium. (Actually it forks three ways: a) equilibrium, b) dispersal to obliviion, or c) just plain stuck at the middle stage.) That middle stage is unfortunate, but it must come in order to advance beyond it, according to my reading. I'm not concerned about this or that butthead for the time being. I'm concerned that, should those of us who still have hopes for a new perl culture get discouraged and leave, buttheads will be all that's left, and we'll have something even worse than the P5P. Social reform takes time. I'm willing to wait it out as long as there is some evidence that it is occuring in at least some minor degree. However, attacking a person for making a valid point is never appropriate. I don't know that this has happened, but plenty of experience with this nonsense with Perl higher-ups leads me to believe that it's the most likely cause of your post. p
RE: Multi-dimensional arrays and relational db data
-Original Message- From: Simon Cozens [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 3:46 AM To: Vijay Singh Cc: Me; [EMAIL PROTECTED] Subject: Re: Multi-dimensional arrays and relational db data On Sun, Jun 10, 2001 at 10:13:28PM -0800, Vijay Singh wrote: Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? In Me's defence, at least they do occasionally produce some useful thoughts about Perl 6, and are not here simply for personal attacks on one particular contributor. The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* You know they say Publish and be damned! :) Hey, I like your book. I've never read it, but I did buy it. Mostly because it wasn't ORA. And if you think Simon's book is bad, you evidently haven't seen the ORA books coming out nowadays. I wonder if they are even proofread at all anymore. p
Re: suggested properties of operator results
Larry and I recently discussed chaining inequality operators.
He's in favour of it, but not of complex semantics involving
properties and implicit state (as I originally proposed in the
RFC)
I think we will see n-ary comparisons allowed in Perl 6:
if ($x $y $z $foo) {...
but as special case syntactic sugar for the expANDed version:
if ($x $y $y $z $z $foo) {...
Oh, and with only single evaluation of each operand.
Damian
Re: Coupla Questions
Simon asked: Are properties subscriptable? (Can the value of a property be a reference that can be dereferenced?) Property values can be any scalar value, including array, hash, and code refs. Can properties have properties? No, but their scalar values can. Damian
RE: suggested properties of operator results
From: Damian Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 11, 2001 4:06 PM
To: [EMAIL PROTECTED]
Subject: Re: suggested properties of operator results
I think we will see n-ary comparisons allowed in Perl 6:
if ($x $y $z $foo) {...
but as special case syntactic sugar for the expANDed version:
if ($x $y $y $z $z $foo) {...
Oh, and with only single evaluation of each operand.
Does it do short-circuit evaluation, too?
Dave.
Re: Coupla Questions
Graham asked:
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm not sure Larry's decided the exact mechanism yet.
This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like
sub a(Foo $self) :lvalue { $self-{a} }
(Did I get that syntax right ? probably not :)
Try this:
sub a(Foo $self) is rw { $self{a} } # or $self.{a}
Damian
Re: Coupla Questions
On Tue, Jun 12, 2001 at 09:08:04AM +1000, Damian Conway wrote:
Can properties have properties?
No, but their scalar values can.
What I was asking, in a roundabout way, was if
$foo.bar.baz
makes sense; your answer suggests that it does. In which case, we can
teach the parser that a property query is just like a method call is
just like a hash or array element (with optional dereference if you're
calling $foo.{bar} instead of %foo.{bar}.)
--
You're not Dave. Who are you?
RE: suggested properties of operator results
Dave Whipp asks: Does it do short-circuit evaluation, too? I would certainly expect it to, yes. Damian
Re: Coupla Questions
What I was asking, in a roundabout way, was if
$foo.bar.baz
makes sense; your answer suggests that it does. In which case, we can
teach the parser that a property query is just like a method call is
just like a hash or array element (with optional dereference if you're
calling $foo.{bar} instead of %foo.{bar}.)
Subscripts don't fit here at all. And, in my option, shouldn't be made too.
It's:
%foo{bar}
@foo[$bar]
not:
%foo.{bar}
@foo.[$bar]
The dereferencing dot is an error there.
I believe it's vitally important not to mix everything together syntactically
(or semantically!)
Damian
Re: Coupla Questions
On Tue, Jun 12, 2001 at 09:20:20AM +1000, Damian Conway wrote: Subscripts don't fit here at all. And, in my option, shouldn't be made too. Oh good, I was hoping you would say that; I misunderstood your message from the 7th of June further up this thread to mean that dot was optional in subscripting. If dot's just a method, property or dereference operator that makes it a whole host easier to deal with. -- I've looked at the listing, and it's right! -- Joel Halpern
Re: Social Reform
If you have not been following this thread, then maybe that is the reason for the confused-sounding nature of your email. I would say Simon was the one ignoring an issue and attacking a person, not Vijay. I think Vijay was the one pointing out that this person (Me) was contributing to the discussion and that a personal attack from Simon was inappropriate (If I may paraphrase you Vijay. Correct me if I'm wrong.) Me, it would help if you would use a name, even if its not your real one. Daniel David Grove wrote: Previously, on St. Elsewhere... Simon(e) writes... But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here... Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* Actually, Simon's not that bad. We don't always get along, and sometimes disgree less than quietly, but he generally makes sense. I HAVE NOT followed this thread, so I'm only talking in generalities. When trouble strikes, the type you're talking about, within a Perl forum, it has been my experience that it has the appearance of ignoring an issue and attacking a person regardless of what that person said. The more true the person's statements, the more aggressively people, specifically referring to Jan Dubois and Tom Christiansen in my own personal experience, attack the person with complete and utter nonsense, usually personal, usually untrue, apparently in order to avoid having to answer to anything or anyone. I have seen these attacks come in such a way as to specifically shut a person up by provoking him to wrath, then pointing out that he is impossible to have a discussion with... and quiet resumes with the issues still in place. This was a huge problem in the Perl 5 Porters, and it has recently begun coming into the Perl 6 groups. This is why I've been distancing myself from this group, including your previous call to arms. We will achieve social reform only by refusing to conduct ourselves in this manner, and without social reform, Perl 6 may as well not exist for all the good it does us as a community. Sure, it gives some overbrained geeks a chance to play around with language design for a while, but that's about it. And, frankly, I think Simon's been a bit nicer since his book came out. I'm just happy that it's red and doesn't have a trademarked animal on the front. ;-) Me may be s/wrong/clueless/... but I don't think any one of you has actually understood what he/she is talking about. Me is at least one level of abstraction higher than all of the rebuttals that have been fired back in this thread. HOWEVER, (again, not reading OR caring about this thread), my first reponse to me since his initial barrage a couple of months ago was that he had no good intention. He(?) has since changed his attitude somewhat, but that initial impression may be getting in the way for him. Right or wrong, Me or *you* for that matter...has the same right to post to this list...Otherwise, it should be a private list, perhaps: Unfortunately, if we keep going in the way we're going, this will eventually be a semi-private list the same what that P5P became one in order to keep from having to take responsibility for their own actions or lack thereof. This coin has two sides, Vijay. Larry Wall, Damian and the Acolytes of Doom debating Perl6 This particular acolyte (the writer of this email - I would say 'me' but that would make no sense in this context) just calls 'em as he sees 'em, nothing to hide, no book rights or contracts to protect, no financial reason to speak any way other than truth as best I know it. Just how much $foo can dance on the head of a dot operator Is that you really want? Why can't we (cough...) just get along? Think about it (for a change...). I read somewhere about the different stages of an online group. I believe it was referring to IRC channels or newsgroups, but this applies here as well. It describes that at first there is a lot of public interest because people discuss without being told to shut up. They address problems, and discuss things openly. In a later stage (there are several stages, but I forget what they all are), ego, conceit, and bad attitude creep in. You can see such attitudes on the P5P, EFNet #linux, and a few other places where people have gotten stuck in this trap. The final stage, which I believe that EFNet #perl has begun to achieve to some degree, and which we must strive to achieve, is an equilibrium. (Actually it forks three ways: a) equilibrium, b) dispersal to obliviion, or c) just plain stuck at the middle stage.) That middle stage is unfortunate, but it must come in order to advance beyond it, according to my reading. I'm not concerned about this or that butthead for the time
Embrace polymorphic builtins, for they are cool.
Coming to Perl 5 from a C++ background, I was greatly
disappointed, while writing a persistent object base
class and consulting my new, flat-lying Blue Camel (Second
edition, this was 1996), that the following kind of thing
did not do what I wanted:
sub argle($){
print One argle: $_[0]\n;
}
sub argle($$){
print Two argles: $_[0],$_[1]\n;
}
sub argle($$$@){
print join(',',
Many argles: $_[0],
@_[1..($#_-1)],
$_[$#_]\n
);
}
It turned out, on inspection, that the prototyping mechanism
was for syntactic ease -- leave out the occasional sigil -- and
occasional error checking -- rather than for multiple dispatch, as
it is in C++. If you want multiple dispatch, you need to either
write a prototype that will accept all possible valid arguments, then
select from them after the named function has been called, or
somehow wrap your data modeling around some sort of interface object
which can have the appropriate package methods associated with it,
which really doesn't gain you much:
{
#LoggingObjects automatically subclass based on argument number:
my $LoggingObject = new LoggingObject qw/argle bargle whoosh/;
$LoggingObject-Print();# Correct one/two/many distinction!
}
Therefore, last year, when the perl 6 community suggestion period was
announced, I made sure to write a RFC describing a type-based
multiple dispatch mechanism.
But I'm digressing. What I want to talk about is overloaded builtins.
I recently suggested that Cclose be overloaded to make its argument,
when its argument is not a filehandle, become read-only. An objection
was made to this, on the grounds that homonymous operators are confusing,
with eval block and eval string being given as an example of something
that is confusing.
This post is intended to be a response to that objection.
Natural language contains many homonyms. This is rarely, outside of
dramatic plots, a problem, as there are other indicators, up to and
including requests for clarification, but generally context, to
guide us human beings as we apply our common sense to the great
questions of What Is Fair and What Is Right without taking wrong turns
or digressing into discussions of propagandistic trends in modern
journalism while dividing chocolate cake evenly among party guests.
Okay?
Ceval (string/block) is but one. Crequire (file name / version number)
is
another. Cdo might be considered another. There is discussion of
overloading
Clength(@) to do what beginners expect.
Those are the only ones we have right now. I am sure that the people
reading
this are about evenly divided between thinking Basta, no mas! and
agreeing
with what I am about to say.
Just as Websters has multiple entries for some words, with completely
different meanings, it is all right for a programming language to have
different meanings. Commonly used function names vary between different
programs, for instance.
I believe that multiple dispatch based on argument type is an important
feature of a general purpose programming language. With this in mind,
what better way to introduce the concept to the beginning programmer than
to have built-ins that do multiple dispatch based on argument type?
close (IO) # closes an open stream, returns
# true on success or false on failure,
# sets $! on failure
close (\$) # overwrites the ASSIGN method of the
# referenced object or container with
# a placeholder that inherits from
# Cwarn; returns a CODEREF that will
# cause, on run, the referent's ASSIGN
# method to be returned to the current
# method, or undef on failure. Sets
# $! on failure, to, for instance,
# $_[0]-NAME already read-only
Multiple dispatch based on argument type, gentlemen. C++ has it, and
C++ programmers miss it when writing in other languages. Few other
languages
dare to include argument types into the symbolic identifiers for their
code entry points.
In the land of More Than One Way, it is surprising that this important
way -- the mechanism behind, for example, the double-angle-bracket C++
streams library output syntax -- early-binding multiple dispatch based
on known argument type -- is missing.
--
David Nicol 816.235.1187
Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
Vijay Singh wrote: Just how much $foo can dance on the head of a dot operator The current Annals Of Improbable Research (http://www.improb.com) has a piece on applying modern physics to the age-old question, you know, about the boogieing angels. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
[EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
Re: Coupla Questions
Damian Conway wrote:
Graham asked:
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm not sure Larry's decided the exact mechanism yet.
Hopefully, we'll get a with operator and everything:
with %database.$accountnumber {
.interestearned += $interestrate * .balance
}
anything short of that, in my opinion, is merely trading old ugly for
new ugly.
Re: Embrace polymorphic builtins, for they are cool.
So, you want method overloading, I take it? It is a very nice feature and I've used it often in another language. Well, you basically can't have it unless you have type checking of the arguments. And the more strong the type checking, the less dangerous and the more effective the method overloading, since the method signatures get more specific. Others on this list say that strong typing cramps their style and restricts their free-form-dom while writing code. I posit that restrictions can lead to *more* freedom, not less, since there is more you can rely on. Consider the beauty of a fast and complex Irish ceili dance and how one clumsy beginner can easily break someone else's ankle, and you see that the very strict rules of that dance are necessary for the freedom to dance it without getting hurt. No rules lead to high school kids lean against one another and grope in the dark, which is only euphemistically called dance. Programming is not so dissimilar. I think you have brought up another example where the lack of strong enforcement of rules reduces freedom by preventing a nice feature. Daniel David L. Nicol wrote: Coming to Perl 5 from a C++ background, I was greatly disappointed, Multiple dispatch based on argument type, gentlemen. C++ has it, and C++ programmers miss it when writing in other languages. Few other languages dare to include argument types into the symbolic identifiers for their code entry points. In the land of More Than One Way, it is surprising that this important way -- the mechanism behind, for example, the double-angle-bracket C++ streams library output syntax -- early-binding multiple dispatch based on known argument type -- is missing. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
I think you could only delay function calls automatically like this if you could ensure that they are truely functional. That is, their output must depend only on the arugments given and must have no mutation side-effects. It seems to me that this is hard to guarantee in Perl, even for the compiler. David L. Nicol wrote: [EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
