OpenEuphoria

Re: Modular Euphoria

• Posted by Pete Stoner <stoner.pete at gmail.com> Jan 11, 2007
• 503 views

Matt Lewis wrote:
> 
> ags wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > But you might write some C code that uses the Eu-headers, and manipulates
> > > eu data directly.  I'm planning on doing that with the next version of
> > > wxEuphoria.
> > 
> > Maybe not a good time to introduce a completely new topic, but you triggered
> > something I was thinking of recently while perusing the C backend code...
> > 
> > Except for the purely DOS interpreter, would it make sense to start
> > modularising
> > some of the code of the entire interpreter?  Perl for example uses
> > libperl.xx.so,
> > perl5.dll etc for the actual interpreter (I think) and the XS mechanism
> > farms
> > a lot of "core" code out to shared libraries (or a similar concept).
> > 
> > With Euphoria on Windows and Linux is it feasible to have say an exw.exe/exu
> > which is runtime linked to (eg) eu_backend.dll/so etc?
> > 
> > What you mentioned had me thinking, what about an (eg) eu_types.dll which is
> > linked by Euphoria as well as C code wanting to manipulate Euphoria objects?
> > 
> > Is that moving too far away from the tight hand coded speed of Euphoria?
> > 
> > I can see advantages with for example linking the interpreter into a larger
> > program, using the syntax highlight dll, or even the scanner and parser for
> > Euphoria related projects (like IDEs etc).
> > 
> > But then, the disadvantages of maybe losing quite a lot of efficiency, and
> > possibly
> > making the code harder to maintain?
> 
> I think we need to figure out what we'd want to accomplish with the 
> modularization.  Just splitting the backend into a dll/so could be 
> fairly easy, to the point of a change in the linker commands.  But I'm
> not sure about the benefit of that.
> 
> snipped 
> Matt

I would be against splitting. One of the big reasons I originally liked EU was
that by doing a bind I could ship a single executable

PeteS