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

Re: Dylan Features

>From: "John Whittaker" <johncwhi@earthlink.net>
>Subject: Re: Dylan Features
>Date: Sam, 5. Aug 2000 5:45 Uhr
>

>
> Gabor Greif <gabor@mac.com> wrote in message
> 8mfgov$ck6$1@rznews2.rrze.uni-erlangen.de">news:8mfgov$ck6$1@rznews2.rrze.uni-erlangen.de...
>> but we have the block macro that provides an exit function:
>>
>> define function invoke(f :: <function>)
>>     f(42*42)
>> end;
>>
>> block(return)
>>     invoke(return);
>>     42
>> end block;
>>
>>
>>
>> will evaluate to 42*42. (too lazy to compute it :-)
>>
>> In this respect it is similar to call/cc:
>>
>> (define (invoke f)
>>     (f (* 42 42))
>> )
>>
>> (define (block)
>>     (call/cc invoke)
>>     42
>> )
>
> Wow!!  I never thought about block() in that way.   But,  if I understand
> this correctly, Dylan still doesn't have enough power to implement
> coroutines.  Is that right?   If it did, I might ask whether it's possible

Compromises have been made to allow efficient compilation and execution.
One of them was to settle on a stack discipline when allocating invocation
frames. There is only one stack. This means no coroutines (by means of
continuations).

> to use Dylan as an embedded extension language.  I've just recently been
> looking for possible extension languages and thought only Scheme or Python
> would pass my criteria.  Maybe Dylan could if...
>  1) it could be made small enough to fit in about 1/2 meg for code and 1/2
> meg heap

This is hardly possible in regard of the great dylan library. Take a look at
DRM. But using some very compact code representation some genius could do
it.

>  2) allowed coroutines or lightweight threads .

Coroutines could be put in dylan in a scheme-like way and it would not
violate the DRM. They would not be portable however. Fun-o has threads.
Gwydion will have them in the future...
But both do not fulfill 1).

>
> Would it also have to have an "eval"-like function to allow for evaluating
> arbitrary Dylan fragments called from the embedding program?
>

This was another compromise. Easy parsing has been given up deliberately to
get infix syntax and pattern matching macros. Again, this could be done, but
it would pull in a big machinery in the runtime.

Maybe you should stick with scheme (+ meroon) as your embedded extension
language. Dylan is not designed for this. It was designed as an application
language.

    Gabor
>
References: