Re: Eu Rebellion (was: New Euphoria Users Website)
On 0, David Cuny <dcuny at LANSET.COM> wrote:
> Matthew Lewis wrote:
>
> > However, if we produced working interpreters that we
> > all found useful, we might be able to demonstrate the utility and
> > effectiveness of the changes, plus giving Rob a leg up on the official
> > implementation.
>
> Having written several preprocessors and even a Euphoria interpreter, I
> disagree. Robert's reaction to most of my stuff was along the lines of
> "That's nice, but it won't happen in Euphoria." Which is, of course, entirely
> his perogative.
Seeing what I have so far, I'd have to agree with David.
>
> I don't think that people will start using alternative interpreters, either.
> Not just because they are crippled, but because there is no guarantee for
> future compatibility. The fear that a product might become unsupported is
> pretty powerful.
Very true. This doesn't explain lack of use of preprocessors, but
alternative
interpreters do have the risk of falling behind. Hence, people will not
flock
to them easily. It doesn't help that we're not allowed to share the
source
code.
>
> Despite all the GUI toolkits, Euphoria is still a DOS application. Anything
> extention beyond that has been developed by the users, and isn't officially
> supported by RDS.
True. Except for c_func/c_proc and friends, and a few misc functions
(like free_console(), or message_box()), its mostly DOS based. (Notice
that
Rob won't add more to the Win/Nix versions, such as Windows graphics to
graphics.e, but once DID offer to enhance certain elements of the DOS one
from Juergen's long-file name lib. (Then again, that might be little more
than a bug fix for the DOS file handling routines, in which case even
the DOS version has stalled, not suprisingly.)
>
> The tools for interfacing Euphoria to the Windows or GTK libraries are about
> at the level of assembly code (except assembly supports structures). The
> Euphoria editor is a DOS application, and the trace under Windows is
> basically a console window (which is why it runs so slowly).
>
> I'm not saying this is a bad thing. That's just the way it is, and I don't see
>
> any reason to think it will change in the near future.
>
> -- David Cuny
>
It won't. Not with the current situation. However, I plan to try to
create an
open-source POSIX compliant Exu. Perhaps that may inspire more users.
(Open
source, should it ever be unsupported, can easily be taken up again by
someone
else.)
jbrown
--
|
Not Categorized, Please Help
|
|
