Hmm.
Larry Wall wrote: [to [EMAIL PROTECTED]]
This is much like a method:
my Cat chases (Dog $spot) :lvalue method = { ... };
In either case, Cat is the type of the return value, and really has
little to do with the implementation of the function (or hash) itself.
$spot.chases is a
On Mon, Apr 23, 2001 at 01:49:36PM +0200, Dav?? Helgason wrote:
This wouldn't mean that anyone is thinking of getting us object
dot-syntax, now would it?
whistle
After giving it a thought, it seems that it can _mostly_ be
disambiguated from the concatenation operator. Whatever mostly
On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote:
$a = $b ~ $c; # Mmm!
Oops. I really can't claim the credit for that one; I seem to have been
subconsciously influenced by one of Larry's previous musings.
--
Pretty, smart, sane:Pick two.
- Ron Echeverri
On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote:
Or we change the concatenation operator.
$a = $b $c; # Do people really use Perl for bit fiddling?
Yes, all the time.
$a = $b # $c; /* Urgh */
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ 0)!;
...
}
(Or even have ! be a valid statement terminator, so (@_0)! would work.)
Or you could have it doing
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr [EMAIL PROTECTED] wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~ is higher
than named unary operators. (It's print($a~$b), not print $a
On Mon, Apr 23, 2001 at 02:31:55PM +0200, H.Merijn Brand wrote:
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr [EMAIL PROTECTED] wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~ is
On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens [EMAIL PROTECTED] wrote:
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ 0)!;
...
}
(Or even have ! be
H.Merijn Brand wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~ is higher
than named unary operators. (It's print($a~$b), not print $a (~b).)
I am not sure I do like the use of ~
On Mon, 23 Apr 2001 13:02:50 +0100, Simon Cozens [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2001 at 01:49:36PM +0200, Dav?? Helgason wrote:
This wouldn't mean that anyone is thinking of getting us object
dot-syntax, now would it?
whistle
After giving it a thought, it seems that it can
On Mon, 23 Apr 2001 14:57:50 +0200, Davíð Helgason [EMAIL PROTECTED] wrote:
H.Merijn Brand wrote:
On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens [EMAIL PROTECTED] wrote:
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting
Or we change the concatenation operator.
$a = $b $c; # Do people really use Perl for bit fiddling?
Oy! You keep your greedy fingers off my bitvectors.
(Incidentally I hope that in Perl 6 there's a way to shift the bitvector
aspect of $s: currently $s and $s to shift the numeric aspect
Simon Cozens wrote:
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
If it wasn't the factorial operator, our math caucus would
be rather unhappy...
--
John Porter
Simon Cozens wrote:
Or we change the concatenation operator.
Perl: Snobol with embedded gravel.
$a = $b $c;
--
John Porter
On Mon, Apr 23, 2001 at 10:48:53AM -0400, John Porter wrote:
Perl: Snobol with embedded gravel.
$a = $b $c;
*snort*
Actually, I'd rather like that to be equivalent to
$a = $c-$b;
--
Complete the following sentence: People *ought* to weigh bricks, cats
and cinnamon in the same units
On Mon, Apr 23, 2001 at 10:47:26AM -0400, John Porter wrote:
If it wasn't the factorial operator, our math caucus would
be rather unhappy...
Good, good. :)
$$y = \pi + 4 x $$, Just another Perl and \TeX\ hacker;
--
Momomoto, Famous Japanese, can swallow his nose.
Simon Cozens wrote:
John Porter wrote:
$a = $b $c;
Actually, I'd rather like that to be equivalent to
$a = $c-$b;
Oops, sorry, I forgot the smiley.
Oh, but thinking seriously about it:
do we really want to keep the indirect object syntax?
It is said to be a major source of
At 11:02 AM 4/23/2001 -0400, John Porter wrote:
Simon Cozens wrote:
John Porter wrote:
$a = $b $c;
Actually, I'd rather like that to be equivalent to
$a = $c-$b;
Oops, sorry, I forgot the smiley.
Oh, but thinking seriously about it:
do we really want to keep the indirect object
At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
H.Merijn Brand wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~ is higher
than named unary operators. (It's print($a~$b), not
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
What's wrong with something like:
$foo = $a :+ $b;
Well, at least it's colon rule compliant.
--
You want to read that stuff, fine. You want to create a network for such
things, fine. You want to explore the theoretical
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
H.Merijn Brand wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~
=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with - as a
Lightning flashed, thunder crashed and Graham Barr [EMAIL PROTECTED] whispered:
| What's wrong with something like:
|
| $foo = $a :+ $b;
|
| I was thinking along those lines too.
Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
and % characters?
@foo = @a
Larry Wall wrote:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with - as a synonym, just for
Stephen P. Potter writes:
: Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
: and % characters?
:
: @foo = @a @+ @b; # element by element add
Because it's difficult to tell the operators from the terms visually.
Larry
Lightning flashed, thunder crashed and Larry Wall [EMAIL PROTECTED] whispered:
| I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will
| be stringify, and unary ^ will be bit complement, on the theory that
| bit complement is like xoring with 0x. And unary + will be a
|
Okay, then:
@foo = @( @a + @b );# @(), $(), and %() set context.
Easier to identify the operators, and little or no question about the
context...
--- Larry Wall [EMAIL PROTECTED] wrote:
Stephen P. Potter writes:
: Maybe this is a crazy (or stupid) idea, but why couldn't we use
Okay, then:
@foo = @( @a + @b );# @(), $(), and %() set context.
Easier to identify the operators, and little or no question about the
context...
--- Larry Wall [EMAIL PROTECTED] wrote:
Stephen P. Potter writes:
: Maybe this is a crazy (or stupid) idea, but why couldn't we use
Nathan Wiger writes:
: Larry Wall wrote:
:
: : I _really_ think dot-syntax would make perl prettier as well as make it
: : more acceptable to the world of javacsharpbasic droids. Which is some
: : kind of goal, no?
:
: Consider it a given that we'll be using . for dereferencing.
Why not
@foo = @( a + b ); # element by element add of @a and @b
or even
@( foo = a + b ); # element by element add of @a and @b assigned to
@foo.
I guess one could claim the idea is similar to the old BASIC MAT prefix,
although it was clearly reached by a different path. This could
[EMAIL PROTECTED] writes:
: Okay, then:
:
: @foo = @( @a + @b );# @(), $(), and %() set context.
:
: Easier to identify the operators, and little or no question about the
: context...
Well, sure, though it was already in list context from the assignment...
I do expect that @() and
On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
I do expect that @() and $() will be used for interpolating list and
scalar expressions into strings, and it is probably the case the $()
would be a synonym for scalar(). @() would then be a synonym for
the mythical list() operator.
At 10:10 AM 4/23/2001 -0700, Larry Wall wrote:
=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using
Glenn Linderman writes:
: Why not
:
:@foo = @( a + b ); # element by element add of @a and @b
I expect that's be written:
@foo := @a + @b;
where the := says to treat the left side as a prototype, and a bare
array in a prototype is going to put scalar context on the right side,
and a
Graham Barr writes:
: On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
: I do expect that @() and $() will be used for interpolating list and
: scalar expressions into strings, and it is probably the case the $()
: would be a synonym for scalar(). @() would then be a synonym for
:
On Mon, Apr 23, 2001 at 09:05:22PM +0200, Bart Lateur wrote:
Or, in analogy to cmp, gt etc:
$a = $b plus $c;
or
$a = $b cat $c;
while left_angle_right_angle:
if dollar_underscore[0] =eq= #:
continue_next;
}
print dollar_underscore;
}
Bart Lateur writes:
: Or, in analogy to cmp, gt etc:
:
: $a = $b plus $c;
: or
: $a = $b cat $c;
It would probably have been Ccc if it had come to that.
Larry
Larry Wall wrote:
I do expect that @() and $() will be used for interpolating list and
scalar expressions into strings, and it is probably the case the $()
would be a synonym for scalar(). @() would then be a synonym for
the mythical list() operator. Which probably, in Perl 6, turns out
to
On 4/23/01 3:25 PM, Larry Wall wrote:
: From a trainer's point of view, having two operators which look very
similar, : are used for the same thing in various different languages, and do
*almost* : the same thing but not quite, is completely *asking* for confusion.
So teach 'em :=, and
I'm starting to be a bit worried with what I'm reading...
1) Use $obj.method instead of $obj-method :
The big question is: why fix what is not broken? Why introduce Javaisms and
VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5
code (and Perl 5 programmers) for a zero
Larry Wall wrote:
The . is just syntax. Do you mean something semantic by .-based?
No, but I think just syntax is a little misleading. I do agree that we
well, Perl 5 did it this way is not a sufficient design decision at
this point. However, if you changed Perl's syntax too radically you
John Porter writes:
: Larry Wall wrote:
: I do expect that @() and $() will be used for interpolating list and
: scalar expressions into strings, and it is probably the case the $()
: would be a synonym for scalar(). @() would then be a synonym for
: the mythical list() operator. Which
On 4/23/01 3:59 PM, Nathan Wiger wrote:
Then how do you concatenate a number?
Here's something I was thinking about at lunch:
$concated_number = $number + $other_number;
$numerical_add = $number + $other_number;
Why not require in the case when you want to forcible concat a number
[EMAIL PROTECTED] writes:
: On 4/23/01 3:25 PM, Larry Wall wrote:
: : From a trainer's point of view, having two operators which look very
: similar, : are used for the same thing in various different languages, and do
: *almost* : the same thing but not quite, is completely *asking* for
At 12:59 PM 23/04/2001 -0700, Nathan Wiger wrote:
Larry Wall wrote:
The . is just syntax. Do you mean something semantic by .-based?
No, but I think just syntax is a little misleading. I do agree that we
well, Perl 5 did it this way is not a sufficient design decision at
this point. However,
Branden writes:
: I'm starting to be a bit worried with what I'm reading...
:
: 1) Use $obj.method instead of $obj-method :
:
: The big question is: why fix what is not broken? Why introduce Javaisms and
: VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5
: code (and
At 04:14 PM 23/04/2001 -0400, John Siracusa wrote:
On 4/23/01 3:59 PM, Nathan Wiger wrote:
Then how do you concatenate a number?
Using + for concat: no!
My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)
People who use one-liners know the value of
On Mon, Apr 23, 2001 at 01:16:57PM -0700, Larry Wall wrote:
Branden writes:
: I'm starting to be a bit worried with what I'm reading...
:
: 1) Use $obj.method instead of $obj-method :
:
: The big question is: why fix what is not broken? Why introduce Javaisms and
: VBisms to our pretty
On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
Using + for concat: no!
My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
$this$is$just$as$ugly$but$it$works
Which
On 4/23/01 4:16 PM, Larry Wall wrote:
What is it about . that seems to inspire allergic reactions in people?
Surely it's not the . itself, but the requirement that you fit everything
into that one syntactic mold. Perl's not going to do that.
I don't mind it, but I always imagined:
Nathan Wiger wrote:
if you changed Perl's syntax too radically you
would almost certainly lose programmers.
I disagree. Changing the semantics of Perl to make it more
powerful is something every perl programmer would be happy
about. Consequent changes to the syntax is something we
would live
Larry Wall wrote:
Except we're not having highlander variables. $foo and @foo remain
distinct entities.
I know. Sad.
(Of course, what I meant by highlander was no prefix chars.
Highlanderishness is just a consequence of that.)
--
John Porter
Larry Wall wrote:
Surely it's not the . itself, but the requirement that you fit everything
into that one syntactic mold. Perl's not going to do that.
I'm not opposed to the change, but I want to make one point:
certain characters (like dot) are special in regexes, so
when you want to search
John Porter wrote:
One of the reasons I program in Perl as my
primary language is *because of* the syntax.
With all due respect, I don't believe that's why you,
or anyone else, likes to program in Perl.
I *really* don't want this to turn into a religious argument, which it's
fast
Branden wrote:
Changing the semantics of Perl to make it more
powerful is something every perl programmer would be happy
about. Consequent changes to the syntax is something we
would live with.
I don't see the semantic change to make it more powerful that is behind
changing - to .
Nathan Wiger wrote:
I *really* don't want this to turn into a religious argument,
Neither do I.
coming from a sh/C background.
I understand. I think I was able to learn Perl as quickly
as I did because of certain syntactic similarities.
But it's not why I program in Perl now, and it's
Larry Wall writes:
wanted, you still get the length. If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated unary
On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote:
Larry Wall writes:
wanted, you still get the length. If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.
How often are you
At 04:46 PM 4/23/2001 -0400, John Porter wrote:
Larry Wall wrote:
Except we're not having highlander variables. $foo and @foo remain
distinct entities.
I know. Sad.
(Of course, what I meant by highlander was no prefix chars.
Highlanderishness is just a consequence of that.)
It wouldn't
I have lurked for several months now, and find that I can hold my tongue
no longer. The 'discussion' of overloading '+', to include concatenation,
suffers from a general degeneration into implementation details, where
linguistic sentiment should reign.
The contention that '+' should be
John Siracusa [EMAIL PROTECTED] writes:
On 4/23/01 4:16 PM, Larry Wall wrote:
What is it about . that seems to inspire allergic reactions in people?
Surely it's not the . itself, but the requirement that you fit everything
into that one syntactic mold. Perl's not going to do that.
I
Dan Sugalski wrote:
I'm not a parser guy by any means (unfortunately) but we have
the distinct possibility of completely replacing all of the
parser rules after token X appears, whatever that token might
be. (Heck, we may have the possibility of replacing the entire
parser) There's no
David L. Nicol writes:
: Dan Sugalski wrote:
: I'm not a parser guy by any means (unfortunately) but we have
: the distinct possibility of completely replacing all of the
: parser rules after token X appears, whatever that token might
: be. (Heck, we may have the possibility of replacing the
Bart Lateur writes:
: On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
:
: Using + for concat: no!
:
: My vote is to use . and require space before and after.
: $this.$is.$ugly.$anyway ;)
:
: My vote is to ditch the concat operator altogether. Hey, we have
: interpolation!
:
:
I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)
I am thinking that maybe it should be a 2 character operator with at least
one of then being + as + is common in many other languages for doing
concatenation.
How
Larry Wall wrote:
David L. Nicol writes:
:
: [this parser switch thing]
: sounds a lot like an exec system call: there are some things
: which remain in effect (open file handles, current directory,
: environment) but there are many others which do not. Maybe
: switching parsers is best
What I see as needed is a designated meta-token that will be
reserved, in some form or another, as the switch-parser command.
.
.
.
What about a hash-bang? Maybe putting a hash-bang in the middle
of the text (outside of quoted literals, of course) could indicate
that the referenced program is
Brent Dax wrote:
Yes, that is exactly what I had in mind, thanks for
the validation. Only the comment syntax would have to
come back to a designated module, with another hashbang.
#!comment
yadda yadda yadda
blah blah blah
foo bar baz
#!VB6
Why would it?
Someone posited a nested stack of parsers, this thread is discussing the
abandonment of one parser when going to the next. Really, the claim
that it should be up to the invoked parser to determine where to go next
allows the invoked parser to have syntax to return to the prior
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote:
Or we change the concatenation operator.
I am thinking that maybe it should be a 2 character operator with at
least one of then being + as + is common in many other languages
for doing concatenation.
Or, in analogy to cmp, gt etc:
At 07:44 PM 04-23-2001 +0100, Graham Barr wrote:
Hm, I would expect @() in a scalar context to give the
same result as
@tmp = @(...); $x = @tmp;
That is, yeild the number of elements in the list.
I can see this. But unless there is a good reason, that seems like a
less-than-optimal
71 matches
Mail list logo
