[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is Elisp slow?

From: 조성빈
Subject: Re: Why is Elisp slow?
Date: Mon, 6 May 2019 18:03:20 +0900

나의 iPhone에서 보냄

2019. 5. 6. 오후 4:33, Tadeus Prastowo <address@hidden> 작성:

> On Sun, May 5, 2019 at 5:51 PM Stefan Monnier
> <address@hidden> wrote:> Language interoperation is very
> difficult, and even more so if you want
>> both languages to be usable "equally" (as opposed to a high-level
>> language with FFI bindings, say).  The .NET platform aims to do just
>> that, and note that it's fairly complex and the most successful
>> languages there were specifically designed/tweaked for that platform.
> Out of curiosity, do you mind to elaborate on how it is to be usable
> "equally"?  (I think the best way to understand it is by studying the
> .NET platform, but maybe you could explain it better).

I would say as ‘to do something in a way that is considered idiomatic in the 
For example, some APIs (in general) makes sense when they use C++ templates or 
Rust `impl` blocks; it doesn’t make sense to enforce type unsafety.
Some APIs makes sense when they are provided as Lisp macros or babel macros; it 
doesn’t make sense to enforce boilerplate code.

Have you ever done FFI between two high level languages, e.g. Swift and Rust? 
It’s a real pain, because the interfacing code can’t use any of the language 
features as they should be defined by their common dominators: the SysV ABI.
You can’t use generics, tuples, lambdas, etc... even though both languages have 

It’s well, a somewhat similar experience.

> Thank you very much.
>>        Stefan
> -- 
> Best regards,
> Tadeus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]