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

[Tim H. <q...@st...>]

Matt Gushee <ma...@gu...> writes:

[snip]
>   * First impression: WOW! Though I'm no expert on language design (no CS
>   degree, just some practical programming experience coupled with an
>   interest in how it all works), Q seems to be one of the best-designed
>   languages I have come across: based on good theory, yet not slavishly
>   adherent to the theory like, say, Haskell[1]; compact, yet powerful;
>   and it has a lot of nice little touches, e.g. symbols that are easily
>   converted to and from strings. Overall, Q strikes a very good balance
>   between theory and practice.

Yup. No need to slave to the functional purity, here. (For example, I get
the impression the libxml binding is impure - if you see `||' as a
side-effect sequential operator, you get snippets of code that look like
"destructively append a node here, || now return the new tree".)

>   * So why isn't Q better known? 

Good question. I also only stumbled across it via a freshmeat update I
spotted - wondered `hello?' and thought it quite cool. Maybe it's because
the set of people for whom ODBC, XML, ImageMagick and audio library
bindings are interesting is comparatively few.

[snip]
>   * 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. Or is there such a thing already? I have
>   to confess I'm not in the habit of reading all documentation in
>   advance--I tend to read a bit, try something, read a bit more, and so
>   on ...

Well, there *are* no undefined variables, you just get a symbol-name back
if you use one, and it can get quite interesting if you're doing various
operations and accidentally hit one (but you soon get used to the forms
that can take). Hmmm. Maybe `issym' or something could come in handy here -
like, um, how do you get it to return false?! :)


One bug-bear I have atm is still the debugger. I've got a classic weak-type
problem, writing something that handles lists and tuples (a prototype
generic FSM for my own amusement), and somewhere along the lines I've got
my datatypes in a twist in the middle of a recursive call, and I just can't
make head or tail of the debugging...

>   * A while back I gave a presentation on OCaml to a local Linux users'
>     group. By way of explaining currying, I demonstrated that the
>     following two function definitions are effectively the same:
> 
>       let foo a b c = a + b + c
> 
>       let foo = fun a -> fun b -> fun c -> a + b + c
> 
>       [ "fun ARGS ->" is the OCaml equivalent of "lambda ARGS" ]
> 
>     The OCaml compiler compiles these two to identical byte code. I tried
>     a similar exercise in Q:
> 
>       foo A B C = A + B + C;
> 
>       foo A = lambda B (lambda C (A + B + C));
> 
>     But if I create two modules, each containing only one of these
>     definitions, and compile them with qc, they produce different byte
>     code. So, assuming the byte compiler is correct, it appears that the
>     first form is not simply syntactic sugar for the second (as was the
>     case in OCaml); there is some substantive difference. Can anyone
>     explain (bearing in mind that I don't have a CS degree) the
>     difference in the two Q definitions?

The first is a function of 3 arguments, the latter one, and one which
doesn't know what B and C are. Lower-case definitions introduce functions,
with upper-case seemingly being handled separately (IME, `def'+uppercase
name leads to the RHS being evaluated once at the time the interpreter
passes by that line of code, while lowercase name leads to once per
invocation).

> Last but not least, thanks to Herr Gräf for all the good work.

Seconded.

> [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, I'm also a haskell newbie, and just can't get my head around the
blighters either. No time, and when there's time, not enough caffeine :/

A random question: is there anything in Q like haskell's $ ? Ie., a
right-associative do-very-little operator that obviates surplus
parentheses?

 | foo (bar (qux X))  ==  foo $ bar $ qux X

> [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.

~Tim
-- 
<http://spodzone.org.uk/>