OpenEuphoria

Re: Eucom 2.05, namespace probs (sorry)

• Posted by Derek Parnell <ddparnell at bigpond.com> Dec 01, 2004
• 515 views

Chris Burch wrote:
> 
> Derek Parnell wrote:
> 
> <snip>
> 
> > > 
> > > I do not use the euinc environment variable, and copy all the win32lib
> > > includes over to my include directory, and have all the old tk_*.e files
> > > there too from old win32libs.
> > 
> > 
> > Not a clever idea, really. It is a *lot* safer to use euinc. I think that
> > one of the entries in euinc can be a 'relative' path to the current folder.
> > 
> >   set EUINC=.\include;
> >  
> > -- 
> > Derek Parnell
> > Melbourne, Australia
> > 
> 
> Ok, finally persuaded, converting to euinc now.
> 
> So why were you leaving again?

LOL, yeah its a slow process, no? 

But on a serious note, now that you've asked, ...

(1) I'm extremely tired of the way that RDS operates.

The way I read things is that Euphoria is a great language, and RDS is
pretty satisfied with that, to the point where it does not really wish
Euphoria to get any 'better'. In fact, its an oxymoron, in that Euphoria
implements RDS's programming beliefs and thus to change it would mean 
compromising the dogma. So the phrase "improving Euphoria" is seen as a
self-contradictory statement. Of course, I could be reading this all wrong.

So this forces me around to the next point ...
(2) To begin working on an alternative to RDS's implementation of Euphoria.

I may not succeed in doing this, as RDS has really done an excellent job
in creating a fast and stable interpreter for the language, but I'll give
it a go anyway. I really didn't want to do this, but as RDS has closed
any discussion, or option, of other languages using RDS's binder/backend
I feel there is no alternative for me. 

If I manage to produce an alternative to RDS's implementation, it will
mean that I can have an influence in improving my product. I will most
likely go the Open Source route once I have a viable prototype. Thus 
enhancement requests for the language can then be validated, costed,
discussed, scheduled, inspected, and implemented with open processes.

This may mean that my Euphoria implementation will diverge from RDS's one,
but that doesn't really worry me. It will be the 'customers' of these
products that ultimately dictate which implementation is successful.

To be fair, there are one or two other alternatives to RDS being worked
on by other groups. I'm not a part of those, though I have discussed
issues with them from time to time. When RDS gave out some hints about
what form v2.5 was taking, I abandoned the idea of alternatives as I 
thought the RDS was going to deliver a tool that I could use. But v2.5
has not lived up to my hopes for it, and RDS has a strong respect for
the status quo.

However, I'll be hanging around here with Win32lib support for about a
month after the next release, or until somebody else picks up the 
support role.

-- 
Derek Parnell
Melbourne, Australia