OpenEuphoria

Re: Rob?

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
• 477 views

Jason Gade wrote:
> > I'll grant you that you've answered 1 and 4, (though
> > the only person you referred to in 1 found a workaround,
> > and is "not demanding" a change to the language).
> > However I don't think you've provided a solution that
> > answers both 2 & 3.
> 
> 2. Just compare the include string. If it is the same, then it is the same
> file.
> If it is not (different path) then it is not. Whether or not the file is the
> same, if global symbols conflict then it is an error and the include either
> needs to be namespaced or fixed. Local symbols are still unique.
> 
> Again, this is just aesthetics on my part and definitely not extensive
> experience
> in programming language design. It seems to be pretty easy to change.

Well, you have a very simple solution, but it's not the problem
Vincent was trying to solve. It would also cause every existing 
Euphoria program that has two different representations of the
path to the same file to break. e.g. include graphics.e
and include \euphoria\include\graphics.e or include mylib.e
and include .\mylib.e

Coming from a C background, my bias is to avoid including things
twice. If you look at a really large C program, you'll see that
they've invented ugly methods of preventing
the same file from being included twice. They define artificial symbols,
and then check if the symbol has been defined, if so, #ifdef around
the rest of the file, else include it, yada yada yada...
If you do include something twice, you get an avalanche of
error messages.

Please let me put this issue aside for now, and move on to more 
interesting enhancements! 

> So, when can I start bugging you to support mingw (basically a Windows version
> of gcc) and let routine_id
> to have forward referencing? 
> 
> PS Seriously, you support DJGPP and gcc already, how hard would it be to
> support
> mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support
> many different compilers but I'm not sure how different mingw is from gcc. I'm
> sure there are differences between it and DJGPP.

What would you do with mingw that you can't do with Borland or Watcom?

It would take me a month (initially) to support a new C compiler,
and there are already three for Windows that you can pick from.
Most users don't care about C. They just want to translate/compile/run.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com