axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET


From: Page, Bill
Subject: RE: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET
Date: Tue, 26 Sep 2006 21:56:01 -0400

Too much context was removed by Tim in his reply and there was
no reference to the specific email to which this was a reply so
at first I thought: What is this all about? :-(

Then I tried to understand from

http://www.lisp.org/HyperSpec/Body/glo_t.html#top_level_form

"top level form n. a form which is processed specially by
compile-file for the purposes of enabling compile time
evaluation of that form. Top level forms include those forms
which are not subforms of any other form, and certain other
cases. See Section 3.2.3.1 (Processing of Top Level Forms)."

and

http://www.lisp.org/HyperSpec/Body/sec_3-2-3-1.html

what is meant by "top level form" in the discussion below but
failed.

Is this distinction relevant to the discussion?

>From my point of view 'bar' is something defined at one level,
i.e. at the "lisp" level. Whereas 'do-bar' is something
defined at a "higher" level, i.e. as a chunk name in the
pamphlet file or the "literate program" level.

Kai writes: "But in a Lisp program I'd very much prefer the
former [bar], since it's easier to understand and to work
with."

To me this raises an important question of the point-of-view
one should have when writing literate programs: Is it correct
to think of oneself as working "in a Lisp program" or should
we think of this first of all as a document?

The noweb <<do-bar>> chunk reference looks like and performs
like a macro expansion in the underlying programming language
even though it is actually done at the time of notangle,
prior to the compilation. From the point-of-view of the static
document perhaps <<do-bar>> is ease to understand. Presumably
one defines <<do-bar>>= because it has a special significance
and/or is a sub-expression that occurs frequently in the
source and deserves to be singled out and explained separately
in the documentation.

But Kai is apparently thinking in terms of working at the lisp
REPL and/or some debugging level where it might be more
convenient to have a name that lisp understands such as 'bar'.
Lisp does not understand the pamphlet format and cannot use
the name 'do-bar'... but maybe it should! When debugging
lisp programs derived from pamphlet source files maybe it
would make sense to have available some "noweb-aware" tools
that allowed simple reference to code chunks? E.g.

  (setq pamphlet-file "vmlisp.lisp.pamphlet")
  (pamphlet-chunk "do-bar")

etc.

Would this allow the lisp programmer/debugger to more easily
cross the gap between her lisp program and the pamphlet
source?

Or am I missing the point of this discussion?

Regards,
Bill Page.

On Thursday, September 21, 2006 4:41 PM Kai Kaminski wrote:

> >...
> >> use lots of small functions. What is the difference between

On Tuesday, September 26, 2006 11:07 AM Tim Daly wrote:

> > This defines 2 functions.

On Tuesday, September 26, 2006 1:35 PM Kai Kaminski wrote:
>
> True.
>
> >> 
> >> (defun bar (...)
> >>   (blah blub))
> >> 
> >> (defun foo (...)
> >>   (let ((...))
> >>     (bar ...)))
> >> 
> >
> > This defines a function and a "top level form".
> > The first expression is evaluated and returns a function.
> > The second expression is immediately evaluated for effect.

> No. The DO-BAR chunk is included in the FOO chunk. Hence
> (BLAH BLUB) ends up in the body of FOO and is not a toplevel
> form. Of course, the two snippets differ in that one defines a
> function and the other does not. But in a Lisp program I'd very
> much prefer the former, since it's easier to understand and to
> work with. If performance is an issue, an INLINE-declaration
> might help.
> 
> >> and
> >> 
> >> <<foo>>=
> >> (defun foo (...)
> >>   (let ((...))
> >>     <<do-bar>>))
> >> @
> >> 
> >> <<do-bar>>=
> >> (blah blub)
> >> @
> >
> > Depending on the situation the value of the top level form
> > could have other side effects.
>
> It is not a toplevel form.
> 
> Kai
> 




reply via email to

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