On 2008-Mar-19, at 1:40 pm, Mark J. Reed wrote:
On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
The use of + in Python or << in C++ is, I think, primarily the
violation of a *linguistic* principle, not a mathematical principle.
Maybe it's just 'cause I cut my teeth on BASIC, but + for string
concatenation has always felt pretty natural.
That's because it is natural. Kids don't have to be very old to get
the joke in "1+1=11". People just naturally think of "plus" or a plus-
sign as a synonym for "and". In a non-technical context, I bet we all
scribble down '+'s on notes and grocery lists, etc. to stand for any
of Perl's: + ~ , ; & &&. It's not that there isn't ambiguity, but
it's an ambiguity that we're used to dealing with in everyday life, so
it maps easily onto a programming language.
Not that I'm saying separate operators are a bad thing. When
programming, we do often have to mix numbers and strings in all sorts
of ways, so Perl's + and ~ are often a better match for the problem-
space. It may require marginally more effort to get used to than
BASIC's dual-purpose +, but I'm not sure even that's true, since we
really are used to distinguishing addition from concatenation, even in
grocery lists -- it's just that we humans are a lot better about
understanding context than machines are, so we implicitly translate
plus signs into one or the other on the fly.
(Actually, Perl6 allows for context in a way that earlier Perls
didn't: you can declare something to be a Num or a Str, and then a
single overloaded "+" would work; in the old days when scalars had
split personalities, you needed to specify the type some other way --
in the operator. Interestingly, BASIC has gone the other direction --
at least, Visual BASIC uses + for addition and & for concatenation;
I'm guessing this happened when VB got "variant" types that could hold
either numbers or strings.)
While I agree with the sentiment of not arbitrarily restricting
people from doing ugly things unless they ask for such restrictions,
Agreed... though I disagree that the sort of overloading under
discussion ("/" for separating paths) falls into the "ugly things"
category.
It's not ideal, but it's a fact of life. Slashes for path separators
are such a widespread custom that it would make as much sense to give
up slashes for division. (Actually, it would make more sense to keep
slashes for paths and switch to ÷ (U+00F7) because the "real" division
sign is at least as widespread for division, and isn't ambiguous in
all the other ways slashes are, such as random separators on grocery
lists.)
Whereas it is common to find addition and concatenation in the same
expression, it's very uncommon to find division and path-building
going on at the same time. Path-building plus string-concat'ing *is*
a likely and reasonable combination, though, so I would be against
using ~ for joining paths.
(It is tempting to want a leading "/" to start an absolute path, and
"./" to introduce a relative path, but those are ambiguous with regex
delimiters and a $_ method. (Although ./ could probably work by the
longest-token rule?) However, it's not a hardship to do something
like: io $foo/$bar, or io /$foo/$bar, where io() is an IO-object
constructor -- those example thus being: io($foo) / $bar, or io() /
$foo / $bar.)
The typical user already has a good notion of what the common
operators
are, and what they mean. So while drastically changing the meaning
of one of those operators may not be a disservice to the writer of
the code, it may well be a disservice to the reader.
Which is why I hope P6 defines "standard" symbols in the standard
way. (Where by "standard" I mean symbols that have a well-defined
popular meaning, e.g. ÷, ≤, ∈, ±, ¬. Well, and a meaning that's
useful to Perl... ♂ and ♀ are well-defined, but I don't know how
you'd use them in P6. (I guess they could be enums!))
I agree *changing* the meaning is bad. But the Good Kind of
operator overloading doesn't do that; it just adds a new meaning.
It really is "overloading".
Yup, again because "overloading" is natural to human communication.
And of course being so flexible about how to balance mapping onto the
way humans think vs. mapping onto the problem space is what makes P6
so delightful.
Which is why I like it so much more than certain of its brethren
with their Orthogonality Ueber Alles attitude. I just don't want to
see that sort of prescriptivity creep in to Perl.
(Unless it's predeclared, of course!!)
-David
