Re: [q-lang-users] Newbie questions and comments

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

Hi, Matt, welcome to the club! :)

Matt Gushee wrote:
>  * So why isn't Q better known?

Good question. Well, maybe I don't advertise it enough. This year will 
be the first time that I actually present Q at an international 
conference. You see, for a long time Q has just been one of my "hobby 
projects", and it has only been "out there" on SourceForge for about one 
year. But I guess that the most prominent factor is that functional 
languages are still perceived as something fairly exotic, and many 
programmers can't easily wrap their head around this way of programming. 
It just takes time I guess.

>  * So far, the one thing that I really dislike about Q is the
>    limitations of the interactive interpreter. It would be nice, for
>    example, if you could test a function definition interactively before
>    putting it in a script. Maybe not such a problem if you use Emacs,
>    but there are some strange people like me who really prefer vi.

I've actually thought about this quite a bit. The basic code-generation 
algorithms can certainly be adapted to work in an incremental fashion 
(with little or no performance penalty at runtime), making it possible 
to dynamically add and remove equations to the pattern-matching 
automaton at runtime. But I just couldn't come up with a reasonable user 
interface to support this feature. The main difficulty is that the basic 
unit in a Q script is not the "function definition" but the "equation". 
Just imagine that you enter a series of equations in the interpreter, 
and then lateron you discover that the 7th equation must be moved before 
the 3rd one. Things like this happen all the time when programming with 
Q, and performing such editing in an interpreter which is anything less 
than a full screen editor is just too cumbersome.

So this is what the emacs mode is for. Of course it would be nice to 
have something similar for vi, but I never got around implementing it, 
as I don't use vi on a regular basis. (Can you bind a key in vi so that 
it invokes an interpreter on the current file? And can you program vi to 
recognize error messages and look up the corresponding line in a file? 
If so, I might be tempted to also add the necessary syntax highlighting 
magic for vim, that would already make a fairly complete vim-based IDE.)

>  * I see that undefined variables can be a major source of frustration:
>    they can cause expressions not to be evaluated as expected, yet they
>    are not errors so the interpreter doesn't point out your mistake. It
>    would be nice if there were some tool (or interpreter mode) that
>    would find all undefined variables.

You can run q with the -w option to have the interpreter warn you about 
"undefined" function and variable symbols. Due to the 1-pass compilation 
this is a bit cumbersome, since it will warn you about *all* symbols 
which are used (on the rhs) before they are introduced (on the lhs or in 
a declaration), so you need to be careful with the order of definitions 
or use explicit symbol declarations. But I found that this option helps 
a lot with larger projects, so I usually have it enabled in my Emacs Q mode.

>      foo A B C = A + B + C;
> 
>      foo A = lambda B (lambda C (A + B + C));

Yes, lambdas are not a builtin in Q, so they compile to ordinary 
function invokations. You can actually find the definition of lambdas in 
the lambda.q standard library script, it's all just plain Q code, no 
magic involved. One advantage of this approach is that you can tweak the 
implementation of lambdas to your liking. The other main advantage is 
that you can manipulate lambdas in Q itself, as they are just ordinary Q 
expressions, and you can add other stuff like list comprehensions on top 
of them without having to build everything into the interpreter (the way 
it's done in ML and Haskell). OTOH, this means that lambdas don't 
integrate as well and are executed less efficiently than in those languages.

>  * It seems like Q might be a good language for programming handheld
>    devices (just my intuitive notion--I can't really give a good reason
>    for thinking this). Has anyone thought about porting Q to, e.g.,
>    PalmOS?

Actually I have a Zaurus 5500 lying around here, and a port to that 
platform has been on my TODO list for some time. But last time I tried 
I've run into obstacles with the cross-compiling environment, and I 
couldn't get libtool to work on the Zaurus itself, so I've not pursued 
this any further up to now.

> [1] In case it isn't obvious, one example of what I mean by this is that
>     in Haskell you have to understand monads in order to write almost
>     any program that does useful work. I believe, because I have been
>     told by some very smart people, that monads are a very useful tool.
>     But the fact that you need to master such a difficult concept for
>     everyday tasks like reading and writing files makes the learning
>     curve prohibitive.

Yes, Haskell certainly is a beautiful language (probably the most 
beautiful there is right now, IMHO), but those monads can really get in 
your way when you have to do some real-world programming. ;-)

> [2] I need to play around with the language a bit more before committing
>     to anything, but I will probably be willing to help create some
>     "buzz" for Q.

Yes, that's a good idea. But how? Slashdot?

Cheers,
Albert

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