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.
>>32
GCs can be faster than manual memory allocation.
Name:
Anonymous2011-06-20 10:16
>>38
Correct C/C++ code allocates all the memory in BSS segment.
Name:
Anonymous2011-06-20 10:18
The only thing that is super easy is your mom.
Name:
Anonymous2011-06-20 14:36
it's a waste of time when you could just be using python in the first place
Name:
Anonymous2011-06-20 16:22
it's a waste of time when you could just glue a desktop pc in your pulse heartbeat monitor
Name:
Anonymous2011-06-20 18:05
>>39 Correct C/C++ code allocates all the memory in BSS segment.
Bullshit you fucking moron. I don't know about C++, but there is nothing in C89, C90, nor C99 that specifically that memory is allocted in the BSS segment. You still suck. Go back to playing with you sister's barbie dolls you mental midget.
>>43
It's not in the language standard specifications, but it's in every C/C++ ABI Standards for respective platforms where there is a BSS segment. Go cry some more.
Name:
Anonymous2011-06-20 19:29
>>45 but it's in every C/C++ ABI Standards for respective platforms where there is a BSS segment
Bullshit taco bell boy. I can name three servers here at Kodak where this doesn't hold true.
Name:
Anonymous2011-06-20 19:30
>>46
But the only way you would know something like this if you would have ever actually worked a programming job at a major US firm. Now go read SICP you fucking mental midget.