Scheme is a great language. It inspired me more than 16 years ago, influenced my
early designs... and got me into denotational semantics.
But, Scheme was first invented in 1975... so now 25 years later, I suggest that there
is a good reason why it is not in widespread use today.
REBOL 1.0 was "Scheme". So we've been there, done that. For us, it was a disaster.
REBOL 2.0 (non Scheme based) is smaller and 30 times faster. Yes there are some cool
things you can do in Scheme. But they cost you too much.
Unfortunately, history has also proven the success of a language has nothing to do
with the merits of good language design. Look at C++, BASIC, or even HTML as examples.
-Carl
PS: the scoping rules for REBOL are very simple. Also, the issues around object
scoping have not been solved by any language that I know. Not even Scheme.
At 6/16/00 03:30 PM -0500, you wrote:
>
>Good thoughts, Chaz. I think, though, dialects would not be a particularly
>helpful. Scoping rules are deeply intrinsic to programming languages and their
>implementations. I doubt the problem could be fixed while preserving backwards
>semantic compatibility. However, the world of Rebol scripts still to write is
>much larger than the world of scripts already written, so now would be the time
>to make any fundamental changes.
>
>The current discussions of weirdnesses, idiosyncracies, and so forth related to
>scope, garbage collection, protection via USE, etc. are all verging around the
>same space. With no disrespect intended to Carl or anyone on the Rebol team
>(they're certainly tracing historical mistakes, Cf. McCarthy's early probs.
>nailing the scope issue in Lisp) there is at lease one good system, very similar
>in many ways to Rebol, from which they could steal liberally: Scheme. It's
>lexically scoped, has first-class closures which are in essence a stronger, more
>formal block, a fundamental symbol / object distinction, and GC... *very*
>similar to Rebol indeed, but with a unified formal approach to scope, GC, and so
>on. It's a beautiful, simple, and powerful language that has never really gone
>mainstream due to its Lisp-like legacy and syntax, which most folks don't grok.
>IMO, Rebol could easily be the Scheme for the masses... but every little
>idiosyncracy and gotcha -w- scope, GC, and so on will create adoption friction.
>
>Unsolicited $0.02,
>
>jb
>
>[EMAIL PROTECTED] wrote:
>
>> At 07:34 AM 6/16/00 +0200, you wrote:
>> >
>> >
>> >[EMAIL PROTECTED] wrote:
>> >
>> >> Just a thought.... most of the "philosophical" questions / discussions
>> here
>> >> about i.e. object lifecycle, scope, bindings, etc. would be simply,
>> >> formally, and workably solved if Rebol had a true lexical scoping model.
>> As
>> >> it is, it's sort of the worst of both worlds: it's semi-fluid scope with
>> >> explicit manipulation coupled with a sort of hybrid object / object
>> >> lifecycle model that is never really formally elaborated. Without knowing
>> >> the internal nitty gritty of the implementation, it's hard to say if
>> this is
>> >> endemic to Rebol or not, but looking at i.e. the potential solutions to
>> >> similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of
>> >> good reasons for solving the problem now.
>> >
>> >Just a note - isn't it too late, if two book on REBOL are already finished?
>> >Elan, Ralph? :-)
>> >
>> >-pekr-
>>
>> Not too late, if solution is implemented correctly. Since the strength of
>> Rebol is dialecting, then we should maintain backward compatibility through
>> dialects. Rebol/Core 2.x scripts would not break if there was a "2.0
>> dialect" included with Rebol/Core 3.x.
>>
>> RT needs more staff and money, so Core team can focus on philosophical
>> issues, and special task forces can focus on integrating Core with other
>> technologies (Graphics = /View, OS and Databases = /Command, WebServer =
>> /Apache).
>>
>> By overcoming implementation challenges, the task forces gain knowledge
>> that they can bring back to /Core that will empower RT to overcome new
>> challenges when integrating into other technologies (imagine
>> multiprocessing = /Beowulf, Home Automation = /Base, streaming media and
>> telephony = /Yell)
>>
>> But the real money may be in business-to-business. Imagine your company has
>> developed an incredible software product whose functionality can be
>> extended through use of a C API. Users would much rather have an easier
>> means than going through a write-compile-test cycle to extend the product's
>> functionality. If Rebol was integrated into the product, then user
>> productivity would skyrocket.
>> Case in point, Remedy Corporation has a workflow product called Action
>> Request System (ARS). The 2 means of accessing its power are through a GUI
>> and the ARS C API. At the State University of New York at Buffalo, users
>> created ARSPerl, a perl module that encapsulates the function of the Remedy
>> ARS C API. To my way of thinking, they turned to Perl because RT wasn't
>> there to save them. What other opportunities might RT missing?
>
