Re: Re: Re: Re: NO PERL 6

[dbp]

Oh man. This ~= vs =~ should quickly catapult to the "most common dumb-ass Perl coding mistake" position when Perl 6 is released.

[theorbtwo]

Which is why the "smart-match" operator (what the =~ regex binding operator is changing to) is changing to ~~ when/if the concatination operator becomes ~.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[pdcawley]

Which is in turn why the recent thread dealing with moving operators around was one of the longest I've seen on perl6-language by quite some margin, and I don't expect anything to surpass it for a good while yet.

[BrowserUk]

I don't see this as any worse than the silent errors created by typing $f =~ $f when what you meant was $f = ~$f? Eg.

c:\test>perl -e "for $f ( @a = qw/0 1 2.3 fred . ''/) { print $f =~ $f
+, '-', $f = ~$f, $/; }"
1-╧
1-╬
1-═╤╠
1-ÖìÜ¢
1-╤
1-╪╪

Of course, it could compound the problem.

Personally, it seems that the search for an alternative to '.' for string catenation is avoiding the obvious choice for sake of not being "me too".

If the use of '+' and '+=' for this is undesirable for syntactic reasons, I wonder if its actually necessary to have a catenation char--why not simply use abuttment? Is there any situation when

$string = "dsadfkjasdkhakhds dhf sahd fsd "
          "sdshsa ashjashjas  asjhasjhasdh";

$str = 'Fred is ' $num " years old\n";

would be ambiguous?

For an alternative to $str .= $more how about $str "= $more;?

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[theorbtwo]

Larry recently addressed both these points. +, he thinks, would be a bad choice for concatination. I note even VB, which does use + as it's concat operator most of the time, has an & operator, for where it's unclear if you want to add, or simply concatinate two strings that happen to be numeric. Larry s Post

As far as using abjunctation as the concat operator (IE the no-operator operator), that "can never happen in perl", since there are quite a number of things that have different meaning if perl is expecting a TERM or an OP, and will only be more in perl6. I can't seem to find Larry's post on this, but for example, << as here-doc (term) vs. shift-left (op).

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[BrowserUk]

Of course you (and LW) are right. I can see the ambiguity in $ip = '192' + '.10' + '.10' + '.1'; for example.

The problem with abuttment is less clear to me. With a here-doc, doesn't the '<<' need to be preceded by '=' and followed by ';' which distinguishes

$var =<<"here"; from $var <<= 2;?

I did spend quite a while trying to find syntactic problems with abuttment of vars and/or string for catenation, and failed. The only place where I saw a particular problem was with print STDERR "string" ; versus print "string" "string"; where the (to me) strange syntactic choice of not just not requiring a comma after the HANDLE, but actually requiring it NOT to be there, causes a problem.

I guess I should read some more stuff by those that have been looking at the problem for a while rather than trying to logic it out for myself.

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[Abigail-II]

    print $fh $foo;

Should that print $foo to the file handle $fh, or print $fh . $foo to STDOUT? sort and exec are other function who may have an optional first argument that isn't followed by a comma.

Abigail

[BrowserUk]

Yup. Thats exactly the conflict I came across. I'm sure there is a very good reason for having an undelimited/space delimited optional first parameter, but it has always struck me as weird. It would be entirely feasible (I think) to check the first parameter to print and determine if it is a filehandle (either a direct or discuised one) and act appropriately?

I guess that in the case of a discuised one, this would mean that if you really wanted to print out the stringyfied version of $fh to standard out you might need to disabiguate the handle to prevent it be used as the target. Maybe print "$fh", 'other stuff'; or print +$fh "other stuff";. This seems like a rare enough occurance for the additional syntax to not be a problem.

I reasise that print $fh, 'stuff';<code> is slightly more verbose that <code>print $fh 'stuff';, but I nearly always have to go back and remove the extra comma that I type by habit when I get the "No comma allowed after filehandle ..." msg as it stands.

I'm not sure that there is any conflict with sort? Isn't the comma only optional if the first parameter to these calls is a bare block or subname? In which case, this would never be ambigous.

I see (now you've mentioned it) that exec can be used with ``indirect object'' syntax, which is another conflict, but I see that you can also use exec { $shell } arg-list; instead of exec $shell arglist;. Is there any situation where the former would act differently to the later? If not, would the deprecation of that latter be a bad thing?

Please note: I am only asking questions for my own curiosity. I am quite happy to leave the decisions to those with the knowledge and power to make them.

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[Abigail-II]

Hmmm, is that worse than += vs =+ and -= vs =- which is already possible in Perl (as well as in C and a bunch of other languages)?

Abigail

[John M. Dlugosz]

We don't need a concatenation operator at all. Just use the new-improved string interpolation: "$(expression-1)$(expression-2)". In fact, since most explicit cases of concatenation are for when interpolation isn't good enough (e.g. an expression not a single variable) this will take care of most of today's uses.

When you want to make it clear that you're concatenating something, why have a small syntax? Seems to me you are asking for big syntax, to emphasize the thing. So just use join with an empty first argument (no separate cat function needed.

—John

I started a new top-level thread here. This is already too deep!

Edit by tye to fix link

[Elian]

There wasn't there... something go wrong somewhere?