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

Re: [q-lang-users] More Unicode queries.

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

John Cowan wrote:
> In particular, the W3C has just released a draft set of unified
> character entities from XHTML, MathML, and the ISO sets: see the draft at
> http://www.w3.org/TR/2007/WD-xml-entity-names-20071214/ and the unified
> list at http://www.w3.org/2003/entities/2007/w3centities-f.ent .

Ok, this is in cvs now. I also made available a tarball (snapshot of
current cvs) in testing:

http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958


Here's the blurb from the manual:

   As of version 7.11 and later, the interpreter also supports symbolic
character escapes of the form `\&NAME;', where NAME is any of the XML
single character entity names specified in the "XML Entity definitions
for Characters", see `http://www.w3.org/TR/xml-entity-names/'. Note
that, at the time of this writing, this is still a W3C working draft,
so the supported entity names may be subject to change until the final
specification comes out; the currently supported entities are described
in the draft from 14 December 2007, see
`http://www.w3.org/TR/2007/WD-xml-entity-names-20071214/'. Also note
that multi-character entities are _not_ supported in this
implementation.


Examples (make sure you set your email client to UTF-8 encoding if this
comes out garbled):

==> "Gr\äf"
"Gräf"

==> "Gr\&junk;f"
! Invalid character escape in string constant
>>> "Gr\&junk;f"
       ^

==> puts "The greek letter \&phgr; is the 21st letter in the Greek
alphabet.\n"
The greek letter φ is the 21st letter in the Greek alphabet.
()


Enjoy, and please let me know if there's anything that doesn't appear to
work right.

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] More Unicode queries.

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

Rob Hubbard wrote:
> I think the user should be able to define his own, but I'm not sure
> how this should be expressed. Then if a user particularly needs a
> character outside that set, he can define his own.

I don't think that this should be part of the language. Q doesn't want
to be XML after all. Q strings are constants; there's no direct way to
rewrite strings, as you suggested as a mechanism to add your own entity
definitions. The escape mechanism just provides an alternative way to
specify certain character literals, and I think it should be kept that
way. If you really need more then you're always free to write your own Q
module which provides the necessary operations to perform any kind of
string substitutions that you want (albeit at runtime).

I agree, however, that it's useful to have symbolic escapes for a fixed
set of special characters such as extended Latin, math symbols, arrows,
block graphics and the like. The W3C set has some 2200 of these, which
AFAICS provides you with plenty of special symbols for almost any
purpose. The downside is that the W3C set doesn't include most foreign
scripts, but why would anyone want to write, say, Kanji using escape
sequences? It's much easier to type these directly using the appropriate
input methods and a Unicode-capable text editor.

D'accord?

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] More Unicode queries.

[Rob H. <hub...@gm...>]

> Will these be allowed in all places (identifiers as well as strings)?
> I would say yes: def \π = 3.141592653

I was inclined to say "yes" initially. But having thought about it a
little more, I think there are the following reasons against it:

(1) this looks bit too much like a #define in 'C' for my taste, a poor
man's macro language

(2) it may be difficult to deal well with both string contexts and code contexts

(3) could there be problems with confusing a user defined (\&) operator?

(4) Q already has a good way to deal with such constants

Rob.

Re: [q-lang-users] More Unicode queries.

[Rob H. <hub...@gm...>]

> > [John] Once you have stripped comments and entities with more than one character
> > in them, you have a list of 2114 short, plausible names for 1509 useful
> > Unicode characters.  There are duplicates for historical reasons, like
> > ContourIntegral and conint -- longer dupes could be stripped if you
> > saw fit.

I'd strip the historical duplicates.

I think its okay for an entity to have more than one character.

> [Albert] I think that this is an excellent idea! Would everyone be happy with
> using the entity names instead of the unwieldy Unicode names?
>
> If so, then the remaining question is which syntax are we going to use
> in strings for that? I suggest something like \φ, as in:
>
> "The greek letter \φ is the 21st letter in the Greek alphabet."

I was thinking in terms of \N{...}, but I like \&...; too. Perhaps
that would be less confusing for Python (and other languages that I
can't bring myself to mention again :-) ) users.

> Any other suggestions? I'm looking forward to a nice lexical syntax
> flamefest. ;-)

I think the user should be able to define his own, but I'm not sure
how this should be expressed. Then if a user particularly needs a
character outside that set, he can define his own.

I can't think of a way to do it without introducing a new keyword such
as "entity".

Rob.

Re: [q-lang-users] More Unicode queries.

[Rob H. <hub...@gm...>]

Ah, I wrote this before I saw John's reply. Here it is anyway...

> >> No. Are there other languages which offer this?
> >
> > Python:
> >     \N{name}
>
> Ok, I see. Well, I could probably extract the necessary tables from ICU,
> but that would add quite as lot of static string data to the
> interpreter. So, before I put this on the TODO list, let me ask whether
> anybody really wants/needs this?

I see. Well in that case, ironically, my vote is "no". I don't think
the price is worth paying. Apart from anything else, the Unicode names
are truly horrible.

However, I wonder whether a mechanism like XML's entities could be
used for Q strings. I can't think of a Q-like way to do it. Allowing
\N{name} within a string to be subject to rewrite rules would be the
sort of thing that would be useful. However, it ought to be done when
the program is parsed rather than run. [XML does not restrict an
entity to a single character.]

I don't think this would upset the Q style, as currently a Q file can
already affect the way a program is parsed, with the advent of
under-defined infixed symbolic operators.

A user would be free to define his string entities in a Unicode-like
or XHTML-like or TeX-like style, according to taste. Thus he could
define an em dash as \N{EM DASH} or \N{mdash} or \N{---}.

In this way, it might be possible to supply a handful of <entity.q>
files containing names for at least the most commonly used symbols,
perhaps in varying styles and to varying extents.

Rob.

Re: [q-lang-users] More Unicode queries.

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

John Cowan wrote:
> Will these be allowed in all places (identifiers as well as strings)?
> I would say yes: def \π = 3.141592653

I would say no, as they go against readability. Just have a look at
ASCII'ified Fortress code; I think that it looks horrible.

In Q, a notation like this really looks more like a conglomerate of
operators and identifiers at first glance. Therefore, if you want
Unicode letters in identifiers, I think it's better to just use a
Unicode-capable editor and type them "as is".

Character escapes in strings are a different kind of thing, however.
I've put the entity character escapes for strings on my TODO list for
the next 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

Re: [q-lang-users] More Unicode queries.

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

Albert Graef scripsit:

> If so, then the remaining question is which syntax are we going to use
> in strings for that? I suggest something like \φ, as in:

I like that.

Be aware that entity names are case-sensitive (unlike Unicode names which
are all upper case) and that valid characters in names are A-Z, a-z, 0-9,
and full stop.  In principle, minus sign and underscore are also allowed,
but are not in fact used.

> "The greek letter \φ is the 21st letter in the Greek alphabet."

Will these be allowed in all places (identifiers as well as strings)?
I would say yes: def \π = 3.141592653

--
But the next day there came no dawn,            John Cowan
and the Grey Company passed on into the         co...@cc...
darkness of the Storm of Mordor and were        http://www.ccil.org/~cowan
lost to mortal sight; but the Dead
followed them.          --"The Passing of the Grey Company"

Re: [q-lang-users] More Unicode queries.

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

John Cowan wrote:
> In particular, the W3C has just released a draft set of unified
> character entities from XHTML, MathML, and the ISO sets: see the draft at
> http://www.w3.org/TR/2007/WD-xml-entity-names-20071214/ and the unified
> list at http://www.w3.org/2003/entities/2007/w3centities-f.ent .
> 
> Once you have stripped comments and entities with more than one character
> in them, you have a list of 2114 short, plausible names for 1509 useful
> Unicode characters.  There are duplicates for historical reasons, like
> ContourIntegral and conint -- longer dupes could be stripped if you
> saw fit.

I think that this is an excellent idea! Would everyone be happy with
using the entity names instead of the unwieldy Unicode names?

If so, then the remaining question is which syntax are we going to use
in strings for that? I suggest something like \φ, as in:

"The greek letter \φ is the 21st letter in the Greek alphabet."

Any other suggestions? I'm looking forward to a nice lexical syntax
flamefest. ;-)

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] More Unicode queries.

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

Rob Hubbard scripsit:

> There's something similar in XML: character entities such as
>     ï
>     —
> defined in the DTD for XHTML
>     <!ENTITY iuml "&#239;" >
>     <!ENTITY mdash "&#8212;" >
> so I suppose these could then be used in XSLT if you count that as a
> programming language.

I think this is a reasonable compromise, as opposed to having either no
names at all or the complete verbose Unicode official names, like, say,
ARABIC LIGATURE UIGHUR KIRGHIZ YEH WITH HAMZA ABOVE WITH ALEF MAKSURA
ISOLATED FORM (U+FBF9).

In particular, the W3C has just released a draft set of unified
character entities from XHTML, MathML, and the ISO sets: see the draft at
http://www.w3.org/TR/2007/WD-xml-entity-names-20071214/ and the unified
list at http://www.w3.org/2003/entities/2007/w3centities-f.ent .

Once you have stripped comments and entities with more than one character
in them, you have a list of 2114 short, plausible names for 1509 useful
Unicode characters.  There are duplicates for historical reasons, like
ContourIntegral and conint -- longer dupes could be stripped if you
saw fit.

-- 
John Cowan                              <co...@cc...>
            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org

Re: [q-lang-users] More Unicode queries.

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

Rob Hubbard wrote:
>> No. Are there other languages which offer this?
> 
> Python:
>     \N{name}

Ok, I see. Well, I could probably extract the necessary tables from ICU,
but that would add quite as lot of static string data to the
interpreter. So, before I put this on the TODO list, let me ask whether
anybody really wants/needs this?

> (Originally, I just wondered whether if might be available "for free"
> through a library used to implement Unicode support in Q.)

No, I didn't like the idea to add a huge dependency like ICU to the
interpreter. So I wrote the code for parsing utf8 myself, and other than
that Q only pilfers a few bits from ICU for the character predicates,
and uses libiconv for encoding conversions.

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] More Unicode queries.

[Rob H. <hub...@gm...>]

> > Finally, can the Unicode characters also be escaped by name?
>
> No. Are there other languages which offer this?


Python:
    \N{name}
e.g.
    \N{LATIN SMALL LETTER I WITH DIAERESIS}
    or \N{EM DASH}
e.g. in
    str = u'Encyclop\N{LATIN SMALL LETTER AE}dia'

[I believe Perl is similar.]


There's something similar in XML: character entities such as
    ï
    —
defined in the DTD for XHTML
    <!ENTITY iuml "&#239;" >
    <!ENTITY mdash "&#8212;" >
so I suppose these could then be used in XSLT if you count that as a
programming language.


I'm not sure there's sufficient need for something similar in Q.
(Originally, I just wondered whether if might be available "for free"
through a library used to implement Unicode support in Q.)


Thanks,
Rob.

Re: [q-lang-users] Documentation of streams

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

Rob Hubbard wrote:
> The section *does* mention that these are now built-in. Perhaps it
> should be clarified that they are therefore not importable.

Ok, I added this in cvs.

> I always feel a bit bad about sending "bug" reports like this.

No problem, I know that the docs are not perfect yet, so I'm thankful
for all suggestions. :)

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] More Unicode queries.

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

Rob Hubbard wrote:
> So the differences are: hex codes begin "\0x" rather than just "\x",
> and the numerals following the escape are read "hungrily", hence the
> need for parenthesis sometimes.

That's right. Maybe a note for C/Python/whatever language users is in
order to emphasize these differences.

> Perhaps you could emphasise these differences, and also give some
> Unicode examples, such as:

There are examples for all kinds of escapes in that section. However,
I'll gladly accept patches to the text (preferably in texi format, though).

> Finally, can the Unicode characters also be escaped by name?

No. Are there other languages which offer this?

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] Documentation of streams

[Rob H. <hub...@gm...>]

Dear Albert,

There have been some changes to streams recently (in Q7.1 and Q7.8).

=A711.8 says that the streams are defined by
    public type Stream =3D special const nil_stream, cons_stream X Xs;

However, the file <stream.q> no longer defines nil_stream,
cons_stream. Thus certain import statements don't work as expected,
e.g.
    from stream import nil_stream, cons_stream;

The section *does* mention that these are now built-in. Perhaps it
should be clarified that they are therefore not importable.

I always feel a bit bad about sending "bug" reports like this. So I
must add that Q is one of my few favourite languages, and that I think
the documentation is both comprehensive and very comprehensible.

Best wishes,
Rob.

[q-lang-users] More Unicode queries.

[Rob H. <hub...@gm...>]

Dear Albert,

Thanks for all the info in reply to my email back in November.

Still on the subject of Unicode, I wondered if the documentation on
Unicode strings could be clarified a little.

In =A73.5 you describe how to encode characters. Your method is subtly
different from that in the other languages I know. I was expecting
something like "\U1234" for a Unicode character. Also, in some
languages, the character encodings are of the form "\0377" and "\xFF"
(of fixed length), and so it's easy to misread the Q documentation if
familiar with such other klanguages.

So the differences are: hex codes begin "\0x" rather than just "\x",
and the numerals following the escape are read "hungrily", hence the
need for parenthesis sometimes.

Perhaps you could emphasise these differences, and also give some
Unicode examples, such as:

    "Gr\(0x00E4)f" // although this is in Latin-1 too
    "Gr\(0xE4)f"
    "Infinity =3D \(0x221E)"
    "\(0x2202)f/\(0x2202)x" // partial "df/dx"

(or some better ones).

I prefer your method, by the way, to that in other languages. I
particularly like the parenthesis. I think "\(0x1B)" looks very clear
even when not required.

Finally, can the Unicode characters also be escaped by name?

Thanks,
Rob.

Re: [q-lang-users] Floating point arithmetics

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

Jir(í Spitz wrote:
> Therefore I would like to ask how Q does represent floating point 
> numbers and whether there is some workaround of that.

They are double precision (64 bit), whatever the C compiler provides
(that's usually IEEE 754 these days). AFAICT, this is exactly what
Erlang uses by default, so if your code runs interpreted (using
bytecodes) then the results should be the same (rounding errors during
I/O notwithstanding). But if you compile your Erlang program to native
code, the actual precision may be higher, e.g., 80 bit on x86 systems,
since the compiler will keep floating point values on the x87 stack as
long as possible [1]. This isn't offered by Q right now, as we don't
have a native code compiler yet, so this may explain the differences
that you see.

As for workarounds, double precision is the only floating point type
that Q offers right now, so you're out of luck with the builtin
arithmetic. It should be possible to implement multiprecision floating
point arithmetic in Q, using, e.g., the MPFR library [2], but that needs
some work. If your algorithms work with rational numbers, you could use
rational arithmetic which is readily available in Q [3], but this isn't
a silver bullet either and I doubt that it will be practical with
ill-conditioned matrices because the numerators and denominators might
get very large.

[1] ftp://ftp.csd.uu.se/pub/papers/masters-theses/0229-lindahl.pdf
[2] http://www.mpfr.org/
[3] http://q-lang.sourceforge.net/qdoc/qdoc_11.html#SEC97

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] Floating point arithmetics

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

Hello Jiшн,

Saturday, January 05, 2008, 1:13:24 AM, you wrote:

JS> Hello Q users,

JS> In order to calculate some linear regressions I ported a few routines 
JS> from the BLAS library to the Q (solving system of linear equations, 
JS> matrix inversion). Experimenting with this routines I found that 
JS> calculations are quite imprecise. E.g. inversion of Hilbert matrix 

That's an interesting question. I've implemented some linear algebra routines
in Q, but the strong point of this language is that they could be done
PRECISE. That means no error at all.

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

[q-lang-users] Floating point arithmetics

[<jir...@bl...>]

Hello Q users,

In order to calculate some linear regressions I ported a few routines 
from the BLAS library to the Q (solving system of linear equations, 
matrix inversion). Experimenting with this routines I found that 
calculations are quite imprecise. E.g. inversion of Hilbert matrix 
(which behaves very badly in this respect) of size of 5 leads to an 
error of approximately 1e-5. Realizing the same algorithm in Erlang 
leads to an error of circa 1e-13.

Therefore I would like to ask how Q does represent floating point 
numbers and whether there is some workaround of that.

Many thanks,

Jiri Spitz

Re: [q-lang-users] problem with command line parsing

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

Hi David, and welcome to the list!

As Tim already pointed out, the interpreter only evaluates expressions,
so you need to put the equations into a file and run that with the
interpreter. The shebang magic and main function in Tim's example are
only needed, however, if you want to run your script as a standalone
program. Otherwise, just use your favourite text editor and put the line

sqr X = X*X;

into a file, say, sqr.q. Now you can run the program from the command
line like so:

q sqr.q

Or, if you already started the interpreter, you can run the script from
the interpreter's prompt:

==> run sqr.q

In any case, the equations are now ready to be used, so you can now type:

==> sqr 2

I should really put this into the FAQ, this has been asked a couple of
times already. :) However, you can find some information about using the
interpreter on the corresponding wiki page:

http://q-lang.wiki.sourceforge.net/Using+the+Interpreter

There you can also read about how to run the interpreter in Emacs, which
is maybe the most convenient way to run Q scripts interactively if you
know Emacs. I'm afraid that this information is a bit Linux-centric
right now, but the described setup should work equally well on OSX and
other Unix systems if you have Emacs installed.

BTW, in case you didn't know this, thanks to the work of Ryan Schmidt a
MacPorts port of Q to OSX exists which greatly reduces the hassle of
compiling Q there. You can find more information about this here:
http://q-lang.sourceforge.net/download.html#Ports

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] problem with command line parsing

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

"David Minor" <dah...@gm...> writes:

>    Hello Qusers,
>    With great travail I succeeded in compiling Q on my mac osx 10.3.4
>    system (cannot upgrade because of unavailable ProTools drivers).  Q
>    passed all of it's internal tests, but the most elementary examples in
>    the tutorials return errors, for example:
>    ==> sqr X = X*X;
>    sqr X=X*X
>    ==> sqr 2
>    sqr 2
>    ==> who
>    is my compilation broken or do I just not understand the syntax of the
>    language?

The latter. You don't define functions interactively; write scripts for
those. 


    #!/usr/local/bin/q
    #! -c main || quit

    sqr X = X*X;

    main = printf "%d\n" $ sqr 2 || quit;

gives:
 | zsh/scr9, potato 12:27PM temp/ % ./q.q
 | 4
 | zsh/scr9, potato 12:28PM temp/ %

HTH,

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

[q-lang-users] problem with command line parsing

[David M. <dah...@gm...>]

Hello Qusers,
With great travail I succeeded in compiling Q on my mac osx 10.3.4 system
(cannot upgrade because of unavailable ProTools drivers).  Q passed all of
it's internal tests, but the most elementary examples in the tutorials
return errors, for example:


==> sqr X = X*X;
sqr X=X*X

==> sqr 2
sqr 2

==> who


is my compilation broken or do I just not understand the syntax of the
language?

Re: [q-lang-users] Compiling Q on Mac OS X

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

Ryan Schmidt wrote:
> Users who do not want the X functionality can install  
> the ImageMagick port with the +no_x11 variant, and then neither  
> Apple's X11 nor XFree86 is required.

Ah, I missed that. Great. I really have to try MacPorts on that lonely
PowerMac in the office some time. :)

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] Compiling Q on Mac OS X

[Ryan S. <q-l...@ry...>]

On Dec 19, 2007, at 19:46, Albert Graef wrote:

> Tim Haynes wrote:
>
>> Definitely maybe the ODBC interface, please :)
>
> Yes, SQLite's advantage is that it's very easy to use, but if you want
> to work with existing databases there's no way around ODBC.
>
>>     ./configure --prefix=/usr/local/stow/q \
>>       --with-{x,gmp,rl,pthread,curl,gdbm,magick,xml}
>
> I didn't mention gdbm since I think it's not used all that much  
> anymore
> (someone correct me if I'm wrong), but it's not a big dependency,  
> so you
> might as well include the gdbm interface in the basic package, along
> with the xml interface. (The latter would bring in libxml2, libxslt  
> and
> libz, so it wouldn't be a huge dependency either. I guess that if you
> use stuff from MacPorts, chances are that you already have these
> libraries anyway, since they are used by a lot of applications.)

I will look into providing variants for these various requests so  
that people who want them can have them, and those who do not will  
not need the extra dependencies.

> The magick module is nice for both graphics and web programming, but
> here the story is a bit different because the ImageMagick port  
> drags in
> XFree86 (even if you don't need the X11 functionality), so you might
> want to provide this as an option.

Users are expected to install Apple's X11 (it's installed by default  
on Leopard, available on the install DVD for Tiger, available from  
Apple's web site for Panther). If Apple's X11 is present, XFree86 is  
not required. Users who do not want the X functionality can install  
the ImageMagick port with the +no_x11 variant, and then neither  
Apple's X11 nor XFree86 is required.

> Anyway, these are just suggestions... It's good to have Q in MacPorts,
> even just the basic package. Now when people ask for OS X packages, I
> can simply refer them to your port, that's very nice. :)

Re: [q-lang-users] Compiling Q on Mac OS X

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

Tim Haynes wrote:
> Definitely maybe the ODBC interface, please :)

Yes, SQLite's advantage is that it's very easy to use, but if you want
to work with existing databases there's no way around ODBC.

>     ./configure --prefix=/usr/local/stow/q \
>       --with-{x,gmp,rl,pthread,curl,gdbm,magick,xml} 

I didn't mention gdbm since I think it's not used all that much anymore
(someone correct me if I'm wrong), but it's not a big dependency, so you
might as well include the gdbm interface in the basic package, along
with the xml interface. (The latter would bring in libxml2, libxslt and
libz, so it wouldn't be a huge dependency either. I guess that if you
use stuff from MacPorts, chances are that you already have these
libraries anyway, since they are used by a lot of applications.)

The magick module is nice for both graphics and web programming, but
here the story is a bit different because the ImageMagick port drags in
XFree86 (even if you don't need the X11 functionality), so you might
want to provide this as an option.

Anyway, these are just suggestions... It's good to have Q in MacPorts,
even just the basic package. Now when people ask for OS X packages, I
can simply refer them to your port, that's very nice. :)

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] Infixed Ternary Operators?

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

Hi Rob,

> It is possible to define a ternary infix operator? For example, suppose 
> the operator is called f, and takes three arguments
>     public f P X Y;
> 
> I'd like to write
>     X (f 13) Y
> rather than
>     f 13 X Y

No, sorry, this isn't possible right now. Since operators are detected
at the lexical level already, I don't even see how this could be
implemented in an LALR(1) parser.

I think there are a few languages which essentially open up the language
syntax to allow the programmer to do this kind of thing (define new
mixfix operators etc.), but I don't think that this would work well in
modern FPL syntax with curried function applications.

> If it can't be done, then I don't consider it important enough (or even 
> necessarily desirable) to implement. I just wondered whether there might 
> be some kind of Q trick I'd not thought of.

Well, you could define an ordinary infix operator, but then you'd have
to use something like X f 13 Y which would actually be parsed as X f (13
Y) so this is probably not what you want. It would be a rather dirty
trick anyway, and wouldn't work in all cases (e.g., X f succ 12 ==> X f 13).

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