1. Modular Euphoria
- Posted by ags <eu at 531pi.co.nz>
Jan 10, 2007
-
Last edited Jan 11, 2007
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?
Gary
2. Re: Modular Euphoria
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.
As for going in the direction that perl took, I'm not sure how this might
work. I think there'd have to be a lot of redesign to make this worth it.
Maybe that's something for a 4.0 timeframe. What you're really asking is
for a straightforward way to extend euphoria as a language so that once
a module is installed, it's transparent to the user. This might or
might not even be desirable, since it will add to the tasks required to
get things to work. I can say that I've been frustrated by CPAN more
than once in trying to get something, only to find out that I needed
MSVC to compile some xs nonsense.
There are several routines that are useful for doing things with eu-data,
but they're kinda spread out right now.
Matt
3. Re: Modular Euphoria
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
4. Re: Modular Euphoria
- Posted by Gary Shingles <eu at 531pi.co.nz>
Jan 11, 2007
-
Last edited Jan 12, 2007
Matt Lewis wrote:
>
> ags wrote:
> > Maybe not a good time to introduce a completely new topic, but you
> > [snip]
> > 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?
> [snip]
> 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.
>
> As for going in the direction that perl took, I'm not sure how this might
> work. I think there'd have to be a lot of redesign to make this worth it.
>
> Maybe that's something for a 4.0 timeframe. What you're really asking is
> for a straightforward way to extend euphoria as a language so that once
> a module is installed, it's transparent to the user. This might or
Yep, thank for your opinion on that. I just thought I'd raise it as something
on the distant horizon :)
Gary
