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

Re: [q-lang-users] The implicit operator in Q

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

Albert Graef scripsit:

> 1. forbid a variable as the head element of the toplevel expression on 
> the lhs of an equation

I think it's against the spirit of Q to forbid something for no particular
reason, just because something that seems equivalent is forbidden
for good reason.  So I'd say no.

> 2. never reduce a function application with a "const" in the head, even 
> if there's a rule which allows this

This would be very surprising.  Rules should either work or provoke
an error.

> 3. forget about "const" and allow rules with constants in the head (but 
> this means that an equation like "0=1;" would be valid Q again)

That makes hash of the idea of constructors, which is a very important
one.  0 is just as much a constructor as bin_stream.

> 4. be happy that Q still leaves some dirty tricks to be discovered by 
> the master Q programmer ;-)

Indeed, though I think this particular trick could now be documented
in the manual.

> Note that this invisible operator is in fact just function application. 
> Since expressions in Q are not subject to any typing constraints, 
> nothing keeps you from writing something like "0 1" which applies the 
> "function" 0 to the "argument" 1.

I discovered this when playing with my Chicken egg; at that time I
didn't have identifiers working.

-- 
Knowledge studies others / Wisdom is self-known;      John Cowan
Muscle masters brothers / Self-mastery is bone;       co...@cc...
Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)

Re: [q-lang-users] The implicit operator in Q

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

>> Albert Graef <Dr....@t-...> wrote: 
>
> There are several ways to resolve this inconsistency:
>
>1. forbid a variable as the head element of the toplevel expression on 
>the lhs of an equation

>2. never reduce a function application with a "const" in the head, even 
>if there's a rule which allows this
>
>3. forget about "const" and allow rules with constants in the head (but 
>this means that an equation like "0=1;" would be valid Q again)
>
>4. be happy that Q still leaves some dirty tricks to be discovered by 
>the master Q programmer ;-)
>
>What do you think?


Since you asked... ;-)

1. Does this formerly hidden "feature" violate PoLS (principle of least surprise)? -- Not in my mind.

2. Do we want Q to take after Java, and try to keep programmers from doing stupid things? -- Again, not in my mind.

The above considerations lead me to favour option 4.

Cheers,
Keith 
 
BTW, it's just as hot where I am... =( 
 

Re: [q-lang-users] The implicit operator in Q

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

John Cowan wrote:
> Today I discovered that (whether intentionally or not, I don't know)
> the Q rule processor will accept rules whose head is a variable.  You can
> write rules like:
> 
> 	X:Num Y:Num = X * Y;

Yes, Q is fairly permissive with respect to the form of the left-hand 
sides of equations. In fact, early versions of the interpreter would 
place no restrictions whatsoever and thus even allow you to have 
equations like "true = false" or "0 = 1" which are now forbidden, to 
keep you from doing something "stupid".

But one could still consider the above behaviour as a misfeature, 
because an equation like "0 Y = Y+1" is forbidden while "X:Num Y = Y+1 
if X=0" works. There are several ways to resolve this inconsistency:

1. forbid a variable as the head element of the toplevel expression on 
the lhs of an equation

2. never reduce a function application with a "const" in the head, even 
if there's a rule which allows this

3. forget about "const" and allow rules with constants in the head (but 
this means that an equation like "0=1;" would be valid Q again)

4. be happy that Q still leaves some dirty tricks to be discovered by 
the master Q programmer ;-)

1+2 seem unnecessarily restrictive to me, while 3 is probably too 
permissive, and it also makes it more difficult to optimize the 
automatic evaluation of suspensions. I'm currently leaning towards 
solution 4, but that might be due to the fact that it's almost 40 degree 
Celsius a.k.a. 100 degrees Fahrenheit over here. ;-)

What do you think?

> ==> [1,2,3] [4,5,6]
> [1,2,3,4,5,6]
> 
> In effect, Q is allowing an implicit (empty) operator in these cases.

Note that this invisible operator is in fact just function application. 
Since expressions in Q are not subject to any typing constraints, 
nothing keeps you from writing something like "0 1" which applies the 
"function" 0 to the "argument" 1.

> This could be a very handy feature when dealing with types that have
> some natural "principal" function of two or more arguments.

Yes, but note that as the algebraic type constructors are usually 
declared "const", they currently cannot occur in the head. E.g., the 
following currently yields an error message:

type BinTree = const bin X Y, ...;

bin X Y Z = ...; // error

In fact, that's the whole point of having "const" function symbols. Of 
course, if you leave away the "const" then the equation becomes legal.

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] The implicit operator in Q

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

--- John Cowan <co...@cc...> wrote:
- Today I discovered that the Q rule processor will accept rules whose head is a variable.
- In effect, Q is allowing an implicit (empty) operator in these cases.

Cool! Thank you for sharing.

Cheers,
Keith 

[q-lang-users] The implicit operator in Q

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

Today I discovered that (whether intentionally or not, I don't know)
the Q rule processor will accept rules whose head is a variable.  You can
write rules like:

	X:Num Y:Num = X * Y;
	X:String Y:String = X ++ Y;
	X:List Y:List = X ++ Y;

and get these results:

==> 5 6
30

==> "abc" "def"
"abcdef"

==> [1,2,3] [4,5,6]
[1,2,3,4,5,6]

In effect, Q is allowing an implicit (empty) operator in these cases.
As long as the definition is associative, we also get useful results
from curried invocations like:

==> 1 2 3 4 5
120

This could be a very handy feature when dealing with types that have
some natural "principal" function of two or more arguments.

-- 
Said Agatha Christie / To E. Philips Oppenheim  John Cowan
"Who is this Hemingway? / Who is this Proust?   co...@cc...
Who is this Vladimir / Whatchamacallum,         http://www.ccil.org/~cowan
This neopostrealist / Rabble?" she groused.
        --author unknown to me; any suggestions?

Re: [q-lang-users] Multiple supertypes for Q?

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

John Cowan wrote:
> Albert Graef scripsit:
> 
>>Useful? Yes. Easy to add? No. 
> 
> Alas.

Well, I guess I'll take a look at this later this year, but no promises 
(yet).

-- 
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] Multiple supertypes for Q?

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

Albert Graef scripsit:

> Useful? Yes. Easy to add? No. 

Alas.

-- 
John Cowan   <co...@cc...>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

Re: [q-lang-users] Multiple supertypes for Q?

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

John Cowan wrote:
> Multiple supertypes would seem to be fairly cheap and easy to add to Q.

Useful? Yes. Easy to add? No. The problem is not so much the runtime 
costs, but that the current algorithm which generates the pattern 
matching automaton (the hairiest part of the bytecode compiler), only 
works with single inheritance.

It's probably possible to extend the algorithm to support multiple 
inheritance, but I don't think it's trivial. (If anyone wants to take a 
look at this, the basic term acceptor technique is described in my paper 
in the "Rewriting Techniques and Applications" 1991 proceedings (LNCS 
488). The source code is in qcrules.c.)

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] Multiple supertypes for Q?

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

Multiple supertypes would seem to be fairly cheap and easy to add to Q.
Declaring "type Bar : Foo" just means that the constructors of Bar will
match a variable with a Foo type guard.  If we further declare "type Baz :
Foo", that further adds the constructors of Baz to what X:Foo will match.
So there seems to be no obvious reason why "type Toto : Tata, Titi, Tutu"
shouldn't add Toto's constructors to the constructors matching X:Tata,
X:Titi, and X:Tutu.

This may be very expensive in the implementation for reasons I don't know
about, but if experience with Java interfaces and C abstract classes
is correct, it will not be used often but will be indispensable in
some cases.

Here are a few ideas for new built-in types assuming #1 is adopted,
borrowed from built-in Haskell type classes:

	Eq: for types on which = is defined;
	Ord: for types (including enums) on which < etc. are defined;
	Ix: for types on which ! is defined.

-- 
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] Is Q 64-bit clean?

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

dxtr scripsit:

> Is someone already installed Q in 64bit machine?
> I tried it in AMD64(Ubuntu), but I got a lot of warnings(size)
> and I got the following error:

64-bit support is not there yet; it's being worked on.

-- 
Possession is said to be nine points of the law,                John Cowan
but that's not saying how many points the law might have.       co...@cc...
        --Thomas A. Cowan (law professor and my father)

[q-lang-users] Is Q 64-bit clean?

[dxtr <dx...@ac...>]

Hi,

Is someone already installed Q in 64bit machine?
I tried it in AMD64(Ubuntu), but I got a lot of warnings(size)
and I got the following error:

./libtool: line 1803: cd: ./lib/termcap: No such file or directory
libtool: link: cannot determine absolute directory name of
`./lib/termcap'
make[3]: *** [libreadline.la] Error 1
make[3]: Leaving directory `/eif/q/readline-4.2'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/eif/q/readline-4.2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/eif/q'
make: *** [all] Error 2

Thanks,
dx

Re: [q-lang-users] q-lang-users Digest, Vol 2, Issue 2

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

Albert Graef scripsit:

> Yes, I see that q is a descendant of k, which I noticed before. It's 
> rather unfortunate that the developers chose the same name, albeit in 
> lowercase.
> 
> Hmm... is this somehow related to Per Bothner's Q? That was developed 
> around the beginning of the 1990s, and it was also based on APL, IIRC.

They don't seem to me to be related.

-- 
I am expressing my opinion.  When my            John Cowan
honorable and gallant friend is called,         co...@cc...
he will express his opinion.  This is           http://www.ccil.org/~cowan
the process which we call Debate.                   --Winston Churchill

Re: [q-lang-users] q-lang-users Digest, Vol 2, Issue 2

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

Boyko Bantchev wrote:
> At least for the Q that Larry Gregg mentioned -- the one
> at http://kx.com -- it most certainly is alive and well :)

Yes, I see that q is a descendant of k, which I noticed before. It's 
rather unfortunate that the developers chose the same name, albeit in 
lowercase.

Hmm... is this somehow related to Per Bothner's Q? That was developed 
around the beginning of the 1990s, and it was also based on APL, IIRC.

> K is highly applicative (though not purely functional),
> and mostly combinator-based (i.e. function-level).
> Blindingly fast, with unbelievably compact implementation

Yes, and it's also a very terse language. :)

-- 
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-lang-users Digest, Vol 2, Issue 2

[Boyko B. <bo...@gm...>]

On 7/5/06, Anthony <ad...@ke...> wrote:
>
> This is the third or possibly fourth "Q" I've seen.
> Our "Q" is perhaps the best or most actively
> developed.  Other q's have seem to have died...

Hmmm...

At least for the Q that Larry Gregg mentioned -- the one
at http://kx.com -- it most certainly is alive and well :)
It is the current development of an excellent language:
K, which is itself a descendant of APL and Lisp.
K is highly applicative (though not purely functional),
and mostly combinator-based (i.e. function-level).
Blindingly fast, with unbelievably compact implementation
(less than 200 KB, considering it has GUI and
such-and-such connectivities), and favours writing of
extremely concise programs.  Check e.g. http://nsl.com
for K and similar languages -- _lots_ of examples there.

Cheers,
   Boyko

Re: [q-lang-users] q-lang-users Digest, Vol 2, Issue 2

[Anthony <ad...@ke...>]

This is the third or possibly fourth "Q" I've seen. 
Our "Q" is perhaps the best or most actively
developed.  Other q's have seem to have died...

--- q-l...@li... wrote:

> Send q-lang-users mailing list submissions to
> 	q-l...@li...
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 
>
https://lists.sourceforge.net/lists/listinfo/q-lang-users
> or, via email, send a message with subject or body
> 'help' to
> 	q-l...@li...
> 
> You can reach the person managing the list at
> 	q-l...@li...
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of q-lang-users digest..."
> 
> 
> Today's Topics:
> 
>    1. Another Q Language (Larry Gregg)
>    2. Re: Another Q Language (Albert Graef)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 03 Jul 2006 23:16:49 -0500
> From: Larry Gregg <lg...@ac...>
> Subject: [q-lang-users] Another Q Language
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <44A...@ac...>
> Content-Type: text/plain; charset=windows-1252;
> format=flowed
> 
> People:
> 
> Perhaps you already know this, but I discovered
> another Q language:
> 
> http://www.kx.com/library/faq.php
> 
> "We enhanced the speed and efficiency of application
> development by 
> combining our general programming, relational, and
> time-series languages 
> into a single, concise programming language ? q. The
> q language is 
> integrated into the database, contributing to very
> high query 
> performance. Q uses English-like commands and a
> simple syntax. C or SQL 
> programmers typically learn q in less than a day.
> (See the Kdb+ Primer 
> written by Dennis Shasha, Associate Professor of
> Computer Science at 
> NYU's Courant Institute.)"
> 
> Larry Gregg
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 04 Jul 2006 15:12:53 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: Re: [q-lang-users] Another Q Language
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <44A...@t-...>
> Content-Type: text/plain; charset=windows-1252;
> format=flowed
> 
> Larry Gregg wrote:
> > Perhaps you already know this, but I discovered
> another Q language:
> > 
> > http://www.kx.com/library/faq.php
> 
> No, I didn't know this. Seems like this is fairly
> new. Oh well, I guess 
> that there's no big danger that the two will be
> confused...
> 
> -- 
> 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
> 
> 
> 
> ------------------------------
> 
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> 
> ------------------------------
> 
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
>
https://lists.sourceforge.net/lists/listinfo/q-lang-users
> 
> 
> End of q-lang-users Digest, Vol 2, Issue 2
> ******************************************
> 

Re: [q-lang-users] Another Q Language

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

Larry Gregg wrote:
> Perhaps you already know this, but I discovered another Q language:
> 
> http://www.kx.com/library/faq.php

No, I didn't know this. Seems like this is fairly new. Oh well, I guess 
that there's no big danger that the two will be confused...

-- 
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] Another Q Language

[Larry G. <lg...@ac...>]

People:

Perhaps you already know this, but I discovered another Q language:

http://www.kx.com/library/faq.php

"We enhanced the speed and efficiency of application development by=20
combining our general programming, relational, and time-series languages=20
into a single, concise programming language =96 q. The q language is=20
integrated into the database, contributing to very high query=20
performance. Q uses English-like commands and a simple syntax. C or SQL=20
programmers typically learn q in less than a day. (See the Kdb+ Primer=20
written by Dennis Shasha, Associate Professor of Computer Science at=20
NYU's Courant Institute.)"

Larry Gregg

Re: [q-lang-users] Why is this an error

[Larry G. <lg...@ac...>]

Tim Haynes wrote:
> Larry Gregg <lg...@ac...> writes:
>
>   
>> People:
>>
>> Why does the following produce a syntax error?
>>
>> ==> 7+09
>> ! Syntax error
>>  >>> 7+09
>>       ^
>>     
> [snip]
>
>   
>> It seems reasonable that 7 + 09 should produce 16, yes?
>>     
>
> Seemingly not. Consider:
>
>  | ==> 071
>  | 57
>
> Octal means numbers digits go up to 7, hence that syntax error ;)
>
> ~Tim
>   
Tim:

Thanks.  I see now why it errored out.

Larry

Re: [q-lang-users] Why is this an error

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

Larry Gregg <lg...@ac...> writes:

> People:
> 
> Why does the following produce a syntax error?
> 
> ==> 7+09
> ! Syntax error
>  >>> 7+09
>       ^
[snip]

> It seems reasonable that 7 + 09 should produce 16, yes?

Seemingly not. Consider:

 | ==> 071
 | 57

Octal means numbers digits go up to 7, hence that syntax error ;)

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

[q-lang-users] Why is this an error

[Larry G. <lg...@ac...>]

People:

Why does the following produce a syntax error?

==> 7+09
! Syntax error
 >>> 7+09
      ^

But this does not?

==> 7+0
7

It seems reasonable that 7 + 09 should produce 16, yes?

Larry Gregg

[q-lang-users] Q 7.2 released

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

On 30/06/06, Albert Graef <Dr....@t-...> wrote:
> Dear All,
>
> The new release includes Q+Q 0.9, and the latest documentation for Q+Q
> can now be found on http://q-lang.sf.net/documentation.html. (Rob, if
> you read this, please feel free to follow up with a closer description
> of what is new and improved in this Q+Q release.)

Hello,

In Q+Q 0.9:
(the bulk of the changes are in the documentation or maintenance)

    * Added a few new functions
        * The val_eng_[interval|approx]_[epsilon|max_den] set is now complete
          (string->rational approximation functions)
        * comp_simplify completes the set {rat_simplify, ratcomp_simplify}
          (type simplification)
        * `decompositions' num, den, num_den extended
          to rational complex numbers

    * Minor bug fixes / changes corresponding to changes to Q, e.g.
        * corrections involving (/) versus (%) and (^) versus pow

    * Improved support for intervals

    * Documentation:
        * More examples
        * Indicated whether functions are in the default prelude throughout
        * Documented the few new functions
        * Some typos corrected

Q+Q 0.9 is a "beta" version. I have not done as much testing a I would like.
The rational utilities file contains some TODOs, which I need to review. I am
now relatively happy with the public interface for this module; I don't now
expect to make changes to that -- at least not anything major.

I hope to have a version 1.0 in the not too distant future. There are some
functions that remain to be written. There are some further improvements
required in the documentation.

There are also some known minor bugs:

    * When converting a "decimal expansion" string to a rational,
      out-of-bounds digits are not detected. E.g.:
        ==> val_real_eng format_uk 10 "1.0*10^0"
        1%1 // this is correct
        ==> val_real_eng format_uk 10 "1.0e0" // used "e" rather than "*10^"
        73%50 // whoops: "e" treated as digit 46

    * The interval routines do not return a zero-size interval
      when a value is approximated exactly. E.g.:
        ==> rational_interval_max_den 100 (4 * atan 1) // (pi)
        interval (311%99,22%7) // correct
        ==> rational_interval_max_den 100 (22%7)
        interval (311%99,22%7) // should be interval (22%7, 22%7)

Any comments on rational.q, ratutils.q, interval.q or the documentation
(rational.pdf) welcome. Please let me know of any other bugs you encounter, or
of anything you think could be explained better in the documentation, or even
of anything you think is missing from the module or documentation.

Thanks,
Rob.

Re: [q-lang-users] Q 7.2 released

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

--- Albert Graef <Dr....@t-...> writes:
- The latest and greatest Q release, Q 7.2, is now available.

Cool.

Cheers!
Keith 
 

[q-lang-users] Q 7.2 released

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

Dear All,

the latest and greatest Q release, Q 7.2, is now available from the Q 
website at http://q-lang.sf.net. This release sports a revision of Q's 
numeric tower, integration of Rob Hubbard's rational number library 
"Q+Q", an overhaul of the Complex type and proper support for IEEE 
floating point INF and NaN values.

Thanks again to all who participated in the lively discussions on the 
mailing list which helped to get the new release out in record time!

More information about what's new in this release can be found in the 
the release notes which are available here:
http://sourceforge.net/project/shownotes.php?group_id=96881&release_id=428441

The packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=103965&release_id=428441

The new release includes Q+Q 0.9, and the latest documentation for Q+Q 
can now be found on http://q-lang.sf.net/documentation.html. (Rob, if 
you read this, please feel free to follow up with a closer description 
of what is new and improved in this Q+Q release.)

Enjoy! :)

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] Unparsing of Complex

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

Rob Hubbard wrote:
> You have already argued that X+0*i should not be parsed as just X,
> even when the 0 is exact, in order that the value should appear to be
> the complex value that it is. I agree.
> 
> Given that X+0*i is unparsed as X+0*i, then by symmetry 0+Y*i should
> be unparsed as 0+Y*i.

Yes. Fixed in cvs already.

-- 
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] Unparsing of Complex

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

On 27/06/06, Rob Hubbard <hub...@gm...> wrote:
> Given that X+0*i is unparsed as X+0*i, then by symmetry 0+Y*i should
> be unparsed as 0+Y*i.

PS. I notice (at 7.2rc3) that 0.0+Y*i is already unparsed as 0.0+Y*i;
as the 0.0 is inexact, and therefore should be considered to be only
possibly zero but perhaps an absolutely small value (as John has
previously noted). Thus to unparse 0+Y*i as 0+Y*i would also look more
consistent with that.