Email list hosting service & mailing list manager

SRFI 220: Line directives Arthur A. Gleckler (09 Feb 2021 23:01 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 06:49 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 07:20 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 08:46 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 10:14 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:37 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:19 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:24 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 10:30 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:54 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 11:13 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:31 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 12:41 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:49 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:12 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 13:21 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 12:47 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:53 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 12:56 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 12:57 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 13:05 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 13:13 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:26 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 13:36 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:49 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 15:42 UTC)
Re: SRFI 220: Line directives Lassi Kortela (11 Feb 2021 10:06 UTC)
Declarations in general Lassi Kortela (11 Feb 2021 10:26 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (11 Feb 2021 12:18 UTC)
Re: SRFI 220: Line directives Lassi Kortela (11 Feb 2021 12:57 UTC)
Re: SRFI 220: Line directives Lassi Kortela (17 Feb 2021 08:23 UTC)
Re: SRFI 220: Line directives John Cowan (18 Feb 2021 03:07 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (18 Feb 2021 10:16 UTC)
Re: SRFI 220: Line directives John Cowan (18 Feb 2021 23:47 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:08 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:16 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:18 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:27 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:32 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:42 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 08:35 UTC)
Re: SRFI 220: Line directives John Cowan (20 Feb 2021 01:11 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:25 UTC)

Re: SRFI 220: Line directives Lassi Kortela 10 Feb 2021 12:41 UTC

> No, you can't use Scheme's `read` because it would sometimes interpret
> the text incorrectly (as shown by my emacs local variable example) or it
> would produce an error for unparsable datum comments, which can
> nevertheless be valid in their native DSL syntax.

We are pursuing different goals. I think generality is a mistake in this
case, and restricting the directives to those that can be represented as
Scheme datums is desirable.

And way to encode language-agnostic data in source files is going to end
up as a mess, due to the great variety of host language syntaxes you
have to accommodate, unless you stick to really simple stuff. I went
through the archive of magic comment samples I have, and once you get
into the hairier examples (e.g. ad hoc macro processors for languages
that don't have good macros of their own) the end result is a lost cause
from an aesthetic point of view. And largely from a usability point of
view as well, the two being correlated.

I think encouraging that trend is a mistake. Being able to faithfully
represent all data in Scheme is useful, but it's an anti-goal to
faithfully represent all the ad-hoc encodings of that data.

> The fundamental design flaw also shows up when you consider shebangs:
> You cannot parse them as you want to parse the rest of the "#! " syntax:
>
> #! /usr/bin/scheme -I 'a/b/c' -x (
> ...
>
> What happens to the quotes? The open parentheses would be unbalanced, etc.

IMHO this is a good example of the kind of thing we should not encourage :)

The portable Unix shebang lines are basically:

#! /bin/sh
#! /usr/bin/env foobar

Everything else is bound to hit some kind of problem or another. Even
the "/usr/bin/env" thing is an unfortunate hack since Unix kernels don't
know how to search PATH by themselves.