in reply to perl5 vs perl6

These are the major basic differences that I have seen, in no particular order:

That last is the most important item. This means that any two languages that compile to Parrot will be able to use each other's code seamlessly. For example, let's say you really want to write some class in Ruby because Ruby r0x0rs the OO world. But, you really need to use it in this Python library you have already written. Oh, and now the boss wants you to take that Python library (using the Ruby class) and hook it into the webapp you wrote using Perl. Oh, and it has to communicate with the foobarbaz that has the Java client already working, but nothing else.

Not a problem. :-)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^2: perl5 vs perl6
by blazar (Canon) on Jan 06, 2005 at 18:42 UTC
    Continuations. While most solutions won't need these, those that do need them.
    Well, since you brought up continuations, another item I feel like adding to my randomly selected list amongst the many randomly selectable ones is 'hypotheticals'. Perl6-ese for local is temp, so far nothing new. But there will be let as well, and it will behave like temp except that the value of the variable at the exit of scope will be retained or discarded in favour of the previous one according a condition. I'm not really sure about the exact syntax/semantics, sounds interesting though!!
    Perl will compile to Parrot opcodes.

    That last is the most important item. This means that any two languages that compile to Parrot will be able to use each other's code seamlessly.

    Not only!! It seems that Parrot will indeed be able to run natively bytecode for other virtual machines (this is rumored to be a side effect of the planned compatibility with a game-oriented VM).

      let is like temp but it's only useful inside of rules. If the rule succeeds, then the variable keeps the hypothesized value. If the rule fails, then the variable loses its hypothesized value and thus reverts back to whatever value it had before (if any).

      This is all as far as I know anyway. But then, things I thought I knew about rules have changed at least 2 times since I learned them, so who really knows anyway? ;-)

        let is like temp but it's only useful inside of rules. If the rule succeeds, then the variable keeps the hypothesized value. If the rule fails, then the variable loses its hypothesized value and thus reverts back to whatever value it had before (if any).
        I've quickly searched around and indeed it seems to be so. That is, let is to be used in closures embedded in rules.

        Due to the deep analogy between rules and subs I wonder wether the same mechanism could be made to work also for the latter ones (using the return value for success): I do not see any immediate use, but I bet someone could find one.

        Well, however this is probably not best discussed here...