q-lang-users — general discussion, questions, suggestions, etc.

Re: [q-lang-users] RFC: Conditional syntax

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

Albert Graef wrote:
> (Ex. 3)
> 
> abs X    = cond (X<0, -X; true, X);

Arrgh, I just noticed that cond is already used in clib for pthread 
conditions. Too bad. :( Can anyone think of another nice name for the 
conditional operation?

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

Re: [q-lang-users] RFC: Conditional syntax

[John C. <co...@cc...>]

Albert Graef scripsit:

> Do you mean "lazy" as in "deferred+memoizing" or just "deferred"? If 
> it's the former, then you're right (but streams, by default, aren't 
> memoizing in Q either). If it's the latter then you're wrong because the 
> guards/patterns and the corresponding values need to be deferred until 
> they are looked at. The tails of the clause sequence don't have to be 
> deferred, with that I agree.

It was the last point that I had in mind.

> Unfortunately, I got into the habit of using "lazy" synonymous with just 
> "special" or "call by name", whereas most of the FP community will 
> reserve "lazy" for "deferred+memoizing" a.k.a. "call by need" (which I'd 
> call "fully lazy"). Maybe that's the source of the confusion.

Probably yes.

-- 
John Cowan   co...@cc...    http://ccil.org/~cowan
The known is finite, the unknown infinite; intellectually we stand
on an islet in the midst of an illimitable ocean of inexplicability.
Our business in every generation is to reclaim a little more land,
to add something to the extent and the solidity of our possessions.
        --Thomas Henry Huxley

Re: [q-lang-users] RFC: Conditional syntax

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

Keith Trenton wrote:
> It turns out that our hands are equally "old", vintage 1962.

Hey, that's nice. :) Did you turn 44 already?

> I started my programming "career" part-time in 1975, and by 1978 I was programming full-time...dynamic systems modeling in FORTRAN IV...on punch cards...with that lovely green-and-white fan-fold paper for output...and I had to walk uphill to the computing center...both ways.  ;-)

Ah, the memories... I also started out in my youth, with those 
programmable calculators. At the university, we then had Algol 60, on 
GCOS (anyone still remember that?), so I also remember the punch cards 
and the printouts. Algol was great. Batch processing was not, but it 
taught you how to turn in a program which compiled and ran the first 
time. ;-)

> Where was Q when I needed it most? (I would have settled for Lisp, had I known that it existed)

At least you didn't have to program in COBOL. 8->

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

Re: [q-lang-users] RFC: Conditional syntax

[John C. <co...@cc...>]

Albert Graef scripsit:

> I'd rather move it to the examples folder. If someone really wants to 
> use it, it can just be copied over. "Lambda" isn't possible, though, as 
> it's a variable identifier. I could call it _lambda.

That sounds great.

-- 
Only do what only you can do.               John Cowan <co...@cc...>
  --Edsger W. Dijkstra's advice
    to a student in search of a thesis

Re: [q-lang-users] RFC: Conditional syntax

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

John Cowan wrote:
> For this reason, and also for the sheer coolness of it, I'd like to
> see the old lambda stay in the standard library, but renamed "Lambda".
> It's a nice executable demonstration of exactly how lambdas can be
> expressed as combinators.

I'd rather move it to the examples folder. If someone really wants to 
use it, it can just be copied over. "Lambda" isn't possible, though, as 
it's a variable identifier. I could call it _lambda.

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

Re: [q-lang-users] RFC: Conditional syntax

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

John Cowan wrote:
> I actually prefer Ex. 1 to Ex. 2, because there is nothing lazy here.

Do you mean "lazy" as in "deferred+memoizing" or just "deferred"? If 
it's the former, then you're right (but streams, by default, aren't 
memoizing in Q either). If it's the latter then you're wrong because the 
guards/patterns and the corresponding values need to be deferred until 
they are looked at. The tails of the clause sequence don't have to be 
deferred, with that I agree.

Remember, in Q "special" == "deferred" == "call by name". In Q, there's 
neither a conceptual nor a technical difference between, say, the 
deferred arguments of "defined functions" like (or else) or ifelse on 
the one side and those of "constructors" like (') and cons_stream on the 
other side. That's because there's actually no distinction between 
defined functions and constructors in the first place.

Unfortunately, I got into the habit of using "lazy" synonymous with just 
"special" or "call by name", whereas most of the FP community will 
reserve "lazy" for "deferred+memoizing" a.k.a. "call by need" (which I'd 
call "fully lazy"). Maybe that's the source of the confusion.

Anyway, I'm perfectly happy with option (1), too.

[infinite clause lists]
> Only if we are capable of making infinite decisions, which I at least
> am not.

But you could write a program to generate a potentially infinite (or 
huge) sequence of conditional clauses and then start evaluating it until 
you find a clause that's true. Semi-decision procedures come to my mind. 
Anyway, such (rather esoteric) applications can already be handled using 
stream programming, so there doesn't seem to be a point in supporting 
that directly with cond.

[grouping syntax]
> I agree with this, and I agree that the implied internal objects should
> be tuples in all cases; again, the situation is inherently immutable
> and fixed.

All right, I'm going to implement this and commit it to cvs tonight, 
along with cond/case as described in Ex. (1). Judging from the replies, 
everybody should be happy (or at least not unhappy) with that.

Thanks for all the responses! :)

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

Re: [q-lang-users] RFC: Conditional syntax

[John C. <co...@cc...>]

Albert Graef scripsit:

> - The lambda function used to return combinator terms which weren't nice 
> to look at, but could be unparsed, written to a file and read back. With 
> the new built-in lambda function, you'll get an external <<Function>> 
> object instead.

For this reason, and also for the sheer coolness of it, I'd like to
see the old lambda stay in the standard library, but renamed "Lambda".
It's a nice executable demonstration of exactly how lambdas can be
expressed as combinators.

(It would be all right if, like graphics.q, the modified lambda.q
were not loaded by default.)

-- 
John Cowan   co...@cc...    http://ccil.org/~cowan
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to
lose support instead of finding it when you threat with the charged weapon."

Re: [q-lang-users] RFC: Conditional syntax

[John C. <co...@cc...>]

Albert Graef scripsit:

> (Ex. 1)
> 
> abs X    = cond ((X<0, -X), (true, X));
> empty Xs = case Xs (([], true), (_, false));
> 
> Or maybe the sequence of clauses should actually be a stream instead of 
> a tuple?
> 
> (Ex. 2)
> 
> abs X    = cond {(X<0, -X), (true, X)};
> empty Xs = case Xs {([], true), (_, false)};

I actually prefer Ex. 1 to Ex. 2, because there is nothing lazy here.
What we have is an immutable sequence (tuple) of possibilities to try.
I grant that using a stream makes "cond" and "case" not special forms,
but that is an implementation-level consideration, and unless special
forms are far more expensive in the interpreter, ought not to be
controlling.

> This has the advantage that the sequence of clauses could be a 
> non-special argument (since the expressions inside of it are already 
> protected by the stream constructor), and that we could even have 
> infinite lists of clauses.

Only if we are capable of making infinite decisions, which I at least
am not.

> I'm also considering to add some unobtrusive syntactic sugar to allow 
> "grouping" inside tuples, lists and streams. E.g., [X1,Y1;X2,Y2;...] 
> would be the same as [(X1,Y1),(X2,Y2),...]; this would also be useful, 
> e.g., for writing lists of key-value pairs. 

I agree with this, and I agree that the implied internal objects should
be tuples in all cases; again, the situation is inherently immutable
and fixed.

-- 
A poetical purist named Cowan           [that's me: co...@cc...]
Once put the rest of us dowan.          [on xml-dev]
    "Your verse would be sweeter        http://www.ccil.org/~cowan
    If it only had metre
And rhymes that didn't force me to frowan."     [overpacked line!] --Michael Kay

Re: [q-lang-users] RFC: Conditional syntax

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

Tim Haynes wrote:
>>0. Keep the old definitions (Ex. 0).
> 
> Backwards compatibility is always good ;)

That's right, and normally I'd agree with you, but in this case I argue 
against it, for the following reasons:

- Having two incompatible constructs for exactly the same thing will be 
confusing.

- I really want to use "case" for the new matching conditional. That's 
the most obvious choice, and will be familiar to both Lisp and 
Haskell/ML users. Unfortunately, "case" is already declared as a 
constructor with the old constructs. So I'm afraid that it's either (0) 
or (1|2), but not both.

- AFAICT, nobody really seems to use the current constructs right now.

I scanned all Q sources I have lying around on my hard disk (which also 
includes all the add-on modules and the scripts contributed by you, 
Peter and Rob), and there's exactly one invokation of switch and one 
invokation of match. Both are in gqbuilder.q, which belongs to the core 
distribution, so it can be fixed pretty easily without anyone noticing. 
And if anyone still uses the old constructs occasionally, it should be 
an easy matter to parse those scripts with -w to identify all the 
undefined uses of "switch" and "match" and fix them.

So it seems the right time now to make a clean cut. If there's anyone 
who has a significant amount of code using the old switch and match 
constructs, please speak up now!


Talking about backward compatibility, I think that, even with all the 
other changes under the hood, Q 7.1 as it is in cvs now should still be 
100% backward-compatible, with the following two exceptions:

- The apply and compose functions have been removed from stdlib.q. These 
have been deprecated since the introduction of ($) and (.) in Q 6.1 and 
5.3, so it should be safe to remove them now.

- The lambda function used to return combinator terms which weren't nice 
to look at, but could be unparsed, written to a file and read back. With 
the new built-in lambda function, you'll get an external <<Function>> 
object instead.

I don't think that the latter incompatibility will be much of a problem, 
except if you want to serialize a partially evaluated stream 
comprehension (which makes heavy use of embedded lambdas) and store it 
on disk.

I could actually unparse the new "compiled" lambdas to something which 
can be parsed to reconstruct the function, but I'm afraid that it won't 
look very pretty, so the <<Function>> notation might actually be 
preferable, at least for interactive usage. And it's similar to what 
you'd get for anonymous closures with other FPs, too.

>>1. Clauses as a tuple of (guard/pattern, value) pairs (Ex. 1).
>>2. Clauses as a stream of (guard/pattern, value) pairs (Ex. 2).
> 
> Having thought `hmm, braces, but not in the perl/C sense' I think I like 2
> more. Nested-parens are all very well in a lisp/scheme language but they're
> not what I see in Q. YMMV. :]

Note that the parens/braces there actually belong to the tuple/stream 
arguments of the cond/case functions. There's no syntactic sugar 
involved here, both cond and case will just be ordinary Q functions.

>>3. 1 or 2 with "grouping" sugar (Ex. 3).
> 
> It's certainly neat, watching other languages' switch/case layout come
> about as a result of a formatting change, but as with other sugar, I'm
> wondering what potential for tooth-rot it's letting in through the back
> door. Any? Am I paranoid?

Yeah, the "cancer of the semicolon"... That's the reason why I've always 
been reluctant to add more syntactic sugar to Q. I think that Haskell 
really goes a little overboard with that (in some cases out of 
necessity, since there are no user-definable special forms in Haskell).

But I'd say that the syntax I've added in Q 7.1 is quite unobtrusive, 
really makes frequently-used stuff easier to read and write, was not 
introduced without a second and third thought (in fact I've been 
thinking about most of these features for years, but refrained from 
introducing them before everything else was in place), and fits well 
with the basic syntax. Here is a list of what's new in Q 7.1:

- Stream syntax which looks like lists. I think that noone will argue 
that this is a vast improvement.

- List and stream comprehension syntax. This uses a tried and proven 
set-like notation which comes from mathematics and has been around for 
centuries, I think.

- Lambda syntax. Also uses a tried and proven notation from mathematical 
logic, which has been around since the 1930s.

- If-then-else. Used in many FP textbooks, even if they otherwise use 
applicative syntax throughout.

Note that all of these can still be specified using the basic 
applicative syntax (using nil_stream/cons_stream, listof/streamof, 
lambda, ifelse/when) if you prefer that.

The proposed grouping notation is also quite common in mathematics, for 
the purpose of improving readability of sequences and argument lists, 
albeit with different meanings. I can think of three different 
reasonable implementations:

- Visual cue only. Allow ";" instead of "," in sequences, but without 
any special meaning.

- Nested sequence of same type. [X,Y; ...] will become [[X,Y],...], 
(X,Y; ...) will become ((X,Y),...) and {X,Y; ...} will become {{X,Y},...}.

- Nested tuple. In this case the group always produces a nested tuple, 
i.e., [X,Y; ...] will become [(X,Y),...], (X,Y; ...) will become 
((X,Y),...) and {X,Y; ...} will become {(X,Y),...}.

I think that the latter interpretation would be the most useful for Q. 
Clearly, this kind of notation is not "standard" in the same way as the 
other items above, though. But, as I pointed out earlier, it would be 
fairly convenient in different contexts.

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

Re: [q-lang-users] RFC: Conditional syntax

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

Albert Graef <Dr....@t-...> writes:

[snip]
> So what do you prefer? Multiple choices possible. :)
> 
> 0. Keep the old definitions (Ex. 0).

Backwards compatibility is always good ;)

> 1. Clauses as a tuple of (guard/pattern, value) pairs (Ex. 1).
> 2. Clauses as a stream of (guard/pattern, value) pairs (Ex. 2).

Having thought `hmm, braces, but not in the perl/C sense' I think I like 2
more. Nested-parens are all very well in a lisp/scheme language but they're
not what I see in Q. YMMV. :]

> 3. 1 or 2 with "grouping" sugar (Ex. 3).

It's certainly neat, watching other languages' switch/case layout come
about as a result of a formatting change, but as with other sugar, I'm
wondering what potential for tooth-rot it's letting in through the back
door. Any? Am I paranoid?

> 4. Don't care.

I'd say I don't mind too much. I'm just a mortal user :)

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

Re: [q-lang-users] RFC: Conditional syntax

[Keith T. <kaz...@ea...>]

Albert Graef wrote:
>Being an old hand myself, I don't know. Isn't "cool" "leet" anymore? Or do we all have to write "kewl" now? ;-)

It turns out that our hands are equally "old", vintage 1962. I started my programming "career" part-time in 1975, and by 1978 I was programming full-time...dynamic systems modeling in FORTRAN IV...on punch cards...with that lovely green-and-white fan-fold paper for output...and I had to walk uphill to the computing center...both ways.  ;-)

Where was Q when I needed it most? (I would have settled for Lisp, had I known that it existed)

At least "cool" was "cool"...or was it "groovy"? (shudders...)

Cheers,
Keith 
 

Re: [q-lang-users] RFC: Conditional syntax

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

Hi Keith,

Keith Trenton wrote:
> 1. Wrt the <ifelse> function, I prefer keeping "ifelse X Y Z"; it is clean and concise.

You can use both. Internally "if X then Y else Z" and "ifelse X Y Z" are 
exactly the same. The former will be used for unparsing now (keeping in 
line with the philosophy that the pretty-printer should unparse 
expressions with as much syntactic sugar as possible), but I can easily 
take that out again; it's just the pretty-printing, so it doesn't really 
matter as long it's re-parseable.

It's already implemented and in CVS now. I don't see any problems 
arising from the new syntax, but I can easily back it out if it's 
necessary or if enough ppl complain.

> 2. Wrt multi-way and matching conditionals, I prefer your option (1); however, I would be equally happy if BOTH options (1) and (2) were implemented. I personally dislike curly braces "{}" (they remind me of my Perl days ;-); however, option (2) is consistent with the new stream syntax, so I can live with it (but I prefer using Lispy-parens).

Yeah, (1) looks nicer for me, too (although I prefer (2) for technical 
reasons). And the listof/streamof special forms also take tuples for the 
sequences of clauses, so it would be consistent with that.

Other opinions?

 > 3. Wrt grouping inside tuples, etc., I can only say, "cool".

Yes, I think that the grouping thing would be quite useful for other 
purposes, too, so I'd probably implement it anyway.

 > Or does that date me too much?

Being an old hand myself, I don't know. Isn't "cool" "leet" anymore? Or 
do we all have to write "kewl" now? ;-)

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

Re: [q-lang-users] RFC: Conditional syntax

[Keith T. <kaz...@ea...>]

Hello Albert,

Someone has been busy! Well, as you asked for them, here are my comments:

1. Wrt the <ifelse> function, I prefer keeping "ifelse X Y Z"; it is clean and concise.

2. Wrt multi-way and matching conditionals, I prefer your option (1); however, I would be equally happy if BOTH options (1) and (2) were implemented. I personally dislike curly braces "{}" (they remind me of my Perl days ;-); however, option (2) is consistent with the new stream syntax, so I can live with it (but I prefer using Lispy-parens).

3. Wrt grouping inside tuples, etc., I can only say, "cool". Or does that date me too much?

Thank you for asking!

Cheers,
Keith 
 

[q-lang-users] RFC: Conditional syntax

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

Hi all,

I've completed: memoized special arguments; call-by-need pattern 
matching; and a built-in lambda implementation -- along with the usual 
kind of syntactic sugar, i.e., "\X.Y". As a wanted side-effect, lambdas 
also work much faster now, and correctly deal with the anonymous 
variable and non-linear patterns. This is all in CVS now.

For the next RC I still have one item on my TODO list: conditionals. For 
this, I'm seeking your advice and comments.

First, I'd like to add sugar for the ifelse function ("if X then Y else 
Z"). That should be rather straightforward, but I still have to figure 
out how to add that to the syntax without making the grammar ambiguous. 
But do we really need/want this? Or is everyone happy with "ifelse X Y 
Z" as it is?

Second, I'd like to replace the multiway and matching conditionals in 
the standard library. These look awfully C-stylish and verbose right now 
(the following examples are somewhat silly since you'd probably do them 
with conditions and patterns on the equation level instead, but they are 
for illustrative puposes only):

(Ex. 0)

abs X    = switch (case (X<0) (-X), default X);
empty Xs = match Xs (case [] true, default false);

So this what we have right now. I'd like to replace this with something 
more tidy and Lisp-like. Maybe this:

(Ex. 1)

abs X    = cond ((X<0, -X), (true, X));
empty Xs = case Xs (([], true), (_, false));

Or maybe the sequence of clauses should actually be a stream instead of 
a tuple?

(Ex. 2)

abs X    = cond {(X<0, -X), (true, X)};
empty Xs = case Xs {([], true), (_, false)};

This has the advantage that the sequence of clauses could be a 
non-special argument (since the expressions inside of it are already 
protected by the stream constructor), and that we could even have 
infinite lists of clauses.

I'm also considering to add some unobtrusive syntactic sugar to allow 
"grouping" inside tuples, lists and streams. E.g., [X1,Y1;X2,Y2;...] 
would be the same as [(X1,Y1),(X2,Y2),...]; this would also be useful, 
e.g., for writing lists of key-value pairs. With this notation, the 
above could be rewritten as:

(Ex. 3)

abs X    = cond (X<0, -X; true, X);
empty Xs = case Xs ([], true; _, false);

Which, IMHO, is quite tidy and also looks ok when formatted in two 
columns, e.g.:

empty Xs = case Xs (
              [] , true;
              _  , false;
            );

Incidentally this also closely resembles the corresponding constructs in 
ML and Haskell (minus some of the sugar, of course).

So what do you prefer? Multiple choices possible. :)

0. Keep the old definitions (Ex. 0).
1. Clauses as a tuple of (guard/pattern, value) pairs (Ex. 1).
2. Clauses as a stream of (guard/pattern, value) pairs (Ex. 2).
3. 1 or 2 with "grouping" sugar (Ex. 3).
4. Don't care.
5. Any other ideas?

I'm currently leaning towards 2+3.

Comments appreciated...

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

Re: [q-lang-users] Not able to build RC2

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

Hi Patrick,

yes, the interpreter hasn't been ported to 64 bit yet. This is a known 
issue, I have it on my TODO list for the 7.2 release.

Cheers,
Albert

Patrick Albuquerque wrote:
> Hello,
> 
> FWIW, I was able to compile Q in a 32-bit chroot environment on the same
> machine.  I would prefer to run 64 bit though.
> 
> Thanks,
> Patrick.


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

Re: [q-lang-users] Not able to build RC2

[Patrick A. <rp...@al...>]

Hello,

FWIW, I was able to compile Q in a 32-bit chroot environment on the same
machine.  I would prefer to run 64 bit though.

Thanks,
Patrick.
-- 

Re: [q-lang-users] Not able to build RC2

[John C. <co...@cc...>]

Patrick Albuquerque scripsit:

> I am not able to build q-7.1rc2.tar.gz
> 
> I am running 64 bit Debian unstable, AMD, SMP.  configure ran ok, and I
> installed libgmp3, but make fails as shown below.

Cygwin does not yet support 64-bit platforms, so you need to build it as a 32-bit
application (I don't know how to do that).

-- 
John Cowan     http://ccil.org/~cowan    co...@cc...
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

[q-lang-users] Not able to build RC2

[Patrick A. <rp...@al...>]

Hello,

I am not able to build q-7.1rc2.tar.gz

I am running 64 bit Debian unstable, AMD, SMP.  configure ran ok, and I
installed libgmp3, but make fails as shown below.

I tried running alien on the rpm, but failed due to 32-bit library
problems.

Thanks for any tips,
Patrick.
-- 

if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl   -I../readline-4.2
-DYEAR='"2006"' -DSYSINFO='"
x86_64-unknown-linux"'
-DQPATH='".:/usr/local/share/q/lib:/usr/local/lib/q"'
-DQEXEC='"/usr/local/bi
n/q"' -DLIBTOOL='"/usr/local/lib/q/libtool"' -DCC='"gcc"'
-DREADLINE_LIBRARY -g -O2 -MT qcc-getopt1.
o -MD -MP -MF ".deps/qcc-getopt1.Tpo" -c -o qcc-getopt1.o `test -f
'getopt1.c' || echo './'`getopt1.c; \
then mv -f ".deps/qcc-getopt1.Tpo" ".deps/qcc-getopt1.Po"; else
rm -f ".deps/qcc-getopt1.Tpo"; exit 1; fi
/bin/sh ../libtool --tag=CC --mode=link gcc -DYEAR='"2006"'
-DSYSINFO='"x86_64-unknown-linux"'
-DQPATH='".:/usr/local/share/q/lib:/usr/local/lib/q"'
-DQEXEC='"/usr/local/bin/q"'
-DLIBTOOL='"/usr/local/lib/q/libtool"' -DCC='"gcc"'
-DREADLINE_LIBRARY -g -O2   -o qcc  qcc-qcc.o qcc-qbase.o
qcc-sys.o qcc-getopt.o qcc-getopt1.o  -lgmp  -lcrypt -lutil
-lnsl -lm
gcc -DYEAR=\"2006\" -DSYSINFO=\"x86_64-unknown-linux\"
-DQPATH=\".:/usr/local/share/q/lib:/usr/local/lib/q\"
-DQEXEC=\"/usr/local/bin/q\"
-DLIBTOOL=\"/usr/local/lib/q/libtool\" -DCC=\"gcc\"
-DREADLINE_LIBRARY -g -O2 -o qcc qcc-qcc.o qcc-qbase.o qcc-sys.o
qcc-getopt.o qcc-getopt1.o  /usr/lib/libgmp.so -lcrypt -lutil
-lnsl -lm
PATH=".:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/rpm/bin:/home/rpm/bin"
QPATH="../stdlib:../modules/clib:../modules/clib" ./q ./qcwrap.q
./qcwrap.q
def: error loading module
Warning: 268 unresolved external symbols
! File def, line 297: Value mismatch in definition
make[2]: *** [qcwrap.c] Error 2
make[2]: Leaving directory `/home/rpm/downloads/q-7.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rpm/downloads/q-7.1'
make: *** [all] Error 2

Re: [q-lang-users] CVS head failed to build, flex yytext_ptr problems

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

Peter Minten wrote:
> qmlex.c:1396: warning: conflicting types for 'yyunput'
> qmlex.c:1396: error: static declaration of 'yyunput' follows non-static 

Hi Peter,

so this didn't fix the problem. :( I guess I'll have to install the 
newer flex to figure out how to fix this.

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

Re: [q-lang-users] cgi.q

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

Albert Graef <Dr....@t-...> writes:

[snip]
> > The photo gallery is mostly ruby, but /Pictures/ itself and wittering/
> > are pure Q. scot-pics has one ruby script to regenerate the base map
> > image at regular intervals, but otherwise all the /?x=&y= stuff is
> > handled by Q.
> 
> Is there any reason why the image generation stuff couldn't be done with
> Q? (Other than that you've already written it in Ruby, of course. I'm
> just curious whether there's something crucial missing in the Q library.)

No obvious reason - I had infrastructure-related problems with versions of
imagemagick at the time.

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

Re: [q-lang-users] cgi.q

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

Tim Haynes wrote:
>>BTW, shouldn't we put those (un)lines/words functions into the standard
>>library, i.e., string.q? IIRC Haskell also has them in the standard
>>prelude.
> 
> Sure, that would be most handy.

Well, after giving it a second thought I decided against it. There's not 
a single right way to implement these functions, and so it should be up 
to the user. (In fact, your version of these functions considerably 
differs from the ones in the Haskell prelude.)

> I'll knock-up an example or two in the next few days :)

Great, thanks.

> The photo gallery is mostly ruby, but /Pictures/ itself and wittering/ are
> pure Q. scot-pics has one ruby script to regenerate the base map image at
> regular intervals, but otherwise all the /?x=&y= stuff is handled by Q.

Is there any reason why the image generation stuff couldn't be done with 
Q? (Other than that you've already written it in Ruby, of course. I'm 
just curious whether there's something crucial missing in the Q library.)

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

Re: [q-lang-users] cgi.q

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

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
> > Oh, drat, you've got me - I've not upgraded Q to 7.1 on the live site. Fix
> > it by all means! :)
> 
> All right, it's in cvs now:
> http://q-lang.cvs.sourceforge.net/q-lang/q/examples/cgi.q

Excellent!

> BTW, shouldn't we put those (un)lines/words functions into the standard
> library, i.e., string.q? IIRC Haskell also has them in the standard
> prelude.

Sure, that would be most handy.

> > I keep meaning to normalize everything and make one central library of
> > the Q modules, too...
> 
> Please by all means do. Or, if it's too much hassle right now, I could
> also add a cgi subdirectory to q/examples and put cgi.q there together
> with your other cgi helper scripts, maybe along with some basic examples
> to show how they are used?

I'll knock-up an example or two in the next few days :)

> > [Q-powered websites]
> > Yes indeed - I'm up to at least 3 sites, now:
> >     http://pig.sty.nu/Pictures/      http://scot-pics.sty.nu/
> > http://pig.sty.nu/wittering/
> 
> These are impressive. I've seen them before, but didn't realize that they
> were done with Q. Any chance that I might peek at some of the Q scripts,
> sometime? ;-)

Thanks! Sure - I'll drop you a copy off-list.

The photo gallery is mostly ruby, but /Pictures/ itself and wittering/ are
pure Q. scot-pics has one ruby script to regenerate the base map image at
regular intervals, but otherwise all the /?x=&y= stuff is handled by Q.

[snip]
> That'd be great. BTW, we also have an sqlite3 module now. It should be
> easy to support that, too, because the basic interface is quite similar
> to that of the odbc module. (Besides that it's much easier to set up an
> sqlite database, the sqlite3 module also has a number of nice extras
> which aren't currently supported by the odbc module, like user-defined
> functions and collation sequences; i.e., you can have SQL functions
> implemented in Q.)

Nice!

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

Re: [q-lang-users] cgi.q

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

Tim Haynes wrote:
> Oh, drat, you've got me - I've not upgraded Q to 7.1 on the live site. Fix
> it by all means! :)

All right, it's in cvs now: 
http://q-lang.cvs.sourceforge.net/q-lang/q/examples/cgi.q

BTW, shouldn't we put those (un)lines/words functions into the standard 
library, i.e., string.q? IIRC Haskell also has them in the standard prelude.

> I keep meaning to normalize everything and make one central library of the
> Q modules, too...

Please by all means do. Or, if it's too much hassle right now, I could 
also add a cgi subdirectory to q/examples and put cgi.q there together 
with your other cgi helper scripts, maybe along with some basic examples 
to show how they are used?

> [Q-powered websites]
> Yes indeed - I'm up to at least 3 sites, now:
>     http://pig.sty.nu/Pictures/  
>     http://scot-pics.sty.nu/     
>     http://pig.sty.nu/wittering/ 

These are impressive. I've seen them before, but didn't realize that 
they were done with Q. Any chance that I might peek at some of the Q 
scripts, sometime? ;-)

>>http://muwiinfa.geschichte.uni-mainz.de:5050/kirnberger.html
> 
> Neat!

Well, it's a beginning; I always wanted to put all the midi blobs into a 
database, and maybe "Ajaxify" the page a bit so that you don't have to 
load a new page each time you play a polonaise. If only the day had more 
than 0x24 hours...

> Sounds good to me. There's a test function in cgi.q that might help; if I
> get a moment I might try & write a cleaner db->xml->xslt sample as well.

That'd be great. BTW, we also have an sqlite3 module now. It should be 
easy to support that, too, because the basic interface is quite similar 
to that of the odbc module. (Besides that it's much easier to set up an 
sqlite database, the sqlite3 module also has a number of nice extras 
which aren't currently supported by the odbc module, like user-defined 
functions and collation sequences; i.e., you can have SQL functions 
implemented in Q.)

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

Re: [q-lang-users] cgi.q

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

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
> > Eep, well spotted. OK, I'm attaching the latest version I have in use here.
> 
> Dear Tim,
> 
> thanks a lot indeed. I'm ready to commit the new version to cvs, but with
> Q 7.1 I get: Error cgi.q, line 91: invalid character escape `\?'. Here's
> the corresponding line:
> 
> 
>                          (regex "" "^http://[^?]+\?(.*)$" HR (reg 1) )
> 
> You probably want a \\? there? (Yes, John, I admit that you were right
> all along: It's hard to spot such bugs without making unrecognized char
> escapes a syntax error. (-:)

Oh, drat, you've got me - I've not upgraded Q to 7.1 on the live site. Fix
it by all means! :)

I keep meaning to normalize everything and make one central library of the
Q modules, too...

> >    * A `strictatoi' function (a wrapper around val that only works if the
> > string is a number - saves a risk of Q-injection! - also uses `matches')
> 
> I don't know whether this is helpful, but you can also use `valq' to do a
> "safe parse" without evaluating anything:
> 
> safe_atoi S = I where 'I:Int = valq S;

Ah, thanks :)

> BTW, do you still have a Q-powered page available anywhere? I remember
> that you once had a part of the interface to your picture collection
> written in Q, is that still the case?

Yes indeed - I'm up to at least 3 sites, now:
    http://pig.sty.nu/Pictures/  
    http://scot-pics.sty.nu/     
    http://pig.sty.nu/wittering/ 

Mostly they're simple db<->xml+xslt things, althoguh scot-pics includes
imagemagick and wittering/ is an increasingly complicated not-blog
thing(TM) with spam-reduced comments and support for pinging technorati
etc.

> In case someone is interested in this side of Q programming, I also have
> a little Q-powered website. The entry point is here:
> 
> http://muwiinfa.geschichte.uni-mainz.de:5050/kirnberger.html

Neat!

> Hmm, it just came to me that I should probably put some Q cgi scripting
> examples on q-lang.sf.net...

Sounds good to me. There's a test function in cgi.q that might help; if I
get a moment I might try & write a cleaner db->xml->xslt sample as well.

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

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

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

John Cowan wrote:
> Success!

Great. :)

> I think you should add the "-lqint -liconv -lgmp -lq" incantation to
> Appendix C for Cygwin users.

Done.

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