Lisp on Linux?

[hop-frog]

I'm teaching myself some Lisp and I'm wondering if there are many resources for getting started in Linux. I've already found several books for learning, but they don't cover anything Linux-specific. For example... I've heard Lisp software doesn't run so well under Linux. Should I be dual-booting and developing under another OS? What editor should I be using to handle all the bracket highlighting?
What is the difference between CMUCL and CLISP? Will I be able to compile binaries under Linux that can run on Macintosh, DOS, Palm Pilots, and Amiga computers without having access to those systems?

[CaptainPinko]

Scheme is fairly close to Lisp afaik. Dr. Scheme is a pretty good IDE and its available for both windows and linux. i'm sure you could probably a LISP interpreter for linux, but unless you are specifically intrested in LISP, SCheme should let you experiment with most of the same principles of functional programming and it is supposedly reigned in by fairly conservative designers. www.drscheme.org hth

[Stuka]

CMUCL (http://www.cons.org/cmucl/) is available for Linux - and there's a ton of existing LISP code out there (Emacs uses elisp for programming the editor).

[sasKuatch]

- IDE: I use Jabberwocky. It works pretty well at the prnths. (You could also edit in Kate or Kword, as they both highlight matching pairs. (Even the CLisp command-line highlights prnths))

About Emacs: it's limited in some ways (actually quite a few, as it's not quite standard CLisp), though editing and running lispcode in it is very convenient.

All the software you really need is CLISP-x.x. You can compile with this under Linux, but I'm not sure if there are other ways to compile and I'll let you decide if this is what you need.

Here's what I mean about the compiling:

ftoc.lisp
(defun f-to-c ()
(format t "~%Please enter Fahrenheit temperature: ")
(let* ((ftemp (read))
(ctemp (* (- ftemp 32) 5/9)))
(format t
"~%~s degrees Fahrenheit is ~s degrees Celsius~%"
ftemp
(float ctemp)) ;; print floated value
ctemp)) ;; return ratio value

Becomes ftoc.fas
(SYSTEM::VERSION '(20010503.))
#0Y UTF-8
#Y(#:TOP-LEVEL-FORM-1
#20Y(00 00 00 00 00 00 00 00 00 01 DA 2F 01 DA DC 32 80 C5 19 01)
COMMON-LISP-USER::F-TO-C SYSTEM::REMOVE-OLD-DEFINITIONS
#Y(COMMON-LISP-USER::F-TO-C
#42Y(00 00 00 00 00 00 00 00 00 01 DA 63 33 01 16 38 04 71 73 DB AD 73 02
36 DC 73 02 38 DD 63 AF AF 38 01 72 AD 33 03 16 15 19 02)
#Y(COMMON-LISP-USER::F-TO-C-1
#19Y(00 00 00 00 01 00 00 00 01 17 DA AF 38 02 31 88 9E 19 03)
"
Please enter Fahrenheit temperature: ")
-32. #10r5/9
#Y(COMMON-LISP-USER::F-TO-C-2
#36Y(00 00 00 00 03 00 00 00 01 19 B0 31 8A AF B1 31 80 DA B1 38 02 31
88 AE B1 31 80 DB B1 38 02 31 88 9E 19 05)
" degrees Fahrenheit is "
" degrees Celsius
")))

And ftoc.lib
#0Y UTF-8

(PROGN (SYSTEM::C-DEFUN 'F-TO-C (SYSTEM::LAMBDA-LIST-TO-SIGNATURE 'NIL)))

[bwkaz]

Originally posted by hop-frog
I've heard Lisp software doesn't run so well under Linux. You've heard wrong... ;)

What editor should I be using to handle all the bracket highlighting? Some have been posted. vim (and gvim) handle it the exact same as most other editors, if you do a :set showmatch while in command mode (or in your ~/.vimrc file).

What is the difference between CMUCL CMU (Carnegie-Mellon University) Common Lisp

and CLISP? GNU Common Lisp.

In theory they're the same, since they're both Common Lisp interpreters. But I don't know for sure.

Will I be able to compile binaries under Linux that can run on Macintosh, DOS, Palm Pilots, and Amiga computers without having access to those systems? Not likely, unless compiled Lisp is just a text file.

If the Lisp compiler creates an actual binary executable, then there's no way you can create a compiled Lisp program on one architecture that will run on any other. There's also no way you can create a binary on one OS that will run on any other.

[AresTheImpaler]

Originally posted by bwkaz
Not likely, unless compiled Lisp is just a text file.

If the Lisp compiler creates an actual binary executable, then there's no way you can create a compiled Lisp program on one architecture that will run on any other. There's also no way you can create a binary on one OS that will run on any other.


what? really? I think you are wrong. Of course I might be the one that is wrong, but I had the idea that you could in theory compile for another architecture if you have the libraries and the compiler has the 'knowledge' on how to do this. That way you just tell the compiler what is your target architecture and it compiles it for it. Now, Lisp is an interpreted language, that means that you dont have to copile anything at all. You just need an interpreter for your tarfet machine. There are actually forms to compile lisp code, but it is not necessary. Since as I said already, lisp is an interpreted language.

[bwkaz]

Oh, cross-compiling, yeah, that's possible.

I don't know if you can cross-compile for Windows on Linux, though...

[CaptainPinko]

Originally posted by bwkaz
I don't know if you can cross-compile for Windows on Linux, though...

lisp -> jvm compiler anyone? or just use interpreters

just found this.... might be useful, didn't look at it much: http://www.franz.com/support/documentation/6.2/doc/jil.htm

[louiscypher]

what? really? I think you are wrong. Of course I might be the one that is wrong,
No doubt about it, you are wrong.
but I had the idea that you could in theory compile for another architecture if you have the libraries and the compiler has the 'knowledge' on how to do this. That way you just tell the compiler what is your target architecture and it compiles it for it.
{/i]

What you have just described is source code, which is compiled to a set of ASM instructions the same way C, C++, and now C# are. Because completely different interfaces to the kernel are provided to OS's residing on exactly the same architecture, they bear no resemblance to one another, ergo one compiler will not 'cross compile' between operating systems unless a huge amount of $ has been dumped into the development. LISP is hardly popular enough to warrant that kind of capital investment. Repeat, you have not described code which is 'interpreted' yet.

[i]Now, Lisp is an interpreted language, that means that you dont have to copile anything at all. You just need an interpreter for your tarfet machine.

Now, you are discussing a completely different propositon. If your question is, are there various interpreters for my LISP script/code which will work on DOS, MAC, and Linux? Yes, there are, but they are only going to be free on MAC (due to the BSD code base porting) and Linux that I know of.

There are actually forms to compile lisp code, but it is not necessary. Since as I said already, lisp is an interpreted language.

Do you actually know what you're talking about here? It's clear you're confused about elementary concepts. Stating that it should be clear because you said it should seems perilously close to funny.

Good luck, study hard, and write a kernel sometime. The process will remove any strange concepts some CIS prof may have left you with.

[AresTheImpaler]

Originally posted by louiscypher
There are actually forms to compile lisp code, but it is not necessary. Since as I said already, lisp is an interpreted language.

Do you actually know what you're talking about here? It's clear you're confused about elementary concepts. Stating that it should be clear because you said it should seems perilously close to funny.

Good luck, study hard, and write a kernel sometime. The process will remove any strange concepts some CIS prof may have left you with.

Oh ok.. you must be the master around here since you already wrote a kernel.. right? And let me see. You know 'everything' but couldn't tell me why I was wrong. That really shows how much you know. And since you know a lot, you can start bashing everyone else.

Now let me repeat what I said in my first post. Lisp is interpreted. But, there are ways to 'compile' the damn code because some people have argued that having a binary is faster than interpreting the code at the same time you want to 'execute' it. There is also 'half code' (or something close to that name) that is in between of being the pure code and a binary. It loads and runs faster but is not as portable.

[bwkaz]

Originally posted by louiscypher
Because completely different interfaces to the kernel are provided to OS's residing on exactly the same architecture, they bear no resemblance to one another, ergo one compiler will not 'cross compile' between operating systems unless a huge amount of $ has been dumped into the development. Then please explain how I can specify --target=sparc-sun-solaris.2 to gcc's configure script, and get a (free, BTW) compiler that runs on Linux, but compiles for Solaris on Sparc.

The executables you build with that cross-compiler won't be runnable until you move them over to the Solaris-on-Sparc machine, but they will work there.

Now that I reread the release notes for gcc 3.3.2, I see that there was also support for i?86-*-win32 before that version, which is supposed to be "Windows NT 3.x". The "Supported platforms" page also lists fun stuff like Windows (under Cygwin), *-*-sysv* (which is a LOT of non-Linux platforms...), *-*-solaris2*, and a bunch of other OSes.

You might also want to Google for "canadian cross compile", as that builds a functioning cross-compiler for one arch and OS on a differnet arch and/or OS.

[AresTheImpaler]

Since you are a master in coding not in posting and I didnt completely read your post because I tought you were quoting:

Originally posted by louiscypher
what? really? I think you are wrong. Of course I might be the one that is wrong,
No doubt about it, you are wrong.
but I had the idea that you could in theory compile for another architecture if you have the libraries and the compiler has the 'knowledge' on how to do this. That way you just tell the compiler what is your target architecture and it compiles it for it.


What you have just described is source code, which is compiled to a set of ASM instructions the same way C, C++, and now C# are. Because completely different interfaces to the kernel are provided to OS's residing on exactly the same architecture, they bear no resemblance to one another, ergo one compiler will not 'cross compile' between operating systems unless a huge amount of $ has been dumped into the development. LISP is hardly popular enough to warrant that kind of capital investment. Repeat, you have not described code which is 'interpreted' yet.

It really seems that you are theone that took the dumpy CIS classes. What you dscribing is porting to anoher 'target' machine. What I was saying is that if you have the code for a you target machine you an theoretically compile it anywhere. If you are good enough you can even compile it by hand. compiler does what ever you program it to do. If I wrte a compiler to compile for windows from my linux environment it will. LISP is not popular, I agree, but it is still a very good language for several tasks. I would recommend you to take a Programming Languages course where the go deep into what a programmng language is, its advantages, disadvantages, etc.

Originally posted by louiscypher
Now, Lisp is an interpreted language, that means that you dont have to copile anything at all. You just need an interpreter for your tarfet machine.

Now, you are discussing a completely different propositon. If your question is, are there various interpreters for my LISP script/code which will work on DOS, MAC, and Linux? Yes, there are, but they are only going to be free on MAC (due to the BSD code base porting) and Linux that I know of.


Yes I was changing the idea. Why? because I was first explaining that it is theoretically possible to cross-compile, but that for lisp you could forget about compiling since it is an interpreted language.

Then you say something about me asking a question.. I have a recommendation for you (now that we are all recommending things), take a reading and comprehension class. I never asked anything. Don't know where you got that from.

Also you are wrong when saying that it will only be free interprters on MAC because of BSD and Linux. There area lot for windows. Hell, there is a lot of free software for windows. you can find lots of free software in a cd from here:

http://gnuwin.epfl.ch/en/

[louiscypher]

Originally posted by AresTheImpaler
Oh ok.. you must be the master around here since you already wrote a kernel.. right? And let me see. You know 'everything' but couldn't tell me why I was wrong. That really shows how much you know. And since you know a lot, you can start bashing everyone else.

Now let me repeat what I said in my first post. Lisp is interpreted. But, there are ways to 'compile' the damn code because some people have argued that having a binary is faster than interpreting the code at the same time you want to 'execute' it. There is also 'half code' (or something close to that name) that is in between of being the pure code and a binary. It loads and runs faster but is not as portable.

Rewriting a kernel was just friendly advice, I don't feel the need to re-write Minix just to come to a good understanding of device driveres. If you're going far in this field though, you may have to.

What do you mean by: "But, there are ways to 'compile' the damn code because some people have argued that having a binary is faster than interpreting the code at the same time you want to 'execute' it."

'there are ways to 'compile' the ... code' - Of course, no need to quote 'compile', an LISP compile is as legitimate as a C compile.

'because some people have argued that having a binary is faster than interpreting the code' - Of course. Besides being completely obvious, we can run quick objective tests to prove it.

'at the same time you want to 'execute' it.' If you're saying that running 1 Lisp process as a binary executable and simultaneously running one Lisp script on an interpreter will result in the binary finishing first, sure, I agree.

This is interesting: There is also 'half code' (or something close to that name) that is in between of being the pure code and a binary. It loads and runs faster but is not as portable. Do you mean 'optimized' code? Code which the compiler organizes (as does every compiler anymore) functions and loops in an optimized fashion that allows them to execute in fewer clock ticks? Or does the interpreter do this, and spit out a wad of executable code, and you infer that because the interpreter is doing it, that code is tranformed in such a fashion that it's no longer 'portable'? The mystifying part to me would be that anything other than LISP text script would be transportable. I've programmed the win32 api, and I certainly wouldn't consider any of that code transportable due to the way it's bound up with the GUI libraries. (Note that MS is going to take until 2006 to release Longhorn, and I'm fairly certain that security requires separating user space from the admin process which has to initiate the GUI harware driver. Sounds pretty easy until you realize that is precisely what the rest of the OS is riding on, then it becomes a tricky issue of removal and legacy compatibility with the new monster you create.)

Hmmm, I'm interested to hear which one it is, or if I'm wrong yet again.

[AresTheImpaler]

Originally posted by louiscypher
Rewriting a kernel was just friendly advice, I don't feel the need to re-write Minix just to come to a good understanding of device driveres. If you're going far in this field though, you may have to.

What do you mean by: "But, there are ways to 'compile' the damn code because some people have argued that having a binary is faster than interpreting the code at the same time you want to 'execute' it."

you can run it interactively because it is interpreted or you could compile the source into a binary. If you run it interpreted, then it is going to be slower.

Originally posted by louiscypher
'there are ways to 'compile' the ... code' - Of course, no need to quote 'compile', an LISP compile is as legitimate as a C compile.

ok... what ever...

Originally posted by louiscypher
'because some people have argued that having a binary is faster than interpreting the code' - Of course. Besides being completely obvious, we can run quick objective tests to prove it.

good, you agree with me

Originally posted by louiscypher
'at the same time you want to 'execute' it.' If you're saying that running 1 Lisp process as a binary executable and simultaneously running one Lisp script on an interpreter will result in the binary finishing first, sure, I agree.

good.. ;)

Originally posted by louiscypher
This is interesting: There is also 'half code' (or something close to that name) that is in between of being the pure code and a binary. It loads and runs faster but is not as portable. Do you mean 'optimized' code? Code which the compiler organizes (as does every compiler anymore) functions and loops in an optimized fashion that allows them to execute in fewer clock ticks? Or does the interpreter do this, and spit out a wad of executable code, and you infer that because the interpreter is doing it, that code is tranformed in such a fashion that it's no longer 'portable'? The mystifying part to me would be that anything other than LISP text script would be transportable.

Sorry, it is not called half code, it is called byte code. It produces code that runs in a virtual machine (think java) that is not as portable because there are not many virtual machines for lisp, and most of them are not 100% compliant.

Originally posted by louiscypher
I've programmed the win32 api, and I certainly wouldn't consider any of that code transportable due to the way it's bound up with the GUI libraries.

Let me say it again.. the keyword I had in my other posts was 'target'. If I code for windows using the win32 api, and cross-compile it. It will run nicely. If you say to port code straight from windows to linux using win32 api, then no, you are going to have lots of problems. BUT you could use qt, cygwin, etc. and simplify the process.

Originally posted by louiscypher
(Note that MS is going to take until 2006 to release Longhorn, and I'm fairly certain that security requires separating user space from the admin process which has to initiate the GUI harware driver. Sounds pretty easy until you realize that is precisely what the rest of the OS is riding on, then it becomes a tricky issue of removal and legacy compatibility with the new monster you create.)


Great to hear that they are focusing more in security problems, but what does this have to do with the topic? oh, I get it.. you are just trolling...