RCR Review by Peers

[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: [url]http://www.rubygarden.org/ruby?DoNotPassGo[/url]

Thanks,
-t0

[Gavin Sinclair]

On Monday, November 17, 2003, 6:48:19 PM, T. wrote:

> 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: [url]http://www.rubygarden.org/ruby?DoNotPassGo[/url]

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

[T. Onoma]

Gavin wrote:

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

thanks Gavin, i'll work on improving it in the positive manner you've suggested. (break out the lisp docs here, since in essence the flexibilities of lisp's uniformity is what i'm suggesting to embue to ruby)

-t0

[Robert Klemme]

"T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
news:E1ALe7I-00016k-AI@odie.runbox.com...

>
> 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: [url]http://www.rubygarden.org/ruby?DoNotPassGo[/url]

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

[T. Onoma]

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

[Yukihiro Matsumoto]

Hi,

In message "RCR Review by Peers"
on 03/11/17, "T. Onoma" <transami@runbox.com> writes:

|It is at: [url]http://www.rubygarden.org/ruby?DoNotPassGo[/url]

Please include what we gain by your RCR? I don't see the benefit at
all, but tweaking syntax.

matz.