Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 16:36 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 18:46 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 18:55 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 19:20 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 20:14 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (31 Jul 2019 20:49 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 20:51 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 20:55 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 21:00 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 21:21 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 22:03 UTC)
Re: State of Scheme in the Browser Lassi Kortela (01 Aug 2019 09:40 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (01 Aug 2019 11:25 UTC)
Re: State of Scheme in the Browser John Cowan (01 Aug 2019 14:18 UTC)
Re: State of Scheme in the Browser Lassi Kortela (02 Aug 2019 10:24 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (02 Aug 2019 19:19 UTC)
Re: State of Scheme in the Browser Lassi Kortela (02 Aug 2019 20:42 UTC)
Re: State of Scheme in the Browser Arthur A. Gleckler (02 Aug 2019 00:55 UTC)
Re: State of Scheme in the Browser John Cowan (02 Aug 2019 01:17 UTC)
Re: State of Scheme in the Browser Arthur A. Gleckler (02 Aug 2019 01:28 UTC)
Re: State of Scheme in the Browser John Cowan (02 Aug 2019 02:28 UTC)
Re: State of Scheme in the Browser Lassi Kortela (01 Aug 2019 09:48 UTC)

Re: State of Scheme in the Browser Lassi Kortela 31 Jul 2019 20:14 UTC

> Pre-Scheme is strongly statically typed (with Hindley-Milner typing, not
> with declarations), so not that good a match for JS.

I didn't know that it uses H-M typing. I agree that it'd probably be
nicer to use dynamic typing to compiler to JS. (Elm is accomplishing
interesting JS feats with quite strict H-M typing, but it's a very
different world from Scheme.)

> Personally I've always thought that full-blast interprocedural HM is
> problematic: a little error and your code may typecheck, but the types
> assigned are not the types you expected!  As a matter of language
> design, I think it's better if procedure arguments and global variables
> always have to be explicitly typed; we shouldn't try to infer argument
> types from calls elsewhere in the program.

It does lead to weird types sometimes, but you can always fix it by
hand. The Elm compiler shows you all top-level types it inferred and
says, "if this type annotation looks right, please copy-paste it into
your code".