Re: [PATCH] add language/wisp to Guile?

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 9006 bytes --]

On 18-02-2023 04:50, Philip McGrath wrote:
> I haven't read the patch or this thread closely,

I'll assume you have read it non-closely.

> but R6RS has an answer to any concerns about compatibility with `#lang`. At the beginning of Chapter 4, "Lexical and Datum Syntax" (<http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_chap_4>) the report specifies:
> 
>>   An implementation must not extend the lexical or datum syntax in any way, with one exception: it need not treat the syntax `#!<identifier>`, for any <identifier> (see section 4.2.4) that is not `r6rs`, as a syntax violation, and it may use specific `#!`-prefixed identifiers as flags indicating that subsequent input contains extensions to the standard lexical or datum syntax. The syntax `#!r6rs` may be used to signify that the input afterward is written with the lexical syntax and datum syntax described by this report. `#!r6rs` is otherwise treated as a comment; see section 4.2.3.

That is for '#!lang', not '#lang'.  R6RS allows the former, but the 
patch does the latter.  As such, R6RS does not have an answer about 
incompatibility with `#lang', unless you count ‘it's incompatible’ as an 
answer.

> Chez Scheme uses such comments to support extensions to lexical syntax, as documented in <https://cisco.github.io/ChezScheme/csug9.5/intro.html#./intro:h1>:
> 
>> The Chez Scheme lexical extensions described above are disabled in an input stream after an `#!r6rs` comment directive has been seen, unless a `#!chezscheme` comment directive has been seen since. Each library loaded implicitly via import and each RNRS top-level program loaded via the `--program` command-line option, the `scheme-script` command, or the `load-program` procedure is treated as if it begins implicitly with an `#!r6rs` comment directive. [...]

Again, that's '#!whatever', not '#lang' -- Chez does the former, not the 
latter.

> In Racket, in the initial configuration of the reader when reading a file, "`#!` is an alias for `#lang` followed by a space when `#!` is followed by alphanumeric ASCII, `+`, `-`, or `_`." (See <https://docs.racket-lang.org/reference/reader.html#%28part._parse-reader%29>.) [...] > (Guile does not handle `#!r6rs` properly, presumably because of the 
legacy `#!`/`!#` block comments. I think this should be a surmountable 
obstacle, though, especially since Guile does support standard `#|`/`|#` 
block comments.)

‘#! ... !#’ comments aren't legacy; they exist to allow putting the 
shebang in the first line of a script, and to pass additional arguments 
to the Guile interpreter (see: (guile)The Top of a Script File) (*).  As 
such, you can't just replace them with #| ... |# (unless you patch the 
kernel to recognise "#| ..." as a shebang line).

(*) Maybe they exist for other purposes too.

Furthermore, according to the kernel, #!r6rs would mean that the script 
needs to be interpreted by a program named 'r6rs', but 'guile' is named 
'guile', not 'r6rs'.  (I assume this is in POSIX somewhere, though I 
couldn't find it.)

(This is an incompatibility between R6RS and any system that has shebangs.)

>>
>> (^) it doesn't integrate with the module system -- more concretely,
>> (use-modules (foo)) wouldn't try loading foo.js -- adding '-x' arguments
>> would solve that, but we agree that that would be unreasonable in many
>> situations.  (Alternatively one could place ECMAScript code in a file
>> with extension '.scm' with a '#lang' / '-*- mode: ecmascript -*-', but
>> ... no.)
>>
> 
> Racket has a mechanism to enable additional source file extensions without needing explicit command-line arguments by defining `module-suffixes` or `doc-modules-suffixes` in a metadata module that is consulted when the collection is "set up": https://docs.racket-lang.org/raco/setup-info.html However, this mechanism is not widely used.

I guess this is an improvement over the runtime 'guile -x extension'.
However, if I'm understanding 'setup-info.html' correctly, the downside 
is that you now need a separate file containing compilation settings.

I have previously proposed a mechanism that makes the '-x' + 
'--language' a compile-time thing (i.e., embed the source file extension 
in the compiled .go; see previous e-mails in this thread), without 
having to make a separate file containing compilation settings.

How is Racket's method an improvement over my proposal?

> Overall, the experience of the Racket community strongly suggests that a file should say what language it is written in. Furthermore, that language is a property of the code, not of its runtime environment, so environment variables, command-line options, and similar extralinguistic mechanism are a particularly poor fit for controlling it.

Agreed on the 'no environment variables' thing, disagreed on the 'no 
command-line options'.  In the past e-mails in this thread, there was 
agreement on the ‘embed the source file extension in the compiled .go or 
something like that; and add -x extension stuff _when compiling_ (not 
runtime!) the software that uses the extension’.

Do you any particular issues with that proposal?  AFAICT, it solves 
everything and is somewhat more straightforward that Racket.

> File extensions are not the worst possible mechanisms, but they have similar problems: code written in an unsaved editor or a blog post may not have a file extension.

With the proposal I wrote, it remains possible to override any 'file 
extension -> language' mapping.  It's not in any way incompatible with 
"-*- lang: whatever -*-"-like comments.

Additionally, Guile can only load files that exist (i.e, 'saved'); Guile 
is not an editor or blog reader, so these do not appear problems for 
Guile to me.

If the editor needs to determine the language for syntax highlighting or 
such, then there exist constructs like ';; -*- mode: scheme -*-' that 
are valid Scheme, but that's not a Guile matter.

> (For more on this theme, see the corresponding point of the Racket Manifesto: <https://cs.brown.edu/~sk/Publications/Papers/Published/fffkbmt-racket-manifesto/paper.pdf>) Actually writing the language into the source code has proven to work well.

What is the corresponding point?  I'm not finding any search results for 
'file extension' or 'file name', and I'm not finding any relevant search 
results for 'editor'.  Could you give me a page reference and a relevant 
quote?

> To end with an argument from authority, this is from Andy Wingo's "lessons learned from guile, the ancient & spry" (<https://wingolog.org/archives/2020/02/07/lessons-learned-from-guile-the-ancient-spry>):
> 
>> On the change side, we need parallel installability for entire languages. Racket did a great job facilitating this with #lang and we should just adopt that.

It was never in dispute that 'we need parallel installability'.
This ‘parallel installability’ is also addressed by my proposal.

For the second part: ‘Racket did a great job facilitating this with 
#lang and we should just adopt that’:

   * I previously pointed out some problems with that proposal
     -- i.e., '#lang whatever' is bogus Scheme / Wisp / ..., and
     'the module system won't find it, because of the unexpected
     file extensions'.

   * I gave an alternate proposal (i.e., the 'embed source file extension
     in the compiled .go, and add something like '-x extension' and
     '--language ...' at compilation time), which doesn't have the
     pointed out problems.

   * Andy Wingo hasn't addressed the pointed out problems with the
     Racket solution adapted to Guile.

   * Andy Wingo hasn't considered any alternative proposals in that blog
     post.

Why are you taking Andy Wingo's proposal as an argument by authority, 
when I have already pointed out the problems with that proposal and 
proposed a different solution without those problems?

‘Arguments by authority’ stop being good when someone explains how the 
authority is wrong.  As you appear to consider arguments by authority to 
be valid arguments even in the existence of evidence that the authority 
is _wrong_, here's an argument from authority that ‘arguments from 
authority’ can be refuted:

 > (From: https://en.wikipedia.org/wiki/Argument_from_authority)
> Scientific knowledge is best established by evidence and experiment rather than argued through authority[18][19][20] as authority has no place in science.[19][21] Carl Sagan wrote of arguments from authority: "One of the great commandments of science is, 'Mistrust arguments from authority.' ... Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else."[22] However, countering this it has been argued that science is fundamentally dependent on arguments from authority to progress because "they allow science to avoid forever revisiting the same ground".[23] 

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]