RCR Review by Peers

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