Re: [q-lang-users] Two proposed improvements to Q

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Maybe you could export your TODO list, either to the website or by
> keeping it in the CVS project directory (which is what I do for
> my projects).

My internal TODO list isn't really that suitable for publication ;-),
and I just found that KOrganizer messes up the format in html export
anyway. But when I have the time, I'll manually add at least the main
TODO items to the wiki.

> It's kind of slow, too.  If I were going to cut anything, I'd cut clib.

Well, considering namespace pollution, clib is probably the worst single
offender. But starting the interpreter with the full library takes some
0.35 secs on my devel box (Athlon 2500+ running Linux, so not really a
fast computer by today's standards), and clib takes maybe 0.12 secs from
that. So I don't know whether it's really worth the hassle.

Also, on second thought I realized that clib also provides some fairly
essential stuff besides the system interface, like the C versions of
important list and string routines, and the extra integer functions
which are used and extended in rational.q. I'm afraid that it will be
quite a task to untangle this, and I'd have to chop clib into smaller
pieces for that. I don't like that idea very much, since right now clib
is a nice central repository for all "C things" in the standard library.

The only other obvious candidate I see would be stdtypes.q and the stuff
that it includes, which shaves away a whopping 0.16 secs from the
startup time, but namespace-wise it's probably not much more than a few
dozen public operations.

Still, by unbundling *both* the POSIX interface part of clib (maybe
moving that to a system.q module, along with the stuff in getopt.q) and
stdtypes.q from the prelude, we might be able to shave off almost 80% of
the interpreter's default startup time and clean up the namespace
considerably. Could be worth the hassle after all. But of course it also
breaks backward compatibility big time. :(

What does everybody else think about this? Are you all running little Q
scripts in tight loops from the shell, or do you rather use them
interactively? I.e., how do you want your prelude: "slim" or "fat"? :)

> The proposed R6RS Scheme bytevectors provide read-write access to
> any point in a bytevector as signed and unsigned {8,16,32}-bit values,
> single and double floats, and strings using a specified character code.

I was thinking more about a data structure which also carries type tags
and dimensions, so that you don't accidentally use wrong indices or
access the wrong type of information, and conversion between different
number types could happen on the fly (e.g., if you read a bytevector
with floating point samples from an audio file and then play it back on
an audio device which only understands 16 bit integer samples). Of
course, these objects could still provide the "raw" bytevector interface
you sketched out at the same time. In fact we could probably make all of
these new types subtypes of the existing ByteString type and extend
ByteString's interface so that it provides all the needed raw operations
and the appropriate conversions between different subtypes.

Concerning matrices, there's of course the row- or column-major issue.
Most C codes probably use row-major matrices nowadays, but column-major
would be good for interfacing to legacy Fortran code. ;-)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag