Review of first draft John Cowan (20 Apr 2020 14:11 UTC)
Re: Review of first draft Lassi Kortela (20 Apr 2020 15:02 UTC)
Re: Review of first draft Marc Nieper-Wißkirchen (20 Apr 2020 15:19 UTC)
Re: Review of first draft Lassi Kortela (20 Apr 2020 15:35 UTC)
Re: Review of first draft Marc Nieper-Wißkirchen (20 Apr 2020 15:45 UTC)
Loading code from standard input Lassi Kortela (20 Apr 2020 16:01 UTC)
Re: Loading code from standard input Marc Nieper-Wißkirchen (20 Apr 2020 16:30 UTC)
Re: Loading code from standard input Lassi Kortela (20 Apr 2020 16:49 UTC)
Re: Loading code from standard input John Cowan (20 Apr 2020 17:36 UTC)
Re: Loading code from standard input Lassi Kortela (26 May 2020 12:38 UTC)
Re: Loading code from standard input John Cowan (26 May 2020 17:36 UTC)
Re: Loading code from standard input Lassi Kortela (26 May 2020 17:45 UTC)
Re: Loading code from standard input John Cowan (26 May 2020 17:52 UTC)
Re: Loading code from standard input Lassi Kortela (26 May 2020 18:06 UTC)
Re: Loading code from standard input Marc Nieper-Wißkirchen (26 May 2020 18:12 UTC)
Re: Loading code from standard input Lassi Kortela (26 May 2020 18:50 UTC)
Re: Loading code from standard input Vladimir Nikishkin (27 May 2020 07:48 UTC)
Re: Loading code from standard input Lassi Kortela (27 May 2020 08:07 UTC)
Re: Review of first draft John Cowan (20 Apr 2020 16:02 UTC)

Re: Loading code from standard input Vladimir Nikishkin 27 May 2020 07:48 UTC

IDEs like to connect to a repl with a non-tty.

I think, geiser does that, and maybe scheme-mode too (not sure about DrRacket).

In a perfect world, an interpreter should have something like
"channels", and it should be possible to explicitly indicate which
"channel" to read the code from, and which the data.

Relying on a istty() is not a good option, because (read) may even
need to launch a separate GUI frame (window) for input, if the
current-input-port is configured to do so on being read.

2020-05-27 2:50 GMT+08:00, Lassi Kortela <xxxxxx@lassi.io>:
>> R7RS top-level programs are just
>> perfect to serve as scripts in the Unix sense.
>
> It seems that way to me as well.
>
>> Why standardizing "scripts" (commands read by load or a REPL) at all?
>> The REPL is not really portable.
>
> I guess it's nice if (load "foo.scm") and interpreting from stdin work
> in a predictable manner. Though you're right that neither of those seem
> preferred for real work, more for quick experiments.
>

--
Yours sincerely, Vladimir Nikishkin