On Mon, Dec 03, 2007 at 07:30:53PM +0900, cdumont wrote:
> Moritz Lenz wrote:
>
>> cdumont wrote:
>>
>>> 1- $str1 ~ $str2
>>>
>>
>> The '+' suggests numerical addition (and requires disambiguation in the
>> case of $str + $number - should $str be interpreted as a number, or
>> $number as a string?).
>>
>> The . is already taken by method calls (used far more often), and is
>> easy to overlook when concatenating strings.
>>
>
> Yeah, that's what I thought about the use of the dot for hashes and objects
> but hash or object :
>
> $obj.method();
> or
> %hash.value();
>
> which is visually different from :
>
> $str.$str2
>
> as the concatenation keeps the sigil.
>
> I am not a huge fan of the + operator either but
> well, why add a third type when the dot could be just fine ?
Because it wouldn't be just fine. Even in Perl 5 we have $obj->$method,
so if you're going to allow indirect methods and use . for method calls,
$a.$b has to be an indirect method call, not a concatenation.
In general, one of the design principles of Perl 6 is that we never
overload operators to do very different things, because even if we can
think of a way to finesse it right now, it has a negative impact on
both extensibility and readability. It impacts extensibility because
you leave yourself no "wiggle room" in the grammar for future changes.
It impacts readability because you have to stop to consider the context
to decide which operation is going to happen.
This is why Perl 5's x is now split into x and xx, for instance. Though
Perl 5 got some things right, by this principle. We never made the
mistake of confusing addition with concatenation. Not only is
concatenation not numeric, it's not even commutative!
> 2 ways are already more than one.
If you're doing 3 very different things, then doing it 2 ways is
suboptimal. Things that are different should look different.
Also, keeping operators in 1::1 correspondence with operations gives the
optimizer the most chance to figure things out at compile time without
having to know types at run time. (An oversimplicifcation, I know,
especially given how Perl 6 does multiple dispatch on operators at
run time.)
Nevertheless, most of the overloading of operators historically has
been to avoid using up the ASCII sequences, and now that we allow
users to define Unicode operators, that artificial pressure has mostly
been removed.
That being said, there's still contention for the short ASCII
sequences, and you shouldn't assume that any Perl 6 operator is
what it is for a single reason. Generally, most of these operators
have four or five reasons for being what they are, and some of those
reasons relate to what has already been taken by other more important
operators. Plus there is consistency with the rest of the language,
where ~ generally indicates some kind of string operation.
>>> 2- $life = (!$monster) ?? 'safe' !! 'dead';
>>>
>>
>> is it true??? really??? then you're safe. if not (! is not), you're
>> dead. PWND.
>>
>> Again I think that a visually outstanding operator simplifies reading.
>> It's really easy to overlook a single ':', as it's used in p5.
>>
>>
>
> You are right, that is outstanding but again, so many languages use
> a standard ? :
Languages copy all sorts of suboptimal features from other languages.
After all, that's how Perl 1 got ?: from C. That doesn't make it
right or wrong, merely convenient to learn. Learnability has always
been a secondary goal in Perl 5, compared to expressiveness, which is
a primary goal.
When a language is first starting out, it *must* copy a lot of bad
constructs from other languages, or it will not easily be accepted (see
Icon for a sad example of this). With the wide acceptance of Perl 5,
we have the opportunity to use that as a cultural basis for change.
It remains to be seen whether we can succeed with that, but most of
the signs are positive. Most people only panic about once when making
the mental switch from Perl 5 to Perl 6.
But if you want to panic once per operator, that's okay too. :)
> To make it outstand a little bit more :
>
> $life = (!$monster) ?? 'safe' |(^0^;)| 'dead';
>
> But might take some time to get acoustumed to it...(just kidding)
Sure, if we used |(^0^;)| elsewhere in Perl 6 to indicate false
things, but we use ! elsewhere for that, along with ? for true
things, so the ??!! falls out of that naturally. Also, it fits
better with the other short-circuit/control-flow operators that
are spelled || and &&. Plus ? and : are important short sequences
that should not be wasted on something as unimportant as the
conditional operator.
Most of this reasoning is spelled out long ago in Apocalypse 3,
though the switch from ??:: to ??!! came later.
> But if we want to choose the visibility key then
>
> $*IN
>
> is not what I will call something especially visual even if
> it's not that awful (well, depending on the keyboard this can be a reall
> pain though)
I don't understand your complaint here. It's not control flow. It's
just a variable that comes premarked as a scalar global. You might
typically use it once in your program, or not at all. And it seems
to stand out more visually than STDIN in any case, and if you didn't
memorize the list of magical globals in Perl 5 you wouldn't know that
STDIN is global to every package. This falls out naturally from $*IN
without you having to memorize a list of magical identifiers.
This is another design principle in Perl 6. Where Perl 5 requires
you to memorize a list of exceptions, it's probably designed wrong.
That's why all nonalpha characters are now considered metacharacters
in regex, for instance. You don't have to remember which ones are
and which ones aren't.
>>> 3- given $operator {
>>> when '' {}
>>> }
>>>
>>
>> ...
>>
>>
>>> The given ... when doesn't seem to bring that much from switch ... case
>>> given ... if would make a little bit more sense.
>>>
>>
>> I don't know the rationale about that, but perhaps it's to distinguish
>> given-when (which uses smartmatching) from other languages that just do
>> string or number comparison.
>>
> I am not native so I do not really know either but I don't feel comfortable
> with profusions of different keywords in languages...
> why not a :
>
> pour $operator {
> lorsque '' {}
> }
Because I speak English, and fortunately or unfortunately, English is
the lingua franca (ironic, I know) of computing.
As for given/when vs switch/case, this is yet another rationale that is
given long ago in Apocalypse 4. In short, another language design
principle is that in natural languages you don't name your syntactic keywords
by noun indicating the kind of construct, so we shouldn't do it in
computer languages either. The programmer should be thinking about
the problem, not about the language. Saying "I am a switch statement,
and here are my cases" is drawing attention to the language, not to the
solution of the problem.
Since you're in Japan, you should know the importance of topicalizers.
I actually considered (very briefly) some postfix notation like:
$operator wa {
'' no baai ni { ... }
}
before settling on the English topicalizer "given" and pronoun "when".
>>> And hashes require '=>' but it could be nice to switch to ':'
>>> because then :(or perhaps we can use whatever separator we want?)
>From Apocalypse 1:
Larry's 1st Law of Language Redesign: Everyone wants the colon.
And its corollary:
Larry's 2nd Law of Language Redesign: Larry gets the colon. :-)
> our work is the portrait of ourselves
Indeed. And people find me confusing at times. :-)
Perl 6 は、頑張って、よ！ ^_^
Larry
