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

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

John Cowan wrote:
> These are some changes I thought up while reviewing Q in a Nutshell.
> 
> 1) Q currently can't import names selectively from a module.  I propose
> the Python syntax for this:
> 
> 	from <module> import <name>,<name>,...;
> 
> and a variant that exports as well as importing:
> 
> 	from <module> include <name>,<name>,...;

Yes, the syntax seems reasonable, I already have this on my TODO list.

One related question is whether prelude.q should really import all the
standard library modules. This is convenient, but also a source of
"namespace pollution". E.g., one might discuss whether clib.q and
stdtypes.q should be imported explicitly in user programs. (Of course
this raises backward compatibility issues.)

> 2) Now that Q has ML-style reference cells (which are not documented
> anywhere in the Q manual that I can see)

References have actually been around since Q 3.x, IIRC, but they are
implemented in clib and thus documented in Section 12 of the manual:
http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC137

> adding general mutable
> (but fixed-length) vectors is an easy extension: one simply adds a
> few equations to the standard library for treating tuples of cells
> properly.

Which operations do you have in mind? I mean, you can already create a
tuple of references, e.g., like this: 'tuple [ref ():I in [1..N]]', and
then assign with 'put (V!I) X' and retrieve a value with 'get (V!I)'.

> Following that, byte vectors (mutable byte strings) would also be
> a useful addition for dealing with large quantities of homogeneous
> data; these have to be done in C, but would be far more efficient
> than any alternative representation.

Yes, actually I've had something like this on my TODO list for a while,
in order to provide better support for numeric and signal processing
applications. But this also means that there should be appropriate
functions for dealing with C vectors and matrices of integer and float
values. Maybe a SWIG interface to the GNU Scientific Library or the
Octave library would be in order? Any volunteers for such a project?

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