Why LispOS?

[Rodrigo Ventura]

>>>>> "Chris" == Chris Bitmead <chrisb@Ans.Com.Au> writes:

    Chris> Rodrigo Ventura wrote:
    >> The challenge is indeed to make the LISP communicate with the
    >> kernel in a way at least as *simple* as the UNIX syscalls. One cannot
    >> get any simpler than the open()/read()/write()/ioctl()

    Chris> Of course you can get simpler. You just eliminate them.

        Baa. It is implicit one wants to simplify without affecting
the functionality! Or else, there is always the trivial LispOS
solution: 0 bytes!!!!

    >> (IMHO this was
    >> one major factor that led to UNIX development) -- the file
    >> paradigm. One can access all kinds of different devices, from network
    >> sockets to serial ports, throught memory itself by the means of this
    >> API. A similar API is required to LispOS. 

    Chris> Why?

        Because simplicity (or cleaniness) of an API is usually an
under-rated factor for broad acceptance. Even if a certain API is the
best in some technical sense, if it is not simple, if people cannot
easly grasp how it works, it becomes useless as far as broad use is
concerned? Imagine for instance the Xlib API. It's fast, is flexible,
but nobody uses, because everybody prefers a Motif-like API where you
have widget pointers and callbacks --> simplicity!

    >> BTW, I had a couple of more ideas about things LispOS could
    >> have: to have a graphical interface from the bottom-up, ie no more
    >> text-only console. 

    Chris> No text console? Isn't that one of the fascinations of Lisp, to
    Chris> be able to type at a text console?

        You mean a LISP listener. I think that a LISp listener can be
more than a bi-directional stream of ASCII chars. For instance,
something like curses of termcap  are required to make "special
effects" with this stream of ASCII chars, using escape sequences and
such hacks. Why not re-engineer the shell? The shell is such a
powerful tool, why not improving it instead of throwing it away and
use some mac-like desktop? (very neat, but not as powerful).

    >> And instead of formating text straight
    >> to ASCII, using "%d" printf()  or "~a" (format) sequences, why not
    >> something like LaTeX? (Am I getting crazy?) Well, a small subset of
    >> LaTeX, including \bf like commands and even font-changing ones (\tt)!
    >> All together with a PostScript display, we could get it from
    >> GNUstep. It could become quite neat.

    Chris> I'm not quite sure what you've got in mind. Where would you use
    Chris> these TeX like APIs?

    Chris> LaTeX by itself is a bad tool for laying out GUIs. It is a good
    Chris> tool for producing documents. But I don't think you had that in
    Chris> mind did you?

        Ok, I probably didn't explain myself good enought. This idea
came up while I was thinking about whether to use (format)-like
semantics or a printf()-like one. Then I had an idea: why not a much
more complete and powerful semantics, for instance based on LaTeX
syntax, eg "\int[5]". It's much more readable than "%5d", don't you
think? And then it came up that we could extrapolate this scheme to
implement font changes, size changes, and all those special
effects. Another idea would be to use something like HTML, or even
SGML, but I guess it is far more complex... Well, it's just a
printf()-like function! But the baseline is why not dettach from the
old console ASCII streams paradigm and depart to a more powerfull
scheme.

        Regards,

-- 
--

*** Rodrigo Martins de Matos Ventura, alias <Yoda>
***  yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
***   Instituto de Sistemas e Robotica, Polo de Lisboa
***    Instituto Superior Tecnico, Lisboa, Portugal
***     PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99  CF 9C AF 9E 10 02 BB 2A