Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by jbrown105 at speedymail.org Nov 15, 2002
- 467 views
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 --