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

[q-lang-users] New multimedia stuff on q-lang.sf.net

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

Hi, all,

I've just released several new components for Q's multimedia library: 
Q-OpenGL (OpenGL interface, 3d graphics programming), Q-Xine (Xine 
interface, multimedia playback) and Q-Faust (interface to Grame's Faust, 
a functional realtime DSP language; build your own realtime software 
synths, audio effects, etc.). All brand-new (well, they've been in cvs 
for a while, but now tarballs and binary and source rpms are available).

Enjoy! :)
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

[q-lang-users] Types and multiple inheritance

[John.Cowan <jc...@re...>]

As I understand it, variable references with a type guard T match only
expressions whose operators are declared in the type declaration for T
or inherited from T's supertype, if any.

Since there is no state involved with types, it's not clear to me why
types aren't permitted to inherit from multiple supertypes.  The diamond
inheritance problem would be trivial in such a situation, since one
"nil" is as good as another.

I have no particular use cases for this, but the restriction to a single
supertype seems arbitrary and un-Q-ish.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              jc...@re...
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

Re: [q-lang-users] A proposal to adopt Python tuple syntax

[John.Cowan <jc...@re...>]

Albert Graef scripsit:

> >A minor point is whether (,) and [,] will become legal ways to write the
> >empty tuple and list respectively.  I don't much care either way.
> 
> Why would anyone want to have this? I don't see what this would buy.

It's a matter of how you conceptualize the optional trailing comma in tuples
other than 1-tuples.  If the rule is "a comma is permitted after the last
element", then "(,)" is illegal.  If the rule is "a comma is permitted before
the right parenthesis", then "(,)" is legal and means the same as "()".
(And the same reasoning for lists.)

As I say, I don't care how this one is decided.

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.reutershealth.com
Jurchen tribes under the leadership of the      http://www.ccil.org/~cowan
Manchus, his successor Abahai (1592-1643)       jc...@re...
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all         The Languages of China
to be called Manchus.

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

John.Cowan wrote:
> It's plausible, I think, to stage the change in:  let 6.1 accept trailing
> commas everywhere, and start to warn about the old style (but still accept
> it as making a tuple); 6.2 then drops support for the old style, and
> plain parens are just for grouping thereafter.

Yup, that's the way to go. If noone objects, the transition will start 
with the next Q release.

> Something I didn't realize until today is that Python doesn't actually
> require parens around tuples: it's the comma that is the (currying)
> tuple constructor:

Yes, I know this. But in Q that shortcut is not possible, it would 
collide with the def and where clause syntax.

> A minor point is whether (,) and [,] will become legal ways to write the
> empty tuple and list respectively.  I don't much care either way.

Why would anyone want to have this? I don't see what this would buy.

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

Re: [q-lang-users] magick.q: error loading module

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

Brian Wilfley wrote:
> One other question: do you have a suggestion for a plotting library
> that could be used by Q?

Well, under Linux I'd probably use opendx, or gnuplot (via octave). The 
latter might even work under Windows as well, I haven't tried that yet.

Do you have something specific in mind? If you have a C or C++ library 
which does the job, you could wrap it as a Q module using Q-SWIG.

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

Re: [q-lang-users] magick.q: error loading module

[Brian W. <drc...@gm...>]

Ahhh, very good. I'm running pretty good now. (I had Q8, switched to 5.5.7-=
Q16.)

Thanks very much.

One other question: do you have a suggestion for a plotting library
that could be used by Q?

Thanks again.

Brian

Re: [q-lang-users] magick.q: error loading module

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

Brian Wilfley wrote:
> I installed version 6.2.3 of imagemagick, which gave "signal 11
> caught" which caused things to fail.

Yes, the necessary fix for IM 6.x support is in cvs already, will be in 
the Q 6.1 release, so the next version of Qpad will be linked against 
the newest IM release.

> Then I down-graded to version
> 5.5.7. Now, I'm getting further, but when I use read_image I get the
> following sort of problems: [...]

All this works without a problem on my WinXP system. Which version do 
you have, _exactly_? Note that there are two different variants, 
5.5.7-Q16 and -Q8. Qpad-6.0 is linked against the former.

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

Re: [q-lang-users] magick.q: error loading module

[Brian W. <drc...@gm...>]

Hello Dr. Gr"af,

Thanks for your comments. Based on them, I made some progress.

I installed version 6.2.3 of imagemagick, which gave "signal 11
caught" which caused things to fail. Then I down-graded to version
5.5.7. Now, I'm getting further, but when I use read_image I get the
following sort of problems:

=3D=3D> read_image "mozilla.png" ()
**  read_image "mozilla.png" ()  =3D=3D>  magick_error "430: UnableToOpenFi=
le ()"
magick_error "430: UnableToOpenFile ()"

=3D=3D> read_image "logo:" ()
**  read_image "logo:" ()  =3D=3D>  magick_error "430: UnableToOpenFile ()"
magick_error "430: UnableToOpenFile ()"

=3D=3D> read_image "xc:white" (100,100,0,8)
**  read_image "xc:white" (100,100,0,...)  =3D=3D>  magick_error "430:
UnableToOpenFile ()"
magick_error "430: UnableToOpenFile ()"

By virtue of at least the last example, I conclude that the problem is
not one of paths: xc: creates an image without reference to the file
system, I gather.

Any further comments would be greatly appreciated.

Thanks again.

Brian


On 6/25/05, Albert Graef <Dr....@t-...> wrote:
> Brian Wilfley wrote:
> > I grabbed the windows executable bundle: Q-pad. When I try to run
> > magicktest.q, I get 116 unresolved symbols. (See output including
> > debug output below.)
>=20
> Which ImageMagick version do you have installed? And are you sure that
> the ImageMagick dlls are somewhere on the PATH?
>=20
> --
> 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
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] magick.q: error loading module

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

Brian Wilfley wrote:
> I grabbed the windows executable bundle: Q-pad. When I try to run
> magicktest.q, I get 116 unresolved symbols. (See output including
> debug output below.)

Which ImageMagick version do you have installed? And are you sure that 
the ImageMagick dlls are somewhere on the PATH?

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

[q-lang-users] magick.q: error loading module

[Brian W. <drc...@gm...>]

Hi folks,

I'm a new user.

I grabbed the windows executable bundle: Q-pad. When I try to run
magicktest.q, I get 116 unresolved symbols. (See output including
debug output below.)

I did a search for "magick.dll" files on my disk and only have the one:
c:\Program Files\Qpad\lib\magick.dll
so I don't think it's a conflicting version.

Any thoughts?

Thanks very much.

Brian

-----------------------
% C:\Program Files\Qpad\examples\magick\magicktest.q
C:\Program Files\Qpad\lib/magick.q: error loading module
Warning: 116 unresolved external symbols
! Value mismatch in definition
**  clib::sys_vars  =3D=3D>  (1,2,4,...)
--  def (SIZEOF_CHAR,SIZEOF_SHORT,SIZEOF_INT,...) =3D (1,2,4,...)
--  def SIG_IGN =3D -1
--  def SIG_DFL =3D 0
--  def SIG_TRP =3D 1
--  def SCHED_OTHER =3D 0
--  def SCHED_RR =3D 1
--  def SCHED_FIFO =3D 2
--  def AF_UNIX =3D -1
--  def AF_FILE =3D -1
--  def S_ISUID =3D 2048
--  def S_ISGID =3D 1024
--  def S_ISVTX =3D 512
--  def S_IRWXU =3D 448
--  def S_IRUSR =3D 256
--  def S_IWUSR =3D 128
--  def S_IXUSR =3D 64
--  def S_IRWXG =3D 56
--  def S_IRGRP =3D 32
--  def S_IWGRP =3D 16
--  def S_IXGRP =3D 8
--  def S_IRWXO =3D 7
--  def S_IROTH =3D 4
--  def S_IWOTH =3D 2
--  def S_IXOTH =3D 1
**  this_thread  =3D=3D>  <<Thread>>
--  def clib::MAIN_THREAD =3D <<Thread>>
**  ggi::ggi_vars  =3D=3D>  (1,0,1,...)
--  def (GGI_FLAG_ASYNC,GGI_EV_NOTHING,GGI_EV_COMMAND,...) =3D (1,0,1,...)
--  def DEFAULT =3D 0

Re: [q-lang-users] A proposal to adopt Python tuple syntax

[John.Cowan <jc...@re...>]

Albert Graef scripsit:

> - You have to remember to write foo X, not foo(X), unless you really 
> want the argument to be a 1-tuple.

I think the Lispish impulse to write lambda (X) instead of lambda X fits in
here too.

> - You have to remember that -X is not a primary, so (-X) is not a 
> 1-tuple, but ((-X)) is.

That is, that -3.14159 is not a primary (it's self-evident that -X is not).

> OTOH, I'm arguing that Q's way to write 1-tuples avoids the ugliness of 
> a special notation like (X,). But I see the point that the current 
> notation is a possible source of confusion.

Guido characterizes the Python style as "ugly but effective", which I think
sums it up.

> How does everyone else here feel about this? If you have any anecdotal 
> evidence where you have been bitten by Q's 1-tuples, please speak up! 
> I'm not going to make a change like this light-heartedly, as it might be 
> a big inconvenience for some (it'll be one for me ;-). But if everyone 
> agrees that this must be changed, then it ought to change asap, before 
> everybody and his brother starts using Q. ;-)

It's plausible, I think, to stage the change in:  let 6.1 accept trailing
commas everywhere, and start to warn about the old style (but still accept
it as making a tuple); 6.2 then drops support for the old style, and
plain parens are just for grouping thereafter.

Something I didn't realize until today is that Python doesn't actually
require parens around tuples: it's the comma that is the (currying)
tuple constructor:

$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1,2,3
(1, 2, 3)
>>>

$ q
Q interpreter version 6.0 (i686-pc-cygwin)
Copyright (c) 1991-2004 by Albert Graef
This software is distributed under the terms of the GNU General Public
License version 2 or later; type `copying' for details.

==> 1,2,3
1
! Syntax error
>>> 1,2,3
     ^

==>

> Having thought about this a 
> little more, trailing commas could be allowed in all tuples and lists 
> (that's sometimes useful, anyway), and it would just be the 1-tuple case 
> where it's mandatory. Does that sound like a reasonable solution?

Yes, that was my original proposal (trailing commas allowed in all tuples,
required in 1-tuples).  The extension to lists is sensible for the sake of
having one fewer thing to learn.

A minor point is whether (,) and [,] will become legal ways to write the
empty tuple and list respectively.  I don't much care either way.

-- 
John Cowan  jc...@re...  www.ccil.org/~cowan  www.reutershealth.com
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

Re: [q-lang-users] LPs, CDs and other records

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

Tim Haynes wrote:
> Albert Graef <Dr....@t-...> writes:
>>
>>Not yet. That's something I've been thinking about lately. Might be a
>>good idea to adopt an ML/Haskell-ish syntax for that. [...]
> 
> Groovy. I like the way this is going.

Well, it's not going, rather crawling right now. :( I still have to work 
on the details, so don't expect this for the next release...

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

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

> Tim Haynes wrote:
>
> >>Concerning the curly braces, it might be a good idea to keep {...} for
> >>possible future extensions (Haskell-style records come to my mind).
> 
> > You read my mind ... or at least the other mail I just fired-off, partly
> > inspired by this idea.
> 
> No, I read your mind. Really. You know, I do that regularly. ;-)

:)

> > Would the change *require* trailling comma, or just permit it on the
> > grounds of forcing something to be a tuple?
> 
> No, the trailing comma would be entirely optional, except in that one
> ugly special case of the 1-tuple, where it would distinguish (X,) (a
> tuple) from (X) (a parenthesized expression).

Cool. I can cope with that, for sure. 

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

Re: [q-lang-users] LPs, CDs and other records

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

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

> Tim Haynes wrote:
>
> > Do we have some form of record / structure data-type and associated
> > manipulation functions?
> 
> Not yet. That's something I've been thinking about lately. Might be a
> good idea to adopt an ML/Haskell-ish syntax for that. Something like:
> 
> 
> type Person = person { name, address, phone };
> 
> def AG = person { name = "Albert", address = "Mainz", phone = "???" };
> 
> That would actually be syntactic sugar for an algebraic data type with
> getter and setter functions created automatically for you. However, it's
> not yet clear to me how to extend inheritance and pattern matching to
> make this really useful.

Groovy. I like the way this is going.

Ta,

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

Tim Haynes wrote:
>>Concerning the curly braces, it might be a good idea to keep {...} for
>>possible future extensions (Haskell-style records come to my mind). 
> 
> You read my mind ... or at least the other mail I just fired-off, partly
> inspired by this idea. 

No, I read your mind. Really. You know, I do that regularly. ;-)

> Would the change *require* trailling comma, or just permit it on the
> grounds of forcing something to be a tuple?

No, the trailing comma would be entirely optional, except in that one 
ugly special case of the 1-tuple, where it would distinguish (X,) (a 
tuple) from (X) (a parenthesized expression).

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

Re: [q-lang-users] LPs, CDs and other records

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

Tim Haynes wrote:
> Do we have some form of record / structure data-type and associated
> manipulation functions?

Not yet. That's something I've been thinking about lately. Might be a 
good idea to adopt an ML/Haskell-ish syntax for that. Something like:

type Person = person { name, address, phone };

def AG = person { name = "Albert", address = "Mainz", phone = "???" };

That would actually be syntactic sugar for an algebraic data type with 
getter and setter functions created automatically for you. However, it's 
not yet clear to me how to extend inheritance and pattern matching to 
make this really useful.

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

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

> Hi, Tim,
> 
> > I've not really been bitten by it except as a result of programmer error -
> > I might get temporarily confused whether I want to write
> >     map (lambda (N) (N+1)) [1..10]
> >                 ^ ^
> > or not (and in this case, not), but that's it.
> 
> Yup, that's actually the foo(99) thing in disguise. In my experience
> that's actually the most common source of confusion. So that speaks in
> favour of John's argument. I agree that if you really have to constantly
> think about those situations, then it should be changed.

OK.

[snip]
> > At first blush, I don't mind (and might even favour) having a different
> > syntax for forcing something to be a tuple - say use [] for lists, () for
> > parenthetical purposes *only*, which leaves <> or {} for tuples?
> 
> <...> doesn't work, e.g., how should something like < 5 > 3 > 1 be
> parsed, is it ((< 5 >) 3) > 1 or (< (5 > 3) >) 1 ? 

Very good question. OK, scrap that for a lark :)

> Concerning the curly braces, it might be a good idea to keep {...} for
> possible future extensions (Haskell-style records come to my mind). 

You read my mind ... or at least the other mail I just fired-off, partly
inspired by this idea. 

> So I'd actually prefer to keep using the parentheses for tuples, John and
> I even agree on that point. ;-)
> 
> Tim, if I understood you correctly, you don't really have any objections
> against the current notation, but wouldn't mind a change either. Is that
> correct? Could you live with that "trailing comma" thingie?

Would the change *require* trailling comma, or just permit it on the
grounds of forcing something to be a tuple?

Not that I'd object either way, really. No complaints here, it does seem
less insane than abusing <> for the purpose :)

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

Hi, Tim,

> I've not really been bitten by it except as a result of programmer error -
> I might get temporarily confused whether I want to write
>     map (lambda (N) (N+1)) [1..10]
>                 ^ ^
> or not (and in this case, not), but that's it.

Yup, that's actually the foo(99) thing in disguise. In my experience 
that's actually the most common source of confusion. So that speaks in 
favour of John's argument. I agree that if you really have to constantly 
think about those situations, then it should be changed.

> Not awake yet: would (-1,) be well-defined this way? What about ((-1),) and
> ((-1,),)  ? Would I want to remember all these permutations?

Yes, (-1,) = ((-1),) = (((-1)),) = a 1-tuple with member -1, whereas 
((-1,),) is a 1-tuple of a 1-tuple of -1. The only thing to remember 
would be that (X,) is always a 1-tuple, while (X) is always just X. When 
a tuple has more than one member, you could leave away the trailing 
comma, there is no ambiguity (and never has been) in that case. However, 
admitting a trailing comma in _all_ tuples (and lists) might be a good 
thing, for consistency, and for the same reasons that it is allowed in 
C's array constants.

> At first blush, I don't mind (and might even favour) having a different
> syntax for forcing something to be a tuple - say use [] for lists, () for
> parenthetical purposes *only*, which leaves <> or {} for tuples?

<...> doesn't work, e.g., how should something like < 5 > 3 > 1 be 
parsed, is it ((< 5 >) 3) > 1 or (< (5 > 3) >) 1 ? Concerning the curly 
braces, it might be a good idea to keep {...} for possible future 
extensions (Haskell-style records come to my mind). So I'd actually 
prefer to keep using the parentheses for tuples, John and I even agree 
on that point. ;-)

Tim, if I understood you correctly, you don't really have any objections 
against the current notation, but wouldn't mind a change either. Is that 
correct? Could you live with that "trailing comma" thingie?

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

[q-lang-users] LPs, CDs and other records

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

Hi folks,

Do we have some form of record / structure data-type and associated
manipulation functions?

I've trawled qdoc.pdf, hunting for `record' and `struct', but can't see
anything obvious.

I would like to be able to make class definitions and have accessor
functions automatically generated for all the fields therein. 
E.g., how do you say "a Point is a triple (X,Y,Z), Velocity and
Acceleration are Points (ish), and a Star object has Location, Velocity and
Acceleration and mass and colour", and go on to write some obvious
astrophysical simulation?

May it be possible to do this with a macro, perhaps, rather like Scheme? Or
have I missed something in the fine manual altogether?

Ta,

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

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

[snip]
> > I think it is a real problem.
> 
> Ok, point taken. To summarize: So far the most problematic usability issues
> related to Q's 1-tuples seem to be the following:
> 
> - You have to remember to write foo X, not foo(X), unless you really want
> the argument to be a 1-tuple.
> 
> - You have to remember that -X is not a primary, so (-X) is not a 1-tuple,
> but ((-X)) is.
> 
> - Superflous extra parentheses around non-primaries can sometimes be
> useful, especially in code generation.
> 
> OTOH, I'm arguing that Q's way to write 1-tuples avoids the ugliness of a
> special notation like (X,). But I see the point that the current notation
> is a possible source of confusion.
> 
> How does everyone else here feel about this? If you have any anecdotal
> evidence where you have been bitten by Q's 1-tuples, please speak up! I'm
> not going to make a change like this light-heartedly, as it might be a
> big inconvenience for some (it'll be one for me ;-). But if everyone
> agrees that this must be changed, then it ought to change asap, before
> everybody and his brother starts using Q. ;-)

TBH I don't have a major problem with the status quo, but then I'm only a
small-time allegedly-human not-much-of-a-programmer... :)

I've not really been bitten by it except as a result of programmer error -
I might get temporarily confused whether I want to write
    map (lambda (N) (N+1)) [1..10]
                ^ ^
or not (and in this case, not), but that's it.

> > One approach is to have prefix syntax to mark tuples, like the #(...)
> > of Scheme or Smalltalk (but not implying that the tuple members are
> > literals). This would be mandatory for 1-tuples and optional for all
> > other tuples.
> 
> No, then I'd favour the (X,) solution. Having thought about this a little
> more, trailing commas could be allowed in all tuples and lists (that's
> sometimes useful, anyway), and it would just be the 1-tuple case where
> it's mandatory. Does that sound like a reasonable solution?

Not awake yet: would (-1,) be well-defined this way? What about ((-1),) and
((-1,),)  ? Would I want to remember all these permutations?

At first blush, I don't mind (and might even favour) having a different
syntax for forcing something to be a tuple - say use [] for lists, () for
parenthetical purposes *only*, which leaves <> or {} for tuples?

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

John.Cowan wrote:
> Speaking as a human programmer, I wouldn't; speaking as someone who
> writes code that generates code, I have found redundant generation of
> parens to make my life simpler, secure in the knowledge that the next
> stage will discard them.

Ok, that is a point. To work around this right now, you could just 
generate all expressions in prefix form ((+) X Y etc.), though.

> De gustibus.

Well, I can say that in favour of my solution, too. ;-)

> Indeed, and in ML foo(99) works just fine, since there are no 1-tuples
> and the 0-tuple syntax means something else.

Yees, but in those languages you just can't write a generic function 
operating on tuples of arbitrary sizes, much less on an argument that 
can have _any_ type. In Q you can, and actually it's fairly 
straightforward, see e.g. lambda.q.

> I think it is a real problem.

Ok, point taken. To summarize: So far the most problematic usability 
issues related to Q's 1-tuples seem to be the following:

- You have to remember to write foo X, not foo(X), unless you really 
want the argument to be a 1-tuple.

- You have to remember that -X is not a primary, so (-X) is not a 
1-tuple, but ((-X)) is.

- Superflous extra parentheses around non-primaries can sometimes be 
useful, especially in code generation.

OTOH, I'm arguing that Q's way to write 1-tuples avoids the ugliness of 
a special notation like (X,). But I see the point that the current 
notation is a possible source of confusion.

How does everyone else here feel about this? If you have any anecdotal 
evidence where you have been bitten by Q's 1-tuples, please speak up! 
I'm not going to make a change like this light-heartedly, as it might be 
a big inconvenience for some (it'll be one for me ;-). But if everyone 
agrees that this must be changed, then it ought to change asap, before 
everybody and his brother starts using Q. ;-)

> One approach is to have prefix syntax to mark tuples, like the #(...)
> of Scheme or Smalltalk (but not implying that the tuple members are
> literals).  This would be mandatory for 1-tuples and optional for all other
> tuples.

No, then I'd favour the (X,) solution. Having thought about this a 
little more, trailing commas could be allowed in all tuples and lists 
(that's sometimes useful, anyway), and it would just be the 1-tuple case 
where it's mandatory. Does that sound like a reasonable solution?

Comments, please! I need _your_ inputs on that matter. Or do you all 
prefer that John and I decide this issue on our own? ;-) I'm soon going 
to start work on Q 6.1, this could be one of the language changes going 
into it (besides the $ operator proposed by Tim Haynes).

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

Re: [q-lang-users] A proposal to adopt Python tuple syntax

[John.Cowan <jc...@re...>]

Albert Graef scripsit:

> Identifying 1-tuples with their single members would certainly be the 
> most elegant solution, but unfortunately you can't do that in a language 
> where tuples are defined in a recursive fashion, so that you can 
> conveniently write generic functions operating on tuples of arbitrary sizes.

I agree.

> Why would you want to write something like ((A-B)) to mean (A-B) anyway?

Speaking as a human programmer, I wouldn't; speaking as someone who
writes code that generates code, I have found redundant generation of
parens to make my life simpler, secure in the knowledge that the next
stage will discard them.

> The (-99) is _not_ a 1-tuple simply because -X is not an atomic
> expression.

I guess that, as someone who knows more programming languages than I can
easily enumerate, I don't want to have to remember whether -99 is a
primary or an application; different languages take different views of it.
(Obviously -X is an always an application.)

> But I can't help it, I think that this syntax is just plain ugly.

De gustibus.

> Actually, I found that the most common problem related to Q's 1-tuple 
> syntax is that seasoned C or Pascal programmers write something like 
> foo(99) instead of foo 99, because it's what they are used to. 

Indeed, and in ML foo(99) works just fine, since there are no 1-tuples
and the 0-tuple syntax means something else.

> it's possible to relearn this, and if you want to learn a modern-style 
> FP language, you have to learn the curried function application style 
> anyway, so I don't see a real problem with this.

I think it is a real problem.

> Other opinions? I've thought about this problem for quite some time, but 
> maybe there's another, prettier solution I missed?

One approach is to have prefix syntax to mark tuples, like the #(...)
of Scheme or Smalltalk (but not implying that the tuple members are
literals).  This would be mandatory for 1-tuples and optional for all other
tuples.

-- 
John Cowan  www.ccil.org/~cowan  www.reutershealth.com  jc...@re...
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe

Re: [q-lang-users] A proposal to adopt Python tuple syntax

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

John.Cowan wrote:
> Representing tuples as parenthesized expressions separated by commas is
> a Good Thing, but 1-tuples (in languages where they are not the same as
> non-tuples) are always a syntactic wart.

Hi, John, I knew that someone was going to be bothered by this, sooner 
or later. ;-)

Yes I know this wart oh so well, and spent countless hours on it. :( 
Identifying 1-tuples with their single members would certainly be the 
most elegant solution, but unfortunately you can't do that in a language 
where tuples are defined in a recursive fashion, so that you can 
conveniently write generic functions operating on tuples of arbitrary sizes.

> The current Q solution to this wart is to interpret a parenthesized
> expression as a 1-tuple only in certain circumstances: as noted in the
> manual, "(99)" is a tuple but "(-99)" is not.

Yes, it's certainly a pitfall for Q beginners (I teach Q in university 
courses so I'm very aware of this ;-).

But, as a matter of fact, the rules are fairly clear: you get a 1-tuple 
by parenthesizing a primary expression, i.e., either an atomic 
expression or something which is already parenthesized, which is fairly 
well in line with common mathematical usage. Why would you want to write 
something like ((A-B)) to mean (A-B) anyway? The (-99) is _not_ a 
1-tuple simply because -X is not an atomic expression. Now you could 
argue that ((-99)) is even uglier than (-99,), but I'm not with you 
there ...

> I propose that the Python syntax be adopted instead.  A Python tuple
> is expressed in the same way as a Q one, except that there may be a
> terminating comma after the last expression.  In particular, "(expr,)"
> is unambiguously a 1-tuple, allowing "(expr)" and "((expr))" to be merely
> parenthesized expressions.  The Python printer prints a terminating
> comma only for 1-tuples.

Been there, done that. ;-) IIRC, I had something like this in a very 
early version of the interpreter (pre-2.0), well before I was aware that 
Python does it the same way. But I can't help it, I think that this 
syntax is just plain ugly.

Don't get me wrong: I'm all for good standard practices, so that ppl 
don't have to waste time to unneccesarily relearn something. But in this 
case I'd say that the (X,) notation is a wart and _not_ good standard 
practice. (Most, if not all, other FP languages avoid 1-tuples anyway, 
so there's no real "standard" here.)

Actually, I found that the most common problem related to Q's 1-tuple 
syntax is that seasoned C or Pascal programmers write something like 
foo(99) instead of foo 99, because it's what they are used to. However, 
it's possible to relearn this, and if you want to learn a modern-style 
FP language, you have to learn the curried function application style 
anyway, so I don't see a real problem with this.

Other opinions? I've thought about this problem for quite some time, but 
maybe there's another, prettier solution I missed?

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

[q-lang-users] A proposal to adopt Python tuple syntax

[John.Cowan <jc...@re...>]

Representing tuples as parenthesized expressions separated by commas is
a Good Thing, but 1-tuples (in languages where they are not the same as
non-tuples) are always a syntactic wart.

(wart: n.  A small, crocky feature that sticks out of an otherwise
clean design.  Something conspicuous for localized ugliness, especially
a special-case exception to a general rule.)

The current Q solution to this wart is to interpret a parenthesized
expression as a 1-tuple only in certain circumstances: as noted in the
manual, "(99)" is a tuple but "(-99)" is not.

I propose that the Python syntax be adopted instead.  A Python tuple
is expressed in the same way as a Q one, except that there may be a
terminating comma after the last expression.  In particular, "(expr,)"
is unambiguously a 1-tuple, allowing "(expr)" and "((expr))" to be merely
parenthesized expressions.  The Python printer prints a terminating
comma only for 1-tuples.

This syntax could be permitted in an early release, and then the old
interpretation of excess parentheses deprecated later on.

-- 
John Cowan  www.ccil.org/~cowan  www.reutershealth.com  jc...@re...
All "isms" should be "wasms".   --Abbie

[q-lang-users] ANN: Q-Faust

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

(Cross-posted to the Faust and Q mailing lists.)

Hi all,

I thought that some of you might be interested in a Faust [1] interface 
I created for my functional programming language Q [2]. The interface 
allows you to load and run Faust DSPs in Q. Those of you who attended 
Yann Olarey's Faust workshop and my talk about Q at LAC05 should have an 
idea of what I'm talking about. ;-) I think that Faust and Q really make 
a great combo, which allows you to do all your multimedia/DSP stuff 
using nothing but modern FP tools.

The Q-Faust interface is currently only available in cvs, see the 
q-faust module at [3]. A few examples are included, such as a realtime 
synthesizer playable via MIDI. To build and run this stuff, you'll need 
the Q core system, Q-SWIG, and the q-midi and q-audio modules, all 
readily available from [2]. And, of course, you'll also need Faust [1].

Relevant links:

[1] Faust homepage: http://faudiostream.sourceforge.net
[2] Q homepage: http://q-lang.sf.net
[3] Q cvs repository: http://cvs.sourceforge.net/viewcvs.py/q-lang

Enjoy! :)

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