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

[elk] Re: compiling Elk



Am Fre, den 26.09.2003 schrieb Sam Hocevar um 16:17:
> On Tue, Sep 23, 2003, Thies Pfeiffer wrote:
> 
> > I just found out that there is still a bug in elk with the expansions of
> > arrays. The ,@ command in ` environments as you need it within evals
> > does not work correctly. It expands ,@(1 2 . 3) as 1 2 and not 1 2 3.
> 
>    I must admit I don't understand your example. R4RS and R5RS state
> that the argument to ,@ (unquote-splicing) must evaluate to a list, and
> (1 2 . 3) obviously doesn't. It might be an extension to the standard,
> but then I need a proper example of what the expected behaviour is.
That's true - so calling it a bug was wrong... I would call it an
improvement of behavior. Well, you may say that sticking to the standard
is a major objective... Don't know... It seemed somewhat obvious that
the (1 2 . 3) expression should expand in the same way as (1 2 3)...
Thinking of reducing a bracketed expression... 
The reason that made us choose this solution was, that we had problems
with calls to functions with arbitrary number of parameters...
(define a (lambda (a . b) ... ))
When we wanted to use a macro instead
(define-macro ...)
the expansion of the parameter list in the eval (body of define-macro)
using ,@ went berserk because of the stripping of the b... Perhaps we
did not look to deep into the standard these days. So we should have
converted our (a . b) in a (list a b) first.

>    I saw mention of this in this paper:
> 
>   http://www.ircam.fr/equipes/repmus/Rapports/PeterHanappe99/ch4/node2.html
> 
>    I will try to contact the authors, they seem to have done additional
> work on Elk, such as thread-safety.
The report looks quite interesting, although they chose the java vm
instead... I guess they probably won't have the old code any more... But
good luck! 

A standard garbage collector would indeed extremely simplify the
interoperation with c and c++ modules. The GC_LINK/UNLINK stuff would be
no longer necessary. On the other hand I do not know if the elk garbage
collector has been optimized for speed... Perhaps moving to a different,
more general one, could induce a performance drain... But I would say
that it could be worth the effort.

Ciao
Thies

-- 
Dipl. Inform. Thies Pfeiffer
University of Bielefeld - SFB 360 - Project C3 - Room D4-123
EMail: Thies.Pfeiffer@Uni-Bielefeld.de - Telephone: +49 521 106 5276

-- Attached file included as plaintext by Ecartis --
-- File: signature.asc
-- Desc: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQA/dFBLVnBuzrFa7wkRAnp4AKD6Y0k1zF8X+IGCfQ/Eu9w+rlhETACePFbg
TaaT9XjvqWB+tWZS2p3T8sA=
=l4hT
-----END PGP SIGNATURE-----


-- 
This is the elk mailing-list, see http://sam.zoy.org/projects/elk/
Trouble unsubscribing? Please contact <sam@zoy.org>