Re: Strings vs Numbers (Re: Tying & Overloading)

[Russ Allbery]

Bart Lateur <[EMAIL PROTECTED]> writes:

> My vote is to ditch the concat operator altogether. Hey, we have
> interpolation!

>   "$this$is$just$as$ugly$but$it$works"

How do you concatenate together a list of variables that's longer than one
line without using super-long lines?  Going to the shell syntax of:

PATH=/some/long:/bunch/of:/stuff
PATH="${PATH}:/more/stuff"

would really be a shame.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: s/./~/g

[Russ Allbery]

Branden <[EMAIL PROTECTED]> writes:

> 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 net gain?

$obj.method isn't a Java-ism; it's used by both C++ and by Simula (for
class variables), and in C for struct members, which given the origins of
those languages means I wouldn't be surprised if it were in Algol.

The switch from -> to . makes perfect sense from a C perspective if we're
turning objects into first-class entities rather than pointers; think
about a struct versus a pointer to a struct.

-> makes you remember that things are pointers.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Thinking about scalars

[Michael G Schwern]

This may or may not be related to Dave's post, but I just remembered
why I don't like a dual-natured +.  I'm sorry if this was gone through
before.

Consider the following...

sub foo { $_[0] + $_[1] }

What do the following return?

foo(1,1);   obviously 2
foo("this", "that") obvious "thisthat"

Those are simple enough.

foo("1", 1);is that "11" or 2?
foo(undef, 1);  1 or "1"?

Those can be solved by definining precidence, but its still a bit
arbitrary.

foo($foo, $bar);who knows?

You can't know without examining the surrounding code.  I might be the
only one this bothers, dunno.

$foo = 42;  print 42;
$bar = 23;  print 23;  foo($foo, $bar); "4223" or 65?

$foo and $bar are initially set to numbers, but then they're converted
to strings by the print operation.  So does + treat them as strings or
numbers?

$foo = read_num_from_file;$bar = read_num_from_file;
foo($foo, $bar);concatinates as read_num_from_file() probably
returns strings unless its author is very
careful

sub concat { $_[0] + $_[1] };
$foo = read_word_from_file; $bar = read_word_from_file;
concat($foo, $bar); the user obviously intends for this to
concatinate, not add.

Here's probably the cannonical confusing case.  read_num_from_file()
returns a number read in from some file.  That's probably going to be
pulled in as a string (that happens to look like a number).  What
would + do with that?  If you follow the rule "Perl will add two
strings if they both look like numbers" then concat() might do
confusing things.

Solve the final example and you can use + as both addition and
concatination.  If you can't, dont.


The reason why this works in languages like Java and C++ is because
they're typed languages.  There's little ambiguity about whether
something is a string or a number, you can tell just by its type.
This leads to all sorts of annoyances, but what it does let them do is
use the same operator for addition and concatination.



On Mon, Apr 23, 2001 at 03:41:49PM -0700, Dave wrote:
> The contention that '+' should be overloaded is based in machine
> details, expressed in other languages through 'types'.  In this
> model of the world, a 'string' is fundamentally different from a
> 'number', and as such each defines a specific context in which the
> operator exists: (string) + (string) or (number) + (number), or some
> horrid abberation thereof, which aught not to be.

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
AY!  The ground beef, she is burning my groin!
http://sluggy.com/d/990105.html

Re: Tying & Overloading

[Damien Neil]

On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type.  The fact
> that it's become the industry standard for method call syntax is also
> a point in its favor.
> 
> Incidentally, Perl 6 will not require . everywhere that Perl 5 requires
> ->.  The deref will be assumed before (), [], and {} (where an operator
> is expected).  We're only talking about method calls here, really.

Something in my gut feels wrong about needing to relearn all my operators
to use Perl 6.  When I write Perl, . MEANS concatination to me.  It's
spread through all my code.  I know that Perl 6 is going to evolve...but
this is attacking something fundamental to the way I perceive the language.

Change what ., ~, and ^ mean in Perl 6, and I'll need to keep two
operator maps in my head whenever I look at Perl code.  "OK, this is
some old Perl 5, so ~$foo is a bitwise negat...oh, wait, it's really
new Perl 6, and this is a concatination..."

I'm a neophile, and I'd balk at switching to a Perl 6 that did that.
I know my coworkers would revolt; they're already dubious about Perl's
level of complexity.

I'd really rather just make method calls with ->.

If you're dead-set on reassigning ., please consider leaving it at
that, rather than juggling all the other operators around.  Make
concatination be "$a cat $b".  ("eq" and friends already provide
precedent for string operators being words rather than symbols.)

   - Damien

Re: Strings vs Numbers (Re: Tying & Overloading)

[Bart Lateur]

On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:

>How do you concatenate together a list of variables that's longer than one
>line without using super-long lines?  Going to the shell syntax of:
>
>PATH=/some/long:/bunch/of:/stuff
>PATH="${PATH}:/more/stuff"
>
>would really be a shame.

A backslash at the end of a line?

Kidding!

-- 
Bart.

Re: Tying & Overloading

[Bart Lateur]

On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote:

>While that's true, concatenation is quite a common operation 
>that I'd be really
>uncomfortable with it necessitating 4 keystrokes (" cat") instead of one.

Er, "~" is an extremely annoying character to type at many keyboards. It
may depend on your keyboard localization. On my Belgian keyboard, I have
to press Alt-Gr (the second Alt) and keep it down, then the "~" button,
release Alt-Gr, then a space. I don't find this handy, because it's far
too easy to mess up. Just the word "cat" (or "cc") is a lot less work,
simply because it requires no special keypresses.

-- 
Bart.

RE: Tying & Overloading

[Henrik Tougaard]

> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > Make concatination be "$a cat $b".  ("eq" and friends 
> already provide
> > precedent for string operators being words rather than symbols.)
> 
> While that's true, concatenation is quite a common operation 
> (Introspection
> is cool. Run "perl -MO=Terse someprogram | grep concat".) 
> that I'd be really
> uncomfortable with it necessitating 4 keystrokes (" cat") 
> instead of one.

On my keyboard '~' is 3 keystrokes - and rather complicated ones
at that:
  hold down ALTGR (rigth alt) and press the ^/¨/~ key
  release them both
  press spacebar
This is a danish keyboard - many other non-US keyboards have
similar (but different) encodings.

Please don't use the keypresscount as an argument.

Henrik Tougaard - FOA, Copenhagen, Denmark.

Re: Tying & Overloading

[Simon Cozens]

On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> On my keyboard '~' is 3 keystrokes - and rather complicated ones
> at that:

Then maybe ~ isn't best.

> Please don't use the keypresscount as an argument.

Why not? We're making easy things easy, remember.

-- 
Rule 3: If the character is comprised of a container without another radical, 
then Rule 3 will not apply.

RE: Tying & Overloading

[Henrik Tougaard]

> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > Please don't use the keypresscount as an argument.
> 
> Why not? We're making easy things easy, remember.
> 
Because your keyboard layout isnt mine! I have nice letters like
'æ', 'ø' and 'å' readily accessible - I don't think you do.

But oth if we have to choose between 'cat' and
'aninsanelylongandcomplicatedoperatorthatconcatenates'
the former gets my vote.

Henrik

Re: Tying & Overloading

[Dan Sugalski]

At 02:55 AM 4/24/2001 -0400, John Porter wrote:
>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 one downside is that you'd have essentially your own private language. 
Whether this is a bad thing or not is a separate issue, of course.

OTOH, it might not be inappropriate for there to be several variants of 
perl available with differing syntax. PL/I seemed to manage OK with 
something like this. (While PL/I is mostly dead, its death wasn't as a 
result of the varying subsets out there...)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: s/./~/g

[David M. Lloyd]

On 24 Apr 2001, Russ Allbery wrote:

> Branden <[EMAIL PROTECTED]> writes:
> 
> > 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 net gain?
> 
> The switch from -> to . makes perfect sense from a C perspective if we're
> turning objects into first-class entities rather than pointers; think
> about a struct versus a pointer to a struct.
> 
> -> makes you remember that things are pointers.

What's wrong with using both?  You could use -> if you're working with a
reference to an object, and you could use . if you're working with the
object itself.

- D

<[EMAIL PROTECTED]>

Re: Tying & Overloading

[John Porter]

Dan Sugalski wrote:
> The one downside is that you'd have essentially your own private language. 
> Whether this is a bad thing or not is a separate issue, of course.

IIUC, this ability is precisely what Larry was saying Perl6 would have.

-- 
John Porter

Re: s/./~/g

[Russ Allbery]

David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:

>> The switch from -> to . makes perfect sense from a C perspective if we're
>> turning objects into first-class entities rather than pointers; think
>> about a struct versus a pointer to a struct.
>> 
>> -> makes you remember that things are pointers.

> What's wrong with using both?  You could use -> if you're working with a
> reference to an object, and you could use . if you're working with the
> object itself.

It seems relatively unlikely in the course of normal Perl that you're
going to end up with very many references to objects.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Tying & Overloading

[Simon Cozens]

On Tue, Apr 24, 2001 at 03:26:04PM +0200, Henrik Tougaard wrote:
> > From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > > Please don't use the keypresscount as an argument.
> > Why not? We're making easy things easy, remember.
> Because your keyboard layout isnt mine!

Let's put it a different way - if we can find a short operator which
is readily accessible on most people's keyboards, then that would
score over a longer operator which is readily accessible on most 
people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
#, or whatever.

-- 
"Having just ordered 40 books and discovered I have no change out of a grand, 
I'm thinking of getting a posse together and going after some publishers. I'd 
walk into a petrol station and buy lots of petrol on Monday, too, but I think 
I'd get funny looks. More funny looks." - Mark Dickerson

Re: s/./~/g

[David M. Lloyd]

On 24 Apr 2001, Russ Allbery wrote:

> David M Lloyd <[EMAIL PROTECTED]> writes:
> 
> > What's wrong with using both?  You could use -> if you're working with a
> > reference to an object, and you could use . if you're working with the
> > object itself.
> 
> It seems relatively unlikely in the course of normal Perl that you're
> going to end up with very many references to objects.

Well, right now in Perl, an object *is* a reference.  In Perl 6, will that
always be the case?  When talking about something like this:

@myarray.method;

Maybe you want to pass around a reference to @myarray because it contains
a billion elements, or is tied to a file, or something; in that case
(borrowing from p5) you'd have something C-ish like this:

@{$myarrayref}.method;

But doing this:

$myarrayref->method;

is a bit clearer.  I don't know; I guess we don't know for sure how any of
this will fall out, but it makes some sense to me to do it this way.

Maybe I'll be quiet now. :-)

- D

<[EMAIL PROTECTED]>

Re: s/./~/g

[Dan Sugalski]

At 06:34 AM 4/24/2001 -0700, Russ Allbery wrote:
>David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
>
> >> The switch from -> to . makes perfect sense from a C perspective if we're
> >> turning objects into first-class entities rather than pointers; think
> >> about a struct versus a pointer to a struct.
> >>
> >> -> makes you remember that things are pointers.
>
> > What's wrong with using both?  You could use -> if you're working with a
> > reference to an object, and you could use . if you're working with the
> > object itself.
>
>It seems relatively unlikely in the course of normal Perl that you're
>going to end up with very many references to objects.

And even if you do, I can guarantee that within 10 minutes of starting code 
that does, you'll be cursing at perl. "Why can't you just DWIM?" you will 
curse. "You should be able to figure out that reference is to an object!"

If you don't, I certainly will. ;)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tying & Overloading

[Dan Sugalski]

At 09:33 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > The one downside is that you'd have essentially your own private language.
> > Whether this is a bad thing or not is a separate issue, of course.
>
>IIUC, this ability is precisely what Larry was saying Perl6 would have.

I am passing no judgement on the goodness or badness of the proposal, 
merely observing that you will be working with a variant of perl, and that 
may have some issues. It's not my call as to whether you should or not. (It 
may be, however, that a language variant would cause more cognitive 
dissonance in many people than a completely different language. IOW, 
switching to python in mid-source may cause folks fluent in perl less 
trouble than switching to prefixless highlander perl)

Having done this myself (Dec BASIC allowed this for the longest time) I 
find that it isn't a big deal if it's a known thing. I am not most people, 
though.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: s/./~/g

[Russ Allbery]

David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:

>> It seems relatively unlikely in the course of normal Perl that you're
>> going to end up with very many references to objects.

> Well, right now in Perl, an object *is* a reference.

Precisely.  So there's almost never any reason to create a reference to an
object, which would be a reference to a reference, and for those rare
circumstances the existing dereference syntax is probably adequate.

> Maybe you want to pass around a reference to @myarray because it
> contains a billion elements, or is tied to a file, or something;

I would presume that objects will still be implemented as references under
the hood so that passing them around is efficient no matter what they
contain.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Tying & Overloading

[Bart Lateur]

On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote:

>Let's put it a different way - if we can find a short operator which
>is readily accessible on most people's keyboards, then that would
>score over a longer operator which is readily accessible on most 
>people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
>#, or whatever.

'~' is not good because it's very hard to reach. But "^" is a deadkey
too, so this one also needs pressing a space.

If you want something that's easy to type and that won't conflict with
current Perl, try "!".

Too bad "_" is a word character.

-- 
Bart.

Re: s/./~/g

[Simon Cozens]

On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> Well, right now in Perl, an object *is* a reference.

No. An object is a referent. Two blessed references can refer to the
same data; however, that's only one object.

-- 
teco < /dev/audio
- Ignatios Souvatzis

Re: Larry's Apocalypse 1 \}

[Dan Sugalski]

At 08:01 PM 4/23/2001 -0500, David L. Nicol wrote:
>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 an absolute kind of thing rather than
> > : a stacked kind of thing, with the later parser responsible for
> > : switching back.
> >
> > The truth is somewhere in the middle.  It is incumbent on the
> > outer rule to inform the inner rule how it thinks the inner rule
> > ought to terminate, and it is the choice of the inner rule whether
> > to follow the convention suggested by the outer rule.  A rule that
> > starts at a left parenthesis will suggest stopping on a right
> > parenthesis, but if the inner rule is parsing troff, all bets are
> > off on properly nesting parens.
> >
> > Larry
>
>Right.  The existence of these "all bets are off" cases is what
>makes, IMO, a non-stacked system look better.  If the conversation
>starts in Russian, switches to Chechen, then Turkish, then English,
>the conversants might want to switch back to Russian without having
>to say a single word of Turkish or Chechen on the way back.  Or they
>might not switch back at all!

Well, it actually argues for a way to both nest parsers and switch parsers.

Most of the parser switching is going to be of the nesting variety. Every 
time the parser processes a double-quoted string constant or a regular 
expression you're going to be jumping parsers. That's all temporary, and we 
really do want them to nest. (You really don't want the perl parser to lose 
all its state every time you start a string...)

In some cases you might not, for example if you switch to Python or Forth 
mid-source. Those arguably might still nest, as there'd be end-of-parsing 
cleanup you'd want to do, and probably wouldn't want to do it before the 
very end, at which point the parser would just close down all the nested 
parsers.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: s/./~/g

[David M. Lloyd]

On Tue, 24 Apr 2001, Simon Cozens wrote:

> On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> > Well, right now in Perl, an object *is* a reference.
> 
> No. An object is a referent. Two blessed references can refer to the
> same data; however, that's only one object.

Oops, that's what I meant. :-)

- D

<[EMAIL PROTECTED]>

Re: Strings vs Numbers (Re: Tying & Overloading)

[Jonathan Scott Duff]

On Tue, Apr 24, 2001 at 12:29:23AM -0700, Russ Allbery wrote:
> How do you concatenate together a list of variables that's longer than one
> line without using super-long lines?

join '', $var1, $var2, $var3, ..., $varN;

TMTOWTDI, remember.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Tying & Overloading

[John Porter]

Simon Cozens wrote:
> Let's put it a different way - if we can find a short operator which
> is readily accessible on most people's keyboards, then that would
> score over a longer operator which is readily accessible on most 
> people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
> #, or whatever.

Or maybe a word operator, in the same family as cmp, eq, ne, le, gt...

Perl's stigma for unreadability is bad enough already;
now at least we have a good opportunity to unwreak some badness.

-- 
John Porter

Re: Strings vs Numbers (Re: Tying & Overloading)

[Jonathan Scott Duff]

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
> will help with ^= not resembling =~, though ~= would still mean The
> Wrong Thing...

As has been mentioned by others, ^ has established meaning in other
programming languages (and current perl) as XOR.  It'd be a shame to
break that to get dotted object method/attribute access.

Why do we *need* a concatenation operator at all?  We already have
several methods to accomplish the same thing:

join '', $var1, $var2;
"$var1$var2"

Or are we really trying to optimize it so that we don't have to write

map { "$_$foo" } @arr;  # or the equivalent for loop

but instead

@arr . $foo;

but wait ... everything is an object in perl6, so that could be

@arr.concat($foo);  # or something

Is concatenation really so important that we keep it around and not
only that, but break other things to keep it around?

(Obviously I think using . for objects is important enough to break
concatenation)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: s/./~/g

[Garrett Goebel]

From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl 
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right now in Perl, an object *is* a reference.
> 
> Precisely.  So there's almost never any reason to create a 
> reference to an object, which would be a reference to a
> reference, and for those rare circumstances the existing
> dereference syntax is probably adequate.

How many classes uses a flyweight scalar reference to work around circular
references in garbage collection? Class::Contract does. Also, if it is
common enough to be covered in the Perl Cookbook (13.13)... it probably
isn't too uncommon.

Class::Contract provides a generic constructor which returns a reference to
a reference. 

my $key = \ my $undef;
my $obj = \ $key;
bless $obj, $class;

This is to avoid circular references while providing better encapsulation.
$obj is a flyweight reference to $key. Object attribute accessors lookup
object data in the Class::Contract lexical %data. There is no way to get at
an object's data except through the interface defined in the "contract".
When the $obj goes out of scope, the Class::Contract provided destructor
deletes $data{$key}.

Now all that that means, is that it isn't uncommon that an object might be a
reference to a reference. It is up to the user to decide to make a reference
to that object. But I'd venture to guess that that isn't an all too uncommon
thing.


> I would presume that objects will still be implemented as 
> references under the hood so that passing them around is
> efficient no matter what they contain.

I guess that falls back into Branden's thread of tying variables vs.
overloading values. Which to me is overloading accessors vs. methods. When
someone overloads @foo to be an instance of Foo, is that tying per Perl 5:
magic variables which redirect variable accessors to a class... or something
new? I certainly hope magic in perl 6 is reincarnated as something much more
accessible at runtime to users.

Re: Strings vs Numbers (Re: Tying & Overloading)

[John L. Allen]

On Tue, 24 Apr 2001, Graham Barr wrote:

> 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 that area. Changing these just
> to get . for -> so that we are more "standard" seems very strange
> as you are loosing two standards to gain one.
> 
> To be honest though I don't think it is possible to get a single
> char concat operator with loosing something else, which is a shame.
> It would be good if we could somehow overload + to be both string
> and numeric, but I not sure that is possible.

I think someone may have mentioned this already, but why not just say
that if you want '.' to mean concatenation, you have to surround it on 
either side with white space?  If there's no white space around it, then 
it is forced to mean method invokation, or whatever else.  Sure, some 
japhs will break, but that's just too bad :-)  Perl already 
has other cases where white space matters, why not one more.  That way, 
perhaps we can all get what we want, namely that '.' means both 
concatenation _and_ method invokation.

John.

Re: Strings vs Numbers (Re: Tying & Overloading)

[Michael G Schwern]

On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> I think someone may have mentioned this already, but why not just say
> that if you want '.' to mean concatenation, you have to surround it on 
> either side with white space?  If there's no white space around it, then 
> it is forced to mean method invokation, or whatever else.

This approaches "whitespace as syntax".  Very few Perl operators care
about whitespace between their words (even ->) or whitespace at all.

More generally, its going to cause alot of careful squinting at code
to distinguish between different operators.  This will lead to subtle
bugs because someone accidentally put a space after the . and didn't
notice.

Its just cutting it too thin.  Don't go this route unless others are
exhausted first.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
BOFH excuse #100:

IRQ dropout

Re: Strings vs Numbers (Re: Tying & Overloading)

[Casey West]

On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
: 
: On Tue, 24 Apr 2001, Graham Barr wrote:
: 
: > 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 that area. Changing these just
: > to get . for -> so that we are more "standard" seems very strange
: > as you are loosing two standards to gain one.
: > 
: > To be honest though I don't think it is possible to get a single
: > char concat operator with loosing something else, which is a shame.
: > It would be good if we could somehow overload + to be both string
: > and numeric, but I not sure that is possible.
: 
: I think someone may have mentioned this already, but why not just say
: that if you want '.' to mean concatenation, you have to surround it on 
: either side with white space?  If there's no white space around it, then 
: it is forced to mean method invokation, or whatever else.  Sure, some 
: japhs will break, but that's just too bad :-)  Perl already 
: has other cases where white space matters, why not one more.  That way, 
: perhaps we can all get what we want, namely that '.' means both 
: concatenation _and_ method invokation.

No thanks.  We already have the ability to put white space around '->'
which is helpfull a la Soap::Lite.

Besides, I can't think of instances where white space matters without
being except:

print <<__EOT__

__EOT__

which is easily avoidable via 'print <<" __EOT__"'.

-- 
Casey West

Sane "+" string concat proposal

[Nathan Wiger]

THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're
probably already rolling your eyes. However, I searched p5p all the way
back to 1997 and could not find this proposal anywhere. Even though it
looks similar to the standard "Java + concat overload" stuff, it is not,
so please try to keep an open mind.

Everyone agrees that keeping string and numeric ops semantically
separate is a Good Thing. As Dave nicely explained, this allows us to
twist our scalars into strings or numbers based on the operators,
instead of the other way around. This allows a single scalar type. This
is not something we want to lose.

Under this proposal, string concatenation would be acheived by the
*combination* of "" and +. So, in Perl 5 you would have something like
this:

   $string3 = $string1 . $string2;

In Perl 6, you would do this like so:

   $string3 = "$string1" + "$string2";

Here's the key: The quotes are REQUIRED. 100%. Always. If you left them
off, you'd get numeric addition. Always. There is no magic type 
inference.

Think of this like using $ and [] to get an array element. You can't
just say 'array[1]' or '$array' and expect to get the right thing.
Rather, you have to combine the two. Same here, you have to combine ""
and +.

The win here with Perl is that having $prefixes actually allows us to
expand variables in "" still. No other HLL can do that. As such, other
languages have to overload their operators based on type. In Perl, we
can maintain the semantics of a separate string concat by requiring
quotes. This is hardly a far cry from current; in fact, it's quite
logical (since "" is already string context) and very close
syntactically to other HLL's.

So, here's a little table:

   Perl 5  Perl 6
   --- ---
   ->  .
   +   +
   .   "" and +

You get a Java/Python/etc syntax while retaining the semantics of
separate string and numeric ops.

More Details

Ok, if you're still reading, cool. Let's get down to the nitty-gritty.
Here are some more examples of code:

   Perl 5Perl 6
   - 
   $res = $var + $var2;  $res = $var + $var2;
   $name = "This" . "that";  $name = "This" + "that";
   $name = "This" . $that;   $name = "This" + "$that";
   print "Next is " . $i + 1;print "Next is " + $i + 1;
   $me = $name . getpwuid($<);   $me = "$name" + getpwuid($<);   

That last one is important. Notice that the "" on the $name means that
the next + becomes a string concat. The getpwuid call is then concat'ed
onto that. If, instead, you wrote:

   $me = $name + getpwuid($<);

You would get numeric addition. Always. In this way, you maintain a
reliable semantic separation of string concat and numeric addition,
while gaining a syntax that is similar to other HLL's. Having "$var"
expand $var is the reason this is possible.

Anyways, what do you think? (Please try to resist knee-jerk Java
reactions :).

-Nate

P.S. I've got many more examples, but didn't want to flood the list with
a massive proposal. I'm pretty sure all the bases are covered, but am
interested in potential gotcha's...

P.P.S. I'm also not some Java newbie who's complaining about "." and
"eq", so don't even go there.

Re: Sane "+" string concat proposal

[Mark Koopman]

>Perl 5Perl 6
>- 
>print "Next is " . $i + 1;print "Next is " + $i + 1;


this is the root of the problemPerl 5 version is easy to 
understand,  Perl 6 version is still ambiguous

Re: Sane "+" string concat proposal

[Michael G Schwern]

Seems servicable.  Doesn't exactly make me jump up and down, though.

A few nits...


On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
> More Details
> 
> Ok, if you're still reading, cool. Let's get down to the nitty-gritty.
> Here are some more examples of code:
> 
>Perl 5Perl 6
>- 
>print "Next is " . $i + 1;print "Next is " + $i + 1;

Two problems.  First, the Perl 5 example is equivalent to:

print +("Next is " . $i) + 1;

and I don't think that's what you ment.  I think you ment...

print "Next is " . ($i + 1);

Which brings up a problem.  '"$foo" + $number' is numeric addition.  So
shouldn't '"Next is " + ($i + 1)' be numeric as well since one of the
sides is unquoted?  Probably not what you wanted.

This problem will happen with any complex expression which you can't
easily put quotes around.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
If you are only one year old, and this is the first time you have ever seen a
burger, your related neurons will gather into a new "hamburger" group. But I
bet you are not that young and already know what a burger is.
 --Alex Chiu, Immortality Guy

Re: Sane "+" string concat proposal

[Dan Brian]

> If, instead, you wrote:
> 
>$me = $name + getpwuid($<);
> 
> You would get numeric addition. Always. In this way, you maintain a
> reliable semantic separation of string concat and numeric addition,
> while gaining a syntax that is similar to other HLL's. Having "$var"
> expand $var is the reason this is possible.

So, what would this do?

$user_pass = (getpwuid($<))[0] + (getpwuid($<))[1];

Your operator is still ambiguous, since you probably want a concat, but
have no place for the quotes. The convention needs to consider more than
just variables.
 

Re: Sane "+" string concat proposal

[Michael G Schwern]

On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote:
> >Perl 5Perl 6
> >- 
> >print "Next is " . $i + 1;print "Next is " + $i + 1;
> 
> 
> this is the root of the problemPerl 5 version is easy to 
> understand,  Perl 6 version is still ambiguous

The Perl 5 version is also ambiguous as you didn't catch the
precidence problem I noted eariler.  ;)

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
...and that, children, is how to clean and load a .38 revolver.  Questions?

Re: Sane "+" string concat proposal

[Casey West]

On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote:
: >Perl 5Perl 6
: >- 
: >print "Next is " . $i + 1;print "Next is " + $i + 1;
: 
: 
: this is the root of the problemPerl 5 version is easy to 
: understand,  Perl 6 version is still ambiguous

It is important to explain that if either side of the '+' operator is
in string context, it is interpreted as concat.

These would all have string context:

Perl5   Perl6
--- ---
print "Next is " . $i + 1;  print "Next is " + $i + 1;
print 1 . $two; print 1 . "$two";
print 1 + 2 . $three;   print 1 + 2 + "$three";

I think that another area of confusion might be the precidence model,
which was not detailed.  For example:

[cwest@stupid cwest]$ perl -le'$i=2;print "Next is " . $i + 2'
2
[cwest@stupid cwest]$ perl -le'$i=2;print "Next is " . ( $i + 2 )'
Next is 4


I would prescribe it to be the following, just like Perl5 is now:

Perl5   Perl6
--- ---
print "Next is " . ($i + 1);print "Next is " + ($i + 1);
print 1 . $two; print 1 . "$two";
print (1 + 2) . $three; print (1 + 2) + "$three";

Numeric context wins.

I am not opposed to this idea, I see it to be quite easy to
understand, even without explicit parens, though they help.

-- 
Casey West

Re: Sane "+" string concat proposal

[Jonathan Scott Duff]

On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
>Perl 5Perl 6
>- 
>$res = $var + $var2;  $res = $var + $var2;
>$name = "This" . "that";  $name = "This" + "that";
>$name = "This" . $that;   $name = "This" + "$that";
>print "Next is " . $i + 1;print "Next is " + $i + 1;
>$me = $name . getpwuid($<);   $me = "$name" + getpwuid($<);   
> 
> That last one is important. Notice that the "" on the $name means that
> the next + becomes a string concat. 

Your fourth example disturbs me.  You change the precedence of the
same operator based on context.  That's just weird.  Do we do that
anywhere else?

Oh, and you need to relax your "Always" a bit.

"string" + $foo # string concat
$foo + "string" # string concat

Quotes around $foo shouldn't be necessary.

As an aside, I wish we could do something like this with our comparators
too.  (Isn't that one of Damian's RFCs?)  Although I get the feeling
that this will cause more headaches.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Sane "+" string concat proposal

[Stephen P. Potter]

Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| Under this proposal, string concatenation would be acheived by the
| *combination* of "" and +. So, in Perl 5 you would have something like
| this:
| 
|$string3 = $string1 . $string2;
| 
| In Perl 6, you would do this like so:
| 
|$string3 = "$string1" + "$string2";

Once you go this route, you've pretty much destroyed the usefulness of
having a concat operator.  It is far less typing to do

   $string3 = "$string1$string2";

I've seen someone say something about concating a large list of scalars.
Can you imagine:

$longstring = "$short" + "$another" + "$andathird" + "$andafourth" +
"$onemore" + "$okanother" +"$wowlots" 

Personally, my fingers got really tired of having to use the shift key for
all the quotes, the $, and the +.  Of course, I'd normally just write that
as

$longstring = join('', $short, $another, ... , $wowlots);

-spp

Re: Sane "+" string concat proposal

[John Porter]

Nathan Wiger wrote:
> string concatenation would be acheived by the
> *combination* of "" and +. 
>$string3 = "$string1" + "$string2";
> Here's the key: The quotes are REQUIRED. If you left them
> off, you'd get numeric addition. There is no magic type 
> inference.

That, imho, is bending way too far in the wrong direction,
just for the sake of having a "+" operator that seems to DWIM
on both strings and numbers.  By that logic, we should dispense
with cmp, eq, lt, etc. and replace them with
"$a" <=> "$b"
"$a" == "$b"
"$a" < "$b"
etc.  There really is no inherent benefit in having "+" mean
concat in addition to, uh, addition, and it seems to be causing
an undue amount of consternation.  Certainly "+" is no more
intuitive than "##" or "cc" or "cat".

I also don't like the special status accorded the the left operand
in your proposal.  Seems unecessarily capricious and restricting.


-- 
John Porter

It's a sky-blue sky
The satellites are out tonight
let x = x

Re: Sane "+" string concat proposal

[Casey West]

On Tue, Apr 24, 2001 at 03:09:18PM -0400, Stephen P. Potter wrote:
: Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
: ed:
: | Under this proposal, string concatenation would be acheived by the
: | *combination* of "" and +. So, in Perl 5 you would have something like
: | this:
: | 
: |$string3 = $string1 . $string2;
: | 
: | In Perl 6, you would do this like so:
: | 
: |$string3 = "$string1" + "$string2";
: 
: Once you go this route, you've pretty much destroyed the usefulness of
: having a concat operator.  It is far less typing to do
: 
:$string3 = "$string1$string2";

I would consider thinking about the bigger problem of:

$string = foo() [something here] bar();

Of course, if we choose to remove the concat operator all together
we're left:

$string = join '', foo(), bar();

I could live with that if I had to, but only if I had to.

: I've seen someone say something about concating a large list of scalars.
: Can you imagine:
: 
: $longstring = "$short" + "$another" + "$andathird" + "$andafourth" +
:   "$onemore" + "$okanother" +"$wowlots" 
: 
: Personally, my fingers got really tired of having to use the shift key for
: all the quotes, the $, and the +.  Of course, I'd normally just write that
: as
: 
: $longstring = join('', $short, $another, ... , $wowlots);

I would do that for this example anyhow.

-- 
Casey West

Re: Sane "+" string concat proposal

[Austin Hastings]

Some of the objections have gone by, but what if you reverse the
quotes?
Make operator-in-quotes be a string operator (hell, make that true for
the other ops, too)

Perl 5  Perl 6
--- ---
->  .
+   +
.   "+"
eq  "=" or eq
gt  ">" or gt

Special rule: the operator is "", not " in a literal context". (Of course, someone
with more mojo than me may be able to convince folks that any qquoted
 is sufficient, but ...)


>Perl 5Perl 6
>- 
>$res = $var + $var2;  $res = $var + $var2;
>$name = "This" . "that";  $name = "This" + "that";
>$name = "This" . $that;   $name = "This" + "$that";
>print "Next is " . $i + 1;print "Next is " + $i + 1;
>$me = $name . getpwuid($<);   $me = "$name" + getpwuid($<);   

Perl 5Perl 6
- 
$res = $var + $var2;  $res = $var + $var2;
$name = "This" . "that";  $name = "This" "+" "that";
$name = "This" . $that;   $name = "This" "+" "$that";
print "Next is " . $i + 1;print "Next is " "+" $i + 1;
$me = $name . getpwuid($<);   $me = $name "+" getpwuid($<);   

It has the advantage of separating the need to distinguish the operator
out to the operator, so the "func1() . func2()" arguments are
eliminated, and it's just as hideous as anything else. Plus, it's
intuitive and easy to type, even for those poor benighted folks who
don't have $LOCALE or xmodmap or MSFT Multiple language support.
(And admit it, "All string operators must be surrounded by string
quotes" is newby-friendly, even if it does make my skin crawl...)

Frankly, I like the "cc" operator idea better. 

(Although maybe as a unary operator, "cc" could still be defined as
returning a sub generated by feeding its arguments to the
system-provided 'C' compiler...)

$hi_sub = cc <
int foo(void)
{
  printf("Hello, world.\n");
}

END_CODE





ORIGINAL MESSAGE
--- Nathan Wiger <[EMAIL PROTECTED]> wrote:
> THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're
> probably already rolling your eyes. However, I searched p5p all the
> way
> back to 1997 and could not find this proposal anywhere. Even though
> it
> looks similar to the standard "Java + concat overload" stuff, it is
> not,
> so please try to keep an open mind.
> 
> Everyone agrees that keeping string and numeric ops semantically
> separate is a Good Thing. As Dave nicely explained, this allows us to
> twist our scalars into strings or numbers based on the operators,
> instead of the other way around. This allows a single scalar type.
> This
> is not something we want to lose.
> 
> Under this proposal, string concatenation would be acheived by the
> *combination* of "" and +. So, in Perl 5 you would have something
> like
> this:
> 
>$string3 = $string1 . $string2;
> 
> In Perl 6, you would do this like so:
> 
>$string3 = "$string1" + "$string2";
> 
> Here's the key: The quotes are REQUIRED. 100%. Always. If you left
> them
> off, you'd get numeric addition. Always. There is no magic type 
> inference.
> 
> Think of this like using $ and [] to get an array element. You can't
> just say 'array[1]' or '$array' and expect to get the right thing.
> Rather, you have to combine the two. Same here, you have to combine
> ""
> and +.
> 
> The win here with Perl is that having $prefixes actually allows us to
> expand variables in "" still. No other HLL can do that. As such,
> other
> languages have to overload their operators based on type. In Perl, we
> can maintain the semantics of a separate string concat by requiring
> quotes. This is hardly a far cry from current; in fact, it's quite
> logical (since "" is already string context) and very close
> syntactically to other HLL's.
> 
> So, here's a little table:
> 
>Perl 5  Perl 6
>--- ---
>->  .
>+   +
>.   "" and +
> 
> You get a Java/Python/etc syntax while retaining the semantics of
> separate string and numeric ops.
> 
> More Details
> 
> Ok, if you're still reading, cool. Let's get down to the
> nitty-gritty.
> Here are some more examples of code:
> 
>Perl 5Perl 6
>- 
>$res = $var + $var2;  $res = $var + $var2;
>$name = "This" . "that";  $name = "This" + "that";
>$name = "This" . $that;   $name = "This" + "$that";
>print "Next is " . $i + 1;print "Next is " + $i + 1;
>$me = $name . getpwuid($<);   $me = "$name" + getpwuid($<);   
> 
> That last one is important. Notice that the "" on the $name means
> that
> the next + becomes a string concat. The getpwuid call is then
> concat'ed
> onto that. If, instead, you wrote:
> 
>$me = $name + getpwuid($<);
> 
> You would get numeric 

Re: Strings vs Numbers (Re: Tying & Overloading)

[Edward Peschko]

On Tue, Apr 24, 2001 at 05:44:49PM +0100, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on 
> > either side with white space?  If there's no white space around it, then 
> > it is forced to mean method invokation, or whatever else.
> 
> This approaches "whitespace as syntax".  Very few Perl operators care
> about whitespace between their words (even ->) or whitespace at all.
> 
> More generally, its going to cause alot of careful squinting at code
> to distinguish between different operators.  This will lead to subtle
> bugs because someone accidentally put a space after the . and didn't
> notice.
> 
> Its just cutting it too thin.  Don't go this route unless others are
> exhausted first.

ok, well.. I've heard arguments for '+' (namely that its intuitive, other 
language compatible, etc...) so what are the arguments against it?

after all, it has a corresponding operator in minus:

"hey" - "y" = "he"
my $singluar = $plural - "s"; 

The only thing I could see gumming up the works is if one argument is a string,
and the other argument is a number, and both are in variables:


my $a = "hello";
my $b = 3;


print $a + $b;  # should print "hello3";

print $b + $a   # prints 3hello; 

This would be doable ( along with making "$a > $b" context dependent ). 
Question is, would it be too confusing, too prone to error?  I like it better 
than '~' (which seems odd to me..)

As for '.', well I think that makes sense if packages are 'first class', and 
they can contain variables, ie:

class MyClass
{
my  $a = 1;   # instance variable
our $b = 2;   # static variable
my @c = (1,2);
}

my $b = new MyClass()

print $b.a;
print @b.c
print $b.d{'a'}
print $MyClass::b;

Ed

Re: Strings vs Numbers (Re: Tying & Overloading)

[Edward Peschko]

> ok, well.. I've heard arguments for '+' (namely that its intuitive, other 
> language compatible, etc...) so what are the arguments against it?

Well, it looks like I'm a little bit behind. Spend 15 minutes typing something,
and you get 7 messages in your mailbox on the exact topic that you had questions
on. sheesh.

Ed

Re: Sane "+" string concat proposal

[Michael G Schwern]

On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote:
> Some of the objections have gone by, but what if you reverse the
> quotes?
> Make operator-in-quotes be a string operator (hell, make that true for
> the other ops, too)
> 
> Perl 5  Perl 6
> --- ---
> ->  .
> +   +
> .   "+"
> eq  "=" or eq
> gt  ">" or gt

If we go this route, we may as well just use 'cc'.  Much less typing
(no chording), less confusing, analagous to 'eq' and
'gt'.


> Perl 5Perl 6
> - 
> $res = $var + $var2;  $res = $var + $var2;
> $name = "This" . "that";  $name = "This" "+" "that";
> $name = "This" . $that;   $name = "This" "+" "$that";
> print "Next is " . $i + 1;print "Next is " "+" $i + 1;
> $me = $name . getpwuid($<);   $me = $name "+" getpwuid($<);   

All those quotes make my eyes bleed.


Oh, not to seed the clouds or anything, but what about "+=" and ".="?
Any proposal will have to deal with those.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
Do you have a map? Because I keep getting lost in your armpits.

how about just juxtaposing? (Re: Sane "+" string concat proposal)

[Jarkko Hietaniemi]

I think the magical "+" isn't going to work.

Has the road of just putting things next to each other been extensively
tried?  It works for Awk...  "juxtapose", the Famous Invisible Perl
Operator.

Perl 5  Perl 6

$a = $b . $c;   $a = $b $c; # or $b$c
$a = "foo".$c;  $a = "foo" $c;  # or "foo"$c
$a = foo . $c;  $a = foo$c; # foo $c wouldn't work...
$a = $c . foo;  $a = ${c}foo# (if foo is a function)
$a = foo() . $c;$a = foo() $c;
$a = $c . foo();$a = $c foo();
$a = $b->c . $d;$a = $b->c $d;  # or $b->c$d;

I can see that the indirect objects can be painful

my $fh = open(...);
print $fh $blah;

but maybe we can spread magic thickly enough on filehandles so that
"concat to a filehandle" means output...

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Strings vs Numbers (Re: Tying & Overloading)

[Michael G Schwern]

On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other 
> language compatible, etc...) so what are the arguments against it?

This one seems to have slipped by...
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html

Basically talking about the problems of trying to use the same
operator for strings and concat in a typeless language.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
Beer still cheaper than crack!

Re: Sane "+" string concat proposal

[jc vazquez]

From: "Austin Hastings" <[EMAIL PROTECTED]>
> Perl 5Perl 6
> - 
> $name = "This" . "that";  $name = "This" "+" "that";


$name = "+" "+" "+" "+"; # uh???

Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)

[Michael G Schwern]

On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
> Has the road of just putting things next to each other been extensively
> tried?  It works for Awk...  "juxtapose", the Famous Invisible Perl
> Operator.
> 
>   Perl 5  Perl 6
> 
>   $a = $b . $c;   $a = $b $c; # or $b$c
>   $a = "foo".$c;  $a = "foo" $c;  # or "foo"$c
>   $a = foo . $c;  $a = foo$c; # foo $c wouldn't work...
>   $a = $c . foo;  $a = ${c}foo# (if foo is a function)
>   $a = foo() . $c;$a = foo() $c;
>   $a = $c . foo();$a = $c foo();
>   $a = $b->c . $d;$a = $b->c $d;  # or $b->c$d;

This is going to make finding syntax errors a bit difficult, as many
will simply become concatination operators.  Consider

print "Foo"
foo("bar");

Did the author forget a semi-colon, or did they intend to concatinate
there?  Also, consider this...

print foo "bar";

Is that 'print foo("bar");' or 'print foo()."bar";' in Perl 5?


> I can see that the indirect objects can be painful

That's ok, just kill indirect objects.  Ooop, I'll be leaving before
Nathan finishes loading his gun. ;)


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
 Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!  

Re: Sane "+" string concat proposal

[Casey West]

On Tue, Apr 24, 2001 at 08:32:09PM +0100, Michael G Schwern wrote:
: On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote:
: > Some of the objections have gone by, but what if you reverse the
: > quotes?
: > Make operator-in-quotes be a string operator (hell, make that true for
: > the other ops, too)
: > 
: > Perl 5  Perl 6
: > --- ---
: > ->  .
: > +   +
: > .   "+"
: > eq  "=" or eq
: > gt  ">" or gt
: 
: If we go this route, we may as well just use 'cc'.  Much less typing
: (no chording), less confusing, analagous to 'eq' and
: 'gt'.

I like 'cc' for that very reason.  String operators should look the
same, imho.

-- 
Casey West

Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)

[Casey West]

On Tue, Apr 24, 2001 at 08:42:10PM +0100, Michael G Schwern wrote:
: On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
: > Has the road of just putting things next to each other been extensively
: > tried?  It works for Awk...  "juxtapose", the Famous Invisible Perl
: > Operator.
: > 
: > Perl 5  Perl 6
: > 
: > $a = $b . $c;   $a = $b $c; # or $b$c
: > $a = "foo".$c;  $a = "foo" $c;  # or "foo"$c
: > $a = foo . $c;  $a = foo$c; # foo $c wouldn't work...
: > $a = $c . foo;  $a = ${c}foo# (if foo is a function)
: > $a = foo() . $c;$a = foo() $c;
: > $a = $c . foo();$a = $c foo();
: > $a = $b->c . $d;$a = $b->c $d;  # or $b->c$d;
: 
: This is going to make finding syntax errors a bit difficult, as many
: will simply become concatination operators.  Consider
: 
: print "Foo"
: foo("bar");
: 
: Did the author forget a semi-colon, or did they intend to concatinate
: there?  Also, consider this...

Or, did they intend to concatinate 'print' and "Foo" in void context?

-- 
Casey West

YA string concat proposal

[Michael G Schwern]

Ok, time for me to shot down.

I've already voiced my views about trying to make addition and
concatination into a single operator in a typeless language
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html
and I think its a losing proposition.

So here's something simple.  Sort of a fallback proposal in case
nothing amazingly clever comes up.

cc and ce

Perl 5  Perl 6
print "foo" . "bar";print "foo" cc "bar;
print 2 . 4;print 2 cc 4;
print "foo " . ($i + 1);print "foo " cc ($i + 1);
$foo .= "bar "; $foo ce "bar";

Its unambiguous and its analgous to eq, ne, gt, get, etc...  About the
only problem I can think of is if you define a function called cc() or
ce(), but we live with that already with gt() and friends.

It also has the nice side-effect of preserving '.=' functionality,
which I'd rather not lose (especially after having made fun of 
$foo = $foo . 'bar'; type code).


PS  It doesn't have to specifically be cc and ce.  Just so long as it
matches /^[a-z]{2}$/ and /^[a-z]e$/


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
I'm going to have to hurt you on principle.

Re: Sane "+" string concat proposal

[Nathan Wiger]

"Stephen P. Potter" wrote:
> 
> | In Perl 6, you would do this like so:
> |
> |$string3 = "$string1" + "$string2";
> 
> Once you go this route, you've pretty much destroyed the usefulness of
> having a concat operator.  It is far less typing to do
> 
>$string3 = "$string1$string2";

Agreed. The point wasn't to get rid of that usage by any means, but
rather to propose an alternative to "." since that will likely get
gobbled up as a replacement for ->.

The only reason you'd have to use the op form of a string concat is when
you have to add stuff in that isn't evaluated inside quotes, like funcs.

-Nate

Re: Sane "+" string concat proposal

[Stephen P. Potter]

Lightning flashed, thunder crashed and Casey West <[EMAIL PROTECTED]> whispere
d:
| I would consider thinking about the bigger problem of:
| 
| $string = foo() [something here] bar();

In either case, quoting the operands isn't going to work.

$string = "foo()" + "bar()";

And, my one argument still stands, I get really tired of
<'>foo<'>.  That's four extra keystrokes just so we can
change . to + under this plan.  No thanks.

-spp

Re: Sane "+" string concat proposal

[Dan Brian]

> The only reason you'd have to use the op form of a string concat is when
> you have to add stuff in that isn't evaluated inside quotes, like funcs.

That doesn't make sense. Your proposal was to cause quotes to force concat
context, but here you say the op is only useful when evaluating stuff
outside of quotes. Umm.

Re: Strings vs Numbers (Re: Tying & Overloading)

[Nathan Wiger]

Michael G Schwern wrote:
> 
> On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> > ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> > language compatible, etc...) so what are the arguments against it?
> 
> This one seems to have slipped by...
> http://archive.develooper.com/perl6-language%40perl.org/msg06550.html

>From that email:

> Consider the following...
>
>sub foo { $_[0] + $_[1] }
>
> What do the following return?
>
>foo(1,1);   obviously 2
>foo("this", "that") obvious "thisthat"
>
> Those are simple enough.
>
>foo("1", 1);is that "11" or 2?
>foo(undef, 1);  1 or "1"?
>
> Those can be solved by definining precidence, but its still a bit
> arbitrary.
>
>foo($foo, $bar);who knows?

Based on what I posted, my position would be: &foo returns numeric
addition.

Again, don't think of + as a dual-natured op. That's not what I'm
saying. It remains numeric addition. The C<"" +> operator is your string
concat.

If you wanted foo to return a string concat, you would have to say:

   sub foo { "$_[0]" + $_[1] }

(or use "$_[1]", either way). Without the quotes you're not properly
using the operator.

I'm not really fighting for what I posted per se, but I do want to
emphasize it's not the same as what's been discussed before.

-Nate

Re: YA string concat proposal

[Nathan Wiger]

Michael G Schwern wrote:
> 
> cc and ce
> 
> Perl 5  Perl 6
> print "foo" . "bar";print "foo" cc "bar;
> print 2 . 4;print 2 cc 4;
> print "foo " . ($i + 1);print "foo " cc ($i + 1);
> $foo .= "bar "; $foo ce "bar";

> It also has the nice side-effect of preserving '.=' functionality,
> which I'd rather not lose (especially after having made fun of
> $foo = $foo . 'bar'; type code).

While we're brainstorming a wish-list, here's something I've always
wanted, a replacement for:

   $a = $b . $a;

Under the above plan, maybe this is:

   $a ca $b;

For "concat after"?

-Nate

Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)

[Edward Peschko]

> This is going to make finding syntax errors a bit difficult, as many
> will simply become concatination operators.  Consider
> 
> print "Foo"
> foo("bar");
> 
> Did the author forget a semi-colon, or did they intend to concatinate
> there?  Also, consider this...

*sigh*. Ok, how about: '++'?

Ed

Re: YA string concat proposal

[Jonathan Scott Duff]

On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
>$a = $b . $a;
> 
> Under the above plan, maybe this is:
> 
>$a ca $b;
> 
> For "concat after"?

I'd rather it be called "pp" for prepend.  :-)

It's good that we decided to let Larry design the language, otherwise
we'd be mired in muck like this for a long time.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Sane "+" string concat proposal

[Nathan Wiger]

Michael G Schwern wrote:
> 
> Oh, not to seed the clouds or anything, but what about "+=" and ".="?
> Any proposal will have to deal with those.

Under what I originally posted:

   $a += "$b";# string
   $a += $b;  # numeric

Seems easy enough...

-Nate

Re: YA string concat proposal

[Casey West]

On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
: Michael G Schwern wrote:
: > 
: > cc and ce
: > 
: > Perl 5  Perl 6
: > print "foo" . "bar";print "foo" cc "bar;
: > print 2 . 4;print 2 cc 4;
: > print "foo " . ($i + 1);print "foo " cc ($i + 1);
: > $foo .= "bar "; $foo ce "bar";
: 
: > It also has the nice side-effect of preserving '.=' functionality,
: > which I'd rather not lose (especially after having made fun of
: > $foo = $foo . 'bar'; type code).
: 
: While we're brainstorming a wish-list, here's something I've always
: wanted, a replacement for:
: 
:$a = $b . $a;
: 
: Under the above plan, maybe this is:
: 
:$a ca $b;
: 
: For "concat after"?

Now this sparks my interest.  :)

The only think I don't like is:

  $a ce $b;
  $a ca $b;

because I'm so used to seing

  $a [char]= $b;

I would think of:

  $a c= $b;

but then the ca() idea might not be feasible unless we thought:

  $a ce= $b;
  $a ca= $b;

was a good idea.

-- 
Casey West

Re: YA string concat proposal

[Uri Guttman]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

  NW>$a = $b . $a;

  NW> Under the above plan, maybe this is:

  NW>$a ca $b;

substr( $a, 0, 0, $b ) ;
$a =~ s/^/$b/ ;

just my $.02 on this. i rarely use bare . for concat. as someone else
mentioned, it is usually only needed when you have expressions or
function calls that don't directly interpolate in "". a long
. expression with many terms is rare and probably best done with join
''.

on the other hand, i use .= all the time and wouldn't like to lose
it. schwern idea of ce doesn't work for me as only the op= stuff means
assignment and ce would break that (e for = isn't visual enough).

.= could still be left working as that is a complete separate op from
method invocation. i can live with most any other form of . including
none. join is fine for that.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html

YA string concat proposal

[Garrett Goebel]

~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.

Its doubtless naive to suggest it, but why not:

Perl 5  Perl 6
--- ---
->  .
+   +
.   ~+
eq  ~==
ne  ~!=
gt  ~>
ge  ~>=
lt  ~<
le  ~<=
cmp ~<=>
.=  ~+=
~=+ (concat after)
=~  =~
!~  !~

You can leave aliases for eq, ne, gt... or depreciate them. -But leave
precedence as is...

Perl 5Perl 6
- 
$res = $var + $var2;  $res = $var + $var2;
$name = "This" . "that";  $name = "This" ~+ "that";
$name = "This" . $that;   $name = "This" ~+ $that;
print "Next is " . $i + 1;print "Next is " ~+ $i + 1;
$me = $name . getpwuid($<);   $me = $name ~+ getpwuid($<);   

recap on new operators?

[Dave Storrs]

For those of us who came in late...I gather that -> is expected to be
replaced by '.', which means that we need to find something else for '.'.  
Somehow, however, I missed out what the exact benefits are of this
replacement--I'm not saying that there *aren't* any, I just never saw the
message where they were spelled out.  Could someone please give a recap?

Also, rather than trying to jam extra functionality into '+' or '=~' or
whatever, would it be possible to simply use -> as the concat operator
(i.e., switch '->' and '.')?

Perl 5Perl 6
----
$mail_obj->{header} .= "Hi, John!"$mail_obj.{header} ->= "Hi, John!"

The pros and cons that I see are:

Pro:
  - requires the minimum amount of disturbance to the syntax

Con:
  - You need to know whether you are looking at Perl5 or Perl6 before you
know how to read the operator (raises problems both for programmers and
for p526 translator script)

  - Some of the permutations (e.g. ->= ) look terrible.


Dave

Re: YA string concat proposal

[Michael G Schwern]

On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> While we're brainstorming a wish-list, here's something I've always
> wanted, a replacement for:
> 
>$a = $b . $a;

I don't think there's any pressing need for this unless you can show a
common case where a prepend op would make things significantly easier.


(Postpend (is that a word?) doesn't make things particularly easier
either, but people will expect it and its a bit more common case.)


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
Free beer w/riot!

Re: YA string concat proposal

[Nathan Wiger]

Uri Guttman wrote:
> 
> on the other hand, i use .= all the time and wouldn't like to lose
> it. schwern idea of ce doesn't work for me as only the op= stuff means
> assignment and ce would break that (e for = isn't visual enough).

I was just thinking, too bad that Larry's claiming the colon
currently...

   $str = $a : $b : $i + 1;
   $a := $b : $c;
   $name = $p->param('first') : $p->param('last');

Maybe it's just me, but I like that.

There is, of course, the possibility others have mentioned which is to
make , in a scalar context do something perceived as "more useful":

   $str = $a, $b, $i + 1;
   $a ,= $b, $c;
   $name = $p->param('first'), $p->param('last');

But that second one is a little weird. Plus, this:

   ($a, $b) = ($1 . $2, $3 . $4);

Is now not possible.

> .= could still be left working as that is a complete separate op from
> method invocation. i can live with most any other form of . including
> none. join is fine for that.

Possible, but my gut reaction is that this could be confusing,
especially assuming that you're going to see "." all over your code
meaning object deref now.

-Nate

Re: YA string concat proposal

[James Mastros]

From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 4:08 PM
Subject: Re: YA string concat proposal
> On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> > Under the above plan, maybe this is:
> >$a ca $b;
> > For "concat after"?
> I'd rather it be called "pp" for prepend.  :-)
I'd rather it be spelled $a =. $b;  (or $a=.$b, or $a=."/index.html"; I
don't see how any of those are subject to misparse.  $a=.5 would be, of
couse, but you can disambugate by $a=. 5 or C<$a=."5">.

> It's good that we decided to let Larry design the language, otherwise
> we'd be mired in muck like this for a long time.
Yah.  And it looks like we're going to be as it is.  It's been said
elsewhere on these threads: What does changing to "." from -> buy us?

I can see that "." is shorter to type then ->, but, say, \ would be just as
good.  I can't really say changing because "." is more standard.  It isn't
standard to C or perl5.  It's possible to misparse "." as concat with "." as
a sepperator on version-strings, but that's more of a problem with using it
for method-call.

-=- James Mastros

Re: Strings vs Numbers (Re: Tying & Overloading)

[John L. Allen]

On Tue, 24 Apr 2001, Michael G Schwern wrote:

> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on 
> > either side with white space?  If there's no white space around it, then 
> > it is forced to mean method invokation, or whatever else.
> 
> This approaches "whitespace as syntax".  Very few Perl operators care
> about whitespace between their words (even ->) or whitespace at all.
> 
> More generally, its going to cause alot of careful squinting at code
> to distinguish between different operators.  This will lead to subtle
> bugs because someone accidentally put a space after the . and didn't
> notice.

I still think it's a good idea - better than any other proposed so far.

Are we so afraid of a little mandatory disambiguating white space
that we are willing to pay the price of contorting other syntax
beyond the bounds of sanity? :-)

It's perfectly obvious to me that

$x = $foo . bar;

"wants" to mean concatenation, and that

$x = $foo.bar;

doesn't.

Well, that's this inmate's HO anyway.

John.

Re: YA string concat proposal

[Jarkko Hietaniemi]

On Tue, Apr 24, 2001 at 01:42:43PM -0700, Nathan Wiger wrote:
> Uri Guttman wrote:
> > 
> > on the other hand, i use .= all the time and wouldn't like to lose
> > it. schwern idea of ce doesn't work for me as only the op= stuff means
> > assignment and ce would break that (e for = isn't visual enough).

The fastidious ivory tower side of my brain has always disliked the
fact that there is .= for append but no =. for prepend.  So if I may
have c= and =c in Perl 6 I will be happy :-) (and of course cc for the
"functional" non-argument-modifying version)

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: YA string concat proposal

[Stephen P. Potter]

Lightning flashed, thunder crashed and Garrett Goebel <[EMAIL PROTECTED]> w
hispered:
| cmp ~<=>
| .=  ~+=
| ~=+ (concat after)
| =~  =~
| !~  !~

It's not bad enough that we're getting a proliferation of trigraph
operators, now you want to add a quadgraph?  No thank you.

Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
and !~ went away and were replaced by match(string, [pattern], options),
replace(string, [pattern], options) and trans(string, ["pattern"], options)
or some such.  This is one place where I think PHP had a really good idea,
but missed the mark a little.  ereg_* and eregi_* and preg_* and pregi_*,
ugghhh...

-spp

Re: Sane "+" string concat proposal

[Stephen P. Potter]

Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| Michael G Schwern wrote:
| > 
| > Oh, not to seed the clouds or anything, but what about "+=" and ".="?
| > Any proposal will have to deal with those.
| 
| Under what I originally posted:
| 
|$a += "$b";# string
|$a += $b;  # numeric

You still haven't given a good explanation of

$a += sub();  # is it a string or a number?

Does your plan mean that we can no longer have subs that are context
dependent?

-spp

Re: Sane "+" string concat proposal

[Dan Brian]

> | Under what I originally posted:
> | 
> |$a += "$b";# string
> |$a += $b;  # numeric
> 
> You still haven't given a good explanation of
> 
> $a += sub();# is it a string or a number?

The quotes don't work. Anything but the most basic statement introduces
way more ambiguity than we should be comfortable with. And the idea that
<" +> should be interpreted by the parser as an op, well, doesn't work. At
all.

Re: Strings vs Numbers (Re: Tying & Overloading)

[Edward Peschko]

> I still think it's a good idea - better than any other proposed so far.
> 
> Are we so afraid of a little mandatory disambiguating white space
> that we are willing to pay the price of contorting other syntax
> beyond the bounds of sanity? :-)
> 
> It's perfectly obvious to me that
> 
>   $x = $foo . bar;
> 
> "wants" to mean concatenation, and that
> 
>   $x = $foo.bar;
> 
> doesn't.
> 
> Well, that's this inmate's HO anyway.
> 
> John.

I agree. The more I think about it, the more I like it. Think about it; we are 
actually considering space *by itself* to be syntax. Which is bound to cause 
more problems than space + '.'.

As for usability, I remember one project where someone had done this exact same
thing (via Filter::Util::Call) and it didn't cause any problems that I can 
remember.

I guess my question is what would be the syntax to access hashes? Would

$hashref.{ }

be that desirable? I really like ->{  } in that case..

Ed

Re: Sane "+" string concat proposal

[Nathan Wiger]

"Stephen P. Potter" wrote:
> 
> You still haven't given a good explanation of
> 
> $a += sub();  # is it a string or a number?
> 
> Does your plan mean that we can no longer have subs that are context
> dependent?

No, Schwern asked me this same thing off list, here's what I said:

One possibility:

   "$a" += foo();

And for the multi-function version I'd say:

   $result = join " ", func1(), func2();

I don't see a solution for that with the C<"" +> proposal, so this is
one issue. Any ideas?

---
Summarizing, here are the pros/cons of this approach. Please let me know
if I've left any out:

Pros

- Similar syntax to other HLL's (like .-deref)
- Semantically separate string concat and
  numeric addition maintained
- Most functionality maintained

Cons

- Lose some important . stuff, like with functions
- The C<"" +> concept actually changes precedence
  of + in certain circumstances, which is weird
- Parsing C<"" +> as an "op" just ain't that easy

Anyways, I'm not sure of what the fate of this concept is going to be,
and I'm not going to try and fight for it per se. Truthfully, I'd rather
we keep -> and . as-is. I rather like them that way.

However, if Larry decides that .-deref is happening, then this is at
least one alternative of several to ponder, if for no other reason than
it bridges Perl to other HLL's with a syntax/semantics that mostly
works.

-Nate

Regexp::Func (Re: YA string concat proposal)

[Nathan Wiger]

"Stephen P. Potter" wrote:
> 
> Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
> and !~ went away and were replaced by match(string, [pattern], options),
> replace(string, [pattern], options) and trans(string, ["pattern"], options)
> or some such.  This is one place where I think PHP had a really good idea,
> but missed the mark a little.  ereg_* and eregi_* and preg_* and pregi_*,
> ugghhh...

I'm working on Regexp::Func in another vi window that does this very
thing right now. Although, the syntax I'm working with is a little
different from what you describe above:

   $result = match /pat/flags, $strings ...;
   $result = replace /from/to/flags, $strings ...;
   $result = trade /from/to/, $strings ...;

The advantage to this syntax is you can do whole lists inline. See also
RFC 164. Suggestions welcome, and anyone wanting to test this *very*
welcome (off-list is probably best, this is OT).

-Nate

Re: Sane "+" string concat proposal

[Dan Sugalski]

At 03:38 PM 4/24/2001 -0700, Nathan Wiger wrote:
>"Stephen P. Potter" wrote:
> >
> > You still haven't given a good explanation of
> >
> > $a += sub();  # is it a string or a number?
> >
> > Does your plan mean that we can no longer have subs that are context
> > dependent?
>
>No, Schwern asked me this same thing off list, here's what I said:
>
>One possibility:
>
>"$a" += foo();

Okay, I've been ignoring this more or less up until now, but...

Can we *please* not do this? The "magic if stringified" trick will either 
shoot the optimizer (if we need to tell at runtime if something's string or 
non-string) or make my head explode trying to make the parser handle it in 
anything resembling an elegant way.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Larry's Apocalypse 1 \}

[David L. Nicol]

Dan Sugalski wrote:

> Most of the parser switching is going to be of the nesting variety. Every
> time the parser processes a double-quoted string constant or a regular
> expression you're going to be jumping parsers. That's all temporary, and we
> really do want them to nest. (You really don't want the perl parser to lose
> all its state every time you start a string...)

No, of course not.  I'm asking for separation of "parsing" and "state"
so that multiple parsers can cooperatively contribute to the developing
state.  That is what would be required for python mode to be able to
close blocks opened in perl mode, or v/v.

Just like SH doesn't throw out all environment variables between
instructions. 

SH is very much like this: you can have multiple parsers acting on
multiple HERE documents, one after the other, in case anyone wasn't
aware of that already, which I doubt.

Re: Sane "+" string concat proposal

[Simon Cozens]

On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
> THESE ARE NOT THE SAME TIRED ARGUMENTS!

Ooh, different tired arguments!

>$string3 = $string1 . $string2;
>$string3 = "$string1" + "$string2";
 
That's now *five* characters required to perform a very common operation.

Rather than one.

I remain unconvinced.

-- 
 Remember: amateurs built the Ark; _professionals_ built the
Titantic.

Re: Sane "+" string concat proposal

[Bart Lateur]

On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote:

>>$string3 = $string1 . $string2;
>>$string3 = "$string1" + "$string2";
> 
>That's now *five* characters required to perform a very common operation.
>
>Rather than one.

I'm really beginning to like

$string3 = $string1 _ $string2;

The underscore indeed "connects" the two strings.


But: as somebody else wrote: why on earth do we need to reserve the dot
for OO? Why do we have to be compatible with everybody else in the
world? Because we're not, anyway.

Recently, there was a question about polymorphism in Perl. This person
did not understand that it is possible that you can use the same method
for two different classes, without them having a common superclass. It's
perfectly possible in Perl (because method resolving actually is a form
of symbolic dereferencing... heheh...), but most definitely not in most
other OO languages.

So, perl is different anyway. What does one tiny extra superficial
difference of notation FGS make any difference. I think backward
compatibility with Perl5 is far more important, than having the
*appearance* of doing the same as other OO languages.

-- 
Bart.

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
: 
: $hashref.{ }
: 
: be that desirable? I really like ->{  } in that case..

It won't be either of those.  It'll simply be $hashref{ }.

Larry

Dot can DWIM without whitespace

[Brent Dax]

IMHO, . can DWIM in most cases even if it's both object deref _and_
concat--without paying any attention to whitespace.

Let's think about this for a minute.  What are the common cases for use of
concat?

$a."b";
"a".$b;
$a.$b;
a.$b;
$a.b;
a.b;

The first two are obviously concat, since that code makes absolutely no
sense as an object deref.  Unless we decide that objects can contain scalars
and to access them you must prefix their name with $, the middle pair can't
be object calls, so they're concat.  The last two, however, are ambiguous.
How can we figure out what they mean?

Two possibilities:
1) we define a cc (or something like that--I prefer j, since it's shorter)
operator that _always_ means concat, or
2) when you mean "call a function called b", you have to say &b;

Alternately, we can overload . to do a deref on (blessed?) references, and
concat otherwise.

Does any of that make sense?  Or should I be returned to my straightjacket?
:^)

--Brent Dax
[EMAIL PROTECTED]

Re: Tying & Overloading

[Edward Peschko]

On Tue, Apr 24, 2001 at 06:54:18PM -0700, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : Larry Wall <[EMAIL PROTECTED]> writes:
> : >I think using overloading to write a parser is going to be a relic of
> : >Perl 5's limitations, not Perl 6's.
> : 
> : I am _NOT_ using overloading to write a parser. 
> : Parse::Yapp is just fine for writing parsers. I am trying to re-use
> : a parser that already exists - perl5's parser. 

Not trying to be pedantic or anything, but 'Parse::Yapp' is *not* the model to 
follow IMO if there is to be a generic parser tool made to create plug-in 
grammars.  I'm not sure of performance issues, but 'Parse::FastDescent' would 
be a better model for designing one. IMO, tons more flexible and easy to use.

Ed

Re: Strings vs Numbers (Re: Tying & Overloading)

[Edward Peschko]

On Tue, Apr 24, 2001 at 06:39:09PM -0700, Larry Wall wrote:
> Edward Peschko writes:
> : I guess my question is what would be the syntax to access hashes? Would
> : 
> : $hashref.{ }
> : 
> : be that desirable? I really like ->{  } in that case..
> 
> It won't be either of those.  It'll simply be $hashref{ }.
> 
> Larry

Ok, so what does:

my %hash = ( 1 => 3);
my $hash = { 1 => 4};

print $hash{1};

print?

Ed

Parser swiching (was Re: Larry's Apocalypse 1 \})

[Dan Sugalski]

At 06:40 PM 4/24/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > [BTW, was this meant to be CC'd to one of the perl 6 lists? My copy wasn't]
>
>yeah, I have perl6-language as a alias but not "language" by itself

Fixed.

> > At 05:55 PM 4/24/2001 -0500, David L. Nicol wrote:
> > >Dan Sugalski wrote:
> > >
> > > > Most of the parser switching is going to be of the nesting variety. 
> Every
> > > > time the parser processes a double-quoted string constant or a regular
> > > > expression you're going to be jumping parsers. That's all 
> temporary, and we
> > > > really do want them to nest. (You really don't want the perl parser 
> to lose
> > > > all its state every time you start a string...)
> > >
> > >No, of course not.  I'm asking for separation of "parsing" and "state"
> > >so that multiple parsers can cooperatively contribute to the developing
> > >state.  That is what would be required for python mode to be able to
> > >close blocks opened in perl mode, or v/v.
> >
> > Urk. I'd rather not do that. The language that opens a block closes it.
>
>
>A reasonable rule.  you ARE the voice of sanity aren't you.

Yep. It's a rather bizarre turn of events. I figure it's some sort of 
Karmic payback... :)

Anyway, what we might want to talk about is how we want to switch parsers 
on a large scale. (As opposed to minilanguages like the regex stuff)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Edward Peschko writes:
: Ok, so what does:
: 
: my %hash = ( 1 => 3);
: my $hash = { 1 => 4};
: 
: print $hash{1};
: 
: print?

4.  You must say %hash{1} if you want the other.

Larry

Re: Tying & Overloading

[David L. Nicol]

Larry Wall wrote:
> (And juxtaposition is out because we're not going to destroy indirect
> object syntax

How often is indirect object syntax used without some whitespace? Having
the perl5->perl6 converter locate it and insert a space shouldn't be too
very tricky.


$these=$this$that$the_other;

is what we've been doing inside double quotes for years. Making
butted-against-each-other be the string concatenation operator looks
good IMO.




> I'm thinking concat will be ~.  Furthermore, I'm thinking unary ~ will
> be stringify.

Not unary diglyph \" ?

C or SH like string cat proposal

[David L. Nicol]

1:  use adjacency w/o white space for string cat.

2:  allow, as in C, consecutive double-quoted strings
with no intervening tokens (i.e. just whitespace and comments) to
be considered as one string

3:  as Uri pointed out, it's all syntactic sugar for convolutions
of C


That means, if you have a long list of scalars rou want to cat
together and it will run over the edge of your line
you can do this:

$onethroughten = $one$two$three$four$five""
""$six$seven$eight$nine$ten;


Will someone please explain to me the "indirect object syntax"
which this allegedly steps on?


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   Henrik's keyboard has nice letters like 'æ', 'ø' and 'å'

Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)

[David L. Nicol]

Ah.. I knew I'd find the thread in here somewhere.

The problems go away if you allow white space to signify.


> [...]  Consider
> 
> print "Foo"
> foo("bar");
> 
> Did the author forget a semi-colon, or did they intend to concatinate
> there?  Also, consider this...
they forgot a semicolon.  A spaceless juxtaposed concat would look like

 print "Foo"foo("bar");


and we insist that indirect objects have a space in them. And introduce
"" "" for when you absolutely positively don't want to write an expression
with C.


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   Henrik's keyboard has nice letters like 'æ', 'ø' and 'å'

Re: Strings vs Numbers (Re: Tying & Overloading)

[Peter Scott]

At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
>Edward Peschko writes:
>: Ok, so what does:
>:
>: my %hash = ( 1 => 3);
>: my $hash = { 1 => 4};
>:
>: print $hash{1};
>:
>: print?
>
>4.  You must say %hash{1} if you want the other.

I was teaching an intro class yesterday and as usual, there were several 
people who typed just that instead of what I'd taught, so there is 
obviously some intuitive merit to it.

Re: Tying & Overloading

[Simon Cozens]

On Tue, Apr 24, 2001 at 02:01:11AM -0700, Damien Neil wrote:
> If you're dead-set on reassigning ., please consider leaving it at
> that, rather than juggling all the other operators around. 

Don't forget that binary ~ doesn't currently exist, so this is adding
syntax rather than reassigning it.

> Make concatination be "$a cat $b".  ("eq" and friends already provide
> precedent for string operators being words rather than symbols.)

While that's true, concatenation is quite a common operation (Introspection
is cool. Run "perl -MO=Terse someprogram | grep concat".) that I'd be really
uncomfortable with it necessitating 4 keystrokes (" cat") instead of one.

-- 
emacs: Terminal type "emacs" is not powerful enough to run Emacs.