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 21 Oct 2019 18:37 UTC

Am Mo., 21. Okt. 2019 um 19:26 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Oct 20, 2019 at 5:15 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>
>>
>> What I wanted to express is that later
>> additions to the R7RS-large might make possibly better
>> abstractions/syntax possible. At least for R7RS-large it does not seem
>> to make sense to me to restrict ourselves to syntax that can be
>> portably implemented with `syntax-rules' until we haven't decided on
>> the macro system of R7RS-large.
>
>
> I see your point.  But that will be a hard fight.  How would things be better with syntax-case?  (I am asking for instruction, not rhetorically.)

With a procedural macro system, we have a few more options than with
`syntax-rules' alone. For example, a macro like `keyword-call' cannot
match symbol arguments by name with `syntax-rules' alone. It can only
detect whether symbol arguments are bound-identifier=? or
free-identifier=?.

Depending on how much work we want `keyword-call' to be able to do at
compile-time and depending on how we want to match keyword arguments,
we may want to be able to compare symbol arguments by name (and not as
identifiers).

Lassi mentioned somewhere that the shape of the high-level interface
of this SRFI 177 was partly dictated by the limitations of
`syntax-rules'. Maybe I can answer your question better if we decide
on how we want the interface to look like if don't care whether it can
be implemented with `syntax-rules'.

Another possibility allowed by a sufficiently-rich procedural macro
system could be to declare a new type of identifier binding (apart
from a binding as a variable, a pattern variable, a macro keyword),
e.g. a `keyword' binding. Then, a form like `(keyword-call foo 1 2 a:
3 b: 4)' would be portably possible, where the `keyword-call' macro
would check whether `a:' and `b:' are identifiers bound to keywords so
that the macro knows what are keyword arguments and what are macro
arguments.

Some of these procedures are extending the `syntax-case' system and
make the above possible:
https://www.gnu.org/software/guile/manual/html_node/Syntax-Transformer-Helpers.html#Syntax-Transformer-Helpers.

We cannot look into the future, but if R7RS-large becomes at least as
powerful in the macro department, we may even be able to make SRFI
177's syntax to be as nice as the existing native systems.

>
>>
>> > Unfortunately, the Chibi syntax-case layer depends on syntactic closures,
>>
>> whereas Chicken and Gauche only provide explicit renaming.  (Syntactic closure support is rare:  MIT, Chibi, Picrin.)
>>
>> What do you mean by "unfortunately"?
>
>
> By "unfortunately" I mean that if an implementation of syntax-case could be provided on top of explicit renaming, then the barrier to adopting syntax-case as a standard part of the large language is greatly reduced.
>
>>
>>  while `syntax-case'
>> cannot be implemented on top of explicit renaming or syntactic
>> closures, it can after slight modifications.
>
>
> Do you mean modifications to syntax-case itself, or to the substrate?  And what would those modifications consist of?  We could standardize slightly different versions of either.

I meant modifications of the substrate.

First of all, `define-syntax' has to accept transformers that are just
a procedure taking a single argument (the form that is to be
transformed). In this modified system, the original transformers like
`er-macro-transformer' become forms evaluated at compile time that
evaluate to such single argument procedures.

Secondly, every renamed identifier (through `rename' in
`er-macro-transformer', for example) has to remember the local rename
map. Otherwise things like `datum->syntax' (and thus things like SRFI
99) cannot be implemented. For that, it would be enough that the
substrate provides a procedure like `datum->syntax' that takes a
symbol and an identifier and yields an alias of symbol as if
introduced where the identifier was introduced.

Thirdly, one has to be able to define a new kind of binding, namely
bindings as pattern variables.

Next, the substrate has to allow identifier macros.

Lastly, we need parameter objects containing the macro and the usage
environment at expansion time.

All of these changes/additions are not particularly hard to implement
in a working `er-macro-transformer' system. Except for psychological
reasons, I don't see a barrier. The most costly part may be to
implement the pattern matcher of `syntax-case', but this is the same
matcher needed for `syntax-rules'.

On the other hand, it doesn't seem to be possible to implement
`er-macro-transformer' unmodified and efficiently on a `syntax-case'
system. `er-macro-transformer' misses the `bound-identifier=?'
abstraction (it just uses `eq?') and it forces to completely unwrap
all syntax objects, making it slow.

From a user's point of view, nothing speaks for `er-macro-transformer'
in my opinion if one has access to `syntax-case'.
`ir-macro-transformer' of Chicken is better than
`er-macro-transformer', but it is slow and doesn't do anything better
than `syntax-case'.

Thus, standardizing `er-macro-transformer' does not make sense in my
opinion. If we want to standardize something very low level, it should
be something on top of which things like `syntax-case' can be
implemented and which is implementable by Schemes like Guile, Chez,
etc. as well. However, I don't see a compelling reason for such a
low-level system as people will want/should use a higher level system.

Marc
--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/