Re: Why is Elisp slow?

[조성빈]

> 2019. 5. 7. 오전 3:08, Stefan Monnier <monnier@iro.umontreal.ca> 작성:
> 
>> I’m curious: How likely is this to happen?
> 
> As long as noone works on it, I'd say 0% likelihood.
> 
>> I can confirm that SBCL works great on at least these platforms:
>> * Arch Linux(GNU userspace) on AMD64 (my friend’s confirmations)
>> * macOS(Darwin) on AMD64 (I’m currently using macOS)
>> * Windows 10 on AMD64 (my another friend’s confirmations)
>> * Raspbian(GNU userspace) on ARM (at least when using SBCL about a year 
>> before…)
> 
> [ IIUC of the 4 cases above, at most 2 run the same version, so we'd
>  need to make sure the same Emacs version can be compiled against all
>  of those versions.  No idea if it would impose a significant extra
>  burden or not, but it's something to be considered.  Also the fact
>  that the latest release doesn't work on all those platforms is rather
>  worrying.  ]

Hmm…? I can’t understand :-(
Why can’t Emacs can include a specific version of SBCL’s source (e.g. as a git 
module) and compile them all together?̊̈
I’m pretty sure SBCL’s platform-specific code is self-contained.

>>> Of course, Guile has the advantage that someone has already spent a fair
>>> bit of time implementing support for Elisp, whereas for CLISP and SBCL
>>> that would be extra work (Elisp is close to a subset of CL but not
>>> quite).
>> Would that extra work outweigh than implementing Guile’s language
>> integration features?
> 
> No idea.
> 
>> May I ask what part of elisp makes implementing in CL hard?
> 
> Haven't thought too much about it, so I don't even know if it would be
> hard (the elisp.lisp implementation I mentioned recently shows that
> large parts can be done easily enough).
> The obvious issue is buffer-local and terminal-local variables.
> 
>>> Another approach would be to implement an Elisp-to-JS compiler and
>>> then use one of the heavily-optimized JIT-compilers for JS.
>>> Compiling Elisp to JS should be much easier than compiling to
>>> native code.
>> 
>> If possible, this would be more than great as we would be able to use the
>> *big* number of JS packages in npm registry out there.
> 
> Note that compiling to JS doesn't *directly* let you access random JS
> data-structures and functions any more than implementing Elisp in C lets
> you access random C functions and data-structures.
> [ language-interoperation, again.  ]

Ah, I was saying libraries in general; libraries like immutable.js or left-pad 
:-)

> 
>        Stefan