Larry Wall wrote:
>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.
>
>
Oh! True!
But ~...
it's not has easy to type as '.' and not really visually nice (even if
outstanding)
>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.
>
>
>
I guess there's a need to write some long programs in order to see.
>>>>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. :)
>
>
>
Well I will rewrite all my little mvc framework in perl 6 with
all the new oop features that should make my code cleaner.
It is the best occasion to get dirty a little!
But when you say that a language has to copy other languages
at the beginning to get accepted, I really think it is true.
On the other hand, even if perl 5 is widly accepted
(unfortunately not that much in entreprise context due to CPAN phobia)
and that perl 6 gains a lot from its ancestor,
it is still a new language with a lot of new grammars
If I were to start programming should I start with perl 6 idiomatic
construct or with a language implementing very common construct
other languages?
That's why I was wondering the necessity of all these new grammars
when seen from teaching or trying to learn the language
and especially if you are not a english native speaker.
I really think that perl6 has really neat features
and I am pretty much that it will allow me to become
a little better in programming .
>>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.
>
>
OK
>
>
>>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.
>
>
I have choosen $*IN like I could have choosen a user definer global
variable.
my example was doomed to confusion, sorry.
>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.
>
>
That's a good design principle!
>
>
>>>>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.
>
>
Well, i guess it's fortunately! if we were to learn all the pictograms from
Japan or China, this would be a pain!
>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.
>
>
>
Good explanation, thank you! I'll keep that in mind!
>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".
>
>
In japanese it could even be :
wa {
'' no baai ni { ... }
}
Getting rid off the thema or I guess here taking $_ as the default.
is this possible :
given $operator {
'' {}
'' {}
}
?
>
>
>>>>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 は、頑張って、よ！ ^_^
>
>
Perl 6 、応援するよ！応援するからいろいろ知りたいんだ！
頑張れ、Perl 6!
This is funny because in your Japanese sentence Perl 6 sounds like
a human entity.
Thank you all for your explanations!
I guess I will be able to use this new grammar with more confidence
and if I were to explain why, I could!
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
