> [...]
That would be nice, but would require doing changes in a critical core part of Guile. It would change this addition from a risk-free added feature to a risky core change.
I maintain that a new language shouldn't be merged until the Scheme-specific load path stuff is fixed/extended to work for non-Scheme things (e.g. Wisp) too -- if this requires somewhat risky (*) changes to core parts, then that just means we'll have to do some risky stuff, then.
I also expect that Guile maintainers will have the opposite opinion (i.e., ‘fixing the load path stuff isn't necessary for merging a new language implementation’).
(*) FWIW I disagree on the 'risky' assessment -- it seems like a ‘if it runs, it will work’ thing to me. That it modifies a core part of Guile, makes it less risky IMO, as it would automatically be more tested.
Aside from the (*) and the 'I also expect [...],', I don't have anything new to say about this, so I'll stop here.
> [...]
That would also enable shipping pre-compiled software without sourcecode,
That can already be done -- besides legalities, nothing stops people from putting [^] or [^] .scm files in $GUILE_LOAD_PATH and putting .go in $GUILE_LOAD_COMPILED_PATH.
[^]: Redacted to not give people ideas on how to circumvent stuff. I can elaborate by non-public e-mail if you like.
so there may be strategic reasons to avoid it. Always providing the sourcecode also makes compliance with automatic copyleft licenses automatic.
Mm, yes, I guess. If only people weren't careless and didn't try to circumvent copyleft, then things would be easier ...
On 14-02-2023 22:24, Dr. Arne Babenhauserheide wrote:
PS: So what’s still missing here is to avoid setting the locale. Do you
happen to have a hint how to actually do this right?
I think you might have forgotten about this:
-- Scheme Procedure: set-port-encoding! port enc
-- C Function: scm_set_port_encoding_x (port, enc)
Sets the character encoding that will be used to interpret I/O to
PORT. ENC is a string containing the name of an encoding. Valid
encoding names are those defined by IANA
(http://www.iana.org/assignments/character-sets), for example
‘"UTF-8"’ or ‘"ISO-8859-1"’.
As such, I propose calling set-port-encoding! right in the beginning of read-one-wisp-sexp.
More concretely, replace
(define (read-one-wisp-sexp port env)
;; allow using "# foo" as #(foo).
(read-hash-extend #\# (λ (chr port) #\#))
(cond
((eof-object? (peek-char port))
(read-char port )); return eof: we’re done
(else
(let ((chunk (wisp-scheme-read-chunk port)))
(cond
((not (null? chunk))
(car chunk))
(else
#f))))))
by
(define (read-one-wisp-sexp port env)
;; Allow using "# foo" as #(foo).
;; Don't use the globally-acting read-hash-extend, because this
;; doesn't make much sense in parenthese-y (non-Wisp) Scheme.
;; Instead, use fluids to temporarily add the extension.
(define %read-hash-procedures/parameter
(fluid->parameter %read-hash-procedures))
(parameterize ((%read-hash-procedures/parameter
`((#\# ,(λ (chr port) #\#))
,@(%read-hash-procedures/parameter))))
;; Read Wisp files as UTF-8, to support non-ASCII characters.
;; TODO: would be nice to support ';; coding: whatever' lines
;; like in parenthese-y Scheme.
(set-port-encoding! port "UTF-8")
(if (eof-object? (peek-char port))
(read-char port) ; return eof: we’re done
(let ((chunk (wisp-scheme-read-chunk port)))
(and (not (null? chunk)) ; <---- XXX: maybe (pair? chunk)
(car chunk))))))
(untested).
(I've also done the read-hash-extend stuff and simplified the 'cond'
expressions.)
Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
