Email list hosting service & mailing list manager

Unicode lambda Lassi Kortela (12 May 2019 10:19 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 11:18 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:40 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:50 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 12:06 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (12 May 2019 12:11 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 12:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:46 UTC)
Re: Unicode lambda John Cowan (12 May 2019 14:20 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:38 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:55 UTC)
Re: Unicode lambda John Cowan (12 May 2019 15:00 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 15:20 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 18:42 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 19:43 UTC)
Re: Unicode lambda John Cowan (12 May 2019 22:29 UTC)
Re: Unicode lambda Shiro Kawai (13 May 2019 10:48 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 08:25 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (14 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:10 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:59 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 12:35 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 13:09 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 14:04 UTC)
Re: Unicode lambda Shiro Kawai (14 May 2019 19:18 UTC)
Re: Unicode lambda Vincent Manis (14 May 2019 22:01 UTC)
Re: Unicode lambda Lassi Kortela (20 May 2019 09:21 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 14:20 UTC)
Re: Unicode lambda Shiro Kawai (21 Oct 2019 17:19 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 17:39 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 18:43 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 23:27 UTC)
Encoding declarations Lassi Kortela (22 Oct 2019 08:39 UTC)
Re: Encoding declarations John Cowan (22 Oct 2019 20:52 UTC)
#! directives, general and specific Lassi Kortela (22 Oct 2019 09:11 UTC)
Re: #! directives, general and specific John Cowan (22 Oct 2019 20:27 UTC)
Re: #! directives, general and specific Lassi Kortela (22 Oct 2019 20:43 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (13 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (13 May 2019 10:27 UTC)
Re: Unicode lambda Per Bothner (12 May 2019 14:17 UTC)
Re: Unicode lambda Peter (12 May 2019 15:06 UTC)

Re: #! directives, general and specific Lassi Kortela 22 Oct 2019 20:43 UTC

>> John said he prefers #!precision 25. If I understood correctly, it's
>> because in #!x y, the #!x can affect how the y is read. In #!(x y) the y
>> has to be read in using the reader settings that were in effect before
>> the directive appears. I don't understand the implications; are there
>> cases where the directive should affect how it reads its own settings or
>> metadata? Perhaps there could be.
>
> The encoding declaration that we were discussing is an obvious case.  The
> less junk that has, the better for everyone.
>
> Here's another case:  #!exact, which means that all literals are read as
> exact numbers, and its counterpart #!inexact.

I don't understand how either of these makes a case for or against
directives wrapped in parentheses:

- A parenthesized #!exact would be simply #!(exact). What is the difference?

- A parenthesized #!encoding utf-8 is #!(encoding utf-8). Again, how
could this be read in differently? Both declarations just use ASCII.

Where it makes a difference would be something like #!exact 123.45
versus #!(exact 123.45). In the former case, `#!exact` would be read
first and would cause 123.45 to be read in as (exact 123.45) instead. In
the latter case, the 123.45 inside the parentheses has already been read
in by the time the `exact` directive is interpreted. But this is a
pedagogical example; nobody would actually design a mechanism like this.

>> 1) Open each Scheme file as a byte port initially.
>>
>> [...]
>
> That's basically what my XML encoding sniffer algorithm does.

As well as my S-expression-based encoding/shebang-line reader, which was
also posted some months back:
<https://github.com/lassik/scheme-encoding-declaration>. But currently
Gauche and Kawa use "coding:" comments. We decided then to not make any
decision and wait for UTF-8 market share to increase further :)

> In addition to phasing related to syntax, there is also phasing related to
> lexical syntax.  A directive that changes the lexical syntax that `read`
> parses should not have to use `read`, much less `eval` to do it's work.
> That's the problem with SRFI-10's define-reader-ctor! to change the meaning
> of #,(foo ...); it is a procedure, so it operates at run time, which is too
> late to affect the lexical syntax of the program the call appears in.

That makes sense. Is that why you prefer to avoid parenthesized
directives? Anyway, in that case the parenthesized directive is fully
read in before interpreting the directive. So it is read using the old
reader configuration, not the new one.

>> If I take a Python file and put `#!lang python` on top, ordinary
>> Python can no longer read it.
>
> While this objection is sound in the general case (won't work with Fortran,
> C, Java), it so happens that a lot of so-called scripting languages treat #
> as a comment marker:  awk, Perl, Python, bash, PHP, R, probably others.

Hah, that is true :) As the first line it's problematic, since even a
Racket script has to start with a #!/usr/bin/env racket line (in
addition to #lang) sometimes. But if # is the comment character
everywhere, that doesn't matter.

Anyway, in the general case the point stands.

> Perl, in fact, respects hash-bangs itself as a throwback to the days when
> kernels did not:  if you have a file "chicken-code.scm" that begins "#!env
> csi" and you give the command "perl chicken-code.scm", Perl will actually
> exec Chicken to interpret it.
>
> Put "#env cat" at the top of a random text file, then set the exec bit on
> it, run it, and see what happens.

Wild.

>> If Scheme implementations want to support non-Scheme languages, they
>> should work with the established customs of those communities instead of
>> inventing our own customs as outsiders. That's why I'd prefer to have
>> multi-language-support metadata in some file(s) outside the source files
>> themselves.
>
> The trouble with that is that if you specify it file-by-file it doesn't
> scale.

You can have a metadata file per directory and tie it together with
Scheme's ordinary library lookup system so you can import code written
in a non-Scheme language that the Scheme implementation can also read.
Again, I strongly believe this is the right approach and would like to
sell that idea of embracing and extending Snow-Fort's package.scm files :p