epsilon-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [epsilon-devel] Questions


From: Luca Saiu
Subject: Re: [epsilon-devel] Questions
Date: Mon, 30 Dec 2013 02:46:16 +0100
User-agent: Gnus (Ma Gnus v0.8), GNU Emacs 24.3.50.2, x86_64-unknown-linux-gnu

On 2013-12-29 at 21:54, address@hidden wrote:

Hello amz3.  You wrote your name in a previous private message, but I
won't make it public without your permission.

> 1) What is the purpose of e0:value procedure?

It's not a procedure, it's a macro; this actually makes a difference in
the symbol case.

In epsilon you can write, for example, the literal 3, and it's
interpreted as a literal: an epsilon number.  But the situation is a
little messier in the current system which is contained in Guile:
depending on the context, 3 may be a Guile number or an epsilon number.
This is why you need the e1:toplevel macro to distinguish.

If you don't want to use the e1:toplevel macro, you can make epsilon
literals directly from Guile as well.

(e0:value 3) yields the epsilon ("green") three.
3 yields the Guile "ordinary" three.

e0:value has been useful in this sense while bootstrapping from Guile,
but you will probably not need it for numbers.  It's useful, however,
with symbols:

(e0:value qqq) yields the epsilon symbol qqq (a boxed data
structure).

Notice that e0:value and quote are two different macros: quoting builds
an s-expression symbol, which I call an s-symbol: it contains the symbol
wrapped into a data structure representing the type at runtime plus
optional information about the source location.  epsilon1's
s-expressions are a little heavyweight at the present time, but I'm not
too worried.

If you try to evaluate (e0:value qqq) and (e1:toplevel 'qqq) you will
see that the first structure is *contained* within the second: this is
due to the uniqueness of symbols (there can be only one named "qqq").

e1:value is just an alias of e0:value: the concept is identical in epsilon1.

> 2) How are defined procedures in e0?

There's no way, by design.  (this is explained in chapter 3 of my thesis,
near the beginning; that part should be very easy to read.)

In theory you could use buffer:set! from epsilon0 expression to alter a
symbol component, thus building globals and procedures.  But this
"surgical" technique of defining global objects would be a masochistic
exercise: for a procedure you'd have to build a list of symbols to
represent the formal parameters, an epsilon0 expression as a data
structure to represent the body, and write those into the correct fields
of the symbol naming the procedure.

e1:define is a friendly macro which permits you to automatically use
macros and transforms: it builds the corresponding data structures
including the epsilon0 expression from the s-expression you provide, and
then does that buffer:set! call for you.

> 3) Are state:* procedures part of e0?

The boundary between epsilon0 and epsilon1 is blurry, when it gets to
the library.  Those procedures are convenient to have, but you can in
theory do without them...

> 4) If the only type handled by e0 is fixnum, how is it possible to
> have accelerated floating point operations?

Good question.  B., who should be subscribed to this list, asked the
same question at my last epsilon presentation.

Floating-point support not implemented at this point, and I don't plan
to implement it soon.  I have fixed-point numbers (with just the four
operations, however: more will have to come), which will be bound to a
reasonable input and output syntax as soon as I complete the new
s-expression frontend.  Fixed-point numbers are implemented in core.e,
but should probably be moved to epsilon1.  Fixed-point numbers, as you
can imagine, are actually represented unboxed data, so they are just
"fixnums" with different operations.

The thing should be efficient, and the casual user won't notice a thing:
operations with fractional quantities will just work.  Numerical errors
will behave a little differently: floating-point representation and
operations guarantee a maximum bound on *relative* errors, while
fixed-point representation and operations guarantee a maximum bound on
*absolute* errors.

We can have floating-point numbers as well; that would be no big deal.
The big deal is how to compile them efficiently with respect to register
use.  Unfortunately, I don't have a good general answer about this.  An
easy but inefficient solution would be to always box floating-point
numbers; floating-point primitives would dereference objects into
floating-point registers.

> 5) There is no e0:define procedure? Why?

Because epsilon0 must be as simple as possible, and it doesn't need it.
adding toplevel forms would be overkill because expressions alone are
already powerful enough to modify any part of the global state,
including globals and procedure definitions.  Of course epsilon0 is not
comfortable for humans to use, but that's why we have extensions.

Bootstrapping the first time was indeed very complicated, as you are
thinking; but your project doesn't have to be: you can just use an
unexeced image.  At least, I'd do that.

Now I really have to go to sleep.  Thanks for your interest,

-- 
Luca Saiu
Home page:   http://ageinghacker.net
GNU epsilon: http://www.gnu.org/software/epsilon
Marionnet:   http://marionnet.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]