AW: [clisp-list] Networking?

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

Michael Koehne wrote:
>  An FFI implementing simple (read-line and hiding the nastynesses of
>  IAC telnet signals would be nice. I therefore swiched to GCL where
>  (defentry is much easier than FFI.
This made me curious so I looked at defentry to see whether there was something new about FFI to learn.
http://www.scit.wlv.ac.uk/appdocs/gcl/gcl-si_16.html
I found nothing particularly attracting to me.

If you prefer defentry over FFI then you might wish to take a look at CLISP's module's documentation, esp. modprep.

My opinion is that defentry allows you to put some C code into a Lisp file. Modprep allows you to put C code into a mostly-C file, with special preprocessor macros like DEFUN to ease definining parameters.

Another approach might be to use FFI:C-LINES to add C code to the current module. Long ago, I thought about extending FFI:C-LINES to be able to add functions and variables that the module system would know about. That would be very similar to defentry. It's really just a matter of some more code in CLISP's foreign1.lisp, given some design choices. I wondered if this could be useful to anybody except me.

The list of parameter types supported by defentry is very poor:
>The list of allowed types is (object char int float double string)

There's some benefit (and also drawbacks) in mixing C and Lisp code a la defentry. Literate programming comes to mind, which mixes code and documentation, and variants like dotweb or dotnoweb, which, from a single source file, extract the shell, C Lisp, TeX, xyz. parts and puts these into separate files.

Yet even for small files, I prefer to have separate Lisp and C files, partly because in C, one usually needs a plethora of #include and #ifdef... #include (for portability), which I don't want to see in Lisp files.

All in all, we're talking here about ease of use or suitability for fast-forward aka. quick hacks, not about advanced or high-level features.

Given my Amiga background, where the goal was to interface to existing libraries, compiling and adding tiny C wrappers was deemed superfluous. Nowadays, I'd expect similar useage patters with FFI to dynamic link libraries on MS-Windows and UNIX: to use an existing libxyz.so/dll/dynlib, *I* wouldn't want to have to define some C glue code.
YMMV. In my article on extending CLISP, I believe I had listed some pros and cons on glue code.

Regards,
	Jorg Hohle.