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