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

Re: [q-lang-users] Error compiling Q on Mac

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

Tim Haynes wrote:
> This is fairly well known on the mac. For some reason, the logic concerning
> `#ifdef HAVE_SYS_SOCKET_H' on clib.c:149 seems a bit borked.

That seems to be an issue with Apple's system headers. A proper fix can
be found in Andrew Berg's post (I'll include that in the next release):
http://sourceforge.net/mailarchive/forum.php?thread_id=31075130&forum_id=36790

What's bizarre is that on OSX (at least on recent versions, I don't
remember seeing this the last time I compiled Q on OSX) you apparently
have to *#undef* _POSIX_C_SOURCE to get AF_LOCAL defined. I always
thought that AF_LOCAL was mandated by POSIX (rather than AF_UNIX)?

BTW, can anyone confirm that clib.c compiles under *BSD? Or does it need
a similar workaround?

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] Error compiling Q on Mac

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

Marco Maggesi <ma...@ma...> writes:

> On Dec 2, 2006, at 5:07 PM, John Cowan wrote:
> 
> > Marco Maggesi scripsit:
> >
> >> clib.c: In function '__F__clib_sys_vars':
> >> clib.c:1787: error: 'AF_LOCAL' undeclared (first use in this  
> >> function)
> >
> > That's very bizarre.  OS X definitely supports local domain sockets
> > using AF_LOCAL.  It's got to be a configuration problem of some sort.
> 
> Don't know if this information can be pertinent: I ran ./configure as  
> follows:
> 
> LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include" ./configure
> 
> I set LDFLAGS and CPPFLAGS since I installed gmp with macports.

This is fairly well known on the mac. For some reason, the logic concerning
`#ifdef HAVE_SYS_SOCKET_H' on clib.c:149 seems a bit borked.

One (kludgy) workaround that will at least allow you to proceed is a
simple:

echo '#include <sys/socket.h>' >> config.h

HTH,

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

Re: [q-lang-users] Error compiling Q on Mac

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

On Dec 2, 2006, at 5:07 PM, John Cowan wrote:

> Marco Maggesi scripsit:
>
>> clib.c: In function '__F__clib_sys_vars':
>> clib.c:1787: error: 'AF_LOCAL' undeclared (first use in this =20
>> function)
>
> That's very bizarre.  OS X definitely supports local domain sockets
> using AF_LOCAL.  It's got to be a configuration problem of some sort.

Don't know if this information can be pertinent: I ran ./configure as =20=

follows:

LDFLAGS=3D"-L/opt/local/lib" CPPFLAGS=3D"-I/opt/local/include" =
./configure

I set LDFLAGS and CPPFLAGS since I installed gmp with macports.

Thank you.

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

[q-lang-users] Error compiling Q on Mac

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

Hi!

I am trying to install Q 7.5 on an intel macbook (osx 10.4.8) and I =20
get the following error during compilation in clib:

clib.c: In function '__F__clib_sys_vars':
clib.c:1787: error: 'AF_LOCAL' undeclared (first use in this function)

I tried to modify Makefile.am as explained in "Troubleshooting" but I =20=

get the same error.

Just wondering if an easy fix is available.

Thanks in advance,

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

Re: [q-lang-users] Suggestions on how to debug?

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

Andrew Berg wrote:
> Ok, so I thought I already resent this on Wednesday.  Anyhow, here's what I sent last time:

Hmm, I didn't see that post. Anyway, thanks for resending the script,
I'll put that on the TODO list for the next bugfix release.

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] H/M-based typing for Q

[Andrew B. <an...@vo...>]

Perhaps a word of clarification:

>> My intuition about this is that most of the code that gets written
>> is monomorphic.  (Is that a word?) =20

> (It is.)

Aah, good.  The little bit of Latin I've figured out is not completely =
useless.

> The trouble is not so much with monomorphic variables as with =
monomorphic
> collections.  ML, for example, insists on having monomorphic lists so
> that when you remove an object from a list you know its type.  That is
> very annoying.

My point was not that this is good, but rather that the larger majority =
of functions only ever get one type passed to them, or in the Q =
parlance, the majority of expressions use the same types from evaluation =
to evaluation.  Going back to my initial statement, my (probably =
provably incorrect) belief, based on an incomplete understanding of the =
problem space, is that it is possible to automatically determine the =
types in these cases, and not require the programmer to spell out all =
that extra noise.  In the cases where the programmer does something =
polymorphic, then the compiler's task gets a bit harder, and perhaps it =
will have to emit a different reduction for each input type or =
something.  In the cases where the programmer is doing something =
complicated with delayed execution, it is not hard to imagine that the =
compiler would have to fall all the way back to calling an interpreter =
in the run-time library. =20

-andrew

Re: [q-lang-users] H/M-based typing for Q

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

Andrew Berg scripsit:

> My intuition about this is that most of the code that gets written
> is monomorphic.  (Is that a word?)  

(It is.)

The trouble is not so much with monomorphic variables as with monomorphic
collections.  ML, for example, insists on having monomorphic lists so
that when you remove an object from a list you know its type.  That is
very annoying.

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
Objective consideration of contemporary phenomena compel the conclusion
that optimum or inadequate performance in the trend of competitive
activities exhibits no tendency to be commensurate with innate capacity,
but that a considerable element of the unpredictable must invariably be
taken into account. --Ecclesiastes 9:11, Orwell/Brown version

Re: [q-lang-users] H/M-based typing for Q

[Andrew B. <an...@vo...>]

Albert Graef wrote:
>You can find an explanation of
>these "shebang" lines in Section B.4 of the manual,
>http://q-lang.sourceforge.net/qdoc/qdoc_14.html#SEC154.

Aah, I look forward to getting to Section B of the manual, then.  So far =
I'm up to chapter 12.  I resent the bug report...and I see the message =
reflected by the list this time, so perhaps you'll actually get it this =
time.

I tend to use Vim and the command line version.  I had to quit using =
Emacs about 5 years ago because my ctrl-pinkie fingers started getting =
some nerve damage.  Vim requires far fewer ctrl-key presses, and now I =
can feel all of my fingers again.

I started making a QPad-like GUI for Cocoa on the Macintosh, but quickly =
decided that Vim+interactive q was better than QPad, even on Windows.  I =
should at least try out the Emacs mode, maybe it would suggest to me how =
a QPad-replacement GUI should work.

>Well, the idea behind those H/M-based systems is that the type checker
>can figure out the static typing mostly by itself, and explicit
>annotations are only needed rarely, if at all. But I still have to see
>whether Nathan's type checker can actually do this even while =
supporting
>ad-hoc polymorphism. Whenever I tried to invent a type system that does
>this and offers full inference I ended up with a system that is 100%
>permissive (i.e., there are no typing errors at all). ;-) But it looks
>like Nathan might have found a way to handle that issue.

My intuition about this is that most of the code that gets written is =
monomorphic.  (Is that a word?)  The types in this kind of code should =
be easily discoverable by the compiler, with the remaining ones =
limitable to some smallish subset of all the available types.  I have to =
admit that I don't really understand all the ramifications of Q's =
deferred evaluation to really understand what kind of wrenches this will =
throw into it, maybe in those cases you just have to fall back to =
something resembling interpreter evaluation.  Either way, I look forward =
to seeing what you smarter types can make of it.

>Well, a complete grammar for Q can be found in the qyacclex tarball. It
>should be a piece of cake (a rather big one, though ;-) to add the
>necessary semantic processing and make the necessary changes so that
>comments are retained. Any volunteers?

I've been planning to take a look at it once I've finished reading the =
manual.  One project that's been percolating around in the back of my =
head for several years now is to put a scripting language in the place =
of the traditional (compiled) first stage of GCC.  Having looked at Q =
and the ease of writing data transformations in Q I am thinking it would =
be the best candidate language I have yet found.  Being recently =
divorced, I find myself with some spare time in the evenings to work on =
something like this, also.  My goal would not necessarily be to build a =
full Q compiler, but to be able to build parse trees in Q and then send =
them off to be turned into executable code.

-andrew

Re: [q-lang-users] Suggestions on how to debug?

[Andrew B. <an...@vo...>]

Ok, so I thought I already resent this on Wednesday.  Anyhow, here's =
what I sent last time:

>I can't get your fin.q script to work. parse_nums (used at fin.q:72)
>isn't defined anywhere.

Gah!  I went through the script and deleted what I thought were =
commented-out old versions of various functions that I had rewritten, =
and apparently I hit a live one.  That'll teach me to think I can use an =
editor to do a simple task and not break something.  I'm pretty sure =
I've only made that mistake 100 times, maybe after another 300 I'll =
actually learn the lesson.

I've attached a fixed one, or you can just change the "parse_nums" on =
line 72 to "parse_csv_nums".

Sorry,

-andrew

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...]On Behalf Of Albert
Graef
Sent: Tuesday, November 28, 2006 10:14 PM
To: Discuss the Q language.
Subject: Re: [q-lang-users] Suggestions on how to debug?


Andrew Berg wrote:
> Okay, so, I'm writing a little script to fetch
> historic information on stock ticker symbols from
> finance.yahoo.com.  The first two symbols
> I've tried it on are "A" and "AA"

I can't get your fin.q script to work. parse_nums (used at fin.q:72)
isn't defined anywhere.

Albert

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

-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] H/M-based typing for Q

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

Andrew Berg wrote:
> Speaking as a (only mostly) reformed ADA programmer, who cannot even send in a bug report without mangling the script; I would love something like perl's "use strict;" and "use warnings;" options.

You can achieve that by putting a line like

#! -w

or

#! -w2

at the beginning of your main script. You can find an explanation of
these "shebang" lines in Section B.4 of the manual,
http://q-lang.sourceforge.net/qdoc/qdoc_14.html#SEC154.

(Well at least it's supposed to work that way, but actually it doesn't
right now because of a bug in the compiler's option parsing code. That
bug is already fixed in cvs, though. The relevant changes are in qc.y,
see http://q-lang.cvs.sourceforge.net/q-lang/q/src/qc.y?view=log.)

Another method, if you're using emacs, is to configure Q mode to add the
-w or -w2 option to the interpreter command line; you can find that
under "Q => Customize => Q Prog Opts".

BTW, it would be nice if you could follow up to your bug report and
resend the (corrected) version of the script, so I can try to reproduce
the bug.

> I spent a few years looking at Smalltalk or Self type languages, and thought that Self especially could benefit from having a bit more static type information, but that putting it everywhere, and in every script, was too much burden on the programmer.  Just putting it where it is not machine discoverable, and only in the performance sensitive areas of the code seems like a better compromise.

Well, the idea behind those H/M-based systems is that the type checker
can figure out the static typing mostly by itself, and explicit
annotations are only needed rarely, if at all. But I still have to see
whether Nathan's type checker can actually do this even while supporting
ad-hoc polymorphism. Whenever I tried to invent a type system that does
this and offers full inference I ended up with a system that is 100%
permissive (i.e., there are no typing errors at all). ;-) But it looks
like Nathan might have found a way to handle that issue.

> On a sort-of-but-not-quite-related theme, I've always wanted a compiler which would re-emit the source code (with all comments retained) in some normal form, with all the redundant parenthesis removed, and optionally reformatted into the canonical format for that language.

Well, a complete grammar for Q can be found in the qyacclex tarball. It
should be a piece of cake (a rather big one, though ;-) to add the
necessary semantic processing and make the necessary changes so that
comments are retained. Any volunteers?

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] H/M-based typing for Q

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

Albert Graef scripsit:

> Or we could have a separate program (kind of
> "lint" for Q) which does that job.

That sounds like the best idea yet.

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....

Re: [q-lang-users] H/M-based typing for Q

[Andrew B. <an...@vo...>]

Speaking as a (only mostly) reformed ADA programmer, who cannot even =
send in a bug report without mangling the script; I would love something =
like perl's "use strict;" and "use warnings;" options.

One thing I've always wanted from a dynamic type system is the ability =
for it to run across my program and re-emit it with all the type =
annotations it can figure out.  This could be valuable right now to look =
for typing errors, but it seems like in the case that there is a native =
compiler which is going to use this information it would tell me where I =
need to put type hints in order to help it optimize its output.

I spent a few years looking at Smalltalk or Self type languages, and =
thought that Self especially could benefit from having a bit more static =
type information, but that putting it everywhere, and in every script, =
was too much burden on the programmer.  Just putting it where it is not =
machine discoverable, and only in the performance sensitive areas of the =
code seems like a better compromise.

On a sort-of-but-not-quite-related theme, I've always wanted a compiler =
which would re-emit the source code (with all comments retained) in some =
normal form, with all the redundant parenthesis removed, and optionally =
reformatted into the canonical format for that language.  I think of it =
as the "show me what you thought I said" mode.  For C there are programs =
like "indent" which do the reformatting, but to me this is better done =
by the compiler, which has the advantage of having semantic information =
to work from instead of just syntax.

-andrew

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...]On Behalf Of Albert
Graef
Sent: Thursday, November 30, 2006 3:32 PM
To: Discuss the Q language.
Subject: Re: [q-lang-users] H/M-based typing for Q


Yes sure, that's why Nathan's system is much more flexible than basic
H/M. See http://www.cse.ucsc.edu/~nwhitehe/qt.html

Don't worry, nobody wants to put on the concrete shoes of H/M over here.
;-) Q's dynamic typing is one of its distinguishing features and I
certainly want it to stay that way. If someone wants something like
Haskell he knows where to find it.

However, it could be useful to have a tool which tries to infer as much
typing information from a Q program as possible. That information could
be used in a native code compiler, or to give warnings about possible
typing errors in a script. Or we could have a separate program (kind of
"lint" for Q) which does that job.

Cheers,
Albert

Re: [q-lang-users] H/M-based typing for Q

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

Eddie Rucker wrote:
> Are you really going to make a native code compiler for Q?

It's the biggest item which is still on my TODO list. But don't hold
your breath yet. ;-) An intermediate step would be a self-hosting Q
bytecode compiler. I already have the parser (you can find that in the
qyacclex tarball) but it still lacks the semantic processing. It's also
several magnitudes slower than the current bytecode compiler, so this
thing will only become practical with native compilation anyway, if at
all...

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] H/M-based typing for Q

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

John Cowan wrote:
> I would never want to see Q put into the Hindley-Milner straitjacket.
> H/M type inference makes sense if you are going to do static typing
> anyway, but things like monomorphic lists are IMHO completely against
> the spirit of Q.

Yes sure, that's why Nathan's system is much more flexible than basic
H/M. See http://www.cse.ucsc.edu/~nwhitehe/qt.html

Don't worry, nobody wants to put on the concrete shoes of H/M over here.
;-) Q's dynamic typing is one of its distinguishing features and I
certainly want it to stay that way. If someone wants something like
Haskell he knows where to find it.

However, it could be useful to have a tool which tries to infer as much
typing information from a Q program as possible. That information could
be used in a native code compiler, or to give warnings about possible
typing errors in a script. Or we could have a separate program (kind of
"lint" for Q) which does that job.

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] H/M-based typing for Q

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

> convenient in most cases. (Emacs Q mode already allows you to do this.
> It's certainly the quickest way to edit and run Q scripts, I use it all
> the time. It could still be improved in some ways, though.)

Yes, I use emacs for editing and running Q scripts too!

After seeing John Cowan's response, I think more libraries, bug
squashing, and enhancements in the interpreter's code should come first.

Are you really going to make a native code compiler for Q?

Eddie

Re: [q-lang-users] H/M-based typing for Q

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

Albert Graef scripsit:

> Yes. In fact standard H/M allows you to infer *all* types in a program,
> automatically, *without* any explicit typing information (except in some
> rare corner cases). Of course this becomes more difficult if you want to
> support ad-hoc polymorphism (like a function or constructor which takes
> either an integer or a list as an argument, which isn't possible with
> standard H/M, but is a no-brainer in Q).

I would never want to see Q put into the Hindley-Milner straitjacket.
H/M type inference makes sense if you are going to do static typing
anyway, but things like monomorphic lists are IMHO completely against
the spirit of Q.

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           co...@cc...

Re: [q-lang-users] H/M-based typing for Q

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

Eddie Rucker wrote:
> I think that adding the type system as described is an improvement if a
> native code compiler is constructed. But even better, if this could be
> combined with an editor, errors could be caught during the coding process
> whether a native code compiler was ever constructed or not. I can imagine
> hitting enter after banging in an equation and emacs (or whatever) beeps
> at me and tells me there is a type error. Incremental compiling and type
> inference = cool!

Actually, Q could be compiled incrementally, but this most likely also
requires a syntax-directed or syntax-assisted editor as the frontend.
These things have been done before (like, e.g., the famous Cornell
Synthesizer Generator, or the M2SDS system for Modula-2), but have
largely failed in the market-place because these editors are not easy to
implement and fairly awkward to use compared to plain text editors. I
don't think they're really worth the hassle. For daily programming, a
plain text editor integrated with a fast compiler, which allows you to
flag errors in the text after pressing a "Compile" key, is more
convenient in most cases. (Emacs Q mode already allows you to do this.
It's certainly the quickest way to edit and run Q scripts, I use it all
the time. It could still be improved in some ways, though.)

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] H/M-based typing for Q

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

Andrew Berg wrote:
> That being said, I am in favor of a faster native code compiler.  Are there optimizations that become possible with stronger type system that are impossible without one?

Unboxing. E.g., if the type checker can infer that a certain parameter
in a recursive function is always an integer then that parameter can be
unboxed before invoking the function and can be passed around as just a
plain integer. That saves you the runtime checks for the type and
extracting the integer's value from an expression cell.

> It seems to me that if all of the equations for a program are known at compile time (and as Q is defined now, I think that is the case) then it should be reasonable to infer a lot of the type information at compile time.  No?

Yes. In fact standard H/M allows you to infer *all* types in a program,
automatically, *without* any explicit typing information (except in some
rare corner cases). Of course this becomes more difficult if you want to
support ad-hoc polymorphism (like a function or constructor which takes
either an integer or a list as an argument, which isn't possible with
standard H/M, but is a no-brainer in Q).

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] H/M-based typing for Q

[Andrew B. <an...@vo...>]

Being a not-quite-reformed ADA programmer, I like the idea of stronger =
type checking.  I kind of miss compile time errors.  At the same time, =
the fact that I don't know anything about Hindley/Milner-based type =
systems means that I really don't feel qualified to contribute anything =
of value here.

That being said, I am in favor of a faster native code compiler.  Are =
there optimizations that become possible with stronger type system that =
are impossible without one?  It seems to me that if all of the equations =
for a program are known at compile time (and as Q is defined now, I =
think that is the case) then it should be reasonable to infer a lot of =
the type information at compile time.  No?

-andrew

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...]On Behalf Of Albert
Graef
Sent: Tuesday, November 28, 2006 12:12 AM
To: Discuss the Q language.
Subject: [q-lang-users] H/M-based typing for Q


Hi all,

James Litsios recently pointed me to this webpage by Nathan Whitehead, a
UCSC PhD student who has been working on QT, a dialect/sublanguage of Q
with a Hindley/Milner-based type system:

http://www.cse.ucsc.edu/~nwhitehe/qt.html

The interesting thing is that Nathan's type system offers much more
flexibility than basic H/M, which makes it much more suitable for a
dynamic language like Q with its ad-hoc polymorphism. From the webpage:
"QT adds a nice type system to Q. The additional type system is designed
to be as unobtrusive as possible. It supports automatic type inference,
higher order types, unconstrainted polymorphic types, and "delayed"
evaluation types."

Not much additional documentation is available right now, so we'll have
to dig into the ML code to find out how it works, but Nathan has
promised that he'll write up something to make his work more accessible.
It's not clear to me at this point whether his system can be massaged to
support the full Q language, but I think it's worth taking a look.

What do you think about this? Would adding a more elaborate type system
to Q be a wanted improvement? Obviously it might make Q programming a
little safer, and type inference might also help to generate faster code
in a native code compiler. But there might be drawbacks as well...

Cheers,
Albert

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

-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] H/M-based typing for Q

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

Albert Graef,

> What do you think about this? Would adding a more elaborate type system
> to Q be a wanted improvement? Obviously it might make Q programming a
> little safer, and type inference might also help to generate faster code
> in a native code compiler. But there might be drawbacks as well...

I think that adding the type system as described is an improvement if a
native code compiler is constructed. But even better, if this could be
combined with an editor, errors could be caught during the coding process
whether a native code compiler was ever constructed or not. I can imagine
hitting enter after banging in an equation and emacs (or whatever) beeps
at me and tells me there is a type error. Incremental compiling and type
inference = cool!

Just my opinion.

Re: [q-lang-users] Suggestions on how to debug?

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

Andrew Berg wrote:
> Okay, so, I'm writing a little script to fetch
> historic information on stock ticker symbols from
> finance.yahoo.com.  The first two symbols
> I've tried it on are "A" and "AA"

I can't get your fin.q script to work. parse_nums (used at fin.q:72)
isn't defined anywhere.

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] Suggestions on how to debug?

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

Okay, so, I'm writing a little script to fetch
historic information on stock ticker symbols from
finance.yahoo.com.  The first two symbols
I've tried it on are "A" and "AA"

Here's an example of running it for "A":

---------------------------------------------
==> run fin.q

==> fetch_history "A"
[["Date","Open","High","Low","Close","Volume","Adj.
Close*"],["24-Nov-06",33.22,
33.7,33.2,33.56,963900,33.56],["22-Nov-06",33.55,33.6,33.3,33.42,4274200,33.42],
["21-Nov-06",33.74,33.74,33.45,33.63,3407100,33.63],["20-Nov-06",33.55,33.98,33.
46,33.74,2239100,33.74],["17-Nov-06",33.46,33.84,33.3,33.75,2492800,33.75],["16-
   ... a few lines deleted for brevity ...
Nov-99",40.88,41.5,40.75,41.19,1237100,38.81],["24-Nov-99",40.13,41.94,40.0,41.0
6,3464400,38.69],["23-Nov-99",42.5,43.63,40.0,40.0,4274400,37.69],["22-Nov-99",4
1.31,44.0,40.06,44.0,4705200,41.46],["19-Nov-99",42.94,43.0,39.81,40.38,10897100
,38.05],["18-Nov-99",45.5,50.0,40.0,44.0,44739900,41.46],[""]]

==> 
---------------------------------------------

As you can see, it is reading the values and parsing
it into a somewhat logical list of lists.  On the
other hand, here is an example when I run it for "AA":

---------------------------------------------
==> run fin.q

==> fetch_history "AA"

C:\Documents and Settings\andrewb\Desktop\fin>
---------------------------------------------

Maybe this example does not make it so obvious, but it
appears to me that I am the victim of a silent
failure.  (Due to an aborted attempt to install
BootCamp on my Macintosh, I am using a windows machine
today.) How might I go about determining what is
causing this problem?  In case anyone else wants to
look into this, I've attached my script.  You'll need
to have it in a directory that contains a "html" and
"csv" directories for "cache_get" to work.

-andrew

[q-lang-users] H/M-based typing for Q

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

Hi all,

James Litsios recently pointed me to this webpage by Nathan Whitehead, a
UCSC PhD student who has been working on QT, a dialect/sublanguage of Q
with a Hindley/Milner-based type system:

http://www.cse.ucsc.edu/~nwhitehe/qt.html

The interesting thing is that Nathan's type system offers much more
flexibility than basic H/M, which makes it much more suitable for a
dynamic language like Q with its ad-hoc polymorphism. From the webpage:
"QT adds a nice type system to Q. The additional type system is designed
to be as unobtrusive as possible. It supports automatic type inference,
higher order types, unconstrainted polymorphic types, and "delayed"
evaluation types."

Not much additional documentation is available right now, so we'll have
to dig into the ML code to find out how it works, but Nathan has
promised that he'll write up something to make his work more accessible.
It's not clear to me at this point whether his system can be massaged to
support the full Q language, but I think it's worth taking a look.

What do you think about this? Would adding a more elaborate type system
to Q be a wanted improvement? Obviously it might make Q programming a
little safer, and type inference might also help to generate faster code
in a native code compiler. But there might be drawbacks as well...

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] Polynomial Module for Q

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

Rob Hubbard wrote:
> [I'm not sure how Q[i][X] should be pronounced: "quick", "quiz",
> "kick(s)", "keys" or "quiche" (!)]

Hmm ... quiche Lorraine. ;-) I'd pronounce it as "quicks", though.

I might add that this new package is likely to become part of the next Q
release, so if you find any bugs please let Rob know asap.

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] This feels like a dumb question, but...

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

Andrew Berg wrote:
> I (think that I) understand the = vs eq difference.  I was surprised
> that when I tried to apply either one to an expression where the "open F
> 0 0" had failed, all I got was a bigger expression.

Well, you're trying to compare a constructor term "open F 0 0" to a
tuple "()" which isn't defined. If there's no definition for an
expression in Q then it's a normal form. So you get what you asked for. ;-)

Of course you could have equations like

	(X=X) = true;
	(_=_) = false otherwise;

in your program, which would make (=) default to syntactic equality, but
 I wouldn't recommend that.

>>-f F = true where () = close (open F 0 0);
>>        = false otherwise;
> 
> Aah, that's probably the version I was looking for.  So, if the
> evaluation fails in a "where" clause, the containing equation fails
> also.

Not quite. It's the pattern match in the local variable definition,
"where () = close (open F 0 0)", which fails (if close fails). Here we
don't actually define a variable, of course, but the left-hand side of
the definition, (), is matched against the result of the right-hand side
"close (open F 0 0)" anyway. If the pattern match in a local variable
definition fails then the entire equation fails as well, see Section 7.4
[http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC29]. This neat little
trick is applicable whenever you expect a certain outcome of a
computation and want the equation to fail if you get something else.

> It's kind of amusing, I started out trying to write this way, but the
> only version of stat that I could find in the manual seemed to take a
> FD, which required calling "open" anyhow, so since I only needed "-f"
> just then I settled on a really dumb implementation.

Yes, we have stat, lstat *and* fstat. Actually, most of the POSIX
interface is there. :) I guess that Q can't really compete with Perl on
this ground, but most of the stuff you need for everyday scripting
should be readily available.

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