I've been trolling the Perl6 fora and reading the summaries since they began. More and more I get a horrid feeling of deja vu. When I was a student, Algol was supposed to be THE language to replace Fortran. Then Algol68 came out, chock-full of othogonal stuff and "thunks".
I tried Algol68: it was so cumbersome, it was useless. Admittedly many of those "new" concepts are now in modern languages. The problem was compiler technology and computer power. But Algol68 was not the language developers used. C is the language of choice. Fast, simple, amenable to elegant code. Moreover, C today is not the C I first learnt. The compilation sophistication of make files is awesum.
So I wonder whether all the wonderful intentions to use UNICODE and the labarynthine scopes and calling chains of multis (I dont really know how to describe that discussion), whether all this will make perl 6 into a slow cumbersome dinasaur. And to get it to work at all will need inelegant clunky code.
Perl 6 looks as if it will be unfit for todays machines, but useable in 40 years. But by then, it will be python or ruby or something else that is the developers choice, combined with something like a killer IDE.
I developed in used Algol68, C, C++ and Python. Maybe I can step in heer and make a few comments.
Thunking is basically allowing you to pass argument to a procedure WITHOUT any procedure type declarations. Kind of like a #define func() in C and a Template in C++.
However... thunking was allowed to be RECURSIVE and TYPELESS!!! (Try a recursive #define in C?? ;-)
Algol68 did not have ANY thunking because it was just too tough. Indeed Buroughs has to implement Thunking in special Hardware op codes for Algol60.
Algol68 was picky about coercing (known as casting in C) and had a hierarchy of coercing/casting rules:
soft-weak-meek-firm-strong as follows:
Context strength Allowed coercions
soft deproceduring
weak dereferencing or deproceduring, yielding a name
meek dereferencing or deproceduring
firm meek, followed by uniting
strong firm, followed by widening, rowing or voiding
The reason for this was to avoid having to specifically/manually coercing/cast with a type operator. eg in C you sometimes need to for a type change with something like (float)1, or *str to get a type char, or funct() to yield the return value.
C was nice because you had to do most casting manually, and so you knew exactly what type you were dealing with type coercing/casting. C++ is nice because you can define your own coercing/casting rules on classes.
In a strange sort of way Algol68 was kind of the "missing link" between C and and C++. For example, in Algol68 the coercing/casting rule for REAL to COMPLex could not be defined by the programmer, it was build into the compiler. In C++ the programmer has (almost) total freedom to define this casting rules, and even some context/syntax checking. In C, even to this day the coercing/casting from REAL to COMPLex must be done manually.
Python pains me because it is like Algol60 thunking all over again, but interpreted, not compiled. I dont want to be cruel, but it is kind of like turning the clock back 45 years to 1960. In python the "compiler" is impotent to pick up many "type" bugs at compile time (that in other languages would be simple syntax errors)
BTW: Python DOES have some nice stuff that I won't cover here... :-)
NevilleDNZ
BTW: Microsoft reinvented the word Thunking to describe running win16 programs on a Win32 subsystem. Stand by for Thunk64s on Itanium.
I think it's a little silly to worry about the performance of code that doesn't exist yet. Parrot, which does exist, tends to be much faster than Perl 5, Python, and Ruby.
Worry Later
[Reply | View]
Thunking is basically allowing you to pass argument to a procedure WITHOUT any procedure type declarations. Kind of like a #define func() in C and a Template in C++.
However... thunking was allowed to be RECURSIVE and TYPELESS!!! (Try a recursive #define in C?? ;-)
Algol68 did not have ANY thunking because it was just too tough. Indeed Buroughs has to implement Thunking in special Hardware op codes for Algol60.
Algol68 was picky about coercing (known as casting in C) and had a hierarchy of coercing/casting rules:
soft-weak-meek-firm-strong as follows:
Context strength Allowed coercions
soft deproceduring
weak dereferencing or deproceduring, yielding a name
meek dereferencing or deproceduring
firm meek, followed by uniting
strong firm, followed by widening, rowing or voiding
The reason for this was to avoid having to specifically/manually coercing/cast with a type operator. eg in C you sometimes need to for a type change with something like (float)1, or *str to get a type char, or funct() to yield the return value.
C was nice because you had to do most casting manually, and so you knew exactly what type you were dealing with type coercing/casting. C++ is nice because you can define your own coercing/casting rules on classes.
In a strange sort of way Algol68 was kind of the "missing link" between C and and C++. For example, in Algol68 the coercing/casting rule for REAL to COMPLex could not be defined by the programmer, it was build into the compiler. In C++ the programmer has (almost) total freedom to define this casting rules, and even some context/syntax checking. In C, even to this day the coercing/casting from REAL to COMPLex must be done manually.
Python pains me because it is like Algol60 thunking all over again, but interpreted, not compiled. I dont want to be cruel, but it is kind of like turning the clock back 45 years to 1960. In python the "compiler" is impotent to pick up many "type" bugs at compile time (that in other languages would be simple syntax errors)
BTW: Python DOES have some nice stuff that I won't cover here... :-)
NevilleDNZ
BTW: Microsoft reinvented the word Thunking to describe running win16 programs on a Win32 subsystem. Stand by for Thunk64s on Itanium.