From: Nikodemus Siivola Date: 2002-09-29T20:40:27+09:00 Subject: Re: R On Sun, 29 Sep 2002, Mauricio Fern�ndez wrote: > * be compiled: at the beginning simple translation to C would make it Definitely. > * be less dynamic than Ruby: closed classes. > That way method lookup would be faster. Hear, hear! > * have no GC, or at least have one separed from Ruby's main one. > Important as the object model would be different. Hmm. I would personally be loath to not have a GC. > * have lower-level classes (perhaps as literal values) for low-level > arrays and such stuff, thus having C-like types wrapped in real > classes (otherwise we end up with C w/ different syntax) Hmm. One thing I would really like to keep is "everything is an object". > * perhaps be statically typed? (but types could be inferred so it feels > more like Ruby, by not having to declare them always) Definitely. Implicit tyoping is propably the way to go where variables are conserned. OTOH I would think that having only one return type per method, and knowing that and the argument typed when compiling we could drop variable typing. So: def Float square(Float x) x*x # Implicit returns are nice, for one liners' at least. end a = 2.0 # Need a literal float here? Or do we cast? b = (square a).to_s # We know b will be a String. > It could also be procedural (not OOP), but being able to create classes Hmm. I was definitely thinking OO. For first draft maybe without inheritance, to sidestep all the method lookup issues and avoid complexity in the beginning. > * allowing generic programming (so we don't miss Ruby's dynamic > typing too much) What do you mean by this? Like so? def Boolean compare(Comparable a, Comparable b) a == b end > Things to throw away: > * high-level classes such as Array, Hash, Class, etc (in fact (almost) > all of Ruby's!) The existence of Class would depend on the class model, but getting rid of Array and Hash sounds like a bad idea: the lack of such is 90% of the pain of C. -- Nikodemus