Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(19 Mar 2022 05:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(19 Mar 2022 08:24 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
John Cowan
(19 Mar 2022 18:57 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(19 Mar 2022 20:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(19 Mar 2022 22:11 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(20 Mar 2022 07:50 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
John Cowan
(20 Mar 2022 22:34 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Feeley
(21 Mar 2022 04:49 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 06:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 06:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(21 Mar 2022 19:00 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(21 Mar 2022 16:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 16:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures Taylan Kammer (23 Mar 2022 14:20 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(23 Mar 2022 14:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(23 Mar 2022 15:40 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(23 Mar 2022 15:34 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(23 Mar 2022 22:08 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(01 Apr 2022 23:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(01 Apr 2022 23:21 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(01 Apr 2022 23:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(01 Apr 2022 23:50 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(02 Apr 2022 00:01 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(02 Apr 2022 00:35 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(10 Apr 2022 23:46 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(27 Mar 2022 16:54 UTC)
|
On 21.03.2022 15:58, Dr. Arne Babenhauserheide wrote: > > Linas Vepstas <xxxxxx@gmail.com> writes: > >> I'd like scheme to be as-fast-as-possible, as what else is it offering the world? it's not going to be python or java or rust. It may as well be tight. > > One thing that impressed me about Scheme is that, while not being totally > about performance, it avoided features that forced using hard to > optimize approaches. > > That’s where I see the role of the standard: leave the implementations > to actually produce the high performance code, but take care to make > their job easy. > > Making a high-performance Scheme should not require building a huge V8 > or SpiderMonkey or Javascript Core system with their massive memory > consumption and bulging complexity. Those are the consequence of > language-design-by-accident. The same goes for Java and the JVM. Yes, it > is awesome what performance they got, but it should not be that hard. > > Finding the right limitations for a language to make it easy to optimize > without placing the burden on the programmers is hard; but it’s one of > the things that make Scheme special to me. > > I loved it that the discussion about ER and syntax-case was decided on > the basis of “we can only have one, because if we implement one, the > other provably¹ requires more than O(N) for expansion”. > > ¹: I did not see the proof, though — maybe I should have dug deeper. > > Best wishes, > Arne A big +1 on this. I see Scheme as being in a very interesting place with regard to the question of "very high-level" languages like Python vs. "lower-level" languages like C. On one hand we have incredible things like hygienic macros with pattern matching, procedural macros, delimited continuations (not standardized yet but still), correct maths by default, and so on, yet on the other hand a lot of these things are defined in such a way that they map to lower level concepts and don't necessarily hinder (relatively) efficient implementation, at least if your implementation uses some key optimization strategies. Macros are inherently compile-time. Use of continuations can be turned into a simple jump instruction after rudimentary static analysis, tricks for storing small numbers ("fixnums") on the stack are well-known, and the language doesn't force dynamic dispatch on data structures since you can use type-specific accessors like vector-ref. We even have a bunch of type-specific equality procedures, plus eq?, eqv?, and equal?. I'd say Scheme is "high-level in all the right places." :-) -- Taylan