[Chicken-users] Evaluating lists with scoped let's and applying scoped macros to lists

2009-02-13 Thread Christoph Angerer

Hi there,

I am currently trying to write an enhanced version of an interpreter  
for a little language I am developing. For that, I would like to be  
able to (a) pass a list containing symbols of my language's keywords  
to an interpret-function; this function should let-define  
implementations for the keywords and then evaluate the list using  
those procedure bindings. And (b) I would like to do something similar  
with macros.


First, something that is close to what I want to do and what works:

(define (interpret)
(let
[(myadd +) (mymul *)]
(myadd 4 (mymul 5 2

(display (interpret))

This procedure returns 14, as expected. Now, instead of hardcoding the  
program into evaluate, I want to pass it as an parameter. As in:


(define (interpret prog)
(let
[(myadd +) (mymul *)]
(eval prog)))

(display (interpret '(myadd 4 (mymul 5 2

This, however, results in Error: unbound variable: mymul. I also tried  
to pass different environments to eval, but that didn't seem to make  
any difference? How can I convince eval to use the locally bound  
procedures?


To go even one step further (assuming, that the above example worked),  
I would like to be even able to exchange some of the function  
definitions in the evaluate with a define-syntax. However, this define- 
syntax should be scoped to the evaluate procedure. The (non-working)  
example would look like this, then:


(define (interpret prog)
(define-syntax myadd
(syntax-rules ()
([_ params] (+ params
(let
[(mymul *)]
(eval (macro-expand prog

(display (interpret '(myadd 4 (mymul 5 2

In my brain, this should result in the prog being expanded such that  
the myadd-keyword is replaced by the + (that is, the myadd  
implementation is being inlined). The mymul keyword would be a  
reference to the * function. Here it wouldn't be a big difference, but  
for more complicated keywords, there might be a tradeoff between  
doing a lot of inlining of frequently used but short keywords and just  
referencing long or infrequently used functions.


The scoping of the macros would be important, because there might be  
an additional analyse function that expands the program using  
different macros with the same names. The only reference I found, that  
macros can be scoped, is here on the very bottom of the page: http://community.schemewiki.org/?scheme-faq-macros 
 But that didn't help me either.


Maybe this is something really stupid and can be solved by some clever  
quasi-quoting and unqouting or something (oh, and if possible I would  
like to try to solve that without additional libraries, if possible);  
but I really tried hard and searched the net and everything and just  
can't see what I am missing here... So your help would be greatly  
appreciated:)


Thanks,
Christoph 



___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Evaluating lists with scoped let's and applying scoped macros to lists

2009-02-13 Thread Thomas Chust
Hello Christoph,

the problem is that eval never sees local bindings introduced with let
or through function arguments, it always resolves symbols relative to
a top level environment. You should look into the environments egg
(http://chicken.wiki.br/environments) to achieve what you want.

cu,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] newbie: questions about set-finalizer!

2009-02-13 Thread felix winkelmann
On Thu, Jan 29, 2009 at 9:01 PM, Jim Ursetto zbignie...@gmail.com wrote:
 On Thu, Jan 29, 2009 at 5:56 AM, felix winkelmann bunny...@gmail.com wrote:
 On Thu, Jan 29, 2009 at 9:41 AM, Jim Ursetto zbignie...@gmail.com wrote:
 I am seeing finalizers fail to execute on recent SVN and I think
 it is the result of this change.  I backed out the patch and it works
 okay again.

 Is the behaviour identical for compiled code?

 No, it works correctly for compiled code.  They trigger immediately
 after (gc #t).

 In interpreted code, the finalizers do not trigger at all, even when
 you exit csi via (exit).


Hm... I think this is related to the fact, that interpreter environments
are managed differently (the closure representation in the interpreter
is a simple linked list of environments, so it is possible that more indirect
references to finalizers are left. But this should work. Have to investigate.


cheers,
felix


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users