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?
