Amplifying C | Hacker News Reader

Amplifying C

voodoo-slide.blogspot.com

112 pointscesare43 comments

Good spirit!

Interested parties can also hack on Parenscript: it compiles a decent chunk of Lisp to JavaScript, it's extremely well documented, and even has a CLOS like object system.

http://common-lisp.net/project/parenscript/

Regards.

- someone who compiles lisp to native object code

There is also Stella used for PowerLoom - http://www.isi.edu/isd/LOOM/PowerLoom/

To implement PowerLoom we developed a new programming language called STELLA, which is a Strongly Typed, Lisp-like LAnguage that can be translated into Lisp, C++ and Java. PowerLoom is written in STELLA and therefore available in Common-Lisp, C++ and Java versions.

It looks like a constraint programming language; sorta like CLIPS/LISA, am I right?

i like the author's writing style, and i think he's onto something. i've long hoped for a decent language for writing low-level stuff. so far, c++ is the worst, except for all the alternatives.

i think this is a grave 'leaky abstraction' waiting to happen, though. when his 'amplify' system screws up, it's going to do so in a way that nobody else can understand.

" i've long hoped for a decent language for writing low-level stuff."

Have you tried Forth? It is great at low-level stuff.

well, how am i going to compile forth into my iphone app? it usually comes down to something like that.

Probably the same way you compile C into an iPhone app.

But you said low-level. iPhone apps are high-level.

Forth isn't compiled most of the time. So go and write yourself a Forth interpreter in C or Assembler for your iPhone. It's (relatively) easy.

so my options boil down to dealing with c++'s warts or writing my own forth interpreter? heh! i think i can see why the status quo has persisted for so long.

(not trying to be snarky. if you have written your own forth interpreter, then you are a lot more hardcore than me.)

I have written my own Forth Interpreter in Scheme. But it was almost meta-circular.

Seriously, it's not that hard. A hell of a lot easier than "dealing with C++'s warts". (And unlike writing a Scheme, you don't have to figure out how to implement continuations.) Here's the source to one (http://www.annexia.org/forth), it's great reading.

If you're looking for a practical "low level but high level" setup, I'd recommend Lua + C first. I haven't done iphone dev, but if you can work with C, you're golden. Forth is fun, though.

"i've long hoped for a decent language for writing low-level stuff."

brace was on HN a few months ago: http://sam.nipl.net/brace

Brace isn't really anything more than stripping out braces and semicolons in favor of significant whitespace. This amplify thing offers a slightly higher level of abstraction by providing syntactic macros.

I agree that amplify seems to offer more abstraction. But the Brace homepage says its more than just using significant whitespace:

"Brace has coroutines, hygenic macros, header generation, #! scripting and cached executables, libraries with graphics and sound, and many animated demos." (http://sam.nipl.net/brace/)

I'm not really sure that's true; he seems to have gone to a fair amount of trouble to make sure that the expanded form is readable, at which point debugging it should be no trickier than debugging any other macro expansion - just keep expanding step by step until you find the thing that went wrong.

If anything I'd expect this to be easier to deal with than multiple layers of plain C macros given it's going to be a lot easier to introspect - at least for the same level of complexity of expanded result.

Of course, if you do substantially more complex things with it then, yes, it's going to be more complex to debug. But that's always the price paid for using complex abstractions - complexity can be corralled, compartmentalised and contained but rarely eliminated entirely.

LuaJit is so fast now, why not LuaJit + C where needed?

LuaJit is awesome, but he talks purely about using Lisp to describe "C" semantics.

Take it as use "Lisp" Alphabet, but still write a "C" language. Not good analogy, but gets you there.

What he would achieve - well the same semantics, anything generated by his amplifier would be linkable, runnable the same way as C.

What he would achieve by using Lisp - we'll he can just skip the whole C++ templa-bastardization, and just use common lisp macros. He can use it for anything that he would like... Hell I would like to use it tommorow.

It won't be easy on the guy that's trying to debug that thing, after such transformations you would need some heavy "#line" preprocessor magic put in the "C" code, but it's doable.

That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C or C++, write or generate a simple Lua wrapper for its API, and then the do logic in Lua, moving hotspots to C as necessary. (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers, as they say.) As a bonus, the cross-language boundaries are often natural seams for containing complexity.

TCL was also designed with this style of programming in mind, and John Ousterhout describes it pretty well (http://www.vanderburg.org/OldPages/Tcl/war/0009.html).

FWIW, LuaJIT is only available for i386 at the moment, though amd64 porting is in progress. Standard Lua is still pretty fast, and it's great for prototyping. It's a good idea to get algorithms and overall design right before spending much time on low-level tuning.

I've been wondering for a while why the obvious value in this approach isn't more widely recognized. Perhaps its time has come? I hope so! A Parenscript for C is a good idea. It would be exciting to see this sort of library come out of the game industry.

I do think it is recognized.

The biggest problem with these things is not parsing source code and output something else; you get the real pain when you're going to debug. :)

The biggest problem with these things is [...] when you're going to debug.

Since Parenscript is one of "these things", I have to disagree. We've been careful to make PS generate readable, debuggable JS code. It's not what you'd write by hand, of course, but it is not a problem to debug. I debug it every day using standard JS tools. (The biggest problem with PS is the impedance mismatch between Javascript's semantics and Lisp's, but that's another story.)

As I'm sure you're aware, sophisticated C++ template code can be nightmarish to debug. Easier debugging is actually one of the goals of the OP, so if what you said were true then his whole project would be a why-bother.

Whats the point of inventing yet another language? Its far better to use existing and proven languages for both a completeness/stood.the.test.of.time point and time it takes a new developer to get up to speed.

Granted I hate C++ with vengeance my poison if choice is C99 + LUA which creates a really powerful lowlevel and high level combo. Using lua to drive it, farming bits out to C, instead of the opposite "scripting language addon" approach. Yeah lua isnt quite as powerfull as lisp but gets pretty close and dosent look like alien space talk to new devs.

All languages (except maybe Lisp, COBOL, and FORTRAN) were "yet another language" at some point. This is how innovation happens.

yet with those languages were derived from constructs in math - new is always relative to the context.

Guess it depends on whats the advantage of doing this is? just for fun? or for a serious practical application.

Arguably the languages were not "yet another" in the sense that they were the first application of those concepts to executable code. But your point is well taken: everything has its roots in history.

I would say most reasons for creating new languages -- for fun, for production usage, as a learning experience -- are good.

Nitpick: It's 'Lua', not 'LUA'. (It's Portuguese for "moon", and its predecessor was called 'Sol'.)

While I too prefer C+Lua, Schemes that compiler to C are another option. Chicken Scheme (http://www.call-with-current-continuation.org/) is quite good. Gambit (http://www.iro.umontreal.ca/~gambit/) is also popular, though I have less experience with it.

How is cross-language debugger support? I have looked a few of these options, but in the use case I have in mind, the most likely place for bugs to occur is after crossing between languages multiple times, and not being able to move through the stack is pretty much a show-stopper for moving the high-level logic out of C.

I've not debugged Lua but I am familiar with it's integration into C. I imagine debugging Lua+C is no harder than debugging Matlab+C. You load up the REPL in GDB and set your C breakpoints in GDB and your Lua breakpoints in Lua. After control leaves your C function and goes back into the REPL's guts just hit 'continue' to return to the REPL command line. It's more laborious but still straightforward. The only thing you really can't do is step from the high level language to the low one but you can set the proper breakpoint in GDB right before the call so it's more or less the same.

-----

Edit: sorry not sure if you were talking about Lua or a C-based Scheme, though I imagine it's the same.

I'm not concerned about which language right now, anything with a REPL should be able to work in this way. But the context I'm working in is perhaps a bit trickier. The call stack would normally cross between languages multiple times so just inspecting the stack becomes really clumsy. Since both languages have access to the same data structures, a watchpoint set on the C side can break at a fairly arbitrary point in the interpreter, from which you need to gain control on the other side.

And it's important to be able to attach to a running process and move through the inter-language call stack (e.g. when debugging a deadlock under MPI (distributed-memory)). I haven't found a high-level language that offers this sort of interoperability, but I'd love to hear suggestions.

Lua has a simple API for debugging built in. Because of this, there are several free and a few commercial Lua debuggers available.

I'm not concerned about single-language debugging. Can these debuggers move through a mixed C-Lua stack? My stack might start and end in C, but cross through Lua two or more times. Can I set a watchpoint and get the program to stop wherever the memory is modified, regardless of which language is modifying it (i.e. I'd like to see C source when C touches the memory and Lua source (not interpreter inernals) when Lua code touches it).

Which of the Lua debuggers is your favorite?

I'm more of an assert / test suite / REPL and printf debugging person. I've used gdb when debugging wrappers for C libraries, but my use of the Lua debugging API has mostly been for profiling, code coverage, etc.

GDB works across the language boundary, though. As far as it's concerned, Lua is just a C library.

There is a commercial Visual Studio plug-in that will do what you want, but I don't recall it's name.

I wrote a Lua remote debugger myself years ago. A nice trick was that you can associate a string with a chunk of code when you load the code. Then you can retrieve that string from the debug API based on the current instruction. I used that to make a table of "chunk name" to "source" as a global variable in LUA. That made it easy for the debugger to retrieve the source regardless of where it came from (file vs interactive console vs who knows what).

ironic nitpick: It's 'SOL', not 'Sol'.

Ack! You're right!

one thing i really like about lisp/lua presumably erlang and many others. is how trivial it is to send a function down a socket e.g. how functions/bytecode is just a datatype. makes distributed/parallel/async processing so much easier to build.

guessing you cant do this with a compile to C style implementation.

looks like the function language part of the cola framework: http://piumarta.com/software/cola/coke.html

Example with discussion on LtU: http://lambda-the-ultimate.org/node/2796

The first link has no context, just a reference. The second link goes to a page with 3 comments and no body text, just a 1 paragraph abstract. The link in the abstract is a 404.

Related discussion: http://news.ycombinator.com/item?id=888643

Have you looked at C--?

Have you? I have been a Norman Ramsey stalker since 1997, I dabbled in every project the man ever touched, and C-- is not what the author needs. He wants C performance with higher abstractions. C-- is C performance with assembly abstractions (i.e. lower)

Yes, though C-- might be a good target for his amplify system, still.

D also looks interesting --- as a much saner C++.

I predicted that my comment would be taken pejoratively, but I didn't correct for it. All I wanted to know is, had C-- been looked at? Thanks for putting it into perspective.

Reply on news.ycombinator.com