Re: SF.net SVN: fricas:[879] trunk
Ralf Hemmecke
Do you have any explanation of the ")package" command? Where is it
documented?
Ralf
Waldek Hebisch
')package' is ignored by old Boot. In Shoe (need Boot) it gives name
of the Lisp package where generated code will live (for old Boot it
is always "BOOT" package).
The change is part of changes needed to compile whole interpreter
using Shoe.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> of the Lisp package where generated code will live (for old Boot it
> is always "BOOT" package).
Thank you.
> The change is part of changes needed to compile whole interpreter
> using Shoe.
As far as I understand, Shoe is a better Boot. So code is getting higher
level language.
For me the interpreter should only be parsing the input, do some
coercion resolution and manage the session data.
Wouldn't it eventually be possible to exclude the interpreter code from
the build procedure and have it written as a n ordinary SPAD package (of
course calling a well defined lower level API to do compilation etc.)?
That would be wonderful.
Ralf
Waldek Hebisch
> > of the Lisp package where generated code will live (for old Boot it
> > is always "BOOT" package).
>
> Thank you.
>
> > The change is part of changes needed to compile whole interpreter
> > using Shoe.
>
> As far as I understand, Shoe is a better Boot. So code is getting higher
> level language.
Well, in some aspects Shoe is higher level, in some is lower level
then Boot. One benefit of Shoe is that is discovered bunch of
doubious constructs which happened to "work" in old Boot.
Another possible gain is to remove support for old Boot from
'interp' directory, about 2-3 thousends of lines of code is specifially
to support old Boot.
> For me the interpreter should only be parsing the input, do some
> coercion resolution and manage the session data.
> Wouldn't it eventually be possible to exclude the interpreter code from
> the build procedure and have it written as a n ordinary SPAD package (of
> course calling a well defined lower level API to do compilation etc.)?
> That would be wonderful.
>
My plan is to eventually (say around 2030) have "interp" rewritten
in Spad. If you want to rewrite interpreter in Spad you can
start now. To be more precise, in "interp" directory we
have Spad runtime support, Spad compiler, browser (Hyperdoc) support
and interpreter proper. For browser and interpreter proper the
"only" problem is time needed to do the rewrite -- calling Spad
from Boot is not very nice but works OK and if you rewrite the
whole interpreter, then interface with other parts will be resonably
simple. For Spad compiler there is bootstrap problem, but it
is not very hard. The most tricky part is Spad runtime support,
some support routines will be in Lisp (or whatever our target
language will be). However, most of runtime support should be
written is Spad. This is tricky, because large part of runtime
support is handling domain/package initialization and function
calls. Given that all Spad code lives in domains/packages and
all nontivial code uses function calls, if you tried today
to rewrite runtime support in Spad you would get infinite
recursion. But I believe that small modification to Spad
compiler will allow generating code which runs with no
runtime support and such code can be used to implement
support routines.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Gabriel Dos Reis
| > > ')package' is ignored by old Boot. In Shoe (need Boot) it gives name
| > > of the Lisp package where generated code will live (for old Boot it
| > > is always "BOOT" package).
| >
| > Thank you.
| >
| > > The change is part of changes needed to compile whole interpreter
| > > using Shoe.
| >
| > As far as I understand, Shoe is a better Boot. So code is getting higher
| > level language.
|
| Well, in some aspects Shoe is higher level, in some is lower level
| then Boot. One benefit of Shoe is that is discovered bunch of
| doubious constructs which happened to "work" in old Boot.
and you would discover that the build infrastructure becomes a bit simpler.
And improving the compiler is also simpler. That is what happened in
OpenAxiom about 3 years ago. Other things need more attention, but
overall I think it was a win.
PS: since "Old Boot" disappeared from OpenAxiom, I did not feel that
keeping the unofficial "Shoe" was relevant -- I just call it Boot.
And it lives in src/boot :-)
PS^2: I am able to translate Boot to basic C++; but translating Spad to
very good AND higher level C++ is a bit trickier than I expected. This
matters only if you expect a human to read the generated code.
-- Gaby
Waldek Hebisch
> Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
>
> | > > ')package' is ignored by old Boot. In Shoe (need Boot) it gives name
> | > > of the Lisp package where generated code will live (for old Boot it
> | > > is always "BOOT" package).
> | >
> | > Thank you.
> | >
> | > > The change is part of changes needed to compile whole interpreter
> | > > using Shoe.
> | >
> | > As far as I understand, Shoe is a better Boot. So code is getting higher
> | > level language.
> |
> | Well, in some aspects Shoe is higher level, in some is lower level
> | then Boot. One benefit of Shoe is that is discovered bunch of
> | doubious constructs which happened to "work" in old Boot.
>
> and you would discover that the build infrastructure becomes a bit simpler.
> And improving the compiler is also simpler. That is what happened in
> OpenAxiom about 3 years ago. Other things need more attention, but
> overall I think it was a win.
For FriCAS build would simplify a bit, but given that current system
works and do not need serious modifications this is marginal gain.
OTOH simplifying compiler is much more important.
> PS^2: I am able to translate Boot to basic C++; but translating Spad to
> very good AND higher level C++ is a bit trickier than I expected. This
> matters only if you expect a human to read the generated code.
I want code which can be read for the purpose of debugging compiler,
but I do not want to spend effort to do better than that. In
particular I am statisfied with low-level code.
--
Waldek Hebisch
heb...@math.uni.wroc.pl