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
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
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
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
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
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
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
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
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
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.
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
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
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 !?
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
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
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
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
-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
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
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
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
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
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
Dave Whipp asks:
Does it do short-circuit evaluation, too?
I would certainly expect it to, yes.
Damian
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
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
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
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
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.
--
[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
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}
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
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
33 matches
Mail list logo
