Re: Scheme closures
From: Anton van Straaten (anton_at_appsolutions.com)
Date: 04/25/04
- Next message: David Steuber: "Re: SBCL + re-spawning, background swank server (was: How do I deal with &optional args?)"
- Previous message: Jeff Dalton: "Re: Scheme closures"
- In reply to: Jeff Dalton: "Re: Scheme closures"
- Next in thread: Rob Warnock: "Re: Scheme closures"
- Reply: Rob Warnock: "Re: Scheme closures"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 25 Apr 2004 18:55:33 GMT
Jeff Dalton wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
...
> > I think a lot can depend on how well they're written, how descriptive
the
> > names are, whether they're written to be easy to understand or to meet
> > some other constraint, etc.
>
> Absolutely right. However, none of the posted definitions
> were easy to read, yet presumably their authors thought they
> were writing the macro in a good way. That suggests that
> there is a problem with the language.
The syntax-rules constraints are definitely part of the issue here (note
that Will Clinger's point about R5RS doesn't apply to the specific examples
posted in this thread, since both examples expand to a combination of
definitions & expressions).
However, if you look at the example in my earlier message, you can see that
the change from using syntax-rules to syntax-case, to be able to use
generate-temporaries, is trivial. It's analogous to starting out writing a
case expression and then realizing you need a more general cond, instead.
Of course, you can usually tell ahead of time which you're going to need,
anyway.
> I like the sort of pattern-matching used in functional languages
> enough that I wrote macros to provide it in Lisp. Nonetheless,
> I think it has some serious problems.
It's useful to be able to choose between pattern matching or not.
Syntax-case supports that, which is why that "stx" is there (described
below).
> Why do you have (define var (if #f #f)) instead of, say
> (define var #f)?
(if #f #f) returns an implementation-dependent "unspecified" value. R5RS
specifies that prior to initialization, variables have an unspecified value.
"Unspecified" means that an implementation can use any value it likes, but
for consistency with the host implementation, if you're writing code to
generate variable definitions, then (if #f #f) usually gives you access to
whatever value the implementation normally uses to represent an unspecified
value. Most implementations have some kind of "void" value which is used
for this purpose. Portable libraries can (define void (if #f #f)) and then
refer to the value by name; I just used the expression directly in my
examples.
> That's much nicer, though I wonder about the "stx" and the
> "(if #f #f)".
"Stx" is the syntax object representing the source syntax, which you can use
for other purposes than pattern matching with syntax-case. You can write
procedural code to destructure it, if you like. You can even convert it to
a list and use quasiquote to generate the syntax you need, then convert it
back to a syntax object - which is pretty much what syntax-case
implementations of defmacro do.
> > I think this is one of those shortcuts which
> > which may look confusing at first, but which experienced users tend to
> > quickly adopt, because its benefits soon become obvious. The benefit is
> > that you're not repeating the name of the macro over and over in the
> > patterns.
>
> What happens in nested definitions?
In syntax-rules, the identifier in that position is ignored, and there's no
issue with nested definitions. The patterns always apply to the closest
enclosing definition. R5RS 4.3.2 says "The keyword at the beginning of the
pattern in a <syntax rule> is not involved in the matching and is not
considered a pattern variable or literal identifier".
In syntax-case, that identifier is similarly unimportant, although it can
sometimes be useful as a lexical token to specify the lexical level of
syntax being introduced by the macro.
> Also, I'm more concerned
> about reading. That the name would be repeatedly typed doesn't
> seem like much of a cost, especially since editors will
> typically be able to complete it when only partially typed.
Reading is the reason to use the shortcut. The repeated name really doesn't
buy you much. You're inside a lexical block which is identified with the
name of the macro at the very beginning, so there's no ambiguity.
> It might be a benefit when reading, but it's not clear. In some
> cases, it would be, because it would be easier to pick out the "_"s
> than to pick out the instances of the macro name.
>
> A similar abbreviation hasn't been defined for procedures,
> though it might also be useful. Though procedures are a
> different case, it still suggests that the benefits are
> not large.
The equivalent situation with procedures in Scheme would be to use a
construct like case-lambda, in which the procedure name is omitted from the
cases. Using "_" is just a way of "explicitly omitting" the name of the
macro. With macros, there are cases where you want to use the name of the
macro, so you do need to be able to access it if necessary. But if a
particular macro doesn't need it, then you have the choice of "omitting" it.
Any more tire-kicking you need to do? ;o)
Anton
- Next message: David Steuber: "Re: SBCL + re-spawning, background swank server (was: How do I deal with &optional args?)"
- Previous message: Jeff Dalton: "Re: Scheme closures"
- In reply to: Jeff Dalton: "Re: Scheme closures"
- Next in thread: Rob Warnock: "Re: Scheme closures"
- Reply: Rob Warnock: "Re: Scheme closures"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
