Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 07:39 PM 4/19/2001 +, [EMAIL PROTECTED] wrote:
>>Depends what they are. The scheme effectively makes the part "mandatory"
>>as we will have allocated space whether used or not.
>
>Well, we were talking about all PMCs having an int, float, and pointe
Filipe Brandenburger <[EMAIL PROTECTED]> writes:
>
>The big problem with || and && is that they don't evaluate their second
>argument until it's needed, that's what allows us to do something like
>`$xxx || die'.
That is still a run-time thing though - so no real barrier to overloading it.
>I
Larry Wall <[EMAIL PROTECTED]> writes:
>: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>: >Please tell me if there really is an use for overloading && and || that
>: >would not be better done with source filtering, then I will (maybe)
>: >reconsider my opinion.
>
>I think it's a cate
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 doin
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 pr
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 bin
Hmm.
Larry Wall wrote: [to [EMAIL PROTECTED]]
> This is much like a method:
>
> my Cat &chases (Dog $spot) : = { ... };
>
> 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 Dog me
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?
> After giving it a thought, it seems that it can _mostly_ be
> disambiguated from the concatenation operator. Whatever mostly means.
O
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'
At 05:32 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>Please tell me if there really is an use for overloading && and || that
>>would not be better done with source filtering, then I will (maybe)
>>reconsider my opinion.
>
>@foo = @bar &&
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
"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 d
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?
>
>
>
> > After giving it a thought, it seems that it
At 05:58 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:49 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>What would happen when $a = $b? Semantically, according to the tying and
>>overloadings, the bignumber on $b should be written to the file $a is
>>tied to, and when fetching the value of
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
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?
> > >
> >
> 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
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
Nick Ing-Simmons writes:
: >You really have to talk about overloading boolean context
: >in general.
:
: Only if you are going to execute the result in the normal perl realm.
: Consider using the perl parser to build a parse tree - e.g. one to
: read perl5 and write perl 6. This works for all ex
At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>I'd rather be flexible on the low-level and have `default' or `catch-all'
>>functions that call the cmp-style function than have to `trick' the
>>language by modifying the parser to do w
[This started out just as a response, but I've been wading through the
original post at the same time so it sort of drifts]
At 02:47 PM 4/23/2001 -0300, Filipe Brandenburger wrote:
>At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>>I'd
At 09:55 AM 4/23/2001 +0100, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 07:39 PM 4/19/2001 +, [EMAIL PROTECTED] wrote:
> >>Depends what they are. The scheme effectively makes the part "mandatory"
> >>as we will have allocated space whether used or not.
> >
> >Well,
At 07:11 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
>On Fri, Apr 20, 2001 at 05:02:21PM -0700, Larry Wall wrote:
> > Jarkko Hietaniemi writes:
> > : What is someone wants to define matrices and have both cross product
> > : and dot product?
> >
> > At some point, there aren't enough operators, a
As a general rule of thumb, if you sort your structs into decreasing
size, it usually comes out right. That is, put all your 64-bit items
first, then all your 32-bit items, then 16-bit, then 8-bit. Then there
are no "holes" except the one at the end, which most compilers are
pretty good at keepi
[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() operat
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
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
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
Simon Cozens writes:
: On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote:
: > :@foo = @( a + b ); # element by element add of @a and @b
: > I expect that's be written:
: >
: > @foo := @a + @b;
:
: Two different assignment operators? I can understand the intent, but this kind
:
On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote:
> :@foo = @( a + b ); # element by element add of @a and @b
> I expect that's be written:
>
> @foo := @a + @b;
Two different assignment operators? I can understand the intent, but this kind
of difficult-to-remember special-cas
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 C if it had come to that.
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
|
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 w
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 us
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 us
=?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 s
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
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 p
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 c
[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 co
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 poin
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
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 c
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 Pe
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 $ugl
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
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"
At 04:40 PM 23/04/2001 -0400, John Porter wrote:
>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.
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:
$ob
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 liv
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
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
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 =
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. (I
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
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 th
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 una
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
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
fas
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
> changin
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 overload
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
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 bounda
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 g
John Porter writes:
: 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 reg
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
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. (Po
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
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
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 t
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 parser
> 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
f
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 par
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
> At the moment I'm leaning toward ^ for concat, and ~ for xor. That
I think that would lead to confusion too. In many languages ^ is
xor and ~ is a bitwise invert. It is that way in perl now too, so
perl is already quite standard in t
Dan Sugalski wrote:
> It wouldn't be all that tough to change this if you were so inclined--it'd
> certainly be a simpler parser modification than some others that have been
> proposed.
Yes, I hadn't thought of that. Yay again.
> (The requirement to predeclare all variables would come into p
Larry Wall wrote:
> Okay, but it's just as many characters to say -> as it is \., y'know.
Yep. But I'll plead rule #1 for myself, and let it go.
(The other thought I had was that slashes might be nice, since
some filesystem hierarchies use it. But then the division op
gets squeeged.
Hm. Maybe
Graham Barr wrote:
> The other choice is not to have a concat operator but instead have
> C, but I guess not many people would like that either.
sub concat(@) { join '', @_ }
Seems to me like the sort of thing that ought to be in the core.
--
John Porter
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
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
90 matches
Mail list logo
