Email list hosting service & mailing list manager

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)

Re: [scheme-reports-wg2] Threads and futures Taylan Kammer 23 Mar 2022 14:19 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