On Sun, 22 Sep 2002, Markus Laire wrote:
> > On Sat, Sep 21, 2002 at 11:36:49AM -0600, John Williams wrote:
> > > On Sat, 21 Sep 2002, Jonathan Scott Duff wrote:
> > >
> > > Anyway, (7) or (3+4) should yield a number, not a list, because
> > > otherwise every math expression will break.
> >
> > Why can't perl be smart enough to figure out what we mean? Something
> > along these lines:
> > (7) # list context
> > (3+4) # numeric context (there's a numeric operator in there)
> > (3+4,5) # list context (comma trumps the numeric op)
>
> It would be a total nightmare to try to DWIM in this case, especially
> with userdefined operators or more complex expressions.
>
>
> There are 101 reasons why parens shouldn't make lists and how it can
> make mathematical expressions do something totally unexpected.
>
> Consider changing a program where you have many mathematical
> expressions.
>
> $x = $y / (($a + $b) * $c - $d);
>
> If you later find out that $b or $d can be left out, I expect to be
> able to just remove it without need to check if any parentheses now
> contains only one value, and then to remove parens also.
You know, the idea that square brackets are the only things that can make
lists is starting to really appeal to me. Similar for squiggles and
hashes. I don't know how many times in my early Perl5 days I did this:
%colors = {
red => 'ff0000',
green => '00ff00',
... };
By looking at it, it seems to make perfect sense. I don't even know what
it does, but it wasn't WIM. How can a hash have only one element?
Since we now have an explicit flattening operator (unary *), there's no
need to differentiate between a "real" list and a reference to one. We
could extend it to sub calls:
print["foo ", "bar"];
But that would look like Mathematica, which would be creepy. It would be
good to keep parens in sub calls (and declarations), but the details on
how that unifies are wrinkly. Of course, they were never ironed anyway:
print "foo ", "bar";
So parens really do provide grouping, not list constructing. Thus, this
can stay:
print("foo ", "bar");
It also provides a really nice visual clue: If and only if you see [],
there's a list creeping around. Before, the "and only if" could not be
included.
Sure, it's not clean yet, but I presume it could be. Objections?
Suggestions? Obsessions?
Luke
