Nicely done tutorial on how Racket can be used to write new languages, with a syntax that significantly differs from S-expressions. Apparently, it's super easy.
Name:
Anonymous2011-06-19 4:03
At least Brainfuck is readable and doesn't require a special editor.
>>4
Yes. There is a C compiler on the LispM, which is of course better than an interpreter.
It's not to hard to implement special syntaxes for Lisp, you just hook the reader then implement a parser and from there it's all Lisp. If you want other large-scale examples, look at this Python implementation in CL: http://common-lisp.net/project/clpython/
I do have to admit though that it's nice that Racket has its #lang, while in CL you would have to make your own #lang if you wanted a standardized interface for switching readers.
Name:
Anonymous2011-06-19 5:54
>>4
>LISP fanatics have said its easy to implement a C interpreter with LISP macros.
Yes. Just write a parser C/C++.
Most problematic would be handling of 32-bit integers, because Lisp's fixnums are 30-bits and don't overflow.
because Lisp's fixnums are 30-bits and don't overflow.
That depends on implementation and even in the same implementation, 32-bit and 64-bit versions will have different fixnum sizes. The standard way of handling it is to just logand the results with (1- (ash 1 32)), and maybe sprinkle some the declarations and maybe some implementation-specific ones too. Some implementations have efficient MD5/SHA1 implementations which can be examined to see what declarations should be used for efficient compilation (if you don't care about that, then just don't use any and leave it to the compiler).
Name:
Anonymous2011-06-19 6:05
>>7
Efficiency would be the main reason to compile C/C++ into Lisp: to compare compiler quality and use available fast implementation, from inside Lisp. Ideally, C/C++ compiled to Lisp should run as fast as C/C++ compiled by GCC.
>>8
C compilers tend to be better at optimizing C, at least on x86.
Compiling C to Lisp made sense on Lisp Machines as the underlying platform was build on Lisp from the ground up (from the CPU and its microcode to the language and OS).
Name:
Anonymous2011-06-19 6:16
>>8 compile C/C++ into Lisp
That's a bad idea -- at least assembly is readable!
Name:
Anonymous2011-06-19 6:20
>>9 C compilers tend to be better at optimizing C, at least on x86.
It depends on hints, compiler has. Lisp System, for example, can gather run-time statistics and optimize hot-spots just-in-time -- sadly an unused opportunity.
>Compiling C to Lisp made sense on Lisp Machines as the underlying platform was build on Lisp from the ground up
It would made sense doing the same to get rid of CFFI dependencies.
Name:
Anonymous2011-06-19 6:22
>>10
It's hard to do code transformation algebra with assembly.
>>11
>> Compiling C to Lisp made sense on Lisp Machines as the underlying platform was build on Lisp from the ground up It would made sense doing the same to get rid of CFFI dependencies.
Yeah, you just take your OS and compile it to Lisp. No CFFI is necessary anymore, problem solved, next!
>>6 Most problematic would be handling of 32-bit integers
In Racket, you have the unsafe-fx procedures: limited to fixnums and they overflow. The C standard says nothing on integers being exactly 32 bits, right?
>>16 The C standard says nothing on integers being exactly 32 bits...
but most of C/C++ code assume that typedef unsigned long Uint32; will work. Standard is useless.
Compiling C to other languages is pointless, anyway. We only use it because of the fast compilers that systematically miscompile your code (to optimize and make it crash faster), and because OSes only provide C APIs.
Name:
Anonymous2011-06-19 14:44
>>25
We use C/C++ cause of cheap Linux-monkey workforce. Their software is inconsistent and faulty, but it's free and fast as kamikaze's flight.