LateralT

Posts tagged with "lisp"

C native data types in Lisp

This is an example of how to use Common Lisp for the wrong purposes, although this shows that it's closer to a systems language than most of the other high-level modern languages.

Since Lisp has its own implementation-dependent data types, as most high-level languages do, any interaction with the world outside of the Lisp image, such as binary data import/export or code involving system calls or external C functions, is expected to be painful to some degree.

Surprisingly, most serious implementations have a nice enough FFI system to make C-native data definitions and alien function calls very easy, but I'm more concerned with data processing, which means that at some point I'd want to send those native "variables" to some place other than memory.

I am strongly against the use of raw binary formats but that's how the world works. unfortunately. I know that if your application interface depends on tightly-packed C structs you're already screwed, but still, I'd like to be able to do that easily in Lisp like you do in, for example, Perl (pack/unpack). Also, the recommended way to do this in Lisp is to define your own Lisp-to-C data mapping functions manually, which is really not practical. SBCL already knows how to do the mappings, but these features are rather obscure and scarcely documented.

The common link I'm using to bridge the alien C datatypes in SBCL -comprehensive and well documented, by the way- and real Lisp variables is the byte array (an octet is an octet everywhere), so the key to this code is how to collect any C datatype into a byte array that you can later dump into a file or whatever.


keep reading . . .

Extending C programs with S7 Scheme

Only an experiment/tutorial, really. Normally I doodle a lot of drafts and dabble in a lot of things, checking the initial possibilities and evaluating all the implementation alternatives, and then I leave all my enterprises unfinished. This is just one of them.

Small and embeddable scripting languages owe most of their popularity to the gaming industry, Lua being the most famous of the bunch (I'm not including more full-fledged languages like Perl or Python here). Surely, having most of the dynamic and prone to change features of your game managed by a dynamic and easy to modify language rather than having it all crammed into a monolithic binary is good programming design, and Lua is fast, small and easily embeddable.

Still, something doesn't look quite right when you contemplate all the possibilities. Why isn't Scheme, which is older, better designed, easier to implement and has an almost infinite number of diverse implementations, more widely used for these tasks? Maybe it's because of the aversion most programmers have to prefix notation and S-expressions, maybe because the almost infinite number of diverse implementations is more of a drawback than an advantage, who knows.


keep reading . . .

Remote Common Lisp setup

This is a very versatile and convenient way of working with a Common Lisp environment, specially for long-lived programs such as a web application. Having a persistent swank server running in a remote host lets you keep your application running as usual in a production environment and attach a local client for debugging and, hot-fixing and incremental development without having to stop the application.

This workflow was inspired by Ron Garret's article Lisping at JPL.


keep reading . . .