OpenEuphoria

Re: Rob?

• Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
• 474 views

Robert Craig wrote:
> 
> 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

To use your own argument, how often does this happen unintentionally?  Even
when including multiple files (which should use namespaces for whatever files
*they* include)?

> 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! 

I'll drop it for now... I didn't expect to get anywhere with it anyway. I just
think that it could make for easier modularity or object-type programming to be
able to *intentionally* include a file more than once. Not exactly the same issue
as Vincent is arguing but useful none the less.

I think that Euphoria would behave *much* better than C in this respect.

> > So, when can I start bugging you to support mingw (basically a Windows
> > version
> of gcc) and let routine_id</font></i>
> > 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?

Have one less C compiler installed on my machine? I'm not translating anything
right now anyway, I'll just have to bite the bullet when I need to because you
don't support my favorite two comilers, mingw and digital mars. But there are
more important things than supporting every C compiler known to humankind. 
 
> 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
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

Thanks for replying.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
j.