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