[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOOPS Terminal Class - RnRS POSIX support

From: Michael Tiedtke
Subject: Re: GOOPS Terminal Class - RnRS POSIX support
Date: Tue, 23 Jun 2015 10:02:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

From the manual:
"Guile goes beyond the rather austere language presented in R5RS, extending it with a module system, full access to POSIX system calls ..."

Now, full access to "POSIX system calls" means more and less than that. When you want to have a look at my current terminal application driver you will see it's current shortcomings: missing a general (Linux specific) ioctl primitive it uses the stty command to set raw and sane mode of terminal operation. Try to read out the dimension of the terminal with get-dimensions: for me this surprisingly works flawlessly in the modern Gnome Terminal - but it remains stuck in the response reader on a Linux tty and even in XTerm itsself although the escape sequence used stems from it's documentation (ctlseqs.txt). Well, probably window control sequences are turned off on my Ubuntu system and I should revert to the Linux specific ioctl.

What I wanted to tell the RnRS folks: the current POSIX interface still is based heavily on Scsh's flat "wrapper" with out any semantics. Accessing regular files works great but the UNIX file system is system namespace. The entries usually held in "/dev" can be accessed like regular files but denote devices. Each and every device has it's own semantics - I don't know if terminals are one of the worst class of devices but at least these virtual devices have a very long history (100+ years) of being useful teletypewriters in Telex and other uses. Escape sequences do work great but today it's not enough. I would like to suggest rethinking the POSIX interface to allow it to be extended with device semantics, i.e. meaningful entries. In the case of the virtual terminal a well crafted terminal device application driver allows to do without the C-specific readline and ncurses libraries and it would allow to write real applications capable of treating the terminal as the keyboard+screen that it is instead of abusing it as stdio like a typewriter from 100 years ago.

Please respect the semantics of devices especially when they may look like files. POSIX isn't that important or useful anymore but "full access to POSIX system calls" it has never been. And especially on Linux (but probably on Darwin, too) one might try to ask to add a more Scheme friendly system interface to the kernel - but ioctl's complexity arises from the diversity of the controlled devices and their capabilities.

There is a preliminary incomplete implementation of such a meaningful device driver attached. It's very incomplete but nonetheless useful.

Attachment: terminal.scm
Description: Text Data

Attachment: terminal.test.scm
Description: Text Data

Attachment: characters.scm
Description: Text Data

Attachment: pretext.scm
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]