Email list hosting service & mailing list manager

Keywords reduced Lassi Kortela (18 Oct 2019 15:24 UTC)
Re: Keywords reduced John Cowan (18 Oct 2019 20:48 UTC)
Re: Keywords reduced Lassi Kortela (18 Oct 2019 22:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 08:25 UTC)
Re: Keywords reduced John Cowan (19 Oct 2019 19:04 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 09:15 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:26 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 18:37 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 19:27 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:04 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 10:07 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:33 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:38 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 20:06 UTC)
Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 20:30 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 20:54 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 21:07 UTC)
Re: Syntactic keywords vs parentheses Shiro Kawai (22 Oct 2019 22:24 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (23 Oct 2019 07:40 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 23:12 UTC)
Re: Syntactic keywords vs parentheses Amirouche Boubekki (25 Oct 2019 11:55 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (23 Oct 2019 07:18 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 23:06 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 00:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:12 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 10:56 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:42 UTC)
Remaining keyword problems Lassi Kortela (29 Oct 2019 17:59 UTC)
allow-other-keys Lassi Kortela (29 Oct 2019 18:29 UTC)
Re: allow-other-keys John Cowan (29 Oct 2019 18:55 UTC)
Re: allow-other-keys Shiro Kawai (29 Oct 2019 19:18 UTC)
Re: allow-other-keys Lassi Kortela (29 Oct 2019 23:04 UTC)
Re: allow-other-keys Marc Feeley (29 Oct 2019 21:05 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 08:16 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:11 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 10:34 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:54 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 11:13 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 11:39 UTC)
Re: allow-other-keys Arthur A. Gleckler (03 Nov 2019 18:39 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 18:47 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:20 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:18 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 19:51 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 22:19 UTC)
Identifier syntax and the range of Schemes to support Lassi Kortela (03 Nov 2019 19:54 UTC)
Re: Remaining keyword problems John Cowan (29 Oct 2019 19:51 UTC)
Re: Remaining keyword problems Lassi Kortela (29 Oct 2019 21:09 UTC)
Alternative syntax using colon symbols for portable keywords Lassi Kortela (29 Oct 2019 22:29 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:56 UTC)
Re: Remaining keyword problems Lassi Kortela (11 Nov 2019 16:15 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:44 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 16:48 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 17:06 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 17:15 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 09:25 UTC)
Re: Keywords reduced Lassi Kortela (19 Oct 2019 09:38 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 12:22 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 18:43 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 08:39 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:28 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:12 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:17 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 10:22 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:10 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:19 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:33 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:05 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:01 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:18 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:05 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:04 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 06:49 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:52 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 11:46 UTC)
Re: Keywords reduced Peter Kourzanov (21 Oct 2019 15:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 15:54 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 17:38 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:45 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 08:21 UTC)
Keywords vs paremeters for hygiene Lassi Kortela (21 Oct 2019 08:05 UTC)
Re: Keywords vs paremeters for hygiene Marc Nieper-Wißkirchen (21 Oct 2019 11:22 UTC)

Re: Keywords reduced Marc Nieper-Wißkirchen 22 Oct 2019 06:04 UTC

Am Mo., 21. Okt. 2019 um 21:27 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> My $.02
>
> [ie]r-macro-transformer has a nice property that it allows you to combine orthogonal, generic
> tools to write macro transformers, whilst syntax-case forces you to use specialized tools that
> can only be used within syntax-case.

I don't think that it is necessarily right. In principle, nothing
speaks against using the special forms `syntax-case' and `syntax' and
the pattern variable system in run-time code. And the syntax-case
pattern matcher has to be provided in any case because syntax-rules
uses the same pattern matcher. On the other hand, to match source
code, a more general pattern matcher than `syntax-case' won't help
much.

>
> Here's "when-not" macro in er-macro-transformer, with Gauche's supporting libraries:
>
> (define-syntax when-not
>    (er-macro-transformer
>       (lambda (form rename id=?)
>          (match form
>             ((_ test expr1 expr ...)
>              (quasirename rename
>                 `(if (not ,test) (begin ,expr1 ,@expr))))))))
>
> Here's syntax-case version:
>
> (define-syntax when-not
>     (lambda (x)
>       (syntax-case x ()
>          ((_ test expr1 expr ...)
>           #'(if (not test) (begin expr1 expr ...))))))
>
> er-macro-transformer version uses match macro (Wright's match), and
> Gauche's quasirename macro (which applies rename procedure on symbols not unoquoted).
> They are not tied to macro system at all---they're generally useful tools.
>
> Most of times, syntax-case will make shorter code, and that makes syntax-case perfect "middle-level"
> tool.

Apart from cleaner code, a syntax-case macro will retain source code
location information. This is not only important for debugging but
makes it possible to write macros like the R7RS form `include', which
shall include the file from the directory where the source of the
include form comes from.

> I wish it could be deconstructed to orthogonal basic tools.  Could the pattern matcher be
> splitted from it?  It seems such a waste if an implementation has to have two set of pattern
> matchers, and one of them can only be used with specific macro expanders.
> (I know the wrapped syntactic forms require special handling.  But I imagine we could define
> a pattern matcher library that can accept wrapped form and bare form, for example.)

In principle, one could specify syntax parameters that control how
`syntax-case' destructures its input and how `syntax' composes its
argument. This way, it can be adapted to input and output of any
shape.

If you want to fully decompose the syntax-case system, one could end
up with the following components:

(0) Specification what a transformer is, including identifier syntax
and variable transformers.

(1) The idea that source code is not necessarily represented by an
sexp but by some abstraction ("a syntax object") that may be an sexp
expression, but may also be something fancier and may include, for
example, source location information and lexical information.

(2) A primitive procedure to destructure syntax objects like Racket's
`syntax-e'.

(3) A primitive procedure to construct syntax object, like `datum->syntax'.

(4) Some identifier syntax that represents the current macro
environment and that can be used with `datum->syntax'.

(5) A way for macros to lexically introduce pattern variables and to
bind them to expand-time values.

(6) A way for procedural macros to recognize pattern variables and to
retrieve their values.

(7) An implementation of `syntax-case' using the above.

(8) An implementation of `syntax' using the above.

A "native" implementation of `syntax' would still be faster, though.
Also, source code location information may be lost.

On the other hand, something like `syntax-e' can easily be implemented
on top of `syntax-case', so in any `syntax-case' system, you can use
your favorite pattern matcher.

Thus, I would propose to implement the syntax-case system as is but
with making sure that `syntax-case' and `syntax' also work outside
macro transformers. Furthermore, the concept of pattern variables
could be made available to user-level code (so that one can build a
matcher like `syntax-case' from primitive building blocks).

Marc