I think that haiku is great OS , and i have been on BeOs since start and i like it , and legacy goes on.
Also as a developer , when i have discovered lisp in wast ocean of languages and seen what it can do , I thought that combination of powerful OS with Lisp like Unix , and mixing languages two philosophies could give powerful performance , since the BeOs is powerful , and Haiku also ,why not give it more power with lisp , it could boost production , debug stage , also develop new system components + common lisp library-es are full of good tested code that can be implemented in all stages of development , with that you can make Haiku Os Superior OS in years to come. Idea is to make Unix piping into Lisp and from Lisp to Program , and You can outperform any OS of today . Because development sages with common lisp are fast , nothing is faster in live development than lisp , if you do not belive me , read from number of cases where lisp had prove to get the best results .
I think that haiku is great OS , and i have been on BeOs since start and i like it , and legacy goes on.
If you are interested bringing LISP to Hiaku, you should try to actualize the ecl recipe in HiakuPorts, and/or port other lisp implementation. Feel free to send your pull requests.
Although I fully share your enthusiasm about Lisp (Common Lisp, to be precise), Haiku is and will remain the OS written in C++. For Lisp running on bare metal, you can try something like Genera (https://static.loomcom.com/genera/genera-install.html) or Mezzano (https://github.com/froggey/Mezzano). Additionally, you can run Linux with Emacs like window manager, e.g. exwm (https://github.com/ch11ng/exwm).
As for Lisp on Haiku, ECL (https://common-lisp.net/project/ecl/) was once available by @KapiX. There is good chance it can still be compiled, although I never seen it in repository. You can safely run ABCL (https://common-lisp.net/project/armedbear/) which runs over JVM. I started porting SBCL (http://sbcl.org/) to Haiku. For now I have nothing to offer. The porting seems to be straight-forward, but it just needs time and care which I don’t have just now.
Do not expect Lisp binding to Haiku API of any sort. Of course, you can provide it, having Lisp FFI (for C it is easier than for C++, but it is doable).
Are these various implementations of the same thing? I mean, supposing that there’s such a thing as software written in Lisp that someone might want to run on Haiku, it doesn’t much matter whether they find ECL there, or ABCL or SBCL? I guess Emacs Lisp certainly doesn’t count.
Emacs lisp is not a common lisp, neither is Guile or Scheme but they are variants of Lisp… there however is a good degree of interoperability between standardized Common Lisp implementations, such as ECL, Clisp, SBCL and ABC… etc… when inspecting a common lisp implementation you may want to see if they support the following in addition to common lisp itself:
I was thinking about common lisp implementation , since it is mostly used, and it is good for work and it has good library to start with. I have found a lisp implementation that works with BeOs
that is all for start that is needed . But requires work , to build , loading interface , library support system , which I intend to emulate to be functional programming env , since it is possible , next to do is to make brige to api , so I can load source from API , and compile it in Lisp ( Maping Hibrid ) , to make objects from API sources and than to combine in live components , that way I can Instantiate whole system , in a way lisp is like live Virtual Machine and also can do live coding on source, which I think is nice
I believe, the shortest way to what you want is ECL. It is standard Common Lisp implementation and is created to optimize inter-operation with C++. Particularly, it has a good binding to Qt library. Haiku also has a good Qt port and many GUI applications are written in Qt.
As of CLISP, it seems stale. Many libraries available in quicklisp don’t work with CLISP.
Clisp is very portable also… it runs on almost anything even if broken at the moment it probably wouldn’t be hard to fix, and it’s more commonly in use than ECL… ECL is not as good an interactive lisp , it’s more for embedding lisp into other applications.
This is the current official repository https://gitlab.com/gnu-clisp/clisp
Also I wouldn’t be supprised if you are talking about an ancient version of Clisp for BeOS that it doesn’t work with quicklisp…
Thank You for support , I will test with ECL , to see what results will be
Also thank you cb88 I will try that also to see how is working
I thought I’d drop by and let anyone who happens to come upon this thread know that if you can get ECL running, you can use it to bootstrap an sbcl build with which you can build sbcl for real.
It probably sounds weird to install ecl, to bootstrap sbcl, so you can build sbcl, but it wouldn’t be lispy if it wasn’t a bit circular. Or even… dare I say… metacircular. Anyway, if you’re on amd64, the process shouldn’t be too bad.
You are right, @clintm. Common Lisp has several features that are so outstanding, that they cannot be implemented in any non-dynamic language directly, including C/C++, Pascal/Delphy etc. Common Lisp is only easy to implement in Common Lisp itself or in some its dialect.
There are 2 standard ways to overcome this:
- By using Assembler heavily (or other low-level programming similar to what Assembler achieves),
- Writing Common Lisp as interpreted meta-language in some language which lacks Lisp’s dynamic features.
The 2nd approach usually results in rather slow implementation. The first approach results in a good performance, but each single port should be made manually and carefully, keeping track on particularities of every hardware architecture and every OS it is ported onto.
Your suggestion to use ECL to bootstrap SBCL seems to be the most straight forward. But besides playing in low-level stuff in SBCL it is also necessary to bring ECL into working state. I personally use ABCL to try to bootstrap SBCL, admittedly it is much slower solution, but I can concentrate my effort to SBCL internals.
- Write an emulator for a CPU in any language of your choice, and run your assembler-written LISP there.
There is no magic in this language, if it can run on a CPU, you can implement it using any other turing complete language (yes, even CSS).
Indeed. My reply names “standard ways” and follows the approaches described in “Les Langages Lisp” (also known as “Lisp in Small Pieces”) by Christian Queinnec. If you mind something like
Bochs (emulates x86 hardware), its performance is particularly greately slower than
Qemu (emulates software, but not also hardware).
Of course. Unfortunately, beside Turing completeness, there is also Lambda completeness (by Alonzo Church, appeared just before Turing theory), and their equivalence is not a trivial. Although it is proved (Church–Turing thesis - Church–Turing thesis - Wikipedia), it is still very difficult to implement as a working engineering solution. Present day computer’s architecture basically resembles Turing machine. And so are also imperative languages, namely C and C++. But there were also Lisp machines (Lisp machine - Wikipedia) whose architecture was radically different and whose system language was Lisp (yes, each and every bit of the whole OS, including the kernel and all the drivers were written in Lisp).
I agree, there is no magic in the Lisp language. Still, with respect to implement lambda calculus (Lisp) on Turing machine architecture (modern computers) in an efficient way, Common Lisp (and any of its dialects) is not just like any other language. So in essence your choice is:
- To have a portable, easily bootstrap-able and slow implementation due to some abstraction level,
- To have an implementation with good performance, but which needs to be translated by hand between Turing and Lambda architecture on each and every hardware architecture (except it is Lisp machine) and OS.
This discussion could be a little more positive with a concrete example or two. What’s a thing that may be done in assembly language but not C? Maybe efficient tail recursion for example? In the interpreter?
Is it possible that a Lisp interpreter could be implemented in C, but just not practically useful for any real life application because no tail recursion, inefficient garbage collection, etc.? Practically the same as the virtual machine solution, in its impracticality.
I’ve been building the GHC Haskell compiler on Haiku, at this point just for my amusement, and it has a similar problem, needs GHC to build GHC. But as far as I know, it isn’t because the implementation is impossible in C, it’s just too massive for Haskell programmers to accomplish in C and remain sane. There were in fact older versions that could produce intermediary .c files, and that’s how I initially got it going on Haiku years ago. Someone else had built it for NetBSD, so I built the .c file version there, with parameters adjusted for Haiku, copied the C files over to Haiku and compiled them. (That feature has since disappeared, so you have to start from way back at this point.) Haskell builds native executables, but the runtime likely poses similar challenges to Lisp - efficient tail recursion, garbage collection, etc.
Please make notes about your porting jurney if it is possible so the HaikuPortsteam can replicate it. Thank You!
Tail recursion in C is possible if your compiler is able to optimize things.
One thing that’s not possible in C is coroutines, you can approximate them but there is a performance hit (and it’s ugly and/or require extensions to the language). But I don’t think Lisp is made easier by coroutines?
As for GHC, we got it packaged by cross-compiling an initial version from Linux. We now have a rather minimal recipe (just the compiler) and still need to bring in cabal, and all the Haskell ecosystem. I wish we could get pandoc to run, someday!
A bit offtopic, but still…
The largest difference between Lisp and C++ is the fact functions (and lambdas) in Lisp are first class citizens unlike in C++. The following examples show it:
(let ((value 0))
(defun deposit (amount)
(incf value amount))
(defun withdraw (amount)
(when (>= value amount)
(decf value amount))))
Here, we defined 2 functions,
withdraw that share the same local variable
value, which is not visible outside of these 2 functions. In C++ closures are possible still C++11 with lambdas, but the value of captured variable, over which lambda closes, is undefined in this case.
- Copy function definition
(setf (symbol-function 'sum) #'+)
(sum 5 7)
copies the definition of
+ function into
sum, which can now be called as if it would be defined.
- Function definition as user input
(let ((fun (eval (read))))
(funcall fun 5 7))
fun is introduced by user, and its definition is evaluated. Now, it can be used.
Sure, but I thought the question at hand was not whether Lisp is like C, but whether it may be implemented in C. I’m sure there are complications I am overlooking, but … are those features not trivial to implement?
Haskell may have an advantage here, because it doesn’t really have variables per se, which radically simplifies namespaces.
I was just building recently released 8.8.1, and while of course your patches wouldn’t just apply, there isn’t anything super tricky about the fixes.
pandoc looks impressive. Who knows, I expect I could build it if I had a need to (maybe with 8.6, 8.8 breaks too much stuff at the moment), but it wouldn’t be any use to you because it would have to come with recipes to build every last bit of it. (cabal is one of the things that 8.8 breaks, or breaks dependencies anyway.) If I could get patches in to maintainers so that cabal could bring in dependencies out of the box, would “cabal install” suffice for a recipe?