[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: RCR Review by Peers

T. Onoma

11/18/2003 9:06:00 AM

thanks robert for taking a look!

robert wrote:

> Hm, it's not totally clear to me what you are up to and what would be
> gained. From what I understand you're aiming at unifying the syntax for
> various different things, namely method invocations, operators and all
> sorts of type definitions (class and method mainly). (All following
> comments are based on this understanding.)

yes, i need to flush out then explination more. its difficult while trying to be concise at the same time.

> Since we're talking about programming languages there are technical and
> human apsects here. It might be technically feasible to unify all those
> constructs but the price is likely that certain things are deferred from
> compilation to runtime: if there's no syntactic difference between a class
> definition and a method invocation then the runtime types of the artefacts
> involved determines the semantics. This may well impose a performance
> penalty.

on the whole i think there's enough distinction. for instance, a class is named with a captial letter. so obviously its a class (or a module). while there may be some perforamnce lost in this reagard, there may also be some gained from the simplicity and commonality of underlying data structure.

> The human aspect is twofold: while it may be simpler to *write* programms
> it is likely to be much more difficult to *read* program code.

this wouldn't be a problem. one of the things i need to make clearer is that most of the current syntax we all love is still there. its just that it becomes sugar to the generalized forms. so the code is just as easy to read. and atually doesn't change that much.

> And a third aspect: while reading your RCR Lisp came to my mind even
> before you mention it yourself. It's not clear to me where exactly is the
> difference between your proposal and Lisp's approach. If it is too small
> I wonder what will be gained by yet another Lisp language.

in a manner, that's the idea: to give ruby the full benefits of lisp, but more so, because ruby has many constructs that lisp does not or cannot. and ruby of course has a much more readable syntax.

thanks for the feedback, i work on addressing these issues.

-t0