[mine's packed away where it's hard to get to at the moment]
can someone with access to a a lispm manual please tell me for sure
what the args to progw, are? (no, that's not a typo for progv; the
lispm has a progw which is similar to progv but merges the two args
that progv takes into a single one.) in particular, does it
take a traditional dotted alist or does it take a more modern
cadr-style alist?
and while i'm at it, why the heck haven't we as a community given that
other kind of alist a NAME by now? i'd be tempted to call it a
pairlist, but for the fact that pairlis returns the dotted kind. I
suppose we could imagine a new operator pairlist which did the cadr
kind and let pairlis still do the dotted kind, but... anyone thought
hard about style as regards this mess?
Kent M Pitman wrote:
>
> [mine's packed away where it's hard to get to at the moment]
>
> can someone with access to a a lispm manual please tell me for sure
> what the args to progw, are? (no, that's not a typo for progv; the
> lispm has a progw which is similar to progv but merges the two args
> that progv takes into a single one.) in particular, does it
> take a traditional dotted alist or does it take a more modern
> cadr-style alist?
"Its value should be a list that looks like the first subform of let*:
((var1 val-form-1)
(var2 val-form-2)
...)"
If you need more info let me know
"Christopher J. Vogt" <····@computer.org> writes:
> Kent M Pitman wrote:
>
> > [mine's packed away where it's hard to get to at the moment]
> >
> > can someone with access to a a lispm manual please tell me for sure
> > what the args to progw, are? (no, that's not a typo for progv; the
> > lispm has a progw which is similar to progv but merges the two args
> > that progv takes into a single one.) in particular, does it
> > take a traditional dotted alist or does it take a more modern
> > cadr-style alist?
>
> "Its value should be a list that looks like the first subform of let*:
> ((var1 val-form-1)
> (var2 val-form-2)
> ...)"
> If you need more info let me know
Thanks!
Yeah, I thought it was one of those cadr-alist things.
But LET*? Ugh. So it actually does left-to-right binding.
How irritating. That means it can't just do
(progv (mapcar #'car bindings) (mapcar #'cadr bindings) ...)
but then, they probably wanted to allow stack consing so they did
the low-level equiavlent of
(progv (caar bindings) (cadar bindings)
(progw (cdr bindings) ...))
Hmm...
>>>>> On Sun, 1 Jul 2001 00:02:53 GMT, Kent M Pitman ("Kent") writes:
Kent> "Christopher J. Vogt" <····@computer.org> writes:
Vogt>> Kent> what the args to progw, are? (no, that's not a typo for progv; the
Vogt>> "Its value should be a list that looks like the first subform of let*:
Kent> But LET*? Ugh. So it actually does left-to-right binding.
I don't see that in the manual. The version I have says "LET",
not "LET*", but it's only making an analogy to the structure of the args.
The exact text says: "Each element of this list is processed, in turn,
by evaluating the VAL-FORM, and binding the VAR to the resulting variable."
It uses the word "sequential" when describing the evaluation of the
body forms, not when talking about the bindings.
I am pretty sure that PROGW worked the same way as PROGV.
>>>>> On 01 Jul 2001 17:18:43 +0100, Tim Bradshaw ("Tim") writes:
Tim> * Kent M Pitman wrote:
>> But LET*? Ugh. So it actually does left-to-right binding.
Tim> yes, it does, at least in Genera 8.3.
I was looking at the documentation from the pre-Symbolics LispM manual.
I wonder if the semantics changed, or just the documentation?
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On 01 Jul 2001 17:18:43 +0100, Tim Bradshaw ("Tim") writes:
> Tim> * Kent M Pitman wrote:
> >> But LET*? Ugh. So it actually does left-to-right binding.
> Tim> yes, it does, at least in Genera 8.3.
>
> I was looking at the documentation from the pre-Symbolics LispM manual.
> I wonder if the semantics changed, or just the documentation?
Maybe the doc was originally deficient and finally updated to match?
Kent M Pitman <······@world.std.com> writes:
> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> > I was looking at the documentation from the pre-Symbolics LispM manual.
> > I wonder if the semantics changed, or just the documentation?
>
> Maybe the doc was originally deficient and finally updated to match?
FWIW, the documentation for PROGW in the orange chinual contains the
following sentance, "Note that the bindings are sequential not
parallel".
>>>>> On 01 Jul 2001 23:24:46 -0400, Carl Shapiro ("Carl") writes:
Carl> Kent M Pitman <······@world.std.com> writes:
>> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>>
>> > I was looking at the documentation from the pre-Symbolics LispM manual.
>> > I wonder if the semantics changed, or just the documentation?
>>
>> Maybe the doc was originally deficient and finally updated to match?
Carl> FWIW, the documentation for PROGW in the orange chinual contains the
Carl> following sentance, "Note that the bindings are sequential not
Carl> parallel".
I was looking at an older CHINUAL, and wording of the documentation
that you cite from the orange version sounds like a clarification
rather than a change.
>>>>> On Sat, 30 Jun 2001 21:25:42 GMT, Kent M Pitman ("Kent") writes:
Kent> can someone with access to a a lispm manual please tell me for sure
Kent> what the args to progw, are? (no, that's not a typo for progv; the
Kent> lispm has a progw which is similar to progv but merges the two args
Kent> that progv takes into a single one.) in particular, does it
Kent> take a traditional dotted alist or does it take a more modern
Kent> cadr-style alist?
The VARS-AND-VALS-FORMS-FORM is evaluated; its value should be
an alist of the "modern kind" (the same as LET), and this will
then also be processed (evaluating the val-forms).
"Kent M Pitman" <······@world.std.com> ha scritto nel messaggio
····················@world.std.com...
> [mine's packed away where it's hard to get to at the moment]
>
> can someone with access to a a lispm manual please tell me for sure
> what the args to progw, are?
Genera 7.2:
================
progw vars-and-vals &body body Special Form
A somewhat modified kind of progv; like progv, it only works for special
variables. First, vars-and-vals-form is evaluated. Its value should be a
list
that looks like the first subform of a let*:
((var1 val-form1)
(var2 val-form-2)
...)
Each element of this list is processed in turn, by evaluating the val-form,
and binding the var to the resulting value. Finally, the body forms are
eval-
uated sequentially, the bindings are undone, and the result of the last form
is returned. Note that the bindings are sequential, not parallel.
This is a very unusual special form because of the way the evaluator is
called on the result of an evaluation. Thus, progw is mainly useful for im-
plementing special forms and for functions part of whose contrace is that
they call the interpreter. For an example of the latter, see
sys:*break-bindings*; break implements this by using progw.
================
P.
Kent M Pitman wrote in message ...
>[mine's packed away where it's hard to get to at the moment]
>
>can someone with access to a a lispm manual please tell me for sure
>what the args to progw, are? (no, that's not a typo for progv; the
>lispm has a progw which is similar to progv but merges the two args
>that progv takes into a single one.) in particular, does it
>take a traditional dotted alist or does it take a more modern
>cadr-style alist?
>
From my 1990 Genera 8.0 manuals...
progw vars-and-vals &body body [special form]
A somewhat modified version of progv; like progv, it only works for
special variables. First vars-and-vals is evaluated; its value should
be a list that looks like the first subform of let*:
((var1 val1-form)
(var2 val2-form) ...)
Each element of this list is processed in turn, by evaluating the val-form
and binding the var to the resulting value. ... Note that the bindings are
sequential, not parallel.
The documentation goes on to say:
This is a very unusual special form because of the what the evaluator
is called on the result of an evaluation. ... [It] is mainly useful for
implementing [other] special forms and functions [...] that call the
interpreter.
Geez, what were we thinking?
"Scott McKay" <···@mediaone.net> writes:
> The documentation goes on to say:
>
> This is a very unusual special form because of the what the evaluator
> is called on the result of an evaluation. ... [It] is mainly useful for
> implementing [other] special forms and functions [...] that call the
> interpreter.
>
> Geez, what were we thinking?
Honestly, I can't imagine any such layered special forms to implement using
this. The one and only legitimate use I've ever seen of this is:
(defvar *foo-io-bindings*
'((*print-pretty* t) (*print-level* 9) (*print-length* 32)))
(defmacro with-foo-io (&body forms)
`(call-with-foo-io #'(lambda () ,@forms)))
(defun call-with-foo-io (function)
(progw *foo-io-bindings*
(funcall function)))
That is, it's useful to wrap a standard set of bindings around a call to
a function, usually one doing I/O either to a file or interactively.
The command loop in Genera, I think, has a list of standard bindings it
instantiates in this way, for example. And maybe another set of such
bindings it adds for the debugger...