RCR Review by Peers

T

T. Onoma

I've nearly finished my RCR -- the big one on Uniform Data Structures I've been sitting on for years. I'd very much appreciate if others would look at it and comment, so i can be sure to nail it down before submitting. [ or bail if need be :) ]

It is at: http://www.rubygarden.org/ruby?DoNotPassGo

Thanks,
-t0
 
G

Gavin Sinclair

I've nearly finished my RCR -- the big one on Uniform Data
Structures I've been sitting on for years. I'd very much appreciate
if others would look at it and comment, so i can be sure to nail it
down before submitting. [ or bail if need be :) ]

Well, good attempt at putting together a comprehensive RCR, but I just
don't see the point of what you're proposing. Most comments you made
about the proposal are value-neutral (e.g. simplifies language) rather
than giving a positive reason to embrace the proposal. I don't think
the ideas would make Ruby better in an identifiable way.

Cheers,
Gavin
 
R

Robert Klemme

T. Onoma said:
I've nearly finished my RCR -- the big one on Uniform Data Structures
I've been sitting on for years. I'd very much appreciate if others would
look at it and comment, so i can be sure to nail it down before
submitting. [ or bail if need be :) ]

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.)

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.

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.

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.

Kind regards

robert
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top