[Top][All Lists]

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

Re: [Axiom-developer] Boot and other Lisps

From: Gregory Vanuxem
Subject: Re: [Axiom-developer] Boot and other Lisps
Date: Wed, 14 Mar 2007 02:31:52 +0100

Le mardi 13 mars 2007 à 15:22 -0500, Gabriel Dos Reis a écrit :


> Yes, I'm trying to allocate some fixed amount of time per week to work
> on Axiom, and ISO C++ stuff tends to take over :-)

Ah, time is always short...


> | In the version of Axiom that I uploaded I added the
> | Makefile.pamphlet from src/boot, which is the only documentation as far
> | as I know of the boot, more precisely Shoe, language.
> Yes, I intend to improve on that.  I face this dilemma: Produce an
> academic style definition of Shoe, or are more to the rigid
> style of the existing documentation.  I end up doing the latter. But I
> believe the former is the long term solution.

Probably, you know "The 30 years horizon" theme (which is now The 26
years horizon :-)

> I have not had (yet) the chance to look at your package -- shame on me :-(

No problem, I'm more interested by directions taken.


> | My
> | question is as follow, is it possible to declare a variable as special
> | without adding it to this list of variables ? Such that it can be used
> | normally i.e if you want to assign a new value you can use the :=
> | operator and, important thing, it's not bound to nil at the beginning of
> | the prog ?
> Not that I'm aware of, if my understanding of Shoe is correct.  
> When, I stumbled on that problem, I went back and looked at the Shoe code more
> carefully.  First Shoe, translates the body of a function, by
> shoCompTran1.  That function updates global states that keep track of
> fluid variables (those declared with the "fluid" or "local" type),
> global variables (those beginning with $), and local variables (those
> that are assigned to in the body of the function).
> Then Shoe considers that anything that is on the fluid variables list
> or local variables list really is a local variable, therefore put it
> on the PROG header.  That exhausts all the handling of variables.

Thanks, I'll probably look at it though I have to look at the C code
used by Axiom and try to get rid of it when possible. I quickly added,
several days ago, a GCL Lisp version of directoryp using (system::stat)
but it is unsatisfactory, I will probably ask Camm if stat can returns
more information, eventually I'll implement it.

> My first reaction, when I ran into that problem was to extend the 
> algorithm for special handling of the Lisp convention.  Then I
> imagined opposition from more senior contributors and decided to go
> with the solution I like the least (i.e. ugly), direct use of SETQ.
> [ By the way, I would like to get rid of the PROG annotation when
>   there is no variable in the list -- very common situation. ]


> I see your question as suggesting that we should have the translator
> honor the Lisp convention -- that would be the most logical thing to
> do.  If people agree, I can add that capability to the translator --
> and of course, I'll document it :-)


Not exactly, I'm not suggesting something though rereading my mail it
seems to be. In fact I asked some thoughts because I don't know how this
should be handled. I like the idea to add support of Lisp special
variables (*something*) but on the other hand this is a restriction. You
have to use $variable or *variable*. Don't know what to do, force the
user or use a more general way via a declaration.


reply via email to

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