Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 16:29 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(10 Sep 2020 16:34 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Duy Nguyen
(10 Sep 2020 16:42 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Lassi Kortela
(10 Sep 2020 16:57 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Duy Nguyen
(10 Sep 2020 17:09 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Lassi Kortela
(10 Sep 2020 17:21 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Duy Nguyen
(10 Sep 2020 17:35 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(10 Sep 2020 17:37 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 17:36 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Duy Nguyen
(10 Sep 2020 17:51 UTC)
|
Re: Remove file descriptors completely from srfi-170?
John Cowan
(10 Sep 2020 18:11 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Duy Nguyen
(10 Sep 2020 18:49 UTC)
|
Re: Remove file descriptors completely from srfi-170?
John Cowan
(10 Sep 2020 18:52 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 19:02 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Lassi Kortela
(10 Sep 2020 19:12 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(10 Sep 2020 19:08 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Lassi Kortela
(10 Sep 2020 19:16 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 19:23 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(10 Sep 2020 19:28 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Shiro Kawai
(10 Sep 2020 19:58 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(10 Sep 2020 20:02 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Shiro Kawai
(10 Sep 2020 20:13 UTC)
|
Re: Remove file descriptors completely from srfi-170?
John Cowan
(10 Sep 2020 20:19 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 20:49 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(11 Sep 2020 13:20 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(11 Sep 2020 14:04 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(11 Sep 2020 14:56 UTC)
|
Re: Remove file descriptors completely from srfi-170?
John Cowan
(11 Sep 2020 15:32 UTC)
|
Re: Remove file descriptors completely from srfi-170?
John Cowan
(10 Sep 2020 20:18 UTC)
|
Re: Remove file descriptors completely from srfi-170?
Marc Nieper-Wißkirchen
(11 Sep 2020 13:50 UTC)
|
R7RS scope & yearly editions
Lassi Kortela
(11 Sep 2020 14:10 UTC)
|
Re: R7RS scope & yearly editions
Marc Nieper-Wißkirchen
(11 Sep 2020 14:22 UTC)
|
Re: R7RS scope & yearly editions
Lassi Kortela
(11 Sep 2020 14:26 UTC)
|
Re: R7RS scope & yearly editions
hga@xxxxxx
(11 Sep 2020 14:31 UTC)
|
Re: R7RS scope & yearly editions
Marc Nieper-Wißkirchen
(11 Sep 2020 14:48 UTC)
|
Re: R7RS scope & yearly editions & language interop
Lassi Kortela
(11 Sep 2020 15:20 UTC)
|
Re: R7RS scope & yearly editions & language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 15:28 UTC)
|
Re: R7RS scope & yearly editions & language interop
John Cowan
(11 Sep 2020 17:11 UTC)
|
Language interop
Lassi Kortela
(11 Sep 2020 17:55 UTC)
|
Re: Language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 18:04 UTC)
|
Re: Language interop
Lassi Kortela
(11 Sep 2020 18:14 UTC)
|
Re: Language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 18:28 UTC)
|
Re: Language interop
hga@xxxxxx
(11 Sep 2020 18:51 UTC)
|
Re: Language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 20:29 UTC)
|
Re: Language interop
hga@xxxxxx
(11 Sep 2020 21:00 UTC)
|
Re: Language interop Marc Nieper-Wißkirchen (12 Sep 2020 07:26 UTC)
|
Re: Language interop
Lassi Kortela
(11 Sep 2020 19:18 UTC)
|
Re: Language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 20:38 UTC)
|
Re: Language interop
John Cowan
(11 Sep 2020 20:51 UTC)
|
Re: Language interop
hga@xxxxxx
(11 Sep 2020 18:30 UTC)
|
Re: Language interop
John Cowan
(11 Sep 2020 19:46 UTC)
|
Re: Language interop
Marc Nieper-Wißkirchen
(11 Sep 2020 20:15 UTC)
|
Re: Language interop
John Cowan
(11 Sep 2020 19:42 UTC)
|
Re: R7RS scope & yearly editions
hga@xxxxxx
(11 Sep 2020 15:35 UTC)
|
Re: R7RS scope & yearly editions
Marc Nieper-Wißkirchen
(11 Sep 2020 15:56 UTC)
|
Re: R7RS scope & yearly editions & syntax debates are so 1980
Lassi Kortela
(11 Sep 2020 16:36 UTC)
|
Re: R7RS scope & yearly editions & syntax debates are so 1980
John Cowan
(11 Sep 2020 17:02 UTC)
|
Interlisp and structural code editing
Lassi Kortela
(11 Sep 2020 17:45 UTC)
|
Re: Interlisp and structural code editing
John Cowan
(11 Sep 2020 20:16 UTC)
|
Re: R7RS scope & yearly editions
John Cowan
(11 Sep 2020 16:57 UTC)
|
Re: R7RS scope & yearly editions
Marc Nieper-Wißkirchen
(11 Sep 2020 17:23 UTC)
|
Re: R7RS scope & yearly editions
John Cowan
(11 Sep 2020 20:31 UTC)
|
Re: R7RS scope & yearly editions
Arthur A. Gleckler
(12 Sep 2020 17:39 UTC)
|
Re: R7RS scope & yearly editions
John Cowan
(11 Sep 2020 16:39 UTC)
|
Re: R7RS scope & yearly editions
Marc Nieper-Wißkirchen
(11 Sep 2020 17:01 UTC)
|
Re: R7RS scope & yearly editions
Lassi Kortela
(11 Sep 2020 17:15 UTC)
|
Re: Remove file descriptors completely from srfi-170?
hga@xxxxxx
(10 Sep 2020 18:40 UTC)
|
Am Fr., 11. Sept. 2020 um 23:00 Uhr schrieb <xxxxxx@ancell-ent.com>: > > Clojure, being tied to the JVM, has the same evaluation model > > I don't know what this means in this context. If you write a meta-circular evaluator in a language, it inherits a lot of properties. For example, it is easy to implement Scheme with proper tail calls in a language that does have proper tail calls itself. Because C's evaluation model is less sophisticated, it is easy to implement an evaluator for C in Scheme, but not the other way around (when you want to implement the language through transpiling, not interpretation). The JVM neither has proper tail calls nor call/cc. > > and, in particular, no proper tail calls. Why would I consider it > > a proper functional language? > > It's a hosted language, CLR and JVM first, now I believe JavaScript and > JVM are the big platforms. For the JVM, it has hacks that cover a > good fraction of proper tail call use cases. One is even nice in > confirming a tail call during compilation (in the modern style, > everything is compiled before execution), so you catch errors there > error instead of by blowing your stack. Proper tail calls are vital to express iterative algorithms in a functional language. An example of such an iterative algorithm is SRFI 1's fold (while its fold-right is a recursive algorithm). For fold "these hacks" are enough because it just tail-calls itself. For more general algorithms, though, "these hacks" do not generalize. One of the major lessons learned while Scheme was invented is that lambda is the ultimate label. This insight, however, can only unlock its potential if the language has proper tail calls. Moreover, to make higher-order functions in a strict programming language truly universally usable, one needs call/cc (for example, to short-circuit `for-each` or to proceed with `find` after rejecting a result found). Clojure doesn't have call/cc either. > But last time I checked, functional programming wasn't defined by TCO, It's not TCO, it's PTCs! > Clojure is a *lot* more purely functional than Scheme, is by default > functional, with mutation isolated to special cases, including the > MVCC STM one. The data structures are all immutable and readable, and > the collections are particularly well done, primarily lists, vectors, > maps, and sets. That's a library issue. In Scheme, it is my choice whether I use immutable data structures or not. For example, you can choose between SRFI 41 and SRFI 158. I agree that the number of data structures Scheme offers was quite small before R7RS (large), but that's not tied to the language itself. Marc