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

Re: [q-lang-users] "listof" surprises

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

Marco Maggesi wrote:
>> You could even define yourself a special form 'let'
>> as follows:
>>
>> special let B X;
>> let (A=Z) X = case Z (A,X;);
> 
> I like this very much!  Thanks.

Thought so. :) Q's abilities to define "meta" or "macro" functions like
this make the language much more powerful than other modern FPLs.

But actually this isn't the end of the story yet. For simple cases the
above definition of 'let' is already good enough, but there is an
improved definition which is slightly more involved but also properly
treats the corner cases. In the following I consider the 'let' version
using 'lambda':

special let B X;
let (A=Z) X = (\A.X) Z;

The above version works nicely even in nested expressions as long as
there are no repeated variables. For instance:

==> let (X=1) $ let (Y=X+1) (Y,Y+1)
(2,3)

But note what happens, e.g., if a nested 'let' attempts to bind a
variable which is already bound by an outer 'let' expression:

==> let (X=1) $ let (X=X+1) (X,X+1)
(\1 . (1,1+1)) 2

Ugh. This happens because the outer 'let' gets expanded first and
'lambda' replaces *all* instances of X in the nested 'let' expression.
The same misbehaviour also arises if 'let' is nested inside other
"lambda-binding" expressions, like 'listof':

==> [let (X=X+1) (X,X+1) : X in [1..2]]
[(\1 . (1,1+1)) 2,(\2 . (2,2+1)) 3]

Usually this is not what you want. Instead you want a variable to be
bound by the innermost lambda-binding expression. This can be achieved
by making 'let' known to 'lambda' as a lambda-binding expression which
needs to be expanded recursively. This involves two steps:

- Make 'let' expressions a subtype of the predefined 'Lambda' type.

- In addition to the definition of 'let' itself, also give an equation
for the 'lambdax' function which defines how 'lambda' should expand
nested 'let' expressions.

This machinery is supported by the builtin 'lambda' which will
automagically apply 'lambdax' to all members of subtypes of 'Lambda' in
the lambda body. 'lambdax' is supposed to return a quoted expression
which is substituted for the original lambda-binding expression in the
lambda body.

So here is an overhauled definition which follows these guidelines:

type Let : Lambda = special let B X;
let (A=Z) X = (\A.X) Z;
lambdax (let (A=Z) X) = '((\A.X) Z);

(Other special forms involving 'lambda', like list comprehensions, are
defined in the same fashion, see cond.q.)

This now works as expected:

==> let (X=1) $ let (X=X+1) (X,X+1)
(2,3)

==> [let (X=X+1) (X,X+1) : X in [1..2]]
[(2,3),(3,4)]

Well, at least it works with latest cvs version of the interpreter. ;-)

Unfortunately, the above won't work yet if you define 'let' in terms of
'case', because 'case' expressions aren't an instance of 'Lambda' right
now. Should they be? Probably. Another item for the Q 7.7 TODO list...

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] "listof" surprises

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

ma...@ma... wrote:
> I just got burned by this unexpected (for me, of course) behavior of
> list comprehension.  Given the program
> 
>    delta X X      = 1;
>    delta _ _      = 0 otherwise;
>    tabulate N M F = [[F I J : I in [1..N]] : J in [1..M]];
>    eye N          = tabulate N N delta;
> 
> then (eye 2) evaluates to [[0,0],[0,0]] instead of [[1,0],[0,1]] as I
> would have imagined.

Ok, this bug is fixed in cvs now (qmfuns.c revision 1.62).

==> eye 2
[[1,0],[0,1]]

-- 
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] "listof" surprises

[Marco M. <ma...@ma...>]

On May 15, 2007, at 10:26 AM, Albert Graef wrote:

> It's not a bug, it's a feature. ;-) What's maybe confuding for Haskell
> programmers here is that 'case' is really just an ordinary Q function
> (albeit a special form) and the clauses argument is just a tuple.

Thank you for the very clear explanation.  I was completely missing
all that, including the grouping syntax.

> You could even define yourself a special form 'let'
> as follows:
>
> special let B X;
> let (A=Z) X = case Z (A,X;);

I like this very much!  Thanks.

M.

Re: [q-lang-users] "listof" surprises

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

Marco Maggesi wrote:
> Ok.  But
> 
>    ==> case (1,2) ((1,2),3)
>    ! Exception
>    syserr 8
>    >>> case (1,2) ((1,2),3)
>                          ^

It's not a bug, it's a feature. ;-) What's maybe confuding for Haskell
programmers here is that 'case' is really just an ordinary Q function
(albeit a special form) and the clauses argument is just a tuple. For
instance, your first example:

==> case (1,2) ((1,2),3; _, foo)
3

is just a shortcut for:

==> case (1,2) (((1,2),3), (_, foo))
3

Note that the notation used in the first example is "grouping syntax",
see the end of sec. 6.3 in the manual
[http://q-lang.sourceforge.net/qdoc/qdoc_6.html#SEC14] for an
explanation. This works with all kinds of tuple values (and also with
lists and streams):

==> (1,2;3,4,5;6,7)
((1,2),(3,4,5),(6,7))

So 'case (1,2) ((1,2),3)' is really just the same as 'case (1,2)
(1,2;3)', which is most probably *not* what you wanted. You probably
wanted this:

==> case (1,2) ((1,2),3;)
3

Note that '((1,2),3;)' is just a shortcut for the 1-tuple '(((1,2),3),)'
here.

> I discovered this bug while trying to use 'case' to mimimc a common
> pattern used in other functional languages, namely, use 'let .. in ..'
> to destroy data with irrefutable pattern matching.  E.g., say z1, z2
> are complex numbers and you want to computer their sum.  Then in ML
> or Haskell you can write something like:
> 
>    let (x1,y1) = z1 in
>    let (x2,y2) = z2 in
>    (x1+x2, y1+y2);

Well, you can do pretty much the same with Q's 'where' clauses, like:

foo Z1 Z2 = (X1+X2,Y1+Y2) where (X1,Y1) = Z1, (X2,Y2) = Z2;

Or you could use 'case', as you intended, which has the advantage that
you can use it anywhere inside an expression and don't need an equation
to do the binding. You could even define yourself a special form 'let'
as follows:

special let B X;
let (A=Z) X = case Z (A,X;);

Example:

==> let ((1,X)=(1,2)) (X+1)
3

Or you could define 'let' using 'lambda':

let (A=Z) X = (\A.X) Z;

The difference is that the first definition of 'let' will cause an
exception to be raised for a refuted match, while the second definition
just yields an unevaluated lambda application in this case. (Note that,
in any case, a pattern like (X,Y) is *never* going to be irrefutable in
Q, because of the dynamic typing.)

You see, Q is rather different from Haskell and most other FPLs in that
stuff like 'case', 'lambda' etc. is *not* built into the language, but
is defined *on top* of the term rewriting calculus which is the basis of
Q. (Well, actually 'lambda' is provided as a builtin now, but that's
just for performance reasons, otherwise it's just an ordinary Q
function. In fact, 'lambda' was defined in the standard library in
versions <7.x of the interpreter.)

HTH,
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] "listof" surprises

[Marco M. <ma...@ma...>]

On May 13, 2007, at 1:39 PM, Albert Graef wrote:

> Yes, your imagination is certainly right. ;-) [delta I J : I in  
> [1..2],
> J in [1..2]] does the right thing, so it seems to be an issue with the
> nested listof.

Thanks.

BTW, I just found a small bug in 'case':

   ==> case (1,2) ((1,2),3; _, foo)
   3

Ok.  But

   ==> case (1,2) ((1,2),3)
   ! Exception
   syserr 8
   >>> case (1,2) ((1,2),3)
                         ^
and

   ==> case (1,2) ((X,2),3);
   2

I discovered this bug while trying to use 'case' to mimimc a common
pattern used in other functional languages, namely, use 'let .. in ..'
to destroy data with irrefutable pattern matching.  E.g., say z1, z2
are complex numbers and you want to computer their sum.  Then in ML
or Haskell you can write something like:

   let (x1,y1) = z1 in
   let (x2,y2) = z2 in
   (x1+x2, y1+y2);

Often local variables are a convenient way to render this pattern, but
otherwise I cannot find another suitable idom (other than factorize the
function in the composition of several functions, one for every pattern
matching).

M.

Re: [q-lang-users] Another question around SDL and SWIG

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

Andrew Berg wrote:
> /Users/andrewb/dategrity-tourmaline-trunk/q/sdl/q/SDL.q: error loading
> module
> Warning: 361 unresolved external symbols
> [...]
> I've attached the SDL.q file.  It is pretty much swiped from another
> SWIG SDL binding project, so I suspect that it should work.  The last
> line in this .q file is pretty long.  Is there perhaps some line limit
> length in the interpreter that I'm hitting?

No, that shouldn't be a problem. Rather, the message indicates that for
some reason the interpreter cannot load the shared library associated
with the module. Could you please send me the rest of the source (SWIG
.i source etc.) in private mail? Then I can have a look at what's going
wrong there.

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] "listof" surprises

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

Hi Marco,

ma...@ma... wrote:
> I just got burned by this unexpected (for me, of course) behavior of
> list comprehension.  Given the program
> 
>    delta X X      = 1;
>    delta _ _      = 0 otherwise;
>    tabulate N M F = [[F I J : I in [1..N]] : J in [1..M]];
>    eye N          = tabulate N N delta;
> 
> then (eye 2) evaluates to [[0,0],[0,0]] instead of [[1,0],[0,1]] as I
> would have imagined.

Yes, your imagination is certainly right. ;-) [delta I J : I in [1..2],
J in [1..2]] does the right thing, so it seems to be an issue with the
nested listof. Maybe a bug crept in there when the matching semantics
were slightly changed in Q 7.1, so that the nested listof now gets
evaluated too early. I'll look into it, thanks for the report!

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] "listof" surprises

[Alexander N. <AN...@sp...>]

Hello maggesi,

Sunday, May 13, 2007, 3:01:10 AM, you wrote:

mmui> Hi,

mmui> I just got burned by this unexpected (for me, of course) behavior of
mmui> list comprehension.  Given the program

mmui>    delta X X      = 1;
mmui>    delta _ _      = 0 otherwise;
mmui>    tabulate N M F = [[F I J : I in [1..N]] : J in [1..M]];
mmui>    eye N          = tabulate N N delta;

mmui> then (eye 2) evaluates to [[0,0],[0,0]] instead of [[1,0],[0,1]] as I
mmui> would have imagined.  I vaguely understand that the first argument is
mmui> passed to delta 'too early' in tabulate, but I didn't try to read
mmui> cond.q and understand precisely why it works like this (yet).

Yes, it is evaluated 'too early', but there's a simple method to fix
it:

delta X:Int Y:Int     = 1 if Y = X;
                      = 0 otherwise;

thus delta I J will just remain not evaluated.

-- 
Best regards,
 Alexander                            mailto:AN...@sp...

[q-lang-users] Another question around SDL and SWIG

[Andrew B. <and...@ya...>]

So, I've been whacking on some SDL bindings again, and now I'm  
getting something that might be easy, but I don't quite understand  
the error.

Here's the error:

-------------------------------

andrewb$ q SDL.q
/Users/andrewb/dategrity-tourmaline-trunk/q/sdl/q/SDL.q: error  
loading module
Warning: 361 unresolved external symbols
   ____
/ __ \    Q interpreter version 7.6 (i686-apple-darwin8.8.1)
/ /_/ /    Copyright (c) 1991-2006 by Albert Graef
\___\_\    http://q-lang.sourceforge.net

This software is distributed under the terms of the GNU General Public
License version 2 or later; type `copying' for details.
! File SDL.q, line 728: Value mismatch in definition

==>

-------------------------------

I've attached the SDL.q file.  It is pretty much swiped from another  
SWIG SDL binding project, so I suspect that it should work.  The last  
line in this .q file is pretty long.  Is there perhaps some line  
limit length in the interpreter that I'm hitting?

Thanks,

-andrew

[q-lang-users] "listof" surprises

[<ma...@ma...>]

Hi,

I just got burned by this unexpected (for me, of course) behavior of
list comprehension.  Given the program

   delta X X      =3D 1;
   delta _ _      =3D 0 otherwise;
   tabulate N M F =3D [[F I J : I in [1..N]] : J in [1..M]];
   eye N          =3D tabulate N N delta;

then (eye 2) evaluates to [[0,0],[0,0]] instead of [[1,0],[0,1]] as I
would have imagined.  I vaguely understand that the first argument is
passed to delta 'too early' in tabulate, but I didn't try to read
cond.q and understand precisely why it works like this (yet).

This is not the point anyway.  My question rather is: wouldn't be a
different behavior more appropriated to avoid this kind of traps?
E.g., I would like to propose something like:

   special comprehension E V ~R;
   comprehension E V R =3D map (lambda V E) R;

for which the definition like

   tabulate N M F =3D comprehension (comprehension (F I J) I [1..N]) J [1..M=
];

seems to show a more predictable behavior.

Just trying to learn Q ...
M.

--=20
Marco Maggesi
Universit=E0 degli Studi di Firenze
http://www.math.unifi.it/~maggesi/


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [q-lang-users] Q 7.7 roadmap

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

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

> Tim Haynes wrote:
>> OOI does this mean we might get a searcn'n'replace function as standard?
>> If not, could we have one please? :)
>
> Maybe the one-liner in Sec. 12.17.7 of the manual does what you want?
> http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC138

Oh, that's nice! Thanks :)

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

Re: [q-lang-users] Q 7.7 roadmap

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

Tim Haynes wrote:
> OOI does this mean we might get a searcn'n'replace function as standard? If
> not, could we have one please? :)

Maybe the one-liner in Sec. 12.17.7 of the manual does what you want?
http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC138

Best,
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] Q 7.7 roadmap

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

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

[snip]
> - replace GNU regex with libpcre, so that we finally have
> unicode-capable regular expression support

OOI does this mean we might get a searcn'n'replace function as standard? If
not, could we have one please? :)

Ta,

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

Re: [q-lang-users] CVS head doesn't build under Cygwin

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

John Cowan wrote:
> My up-to-date Cygwin installation builds Q 7.6 fine, but cannot build
> from the CVS head because of autogen.sh problems.

Ok, that should be fixed in cvs now. I don't know why automake 1.10
complains about a missing config.rpath, it shouldn't be needed, but I've
added it anyway.

Tested with autoconf 2.61, automake 1.10 and libtool 1.5.23c on Linux.
Please let me know if you still run into problems with Cygwin.

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] Q 7.7 roadmap

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

 
--- Albert Graef <Dr....@t-...> writes:
- I might release a teaser consisting of the the first few chapters,
- which are almost finished, during summer.

That IS great news!

(I will hold a space open in my backpack for "The Q Companion". =)

Cheers,
Keith 
 

Re: [q-lang-users] Q 7.7 roadmap

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

Keith Trenton wrote:
> Great news! Btw., what's your working title?  =)

"The Q Companion: An Introduction to the Equational Programming
Language". I might release a teaser consisting of the the first few
chapters, which are almost finished, during summer.

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] Q 7.7 roadmap

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

 
--- Albert Graef <Dr....@t-...> writes:
- Q 7.7 is supposed to be a preview of Q 8.0 (which I hope
- to finish during summer and which will be the basis of
- the book about Q I'm writing).

Great news! Btw., what's your working title?  =)

Cheers,
Keith 
 

[q-lang-users] Q 7.7 roadmap

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

Hi all,

just to confirm that this project is still alive ... ;-) I started work
on Q 7.7 today with a bugfix in the tuple grouping syntax (see the cvs
log of qc.y and qmparse.y). I'm sorry for the long period of silence, I
was busy with presenting Q as well as other projects at various
conferences during the semester holidays, so I couldn't find the time to
work on Q as I had anticipated.

Q 7.7 is supposed to be a preview of Q 8.0 (which I hope to finish
during summer and which will be the basis of the book about Q I'm
writing). My TODO list for this release comprises the following major items:

- Wadler/Okasaki views: These will allow matching against "virtual"
constructors, using the existing customizable unparsing mechanism. This
will be useful for matching against abstract data types with private
constructors. Taking the Rational type as an example, you will then be
able to write something like 'foo (X%Y) = bar X Y;', employing (%) as a
virtual constructor.

- local variable bindings with lambda and friends (we've discussed this
on the list before, but I'm still not sure about the right way to do this)

- replace GNU regex with libpcre, so that we finally have
unicode-capable regular expression support

- scrap the bundled readline and unbundle the gnocl/gqbuilder stuff from
the core distribution

- add Rob's polynomial library to the "all in one" package

- bug and portability fixes (in particular, as John has pointed out,
compatibility with recent automake versions needs to be worked on, and,
as Rob rightfully complained, the expression unparser needs support for
recursive invokations)

- I also plan to work on 64 bit compatibility asap, but I'm not sure
whether this will make it into 7.7 already.

Any other issues and missing features that I forgot? Please let me know!

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

[q-lang-users] Databases and GUI in Q (was: Re: Bug?)

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

Eddie Rucker wrote:
> You remember when we tested the speed of the bignum operations? Although
> I haven't tested it on more than two machines, it seems that Q is faster
> than mzscheme in the ODBC department as well. The ODBC module takes MANY
> less programming steps than SrPersist for mzscheme to retrieve a query
> too!

Nice to hear. :)

I think that we still need a function which returns the results of a
query as a stream instead of a list. That would make it possible to
handle big result sets in a lazy fashion while retaining the convenience
of a list-like representation. As both the ODBC and the SQLite
interfaces readily support fetching individual results of a query as
they become available, it should be fairly easy to implement that. (In
fact, it's probably just a matter of rewriting the existing list-based
functions with streams.) Any takers?

> I must admit that I dig the GUI stuff in mzscheme over Tk though :(

You mean the "PLT framework" stuff? Is that based on some existing
toolkit? Can you give some more details?

I know that Tk looks rather old-fashioned and Q's Tk interface requires
you to write icky Tcl code, but it's adequate for simple applications,
works almost everywhere and you can use vtcl as a GUI builder. As an
alternative, we also have a bridge to Gnome/GTK via Gnocl, together with
its own GUI builder written in Q, but that only appears to work on Un*x
systems right now and the canvas widget is buggy. It would also be
possible to directly wrap one of the popular toolkits using SWIG but so
far noone has volunteered for such a tedious job. ;-) So it might be a
good idea to work on something smaller and more functional in style.

In fact, Yann Orlarey recently suggested to me that it would be nice to
have an experimental, functional style GUI framework in Q which would
allow you to play with new UI concepts. That sounds like an interesting
research project. We could probably build this on some cross-platform
and cross-backend graphics library (Cairo?). I'm currently working on a
functional reactive programming (FRP) framework for processing realtime
events in Q, and most of the underlying concepts should also be
applicable to GUIs. I'll have to think about that some more, but I think
that it would be a nice addition. If anyone would be interested in
participating in such a project then please let me know.

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] Bug?

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

Eddie Rucker wrote:
> sprintf "%g" 1+3
> => "4"
> sprintf "%g" 1*3
> => "1"*3
> 
> Is this a bug?

Nope. :) sprintf "%g" 1 => "1", and "1" happens to be a Char which is an
enumeration type, thus "1"+3 is the third successor of "1", which (in
Unicode as well as in ASCII) is "4".

Q is a sharp knife, you know... ;-)

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

[q-lang-users] Bug?

[Eddie R. <ed...@bm...>]

Hi!

sprintf "%g" 1+3
=> "4"
sprintf "%g" 1*3
=> "1"*3

Is this a bug?
I know, I know, I should use parenthesis to avoid this sort of thing.

Eddie

Re: [q-lang-users] Q and SDL

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

Andrew Berg wrote:
> After a long, distracting series of illnesses, I'm working once again  
> at using SWIG to allow Q to call SDL.

Hi Andrew,

sorry to hear about your illness, I hope you're well again? Otherwise my
best wishes for a speedy recovery!

> The problem that I run into is that I  
> get some warnings from swig.
> 
> SDL_keyboard.i:25: Warning(314): mod is a Q keyword
> SDL_events.i:72: Warning(314): type is a Q keyword

Looks like q-swig is a bit overzealous with those warnings, those field
names shouldn't actually give you any problems because the generated
setters and getters for the struct fields should be stropped with both a
leading struct name and a trailing _set or _get. If the generated .q
wrapper script compiles cleanly then you should be safe.

I've put the bogus warnings on my TODO list for the next q-swig release.

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

[q-lang-users] Q and SDL

[Andrew B. <and...@ya...>]

Hi, all!

After a long, distracting series of illnesses, I'm working once again  
at using SWIG to allow Q to call SDL.  I've found a set of swig SDL  
wrappers for occam (search for "occsdl" with Google) which seemed  
like a good starting point.  The problem that I run into is that I  
get some warnings from swig.

SDL_keyboard.i:25: Warning(314): mod is a Q keyword
SDL_events.i:72: Warning(314): type is a Q keyword
SDL_events.i:79: Warning(314): type is a Q keyword
SDL_events.i:87: Warning(314): type is a Q keyword

The offending code seems obvious.

typedef struct SDL_keysym {
	Uint8 scancode;			/* hardware specific scancode */
	int sym;			/* SDL virtual keysym - enums*/
	int mod;			/* current key modifiers - enums*/
	Uint16 unicode;			/* translated character */
} SDL_keysym;

... and ...

/* Application visibility event structure */
typedef struct SDL_ActiveEvent {
	Uint8 type;	/* SDL_ACTIVEEVENT */
	Uint8 gain;	/* Whether given states were gained or lost (1/0) */
	Uint8 state;	/* A mask of the focus states */
} SDL_ActiveEvent;

The "type is a Q keyword" one is repeated many times.  I can clearly  
change "mod" to "SDL_mod" or something, and likewise "type" to  
"SDL_type" in order to avoid this, but just changing those two seems  
really vile.  Changing all the identifiers in the structures seems  
less vile, but maybe equally unpleasant for anyone using this library.

Does anyone have a better recommendation for how I might deal with this?

-andrew

Re: [q-lang-users] Q/Tk bug or feechur?

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

Evan Hawkins wrote:
> I was playing with Q and Tk, the clipboard widget, in particular. I
> found that the Q interpreter(?) seems to hang on to a lock after a tk "clipboard get" action.

Hmm, I guess I'll need some more detail to track this down. Do you have
a kind of minimal test program and detailed instructions on how to
reproduce this bug? I've never seen this before, but then I don't use
Windows very much.

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] qix 0.4 - polynomial library

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

 
Sweet! I will definitely find the time to "kick the tires".
Thanks, Rob (and Albert =)!

Keith