Re: Building Extensions for STk

From: Erick Gallesio <eg_at_kaolin.unice.fr>
Date: Tue, 21 Feb 1995 18:12:11 +0000

> I've just read a message from someone, who has implemented the
> procedures 'seek' and 'tell'.
>
> Apart from the fact, that I did the same thing some ago and will be
> sending my work in a day or two (modified for STk 2.1.6), what bothers
> me is, that everybody uses his own ideas, how a function should be
> named.
>
> I think, that everybody, who want to build an extension into STk
> should look at other implementations and see if some function is
> available and then use that name.

This is exactly what I do when I define a new extension. However,
sometimes things cannot be be taken as is or have a poor integration with the
rest of the language. Of course, it is most of the time a question of taste,
and
people with the choices I have made...

>
> As an example, SCM from Aubrey Jaffer has been around for quite some
> time. He build extensions into SCM for a couple of operating system
> functions (like seeking and telling, etc) and regular expressions.
>
> Now, STk is getting the same extensions, but unfortunately with
> completely different interfaces.
>
About regular expression: I find that the notion of compiling is not very
natural (you don't have to know this when you use a tool like edo emacs which
hide them to the user). And I like the fact that a regular expression can be
seen as a new kind of function and
that trying to match a pattern is like applying this function (this idea
and the actual implementation are derived from a contrib code from Tom Tromey).
IMHO, this view of regular expression is more "Scheme-ish".

In counterpart, when things integrate well with the rest of STk, I try to use
them unmodified (for instance the port->??? primitives have been taken without
modification from scsh, STklos syntax is always identical to Dylan when
possible).

I think that the "danger" with extensions is that they are so easy to add that
we can forget to keep them at the good level (i.e. Scheme rather than C).
For instance, after having written the socket code I have seen that Aubrey
Jaffer has integrated sockets in scm4e2 (scm4e2 seems to not be already
officially released but I have seen it in Guile). To avoid to have different
interfaces, I had a look of what is proposed in scm. It seems that every C
socket function has bee implemented in C (i.e. socket, bin, gethostbyname, and
all the others).
IMHO, these routines are not at Scheme level even if they permit to do things
which should be hard to do with the STk implementation of sockets (i.e. all
sockets are
AF_INET, sockets are streams one, you cannot parameter bind, ....).
In my (very short) experience with sockets, most of the time the things I want
to do was either to write a server, either write a client. Most of the C calls
necessary for this task were a kind of "necessary folklore" and most of my
programs share the same structure. This is this structure that I have tried to
embody in the socket STk primitives. With actual version, you need to use only
two primitives for making a server and one primitive call to make a client.It
will probably not permit to do all the tasks you need with sockets but most of
them (I hope). I think that it is very similar to Tk vs Xlib: you can probably
do a lot of things with the Xlib but programming at the Tk level is a lot
easier. This is this scheme that I tried to follow. However, I don't claim
that the choices I have made are the better ones and I don't want to impose
them to STk users; if a better interface is proposed, we can integrate it in
the distribution and ask to use it rather than the older one (the advantage
with extensions is that they can be kept inedpendantly of the current release
and that someone could easily load old versions if needed). The problem with
this
approach is the documentation. How should the extensions be documented? Must
they be decribed in the reference manual, in an annex or even in another
document? Any advice on the subject is welcome.

I apolologize for the length of this message, but I think that this is an
important question and we must probably discuss about this. After all, the
mailing list is also here for this kind of discussions.

                -- Erick
Received on Tue Feb 21 1995 - 18:12:11 CET