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)
|
>> 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