Slashdot Mirror
How Would You Generate C Code Using Common Lisp Macros? (github.com)
Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C.
This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, also known as Lists. It is unknown exactly what power might come about from this combination of low level processing with high level code generation.
This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?
This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?
... and had time to waste on idle thoughts.
It's already hard enough to clearly understand.
Oblig XKCD
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
What kind of dumb article is this? Stop living in the past Grandpa.
Sounds like an emacs junky trying to validate why his editor is the be all end all. Can atom.io or vi create c automatically? Well mine can
http://saveie6.com/
Spell check probably couldn't understand my lisp....
Still my favorite syntax for programming and I believe will always be. I mostly use Clojure at the moment but definitely wanted something just like this to work closer to C.
All the beauty of C syntax with all the conciseness of Lisp:
(int main ((int argc) (char (** argv)))
(sswitch ([] argv 1)
(case ("a" "c")
(printf "The value is \"a\" or \"c\"\n"))
(case "d"
(goto e-label))
(case "b"
(printf "The value is \"b\"\n"))
(case "e"
(: e-label)
(printf "The value is \"d\" or \"e\"\n"))
(default
(printf "The value is neither \"a\", \"b\", \"c\", \"d\", or \"e\"\n")))
(return 0))
"First they came for the slanderers and i said nothing."
But, upon reading the summary, I shuddered - I felt a chill as if Satan himself had walked across my grave...
#DeleteChrome
It is not the best illustration of an idea that's been running around my head for ages.
In terms of what traditional textual C can represent, with the exception of C macros, one can construct a suitable data structure. Now consider how parsed C could then be programmatically manipulated, and produced from other source formats than the usual. And so on.
Thinking more in a pythonic syntax, I have wondered about replacing textual source with a scripting language, so that, with something like C++, we could write
newclass = cpp.Class()
meth = newclass.addMethod(name="dosomething")
meth.signature = cpp.Signature([cpp.int,cpp.float])
While it doesn't look pretty at this point, one can write routines which do much of the code generation for you. Sometimes I look at the clever stuff done with template metaprogramming and think that they are doing this sort of thing but with a hobbled language. (cf. Greenspun's 10th law)
This has the capacity to do far more than C macros, and to allow a programmer to see in detail what things like macros and templates turn into.
An IDE could interactively work with the resulting data structure, avoiding the round-trip to textual source and back,
and the compilation stage for large projects could be accelerated in various ways.
Basically, in Lisp, code is structured data, as is essentially everything else, and essentially you are working with the language downstream from the parser (or at least, you could easily construct and editor which did this, and where a textual representation was only constructed by the tools allowing you to view and edit the programs. With other languages, code is a text file that needs parsing.
John_Chalisque
You already know why. When your C-compiler produces better code for the performance dependent parts of the system than the LISP compiler in your particular system for your particular LISP application, you'll have the option of transpiling. In other words, it depends.
I would let LISP print out a s-expression representing the abstract syntax tree (usually called abstract parse tree). Next I would add a small piece of code to my IParse program to read s-expression and use the unparse abilities with the C grammar to produce nicely formatted C code. The unparse function is smart enough to output a S-expression like '(times (add 3 4) 5) into (3+4)*5 based on the given grammar rules fed to IParse. Feel free to contact me, if you want any help with using IParse.
Who would think there could ever be enough of that loose in the wild!
With great trepidation and a bottle of aquavit, and the obvious subconscious yearning for discipline ultimately resulting in years of medication augmented therapy.
Weeping and at gunpoint. ;)
Anons need not reply. Questions end with a question mark.
I wouldn't, because I'm not a masochist. Next question.
systemd is Roko's Basilisk.
How (and why) would you convert your Lisp code into C
Well that's pretty easy. There are tons of simple Lisp compilers. Heck building a LISP used to be an exercise for many years included (full source) with Microsoft's C compiler.
A few examples:
http://www.buildyourownlisp.co...
http://howtowriteaprogram.blog...
http://sbcl.sourceforge.net/
http://clisp.sourceforge.net/
A little off topic but a Lisp in Java by a master of the programming craft which is worth looking at: http://norvig.com/jscheme.html
And finally also off topic but the original LISP in assembly: http://www.softwarepreservatio...
In short the way you convert LISP to C is writing a LISP interpreter or compiler.
Who bothers with Lisp? Only twisted people used it to begin with.
I twfied to write she code wif a plain old wipth but it didn'th work outh so well.
#include "<stdio.h>"
inth main(inth argshe; char **)
{
pwintf("Hello word\n");
}
I kepth getting compiwer ewos.
Maybe a macwo would help.
aight, cya
Yes and no. Yes in that functional programming isn't nearly all it's cracked up to be by its evangelists. No in that there are some applications (mainly in things involving control systems, physics modelling, and a few other niche applications) where Lisp is a much more elegant (read: less spaghetti-prone) way of writing the code, and having a good way to make your academic Lisp usable in real software is a way to make your life easier if you happen to work in one of those domains.
It little behooves the best of us to comment on the rest of us.
Kyoto Common Lisp and its descendants compile into C.
Can you describe the business requirement behind the ask please?
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
We had a genuine Lisp->C transpiler (we just called it a converter) way, way back when (in the late 1980's, probably before a lot of you were born and maybe even in some cases before your parents were born) at Thinking Machines Corp. The system software for the Connection Machine CM-1/CM-2 (which was effectively a gigantic coprocessor) was originally written in Lisp for the Lisp Machine (Symbolics 36xx IIRC), but eventually we figured out that we needed it on *ahem* more conventional platforms. Rather than rewriting all the code, someone hacked together a Lisp->C converter.
Facebook already did this with PHP. It was called HipHop. But it sucked. Too many issues, and it didnt solve enough issues. Luckily, Facebook started over from scratch, and just built of PHP virtual machine that does JIT compilation instead of needing to compile PHP into C then into machine language, and the result is actually a faster product, which supports more of the PHP language, and is a hell of a lot more stable (still not perfect though)
So, why bother cross-compiling to another language? Just build a LISP JIT VM system. Solve all your problems! :D
mainly in things involving control systems, physics modelling
Those were almost the last places I would have expected to find preference to functional approach due to modelling with state machines and vectorization of code for any vector units available.
I'm not going to do your Senior Project for you.
I'm glad this story got posted and sxc is getting some press, but the real question I asked was:
The idea of using pre-processors to generate C code is not new to programming; but the usage of the full power of Common Lisp in such a natural way is up to the question.
Listen to my music.
Are you implying that functional approach doesn't play well with vectorized code? If so, the APL family of languages would like a word with you.
In fact, Lisp's compiler macros are probably the place where you'd want to plug in a custom vectorized code generator "for any vector units available".
Ezekiel 23:20
Actually, twisted people use Python. ;)
Ezekiel 23:20
Isn't Lisp something used by queers?
I'm not saying that functional is the correct paradigm to replace event-driven as typically used in those places. I'm saying that for working with the actual equations for the system dynamics for some large multi-state model, functional can be cleaner as in fewer lines of code to wrap your head around. But: its output needs to be usable inside a good old fashioned C program which implements the state machine event loop.
It's like the old slashdot rose from the grave one more time... Don't worry kids, tomorrow we'll be back to stories about windmills and mobile phones, I'm sure.
Apparently there is a kind of magic in LISP that is not in other languages. I studied LISP for a while to see if I could get a sense of this magic, but failed miserably - it never clicked, there was never any sense of enlightenment. Is LISP elegant? Not in my eyes. It's a mess of brackets, weird syntax, and strange symbols.
At the same time, the attempts to write software with "C-like words, but with LISP syntax" is almost endearing. "Look, now you can actually have a switch-statement with strings in it!" they proudly exclaim, failing to note that this new statement only exists in their personal version of C, rather than in standard C. Who exactly is the target market for this new type of switch statement? Neither the C community nor the LISP community is likely to want it, since neither side recognizes the syntax they are using in the first place.
According to one of the links, the goal is this: "The syntax is more like C as this is more of a tool that is meant to bring C programmers into the Lisp world rather than pulling Lisp programmers into the C world." To that I say, "good luck with that". But hey, maybe they can get Linus on board and rewrite the entire kernel in LISP-in-C-like-form?
Oh, Slashdot.
All this babbling about "if you want performance, C blah blah" and no mention of Chicken, which is a Scheme to C compiler which is just one of the more prominent members of a long tradition.
Granted, the original poster wanted just to have the (Commmon Lisp) macro expander, and C "beneath" it, but all this territory (and much more) has been explored there, so it'd pay to have a look.
The state of the art for code generation is not Lisp but Pliant.
Basically the main difficulty with code generation is not to make it powerful, but have it generate meaningful error messages rather than crazy code when some bad source is submitted. Through the definition of 'Expression' and 'Instruction' notions, Pliant defined a clean way to encode a program at various stages, and the rules for the code generator. S-expresions plus syntaxical substitution with a Turing machine equivalent substitution engine as opposed to just macros will bring you the power, but only the power.
For extra details, just read the articles on http://www.fullpliant.org/
which only works as long as :
- all of the strings are going to be at least longer than the integer type you're using
(there is no 3-chars long string, when you cast them to uint32 for this hack)
and/or you use proper padding everywhere.
- the integer type you're using is long enough for the different string to be easily distinguishable by this point
(i.e.: you're not having all of your string beginning with "keep..." when you're restricted to uint32)
(and note that both previous point are more or less going in opposite direction but, well, that happens when using pesky things like "human readable language" and other such extremely verbose input data)
- you don't mind garbage aliasing with valid string (both "disable" and "disaJGrmHbnl" resolve to the same uint32)
- or simply use this hack to sort the string in various bins and then subsequently process more (using a second cast-as-a-number switch for the next chars, or using more standard string comparison). (e.g.: the case that detect all the strings beginning with "keep" will do a second switch to check keep-?WHAT?)
In short: nice hack, but is come with so many short comings that it's best left for some internal tool and never exposed to user-data-facing usage (like the internet).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
With a program!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
I'm not sure that there's a limitation on the usefulness of error messages in a custom-written transformer. It can be as bad or as good as you like it. Lisp provides the hooks into the compiler, but you provide the code. The description on that page also very much sounds like what an application of OMeta could do.
Ezekiel 23:20
My bad. I hadn't read up on Lisp, particularly on Common Lisp for over 20 years, and that was from a book from the times before there was a common Lisp.. Arrays are the obvious starting point for such a library of macros.
Which version of Python? :)
I forgot about Erlang. What are those telecom systems that were programmed with it other than event-driven, fault tolerant control systems?
Do you mean, like, Emacs?
"Full Power of Common Lisp". what an oxymoronic statement. A more pertinent claim is that Visual Basic is the most powerful programming language ever.
As are RUST, R, Javascript, Clojure, etc. simply because you don't have to worry about GHarbage collection. BAH. I'll believe NONE of these claims until someone actually writes a working OS in them (yes, I do know about JavaOS, and LispMachines, Inc.) And they survived (snark) because they were just that good, right?