[prev in list] [next in list] [prev in thread] [next in thread]
List: sbcl-help
Subject: Re: [Sbcl-help] macro-function for implementation specific special-operators
From: Marco Antoniotti <marco.antoniotti () unimib ! it>
Date: 2021-11-12 8:10:24
Message-ID: CAG0Nw2nH9sP_vya4-gVswZx02H+zbRvYvoy+JNCSg1ZAqp6bgg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi
I read the post but I think an interpretation, given all the references to
main text and glossary is that
Table of Special Operator 3-2 contains the ... special operators. For
these you MAY have a macro function.
SOME of ALL the OTHER macros in the spec MAY be declared as a special
operator by an implementation; for these - which DO NOT appear in Table 3-2
- you MUST have a macro function as they where declared as macros in the
spec.
All the best
MA
On Fri, 12 Nov 2021 at 01:28, Richard M Kreuter <kreuter@progn.net> wrote:
> Shubhamkar Ayare via Sbcl-help writes:
>
> > Yes, so currently I have two people[1,2] suggesting that
> > implementations *must* provide a macro-function for implementation
> > specific special operators, and one suggesting otherwise. So, I also
> > wanted to check if there is any particular interpretation that SBCL
> > developers (or anyone experienced with the CLHS!) spec subscribe to.
>
> Hi there,
>
> Although I think it would be helpful for implementations to provide
> macro definitions for implementation-specific, non-function operators,
> I'm afraid it seems easy to find an interpretation that does not imply a
> requirement to do it. As the standard defines things,
>
> special operator n. one of a fixed set of symbols, enumerated in
> Figure 3-2, that may appear in the car of a form in order to
> identify the form as a special form. [1]
>
> Under that definition, SPECIAL-OPERATOR-P should return true only for
> the 25 symbols in Figure 3-2 [2], and so the first sentence you cited in
> MACRO-FUNCTION's dictionary entry,
>
> It is possible for both MACRO-FUNCTION and SPECIAL-OPERATOR-P to
> return true of SYMBOL.
>
> would apply only to those 25 symbols.
>
> In other words, the standard might be interpreted to be silent about any
> implementation-specific, non-function operators.
>
> (To the other half of your question: it seems that SBCL's
> SPECIAL-OPERATOR-P returns true for some operators other than the ones
> in Figure 3-2 (e.g., SB-EXT:TRULY-THE). Maybe that's evidence that SBCL
> has aimed to conform with some other reading of the standard. Or maybe
> that behavior is a bug.)
>
> Regards,
> Richard
>
> P.S., ISTM that if one applies the glossary entry that way, at least 2
> other passsages are mistaken (or mysterious). For example, section
> 3.1.2.1.2.2 says
>
> An implementation is free to implement any macro operator as a
> special operator, but only if an equivalent definition of the
> macro is also provided. [3]
>
> This can't be literally correct if "special operator" means one of the
> enumerated set, because no macro operator is one of those symbols.
>
> Likewise, the glossary entry plus the entry for "special form" makes
> this sentence from MACRO-FUNCTION confusing:
>
> The macro definition must be available for use by programs that
> understand only the standard Common Lisp special forms.
>
> If this sentence applies only to operators for which SPECIAL-OPERATOR-P
> returns true and SPECIAL-OPERATOR-P returns true only for the enumerated
> set symbols, the sentence is incorrect: "programs that understand only
> the standard Common Lisp special forms" don't need macro functions for
> those 25 special operators; by stipulation, that set of programs already
> understand all forms that start with those operators!
>
> So I think it would be be reasonable to count these two passages as
> evidence that the glossary entry is incomplete, and that there's an
> implied second sense for "special operator". (Exactly how to define that
> second sense would presumably be up to the person reading the standard,
> I guess.)
>
> But I suppose it would be an equally valid for somebody to say that the
> glossary entry is complete, to agree that those two passages are in
> error, and so to ignore them, leaving us back at the first reading.
>
> In summary, the standard appears either inconsistent or incomplete here,
> and probably does not support a strong case for a unique interpretation.
>
> [1]
> http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#special_operator
>
> [2]
> http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm#clspecialops
>
> [3] http://www.lispworks.com/documentation/HyperSpec/Body/03_ababb.htm
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="auto">Hi</div><div dir="auto"><br></div><div dir="auto">I \
read the post but I think an interpretation, given all the references to main text \
and glossary is that</div><div dir="auto"><br></div><div>Table of Special Operator \
3-2 contains the ... special operators. For these you MAY have a macro \
function.</div><div><br></div><div>SOME of ALL the OTHER macros in the spec MAY be \
declared as a special operator by an implementation; for these - which DO NOT appear \
in Table 3-2 - you MUST have a macro function as they where declared as macros in the \
spec.</div><div><br></div><div>All the \
best</div><div><br></div><div>MA</div><div><br></div></div><div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Nov 2021 at 01:28, \
Richard M Kreuter <<a href="mailto:kreuter@progn.net" \
target="_blank">kreuter@progn.net</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Shubhamkar Ayare via Sbcl-help writes:<br> <br>
> Yes, so currently I have two people[1,2] suggesting that<br>
> implementations *must* provide a macro-function for implementation<br>
> specific special operators, and one suggesting otherwise. So, I also<br>
> wanted to check if there is any particular interpretation that SBCL<br>
> developers (or anyone experienced with the CLHS!) spec subscribe to.<br>
<br>
Hi there,<br>
<br>
Although I think it would be helpful for implementations to provide<br>
macro definitions for implementation-specific, non-function operators,<br>
I'm afraid it seems easy to find an interpretation that does not imply a<br>
requirement to do it. As the standard defines things,<br>
<br>
special operator n. one of a fixed set of symbols, enumerated in<br>
Figure 3-2, that may appear in the car of a form in order to<br>
identify the form as a special form. [1]<br>
<br>
Under that definition, SPECIAL-OPERATOR-P should return true only for<br>
the 25 symbols in Figure 3-2 [2], and so the first sentence you cited in<br>
MACRO-FUNCTION's dictionary entry,<br>
<br>
It is possible for both MACRO-FUNCTION and SPECIAL-OPERATOR-P to<br>
return true of SYMBOL.<br>
<br>
would apply only to those 25 symbols.<br>
<br>
In other words, the standard might be interpreted to be silent about any<br>
implementation-specific, non-function operators.<br>
<br>
(To the other half of your question: it seems that SBCL's<br>
SPECIAL-OPERATOR-P returns true for some operators other than the ones<br>
in Figure 3-2 (e.g., SB-EXT:TRULY-THE). Maybe that's evidence that SBCL<br>
has aimed to conform with some other reading of the standard. Or maybe<br>
that behavior is a bug.)<br>
<br>
Regards,<br>
Richard<br>
<br>
P.S., ISTM that if one applies the glossary entry that way, at least 2<br>
other passsages are mistaken (or mysterious). For example, section<br>
3.1.2.1.2.2 says<br>
<br>
An implementation is free to implement any macro operator as a<br>
special operator, but only if an equivalent definition of the<br>
macro is also provided. [3]<br>
<br>
This can't be literally correct if "special operator" means one of \
the<br> enumerated set, because no macro operator is one of those symbols.<br>
<br>
Likewise, the glossary entry plus the entry for "special form" makes<br>
this sentence from MACRO-FUNCTION confusing:<br>
<br>
The macro definition must be available for use by programs that<br>
understand only the standard Common Lisp special forms.<br>
<br>
If this sentence applies only to operators for which SPECIAL-OPERATOR-P<br>
returns true and SPECIAL-OPERATOR-P returns true only for the enumerated<br>
set symbols, the sentence is incorrect: "programs that understand only<br>
the standard Common Lisp special forms" don't need macro functions for<br>
those 25 special operators; by stipulation, that set of programs already<br>
understand all forms that start with those operators!<br>
<br>
So I think it would be be reasonable to count these two passages as<br>
evidence that the glossary entry is incomplete, and that there's an<br>
implied second sense for "special operator". (Exactly how to define \
that<br> second sense would presumably be up to the person reading the standard,<br>
I guess.)<br>
<br>
But I suppose it would be an equally valid for somebody to say that the<br>
glossary entry is complete, to agree that those two passages are in<br>
error, and so to ignore them, leaving us back at the first reading.<br>
<br>
In summary, the standard appears either inconsistent or incomplete here,<br>
and probably does not support a strong case for a unique interpretation.<br>
<br>
[1] <a href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#special_operator" \
rel="noreferrer" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#special_operator</a><br>
<br>
[2] <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm#clspecialops" \
rel="noreferrer" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm#clspecialops</a><br>
<br>
[3] <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_ababb.htm" \
rel="noreferrer" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/03_ababb.htm</a><br>
<br>
<br>
_______________________________________________<br>
Sbcl-help mailing list<br>
<a href="mailto:Sbcl-help@lists.sourceforge.net" \
target="_blank">Sbcl-help@lists.sourceforge.net</a><br> <a \
href="https://lists.sourceforge.net/lists/listinfo/sbcl-help" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/sbcl-help</a><br> \
</blockquote></div></div>
_______________________________________________
Sbcl-help mailing list
Sbcl-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic