Re: Thoughts on the simplification of CLISP

[Pascal B. <pj...@in...>]

> On 10 Jan 2017, at 22:16, Sam Steingold <sd...@gn...> wrote:
> 
> 
> You mean, "the problem is surface rather than content".
> I agree.
> 
> However, there is a Russian proverb: "One is greeted according to one's
> dress, one is sent off according to one's intelligence".
> Yes, intelligence (=="substance") is more important, but if you wear
> rugs, people won't even talk to you and will never discover your
> intelligence.
> 
> I think we need to drop the gratuitous preprocessors (varbrace &
> comment5) and rename all files to *.c.
> We need to preprocess them into *.m.c behind the scenes.
> lisbpbibl.d should be lisbpbibl.h and not preprocessed.
> &c.

Well, I both agree and disagree.


Pure C code is good, and it would be great for portability, if one could write 100% purely standard C11 code.
Like, no trick like libsigsegv, or worse ffcall/avcall which can never be compiled on new or exotic systems.
Just pure standard entirely defined behavior C11 code.

I’d like that.

You’d not like it at all, because it might imply a performance hit.  (Probably a serious performance hit 
even, if you want to implement all the features we have).




On the other hand, I’m not sure the solution is to go toward C.  Why not write lisp code, and have a 
translator that generates some throw away intermediary C code, that can be compiled anywhere?


Recently compiled a project that was build this way: https://github.com/aoh/radamsa <https://github.com/aoh/radamsa>
It’s actually written in Scheme, and it uses OL (https://github.com/aoh/owl-lisp/files/449350 <https://github.com/aoh/owl-lisp/files/449350>) a scheme to C translator,
to generate the C code that is then compiled. Since OL itself is written in scheme, and applied on itself to produce the C sources 
that are distributed. So you have a 100% C bootstrap path.

On the other hand, you can implement the software in a high level programming language.


-- 
__Pascal J. Bourguignon__