Hello Ara.T.Howard,

ATH> On Fri, 27 May 2005, Lothar Scholz wrote:

ATH> i think things like
ATH>    j = (char (*)[20]) malloc( 20 );
ATH> and
ATH>    char * const *(*next)();
ATH> and
ATH>    int (* foo())[]

ATH> take a considerable amount of time to read - at least for me.

Taking a specific not very good implementation might not be a good
argument for or against a general feature. If you have choosen Eiffel or even
lisps (the ....) code, the type declaration might look much better.

And when i say optional i don't mean to document each type. 90% of the
types are simple class names (yes i know many rubyists don't like it
to call classes types).

ATH> in the end i've decided that there are only two reasonable forms of typing:
ATH> dynamic (a la ruby) or strong and automatic (a la ml langs).  other kinds are
ATH> evil IMHO.

I like Lisp. Sometimes at least.

ATH> that being said i'm not against optional typing - but coding the compiler to
ATH> understand all of them can be tricky unless it's just simplistic.  eg.  how
ATH> would you like to declare, in ruby, a that takes a string parameter, and a
ATH> hash of strings to arrays of int as args?  and, if you would only say 'proc' -
ATH> then what good is that typing system?

I don't want a (complete) typing "system". If it gets complicated
change your app or don't use the optional type hints.

If my IDE could use it or the YARV JIT-Compiler could produce more productive
code for some methods it is enough.

I think that step of pragmatism is what very very few people until now
really understands. Maybe it takes a few years of Lisp experience to
see the value of typing hints.


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's