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

[David L. Nicol]

John Porter wrote:

> We could  y/$@%/@%$/  ...


... and create an alternate parser able to handle the full
internal internals API.

I have finally figured out the main motivation behind the
whole perl6 effort: the obfuscated perl contests were
getting repetitive.

Good night.

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

[Bart Lateur]

On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), 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{ }.

Er... hip hip hurray?!?!

This is precisely the reason why I came up with the raw idea of
highlander variables in the first place: because it's annoying not being
able to access a hash passed to a sub through a hash reference, in the
normal way. Not unless you do aliasing through typeglobs. A highlander
variable would get you that: that if a hash %foo exists, the scalar $foo
would automatically be a reference to that hash.

But, if there won't be full blown highlander variables, how does Perl
know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
hash referenced by the hashref $foo?

-- 
Bart.

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

[Bart Lateur]

On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:

>: 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.

Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimensional hash, going to go? Otherwise %hash{$a, $b} is going to
be ambiguous.

-- 
Bart.

Re: Another string concat proposal

[Nicholas Clark]

On Wed, Apr 25, 2001 at 11:53:33AM +0100, Dave Hartnoll wrote:
> What about using double-dot as the string concat operator:
> 
> P5P6
> ->.
> .  ..
> .=..=  (or =.. for concat after)

You have missed a row for what the P5 .. operator becomes.
And the ... operator

[I am neutral as to whether using .. as concatenation is a good idea]

Nicholas Clark

Another string concat proposal

[Dave Hartnoll]

What about using double-dot as the string concat operator:

P5P6
->.
.  ..
.=..=  (or =.. for concat after)

Many other operators already use doubled characters so this would not be an
oddity for perl and it would leave single dot for all the things Larry wants
it for without sacrificing the normal meanings of any of the other operators
for concat.

Dave Hartnoll.

Re: Another string concat proposal

[Dave Hartnoll]

> On Wed, Apr 25, 2001 at 11:53:33AM +0100, Dave Hartnoll wrote:
> > What about using double-dot as the string concat operator:
> >
> > P5P6
> > ->.
> > .  ..
> > .=..=  (or =.. for concat after)
>
> You have missed a row for what the P5 .. operator becomes.
> And the ... operator
>
> [I am neutral as to whether using .. as concatenation is a good idea]
>
> Nicholas Clark

That'll teach me to jump in without proper research. I had forgotten about
the .. range operator and I wasn't even aware of the ... variety (I am now).
I suppose it would be too cheeky to attempt to redeem myself by
suggesting ->> as a range operator? (I would have suggested -> but that
introduces problems with it meaning the same as comma in some situations.)

P5P6
->.
.  ..
.=..=  (or =.. for concat after)
..->>
...->>>

Another option I briefly considered for concat was   .+

Perhaps too many changes overall, but food for thought for those without
chronic indigestion already!

Dave Hartnoll.

Re: Another string concat proposal

[Dave Hartnoll]

I wrote..
> ..(I would have suggested -> but that
> introduces problems with it meaning the same as comma in some situations.)

Ignore that. I'm getting confused with => sometimes meaning the same as
comma. I think I'll quit now before I dig myself any deeper :-)

Dave.

Re: Sane "+" string concat proposal

[Bart Lateur]

On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote:

>| I'm really beginning to like
>| 
>|  $string3 = $string1 _ $string2;
>| 
>| The underscore indeed "connects" the two strings.
>
>This still breaks because _ is a valid word character.

So are "cmp", "and", "lt", and the proposed "cat" and "cc". Having
operators consisting of word characters doesn't really seem to be any
problem, except that you may not attach them at the end of a variable's
name.

-- 
Bart.

Re: Sane "+" string concat proposal

[Stephen P. Potter]

Lightning flashed, thunder crashed and Bart Lateur <[EMAIL PROTECTED]> whis
pered:
| I'm really beginning to like
| 
|   $string3 = $string1 _ $string2;
| 
| The underscore indeed "connects" the two strings.

This still breaks because _ is a valid word character.  Again, we have to
make the language be white space sensitive.

-spp

Re: Dot can DWIM without whitespace

[Stephen P. Potter]

Lightning flashed, thunder crashed and "Brent Dax" <[EMAIL PROTECTED]> wh
ispered:
| $a.$b;
| a.$b;
| 
| 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.

How about symbolic refs to function names?

$a = $x ? "hop" : "skip";
$b = $y ? "scotch" : "soda";

$a.$b;  # call one of hop.scotch, skip.scotch, hop.soda, skip.soda

Might we have an issue there where these can be ambiguous as well?

| 1) we define a cc (or something like that--I prefer j, since it's shorter)
| operator that _always_ means concat, or

Two operators to do the same thing.  One just to handle the case where the
other is ambigous?  I don't think so.

| 2) when you mean "call a function called b", you have to say &b;

How do you call a builtin function then?

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

I think this would lead to hard to find bugs when someone mispelled
something.

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

They're coming to take us away, ha ha.
They're coming to take us away.

Why should you be the only one allowed out of your jacket?  If the rest of
us have to wear them, so should you.  ;-)

-spp

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

[Larry Wall]

Bart Lateur writes:
: Ok. So how about hash slices? Is $hash{$a, $b}, the faked
: multidimensional hash, going to go?

Yes, fake multidimensional hashes will be defenestrated.

Larry

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

[Larry Wall]

Bart Lateur writes:
: Er... hip hip hurray?!?!
: 
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs. A highlander
: variable would get you that: that if a hash %foo exists, the scalar $foo
: would automatically be a reference to that hash.
: 
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?

$foo{THERE} always means the hashref in $foo.  %foo{THERE} always means
the hashref in %foo.  %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref.  &foo by itself in
a scalar context means a coderef.  It's gonna be pretty consistent.

Likewise, bare @foo, %foo, &foo in function prototypes will default
to supplying a scalar context, so they don't eat arguments.  The final
argument will have to be specifically marked if you want it to eat
up arguments.  And we'll probably distinguish eating a list in list
context from eating a list of scalars, so you could pass a list of
arrays easily to a variadic function with each variable name in
scalar context so as to produce a reference.

This is a little hard to explain, but I intuit that it will turn out to
be intuitive.

Larry

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

[Randal L. Schwartz]

From: [EMAIL PROTECTED] (Randal L. Schwartz)
Date: 25 Apr 2001 07:23:44 -0700
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes:

Peter> 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.

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

I found that to be true until I discovered a trick about teaching this
stuff, which we've incorporated into the Stonehenge "Llama" materials
over the past 18 months, and thus the forthcoming "Learning Perl (3rd
edition)" book.

We spend about 20 minutes in class talking about everything
you can do with $foo[3], without having ever mentioned @foo at all.

When we introduce it, we treat the @ as an operator, phrased "all of
the".  So "@rocks" is "all of the rocks", the same as ($rocks[0],
$rocks[1], $rocks[2],...), which they've already seen at that point.

We've not had anyone try to use @foo[3] since then!

Ditto $foo{"smile"} we don't introduce %foo until we start talking
about operators that work on "all of the hash of ...".  Nobody ever
tries to type %foo{"smile"} after that either.

And yes, these work quite nicely, and the new llama reflects this new
teaching style.

So, I'd say if you get %hash{1} in an intro class, it's the way you
teach it.  I'd also dare say you're teaching the language you want,
instead of the language that it is.  Materials always reflect that.
Better to get within the paradigm.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: YA string concat proposal

[John Porter]

Uri Guttman wrote:
> .= could still be left working as that is a complete separate op from
> method invocation. 

I see a major potential problem with that.

Assuming (which I do) that the equals operator will be
overridable, then you'll need to be able to write

$obj.='x';

meaning this (as in in C++):

$obj.operator=('x');

-- 
John Porter

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

Re: Tying & Overloading

[James Mastros]

From: "Larry Wall" <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 1:10 PM
Subject: Re: Tying & Overloading
> 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 synonym, just for Dan. :-)
>
> Larry

I hate yelling without good reason, but this /is/ good reason.  CAN SOMBODY
PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?

Reasons I have seen are:
1) Two less keys to press.
2) Looks cleaner.
3) Looks more like other languages.

Counterarguments:
1) Produces confusion for perl5 programmers.

I think that we should be kinder to perl5 programmers switching to perl6
then to java[script]/vb programmers switching to perl6.  (C and C++
shouldn't be an issue; we stole -> from C in the first place.)

I submit that := is far uglyer and harder to type then ->.

I don't think that we should change around huge amounts of other things just
so we can s/->/./.

If we really want an easyer-to-type method call operator, I'd go with \.
It's use currently outside of a qq is erronious.  It can't interoperlate
inside of qq, but nor can any other operator discussed here.

It doesn't look much like whitespace (if that's what you mean by "looks
nice").  If you want that, you could go with `, which could produce some
ambiguity, both with qx and with ', which looks very similar in many fonts.

BTW, I think that considering no-whitespace cases of indirect object is
quite silly -- does anybody acatualy use that?
This is the first I thought it wasn't a syntax error.

-=- James Mastros

Re: Dot can DWIM without whitespace

[Dave]

On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:

[snip four examples are obvious ...]
 
>>> $a."b";

If a has a method 'foo' such that

$a.foo

is the standard invocation, it would be nice when $b = 'foo' for

$a.foo === $a."$b" === $a.$b

How I see the . operator working in this case is as something like

$a.foo === &{$a{foo}}

Hence that would logically follow that

&{$a{foo}} === $a.foo === &{$a{"$b"}} === $a."$b" === $a.$b === &{$a{$b}}

and this case

>>> a.b;

is either an error, or something very scary.

-- 

david j. goehrigbit twiddlerwww.valinux.com

"There was nothing creative, charming, admirable or innovative in
Pokémon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants..."

- John Tynes

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

[Eric Roode]

Nathan Wiger wrote:
>
>Here's something I was thinking about at lunch:
>
>   $concated_number = "$number" + "$other_number";
>   $numerical_add   = $number + $other_number;
>

One major, MAJOR pet peeve I have wrt Javascript is that it uses
+ to mean concatenation as well as addition, and that it (like perl)
allows scalars to contain strings or numbers.

One is continually forced to jump through hoops to do simple arithmetic.
User has entered a number -- ah, but it comes in as a string. Want to
add 666 to it? You have to do this nonsense:

$sum = $addend - 0 + 666;

You constantly have to subtract zero in order to force a numeric
context. Asinine.

Whatever the final Perl 6 solution to string concatenation/addition is,
don't let it become the ambiguous mess that Javascript is.


My two cents. Thanks for listening.

 --
 Eric J. Roode[EMAIL PROTECTED]
 Senior Software Engineer, Myxa Corporation

Re: Tying & Overloading

[Jonathan Scott Duff]

On Wed, Apr 25, 2001 at 12:44:11PM -0400, James Mastros wrote:
> I hate yelling without good reason, but this /is/ good reason.  CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?

You've made it impossible for anyone to answer you until you tell us
what "good" means to you.  We could give reasons all day long and you
could reply with "those aren't GOOD reasons".

How about this one:  Because Larry said so.

Seems good enough to me.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: s/./~/g

[Eric Roode]

Larry Wall wrote:
>
>Branden writes:
>: 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?
>
>It's not zero net gain, and I'm going to ignore the next person who says it.

Hokay, fine, I can respect that, but I'm with Branden here... I just don't
see the gain. Is it merely to make Perl's derefs look like Java's? If so,
so what? If there's more, please elucidate. 

[...]
>
>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.

No, more like ". is already used for something". The only reason I have
seen written out so far for the shift from -> to .  and . to  is: it looks more like other languages. That seems like a whole
lot of fixing of non-broken syntax.


 --
 Eric J. Roode[EMAIL PROTECTED]
 Senior Software Engineer, Myxa Corporation

Re: Flexible parsing (was Tying & Overloading)

[Dan Sugalski]

At 01:36 PM 4/25/2001 -0400, Eric Roode wrote:
>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 may have my history wrong here, but didn't Ada try that? Super-
>flexible, redefinable syntax? And wasn't the result that nobody could
>read anybody else's code, so Standards Committees were set up to
>define Legal Styles that basically reduced the syntaxes that you could
>use to just the One Standard Style?

Sounds about right.

And on the other hand you have things like Forth where every program 
essentially defines its own variant of the language, and that works out 
reasonably well. (Granted it's more of a niche language, especially today, 
but that's probably more due to its RPN syntax)

"A power so great, it can only be used for good or evil!" - Firesign Theater

:)


Dan

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

Re: Flexible parsing (was Tying & Overloading)

[Eric Roode]

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 may have my history wrong here, but didn't Ada try that? Super-
flexible, redefinable syntax? And wasn't the result that nobody could
read anybody else's code, so Standards Committees were set up to 
define Legal Styles that basically reduced the syntaxes that you could
use to just the One Standard Style?

 --
 Eric J. Roode[EMAIL PROTECTED]
 Senior Software Engineer, Myxa Corporation

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

[Simon Cozens]

On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > Doesn't ~ look like a piece of string to you?  :-)
> It looks like a bitwise op to me, personally.

That's because every time you've used it in Perl, it's been a bitwise
op. Sapir-Whorf, and all that.

-- 
So what if I have a fertile brain?  Fertilizer happens.
 -- Larry Wall in <[EMAIL PROTECTED]>

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

[Graham Barr]

On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote:
> On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > > Doesn't ~ look like a piece of string to you?  :-)
> > It looks like a bitwise op to me, personally.
> 
> That's because every time you've used it in Perl, it's been a bitwise
> op. Sapir-Whorf, and all that.

Not just Perl. Many other languages use ~ the same as Perl
does now.

Graham.

YAYAYA string concat proposal

[Garrett Goebel]

Suggestion: prepend a ~ or , to numeric comparison operators

Addresses the key concerns:
o  frees up .
o  spaces insensitive (though cmp, eq, ...do care about spaces)
o  using the , instead of ~ would be 1 keystroke on most keyboards
o  ~ and , visually intuit a string (~ more than ,)
o  avoids: $foo = "foo" + "$foo" + foo + foo()
o  easy to differentiate string and numeric ops
o  doesn't spill over into other syntax changes... (i think)

From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel <[EMAIL PROTECTED]> whispered:
> | Perl 5  Perl 6
> | --- ---
> | ->  .
> | +   +
> | .   ~+
> | .=  ~+=
> | ~=+
 [and possibly consider]
> | eq  ~==  or eq
> | ne  ~!=  or ne
> | gt  ~>   or gt
> | ge  ~>=  or ge
> | lt  ~<   or lt
> | le  ~<=  or le
> | cmp ~<=> or cmp
> |
> | You can leave aliases for eq, ne, gt... or depreciate them.
> | -But leave precedence as is...
 
> It's not bad enough that we're getting a proliferation of trigraph
> operators, now you want to add a quadgraph?  No thank you.

cmp requires typing at least 4 characters too:
  sort {$a cmp$b} qw(z y x);
  sort {${a}cmp$b} qw(z y x);

It has been suggested to me privately to leave the lettered ops eq, ne, cmp,
etc. alone since there is a history behind using lettered ops on strings and
symbol ops on numbers. That's fine. You might consider allowing either, or
possibly just dropping the trigraphs and/or quadgraphs.

YAYAYA string concat proposal

[Garrett Goebel]

Suggestion: prepend a ~ or , to numeric comparison operators

Addresses the key concerns:
o  frees up .
o  spaces insensitive (though cmp, eq, ...do care about spaces)
o  using the , instead of ~ would be 1 keystroke on most keyboards
o  ~ and , visually intuit a string (~ more than ,)
o  avoids: $foo = "foo" + "$foo" + foo + foo()
o  easy to differentiate string and numeric ops
o  doesn't spill over into other syntax changes... (i think)

From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel <[EMAIL PROTECTED]> whispered:
> | Perl 5  Perl 6
> | --- ---
> | ->  .
> | +   +
> | .   ~+
> | .=  ~+=
> | ~=+
 [and possibly consider]
> | eq  ~==  or eq
> | ne  ~!=  or ne
> | gt  ~>   or gt
> | ge  ~>=  or ge
> | lt  ~<   or lt
> | le  ~<=  or le
> | cmp ~<=> or cmp
> |
> | You can leave aliases for eq, ne, gt... or depreciate them.
> | -But leave precedence as is...
 
> It's not bad enough that we're getting a proliferation of trigraph
> operators, now you want to add a quadgraph?  No thank you.

cmp requires typing at least 4 characters too:
  sort {$a cmp$b} qw(z y x);
  sort {${a}cmp$b} qw(z y x);

It has been suggested to me privately to leave the lettered ops eq, ne, cmp,
etc. alone since there is a history behind using lettered ops on strings and
symbol ops on numbers. That's fine. You might consider allowing either, or
possibly just dropping the trigraphs and/or quadgraphs.

Re: Dot can DWIM without whitespace

[Simon Cozens]

On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> IMHO, . can DWIM in most cases even if it's both object deref _and_
> concat--without paying any attention to whitespace.

Please, no. Some of us have to *teach* this language.

-- 
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen

Curious: -> vs .

[Nathan Wiger]

I'm just gonna post this, then back off and listen (been yapping too
much...)

The previous discussions about string concat and how to replace . have
revealed that people are somewhat divided over whether replacing -> with
. is actually good thing or not.

I'm just curious what the arguments for and against it are. PLEASE don't
turn this into an unproductive religious flamewar. I'm open-minded about
it, but I at least need a little convincing. Whether or not this has any
impact on Larry's decision is unknown, but it seems like it's good to at
least have the pros and cons clearly on the table.

Just to start it off, here are some of the arguments against changing
this that I know of. If you know of others, or are on the "for" side of
things, feel free speak up. Politely, PLEASE.

   Arguments Against Changing -> and .
   ---
   - It gains superficial similarity to other HLL's,
 yet Perl is fundamentally semantically different
 from all of them. Plus, this is not the only
 syntactic difference.

   - JAPH compatibility. Thousands of people already
 know how deref and concat work, and they're the
 target audience for Perl 6, after all. Sure, we'd
 closer to Python, but we'd be further from Perl 5.

   - C compatibility. One of Perl's great strengths
 over other HLL's is C compatibility. Though
 this is still arguably not as good as it can be, 
 why distance ourselves from the language we're
 trying to interact with?

   - Dissimilarity between Perl and languages like
 JavaScript can actually be beneficial. If you're
 generating code, this makes it easier to scan
 and see where your Perl ends and your Java begins.

   - Two keys less to press? Ever heard of macros? :-)

Re: Tying & Overloading

[Andy Dougherty]

On Wed, 25 Apr 2001, James Mastros wrote:

> I hate yelling without good reason, but this /is/ good reason.  CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?

It might be prudent to avoid rushing to judgment until the bigger picture
becomes clearer.  We have yet to see what changes might be in store for
how, when, and why we'll be using method calls in perl6 vs. perl5.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Curious: -> vs .

[Russ Allbery]

Nathan Wiger <[EMAIL PROTECTED]> writes:

>- C compatibility. One of Perl's great strengths
>  over other HLL's is C compatibility. Though
>  this is still arguably not as good as it can be, 
>  why distance ourselves from the language we're
>  trying to interact with?

You're thinking of objects as references and references as akin to
pointers, which makes sense because that's how they're implemented in Perl
5.  If you think of objects as their own entities, however, or think of
references as something other than pointers (in particular, something that
doesn't require explicit dereferencing), then using . to access object
members is entirely compatible with C.

I tried to make this point before, but I don't think people understood
what I was getting at.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Curious: -> vs .

[Dan Brian]

> You're thinking of objects as references and references as akin to
> pointers, which makes sense because that's how they're implemented in Perl
> 5.  If you think of objects as their own entities, however, or think of
> references as something other than pointers (in particular, something that
> doesn't require explicit dereferencing), then using . to access object
> members is entirely compatible with C.
> 
> I tried to make this point before, but I don't think people understood
> what I was getting at.

I did. :) Moreover, the idea of a "dereference operator" dumbfounds lots
of folks. "What's an object got to do with a reference, much less a
pointer?" A p5 object is very confusing to others for this reason, and so
is the syntax.

While I agree with some that we should keep Perl folk happy before making
the world happy, this is one syntax quirk which really doesn't help Perl
IMO. When method invocation has such a generally-accepted syntax
everywhere else, it can only be positive to adopt a similar syntax.

Re: s/./~/g

[David L. Nicol]

Eric Roode 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.
> 
> No, more like ". is already used for something". The only reason I have
> seen written out so far for the shift from -> to .  and . to  here> is: it looks more like other languages. That seems like a whole
> lot of fixing of non-broken syntax.


which is why, back in 

http://www.mail-archive.com/perl6-all%40perl.org/msg01043.html

Oh, last august, we discussed all this


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
  and they all say "yodelahihu"

Re: Dot can DWIM without whitespace

[Edward Peschko]

On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote:
> On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> > IMHO, . can DWIM in most cases even if it's both object deref _and_
> > concat--without paying any attention to whitespace.
> 
> Please, no. Some of us have to *teach* this language.

Then I guess that either space sensitive '.' is the answer, or '_'. I personally
prefer the space sensitive '.' because it is compatible with perl5, and I think
people would have less difficulty with it even if it was doing double duty in 
the language. And its visually easy to spot the difference between the two
constructs.

But if it is going to be another character, I'd definitely go with '_' over '~'.
At least then we could say _= and =_, although that looks bizarre to me..

I think its really time to have a vote on this, I think that all that has been 
said about this issue has been said...

Ed

Re: Curious: -> vs .

[John Siracusa]

On 4/25/01 5:52 PM, Dan Brian wrote:
> the idea of a "dereference operator" dumbfounds lots of folks. "What's an
> object got to do with a reference, much less a pointer?" A p5 object is very
> confusing to others for this reason, and so is the syntax.

Then remove it from the reference syntax! :)  Isn't that what's going on
anyway, with $foo{'bar'} becoming %foo{'bar'} and $foo->{'bar'} becoming
$foo{'bar'}?

-John

Re: Dot can DWIM without whitespace

[Paul Johnson]

On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:

> I think its really time to have a vote on this

Aaargh.  I don't.  Wouldn't you rather wait and see what Larry is
planning with all this?  I doubt the proposed changes are gratuitous,
and I think he's got a pretty good track record with these sorts of
things.

Anyway, what do you think this is?  Some kind of democracy?

:)

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: Dot can DWIM without whitespace

[Edward Peschko]

On Thu, Apr 26, 2001 at 01:03:50AM +0200, Paul Johnson wrote:
> On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> 
> > I think its really time to have a vote on this
> 
> Aaargh.  I don't.  Wouldn't you rather wait and see what Larry is
> planning with all this?  I doubt the proposed changes are gratuitous,
> and I think he's got a pretty good track record with these sorts of
> things.

My guess is that the majority of the intent is to go for compatibility with 
other HLL, and for simplicity. Although perhaps that is not the whole story...

> Anyway, what do you think this is?  Some kind of democracy?
> 
> :)

well, that's the standard code for 'its time for a decision from larry' isn't 
it? ;-)

Ed

Re: Dot can DWIM without whitespace

[Bryan C . Warnock]

On Wednesday 25 April 2001 18:33, Edward Peschko wrote:
> On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote:
> > On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> > > IMHO, . can DWIM in most cases even if it's both object deref
> > > _and_ concat--without paying any attention to whitespace.
> >
> > Please, no. Some of us have to *teach* this language.
>
> Then I guess that either space sensitive '.' is the answer, or '_'. I
> personally prefer the space sensitive '.' because it is compatible
> with perl5, and I think people would have less difficulty with it
> even if it was doing double duty in the language. And its visually
> easy to spot the difference between the two constructs.

'.' is already, to some extent, space sensitive anyway, because it has 
to pull double duty as a decimal point, as well.

'4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

a modest proposal Re: s/./~/g

[Fred Heutte]

It seems to me that ~ relates to forces (operators, functions and methods)
more than to atoms (scalars), so to speak.  It's the curve of binding Perl
at work here.

So why not leave  .  alone and have  ~  substitute for  ->

$mydsn->Sql("$mysqlstmt " . $moresql) ;
$mydsn~Sql("$mysqlstmt " . $moresql) ;

Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?
Besides, as far as I can tell from a first-order look, the two meanings
would not have to be rival (as in a different way \ for denoting a
reference and \ for denoting an escaped byte are not).

Fred

Re: a modest proposal Re: s/./~/g

[Casey West]

On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
: It seems to me that ~ relates to forces (operators, functions and methods)
: more than to atoms (scalars), so to speak.  It's the curve of binding Perl
: at work here.
: 
: So why not leave  .  alone and have  ~  substitute for  ->  
: 
: $mydsn->Sql("$mysqlstmt " . $moresql) ;
: $mydsn~Sql("$mysqlstmt " . $moresql) ;

In that case I'd rather use this syntax:

$obj'attribute;

$obj'constructor'method;

Or... maybe not...

-- 
Casey West

Re: Dot can DWIM without whitespace

[Edward Peschko]

> '.' is already, to some extent, space sensitive anyway, because it has 
> to pull double duty as a decimal point, as well.
> 
> '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator)

beautiful. Then extending this is simple, consistent, easy to read, compatible 
with perl5.. 

Ed

Re: a modest proposal Re: s/./~/g

[Damien Neil]

On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
> Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?

Today, in fact:
  fcntl($fh, F_SETFL, $flags & ~O_NONBLOCK) or die "fcntl: $!";

  - Damien

Re: Dot can DWIM without whitespace

[Simon Cozens]

On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> > Please, no. Some of us have to *teach* this language.
> Then I guess that either space sensitive '.' is the answer

Sorry. I'll try it again.

SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet?

Are you *really* willing to deal with hundreds of newbies who don't
understand why $a . $b isn't the same as $a .$b and isn't the same as
$a. $b and isn't the same as $a.$b? And do you realise what the only
"good" answer we can possibly give them is? "Because Ed said so".

Sorry, I'm not going to do that.

-- 
I'm surrounded by electromagnetic radiation all the time. There are radio
stations broadcasting at lots of kW, other people using phones, the police, 
[...] the X-rays coming from my monitor, and God help us, the sun. I figure 
I have better things to worry about than getting cancer from the three or 
four minutes a day I spend on my cell phone. - Dave Brown.

Re: Dot can DWIM without whitespace

[Edward Peschko]

On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote:
> On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> > > Please, no. Some of us have to *teach* this language.
> > Then I guess that either space sensitive '.' is the answer
> 
> Sorry. I'll try it again.
> 
> SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet?
> 
> Are you *really* willing to deal with hundreds of newbies who don't
> understand why $a . $b isn't the same as $a .$b and isn't the same as
> $a. $b and isn't the same as $a.$b? And do you realise what the only
> "good" answer we can possibly give them is? "Because Ed said so".

Argh. 

The problem already comes up... '4. 5' is not the same as '4.5'. '.' is 
*already* doing double duty as decimal mark. The fact that you don't see this 
very often shows exactly how rare the mistake arises.

I think the 'tutorial' will come from experience. When the error that you get 
from $a.$b comes up (and it should be a syntax error) you'll see exactly what 
is wrong. If $a. $b, again, syntax error. Only $a . $b should be allowed.

The only point of contention would be if someone said $a . b, when they meant
$a.b. And how often will that occur?

Ed

Re: Dot can DWIM without whitespace

[Bryan C . Warnock]

On Wednesday 25 April 2001 21:37, Edward Peschko wrote:
> > '.' is already, to some extent, space sensitive anyway, because it
> > has to pull double duty as a decimal point, as well.
> >
> > '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator)
>
> beautiful. Then extending this is simple, consistent, easy to read,
> compatible with perl5..

I'm not sure that that was the point I was trying to make.
If nothing else, the '.' would then be responsible for *three* 
different actions.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Dot can DWIM without whitespace

[Nathan Torkington]

Edward Peschko writes:
> I think its really time to have a vote on this, I think that all
> that has been said about this issue has been said...

It's definitely not time for a vote.  Larry'll take what's been said
by both sides and make a decision, just one of a zillion different
decisions that he'll make as part of his job as language designer.

Nat

Re: Dot can DWIM without whitespace

[Edward Peschko]

> > beautiful. Then extending this is simple, consistent, easy to read,
> > compatible with perl5..
> 
> I'm not sure that that was the point I was trying to make.
> If nothing else, the '.' would then be responsible for *three* 
> different actions.

Right, but what *I* am saying is that any given user is already conditioned to 
the fact that it can mean different things in different circumstances.

And like I said earlier, if we make $a . $b the only proper form for 
concatenation, I don't think that there is going to be much of a learning curve.
In any case, I like it better than yet another punctuation mark.

Ed

Re: Dot can DWIM without whitespace

[Casey West]

On Wed, Apr 25, 2001 at 07:23:47PM -0700, Edward Peschko wrote:
: On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote:
: > On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
: > > > Please, no. Some of us have to *teach* this language.
: > > Then I guess that either space sensitive '.' is the answer
: > 
: > Sorry. I'll try it again.
: > 
: > SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet?
: > 
: > Are you *really* willing to deal with hundreds of newbies who don't
: > understand why $a . $b isn't the same as $a .$b and isn't the same as
: > $a. $b and isn't the same as $a.$b? And do you realise what the only
: > "good" answer we can possibly give them is? "Because Ed said so".
: 
: Argh. 
: 
: The problem already comes up... '4. 5' is not the same as '4.5'. '.' is 
: *already* doing double duty as decimal mark. The fact that you don't see this 
: very often shows exactly how rare the mistake arises.

Perl 5:
print 4. 5 # error
print 4.5  # 4.5
print 4 .5 # 45

If you were to ask me, I'd say there is a bug in the last one, it
should be an error, .5 is a valid number.  ( PS, don't talk about my
opinion here, unless it is really relevant. )

: I think the 'tutorial' will come from experience. When the error that you get 
: from $a.$b comes up (and it should be a syntax error) you'll see exactly what 
: is wrong. If $a. $b, again, syntax error. Only $a . $b should be allowed.

It can't be a syntax error:

$a = Foo.new;
$b = "method";

print $a.$b( @params );

: The only point of contention would be if someone said $a . b, when they meant
: $a.b. And how often will that occur?

More often that you might think.  I see Perl folks who love white
space writing:

print
$cgi -> header,
$cgi -> start_html,
$cgi -> h2( 'my page' ),
$cgi -> hr,
$cgi -> a(
{ -href => 'http://geeknest.com' },
$cgi -> font(
{ -color => 'red' },
'My homepage!',
),
),
$cgi -> end_html;

In anycase, it happens frequently already.

-- 
Casey West

Re: Dot can DWIM without whitespace

[Edward Peschko]

> 
> More often that you might think.  I see Perl folks who love white
> space writing:
> 
> print
>   $cgi -> header,
>   $cgi -> start_html,
>   $cgi -> h2( 'my page' ),
>   $cgi -> hr,
>   $cgi -> a(
>   { -href => 'http://geeknest.com' },
>   $cgi -> font(
>   { -color => 'red' },
>   'My homepage!',
>   ),
>   ),
>   $cgi -> end_html;
> 
> In anycase, it happens frequently already.

Fair enough. Then how about '->' as a synonym for '.'?

Ed

Re: Dot can DWIM without whitespace

[Buddha Buck]

Edward Peschko <[EMAIL PROTECTED]> writes:

> > > beautiful. Then extending this is simple, consistent, easy to read,
> > > compatible with perl5..
> > 
> > I'm not sure that that was the point I was trying to make.
> > If nothing else, the '.' would then be responsible for *three* 
> > different actions.
> 
> Right, but what *I* am saying is that any given user is already conditioned to 
> the fact that it can mean different things in different circumstances.
> 
> And like I said earlier, if we make $a . $b the only proper form for 
> concatenation, I don't think that there is going to be much of a learning curve.
> In any case, I like it better than yet another punctuation mark.

I see, and you would be willing to break the cases where I may want to
put spaces around the . used for method invocations for clarity?

{
  

  $foo . foobar ("Test1");
  $foobar  . baz("Test2");
  $tmtowdi . quux   ("Test3");

  
}

That specific use of whitespace I don't do often, but I could see
doing it.  I often do something like that when working with other
variable length identifiers.

> 
> Ed

Re: a modest proposal Re: s/./~/g

[Graham Barr]

On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
> It seems to me that ~ relates to forces (operators, functions and methods)
> more than to atoms (scalars), so to speak.  It's the curve of binding Perl
> at work here.
> 
> So why not leave  .  alone and have  ~  substitute for  ->  
> 
> $mydsn->Sql("$mysqlstmt " . $moresql) ;
> $mydsn~Sql("$mysqlstmt " . $moresql) ;
> 
> Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?

Yes, I use it a lot. Whether you use it probably depends on the kind of
problems you try to solve with perl.

Graham.