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

Re: [q-lang-users] New stuff in cvs: multichar ops, views

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

Hello Albert,

On 31/05/07, Albert Graef <Dr....@t-...> wrote:
> John Cowan wrote:
> > I'm happy with that -- I assume that "--" is distinct from "- -"
> > where the latter is unary minus?
>
> Yes, sure. The unparser now also makes sure that spaces are inserted
> between adjacent binary and unary symbols.
>
> But note that this was just an example, (--) is not in the standard
> library. So unless you define (--) yourself you can still write 5--3 and
> get the expected result, 8. :)

I'm very happy to see multi-character operators introduced. (Does Q
also allow Unicode operators?)

I presume that tokens will be delimited according to which set their
constituent characters belong to: 'alphanumeric' or 'other' (although
an 'alphanumeric' token must begin with an alphabetical character, of
course). Is white-space a special case, i.e. a third class of
character?

Which characters are in the 'other' set for operators - are any (such
as quote and parentheses) excluded?

Does this also mean that multi-other-character function names are also
supported? That is, can I now define a non-operator function called
'--'? (I suppose that includes the secondary question: would 'other'
characters count as lower case?)

It seems that now, introducing a new symbol will affect the way that
code is parsed. This is something I find a little worrying.

Would it be better to have, e.g. '--' always as an atomic token,
producing a normal form unless '--' is defined? That is, would is be
better to break backwards compatibility? Or would that be too painful?

Is the protection offered by the module system thought to be enough?

[Can of worms! Sorry.]

Thanks,
Rob.

Re: [q-lang-users] New stuff in cvs: multichar ops, views

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

 
Hello Albert -- 

--- Albert Graef <Dr....@t-...> writes:
- As a first exercise, I just comitted some changes which turn
- Complex into an ADT with the virtual constructor (:+).
- So the constant i now prints as 0:+1.
- 
- But I'd actually prefer +: for Q. Other suggestions, anyone?)

Why not '0:-1' (as opposed to '0:+1')? After all, the constant i is the square root of -1, is it not?

I know that it is not much of a difference (exchanging '-' for '+'), but at least ':-' reminds me (if no one else ;-) of imaginary numbers.

Am I all wet here, or what?

Cheers,
Keith 
 

Re: [q-lang-users] New stuff in cvs: multichar ops, views

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

Hello Albert,

Wednesday, May 30, 2007, 4:06:47 PM, you wrote:

AG> Hi all,

AG> I had some time to work on the new Q release over the Whitsun holidays.
AG> As a result, you can find some interesting new stuff in cvs today:

Great news. BTW, how can I build Q for windows without installing
cygwin ?


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

Re: [q-lang-users] New stuff in cvs: multichar ops, views

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

Albert Graef scripsit:

> > (I always get bitten by unary minus in Q, still.)
> 
> Care to explain why? I'd say that its usage is rather straightforward.
> The precedence is the same as in Pascal (IIRC), all you have to remember
> is that '-' in sections always denotes *binary* minus so to denote the
> unary minus function you have to write 'minus'.

I always forget that -2 is the application of minus to 2 rather than a
constant, so I write things like "foo -2", which then turns out to be
"(foo -) 2".

> As a first exercise, I just comitted some changes which turn Complex
> into an ADT with the virtual constructor (:+). So the constant i now
> prints as 0:+1.

I don't like that much.  I suppose there is no way to make 0+1*i the
constructor/view?  I guess not, since Q is eager.

-- 
John Cowan    http://www.ccil.org/~cowan   <co...@cc...>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

Re: [q-lang-users] New stuff in cvs: multichar ops, views

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

Hi John,

John Cowan wrote:
> I'm happy with that -- I assume that "--" is distinct from "- -"
> where the latter is unary minus?

Yes, sure. The unparser now also makes sure that spaces are inserted
between adjacent binary and unary symbols.

But note that this was just an example, (--) is not in the standard
library. So unless you define (--) yourself you can still write 5--3 and
get the expected result, 8. :)

> (I always get bitten by unary minus in Q, still.)

Care to explain why? I'd say that its usage is rather straightforward.
The precedence is the same as in Pascal (IIRC), all you have to remember
is that '-' in sections always denotes *binary* minus so to denote the
unary minus function you have to write 'minus'.

>> Wadler/Okasaki-style views (good stuff!): These are now implemented,
> 
> Hurrah!

Thought you might like that. ;-) IMHO, this is in fact the most useful
addition to Q since 'unparse' (which is now called 'view', btw). I
almost dropped the ball there, as this feature was, ahem, somewhat
tricky to implement efficiently in the context of Q. But I perservered,
and in the end I figured out how to do it.

As a first exercise, I just comitted some changes which turn Complex
into an ADT with the virtual constructor (:+). So the constant i now
prints as 0:+1.

(NB: I chose :+ for the sake of Haskell compatibility, but I actually
think that it looks a bit weird. In Haskell they can't do any better
because the ':' has to be on the left side to denote a constructor,
IIRC. But I'd actually prefer +: for Q. Other suggestions, anyone?)

(NB2: Rob, I'm sure you will like this, because you're an ADT fan and
because this makes the treatment of Complex very similar to Rational, as
you suggested before. We might have to fiddle with ratutils.q though,
I'm not sure whether it uses the old 'complex' constructor in some
places, which is not public any more. But it should be easy to fix that
since the rest of the interface of Complex is unchanged.)

I also have plans to turn 'lambda' into a virtual constructor for the
builtin external <<Function>> type used to represent compiled lambdas,
and, instead of having a builtin pretty-printing of <<Function>>
objects, define an appropriate view for them. This will make it possible
to write stuff like:

foo (lambda X Y) = ...;

even if 'foo' is not a special form and thus gets the lambda delivered
in its compiled form. Right now it's necessary to play some dirty tricks
with 'valq . str' to dissect a compiled lambda.

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] New stuff in cvs: multichar ops, views

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

Albert Graef scripsit:

> Multichar operator symbols: These have been asked for on the mailing
> list a while ago. I've given in to the popular demand now and
> implemented them. So you can write, e.g.:
> 
>   public (--) Xs Ys @(-);
>   Xs:List--Ys:List = foldl (flip (filter . neq)) Xs Ys;

I'm happy with that -- I assume that "--" is distinct from "- -"
where the latter is unary minus?  (I always get bitten by unary
minus in Q, still.)

> Wadler/Okasaki-style views (good stuff!): These are now implemented,

Hurrah!

-- 
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum        co...@cc...  http://ccil.org/~cowan

[q-lang-users] New stuff in cvs: multichar ops, views

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

Hi all,

I had some time to work on the new Q release over the Whitsun holidays.
As a result, you can find some interesting new stuff in cvs today:

Multichar operator symbols: These have been asked for on the mailing
list a while ago. I've given in to the popular demand now and
implemented them. So you can write, e.g.:

  public (--) Xs Ys @(-);
  Xs:List--Ys:List = foldl (flip (filter . neq)) Xs Ys;

(Q's lexical syntax had to be revised to support this, but most old
scripts should be unaffected.)

Wadler/Okasaki-style views (good stuff!): These are now implemented,
too. Virtual constructors can be declared with the new 'virtual' keyword
and can then be used in pattern-matching definitions like real
constructors (if the appropriate views a.k.a. unparsings are defined).
Note that in order to go with the customary terminology, I renamed the
builtin 'unparse' routine to 'view' so you will have to change your
scripts accordingly.

For example, here is how the 'Rational' type and its view are now
defined in the standard library:

  // from rational.q
  public type Rational : Real = virtual (%) P Q @ (/)
                              | private const rat N D;

  // from prelude.q
  view Q:Rational = '(N % D) where (N:Int,D:Int) = num_den Q;

Having (%) as a virtual constructor of 'Rational' lets you use the
operator in your definitions just like a real constructor, e.g.:

  def X%Y =  3%14 + 7%6;

  foo (X%Y) = (X,Y);

This yields:

  ==> (X,Y); foo (4%6)
  (29,21)
  (2,3)

The same applies to the container ADTs in the standard library. E.g.:

  def set Xs = set [1..10]+set [5..12];

  mymembers (set Xs) = Xs;

Which yields:

  ==> Xs; mymembers (set ["a".."c"]+set ["A".."C"])
  [1,2,3,4,5,6,7,8,9,10,11,12]
  ["A","B","C","a","b","c"]

It goes without saying that this makes the handling of abstract data
types *much* more convenient and elegant.

(Note that 'def's in the interactive command loop of the interpreter
don't quite work like that yet, as they don't handle virtual
constructors right now; but I'm working on that.)

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] New 'where' syntax

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

Eddie Rucker wrote:
> I went to the SoureForge Archives and saw this submission that I didn't
> get via email.

Strange. I just looked at the header and I'm sure it was also sent to
your pm.

> foo X
>   where Y = bar X:
>     = Y/2;

Right. I'd actually prefer to have the lhs qualifiers stick to the
leftmost column, without any indentation, but your format also looks fine.

Maybe there could be parameters in q-mode.el for the relative
indentation of both lhs and rhs qualifiers (IIRC there already is for
the rhs quals). I'm not sure how to do it since you probably have to do
a full parse of equations to assign indentation properly. The equation
syntax is actually regular so that shouldn't be a problem, but of course
the expression syntax isn't and so you'll need to at least keep track of
nested if-then-else and parens/brackets/braces to make this work. Also,
figuring out where to start the parse without parsing the whole source
file might be tricky. ;-)

> I'm sure the email won't preserve the indention though. I'm seriously
> considering changing my emacs mode to indent "=" on the lhs  differently
> than than the introductory "=" part of the equation. I'm also considering
> changing the way nested "if then else" constructs within parenthesis
> currently indent. I would like them to indent like without ()s. Is this
> something other Q users would want?

Yes, as I already pointed out above, q-mode.el most certainly needs a
full overhaul of the indentation code. The current code is a hack which
started from a Prolog mode which only needed rudimentary indentation;
nevertheless, it worked astonishingly well until if-then-else arrived.
;-) For if-then-else it doesn't really do anything useful right now, and
the mode also needs to be adapted for the lhs qualifiers, of course. If
you can figure that out I'd be very thankful. I hate elisp hacking. :)

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] New 'where' syntax

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

I went to the SoureForge Archives and saw this submission that I didn't
get via email. Oh well. I copied the subject line so I hope it goes to
the write spot.

Albert Graef wrote,

>But I have to admit that
>
>foo X where Y = bar X: = Y/2;
>
>doesn't read very well. I can live with it, since I read it as: "Define
>foo X. First case, where Y = bar X: result is Y/2". Maybe you can get
>used to it. But for native English speakers it might be too much to bear.

To me, a native English speaker (Albeit southern dialect), the "where"
and "if" clauses read just fine if the equation part is broken to the
next line as

foo X where Y = bar X:
  = Y/2;

or even better

foo X
  where Y = bar X:
    = Y/2;

I'm sure the email won't preserve the indention though. I'm seriously
considering changing my emacs mode to indent "=" on the lhs  differently
than than the introductory "=" part of the equation. I'm also considering
changing the way nested "if then else" constructs within parenthesis
currently indent. I would like them to indent like without ()s. Is this
something other Q users would want?

Eddie

[q-lang-users] Fixed: C stack overflows (was Re: Bug? New 'where' syntax)

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

Eddie Rucker wrote:
> Did you figure out the bug with specials like ifelse, cond, case, and
> family running out of stack? Oops, I'll check this when I get a chance!

Thanks to John's hints I was now able to fix this. Here's the blurb from
the NEWS file:

There's a new --cstacksize option and corresponding 'cstacksize' command
which allows you to set the maximum C stack size to be used by the
internal eval() routine. This allows you to catch C stack overflows
which could occur during the evaluation of non-tail-recursive special
forms, as reported by Eddie Rucker. The 'cstacksize' value is given in
KB; the default is 256. If 'cstacksize' is set to zero then these checks
are disabled.

-- 
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] Bug? New 'where' syntax

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

/me wrote:
> I'm still working on some quirks with the debugger, though...

These are now fixed as well.

-- 
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] Bug? New 'where' syntax

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

John Cowan wrote:
> Chicken has a small C program run at configuration time that figures
> out which way the C stack grows.  Then it's just a matter of preserving
> the address of a local variable defined in main() in a global variable,
> then adding or subtracting the maximum stack size (defined at config
> time also; Chicken defaults to 128K) to it, and then occasionally
> comparing the content of that variable with the address of some local
> variable.

Thanks, John, for the info, that sounds like it might just work! At
least in threads under complete control of the interpreter. Otherwise,
if eval() is called from a thread in a user program, it will be hard to
predict the stack size, 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] Bug? New 'where' syntax

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

Eddie Rucker wrote:
>> (3) collections of several 'if' and 'where' clauses are processed in a
>> "backward" fashion, consider e.g.: if X>Y where Y=bla Z where Z=foo X.
> 
> (3) takes some getting use to. For example:
> 
> func [] = [];
> func [L|Ls]
> where (X1,X2) = Ws
> where (W|Ws) = L:
> 	     = [- X1 * X2] ++ func Ls if W > 0;
> 	     = [0] ++ func Ls if W = 0;
> 	     = [X1 * X2] ++ func Ls if W < 0;

Note that different definitions inside a single 'where' clause are
processed from left to right, so you could also write:

func [L|Ls]
where (W|Ws) = L, (X1,X2) = Ws:
	     = [- X1 * X2] ++ func Ls if W > 0;

But I have to admit that

foo X where Y = bar X: = Y/2;

doesn't read very well. I can live with it, since I read it as: "Define
foo X. First case, where Y = bar X: result is Y/2". Maybe you can get
used to it. But for native English speakers it might be too much to bear.

Ouch. Maybe we need an entirely new qualifier syntax which works on both
sides of an equation. Any ideas, anyone? Native speakers to the rescue! :)

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] Bug? New 'where' syntax

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

Eddie Rucker wrote:
> ==> main [(1,2,3,4),(0,3,1,4),(2,6,-1,-2)]
> /usr/local/bin/q[pid 1802]: caught signal 11 (Segmentation fault),

Ok, that's fixed now. (Note to self: Never EVER use goto to jump past
the initialization of an automatic variable. ;-)

I'm still working on some quirks with the debugger, though...

-- 
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] Bug? New 'where' syntax

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

Albert Graef scripsit:

> Someone (John?) came up with the idea of keeping track of a pointer to
> an automatic variable. That might do the trick, but I'm not sure how
> portable that is and how I can determine the available C stack size in
> advance.

Chicken has a small C program run at configuration time that figures
out which way the C stack grows.  Then it's just a matter of preserving
the address of a local variable defined in main() in a global variable,
then adding or subtracting the maximum stack size (defined at config
time also; Chicken defaults to 128K) to it, and then occasionally
comparing the content of that variable with the address of some local
variable.

-- 
In politics, obedience and support      John Cowan <co...@cc...>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan

Re: [q-lang-users] New 'where' syntax

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

John Cowan wrote:
> To me, the term "guard" (which I think is due to Dijkstra ultimately)
> connotes conditionals but not bindings, so I would prefer to retain
> "qualifier" as a term for both bindings and conditionals.

That's my gut feeling, too, and it corresponds to the traditional notion
of "guard" that I know. But then there's Peyton-Jones' notion of
"pattern guards" [1] which are exactly like Q's 'where' clauses. (Well,
I guess that I can say that I reinvented them independently, not knowing
PJ's proposal.) Wikipedia also calls them "guards", referring to PJ [2].
I'm not sure, however, how common that usage of "guard" is in the
general FP community.

[1] http://research.microsoft.com/Users/simonpj/Haskell/guards.html
[2] http://en.wikipedia.org/wiki/Guard_(computing)

-- 
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] Bug? New 'where' syntax

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

Eddie Rucker wrote:
> Did you figure out the bug with specials like ifelse, cond, case, and
> family running out of stack? Oops, I'll check this when I get a chance!

Nope, that's still on my TODO list. I already did a fair amount of
googling but there seems to be no portable way to do this. I might look
into the source code of Chicken or Mercury to figure out how they do it.

Someone (John?) came up with the idea of keeping track of a pointer to
an automatic variable. That might do the trick, but I'm not sure how
portable that is and how I can determine the available C stack size in
advance.

>> (3) collections of several 'if' and 'where' clauses are processed in a
>> "backward" fashion, consider e.g.: if X>Y where Y=bla Z where Z=foo X.
> 
> (3) takes some getting use to.

Yes sure, but that's just the way these things would be written in
mathematical language. Writing this the other way round, i.e. 'where
Z=foo X where Y=bla Z if X>Y' doesn't make sense to me.

> Trying (2): I know that the "where (X1,X2) = Ws is suppose to fail but is
> it suppose to do the following?
> 
> ==> main [(1,2,3,4),(0,3,1,4),(2,6,-1,-2)]
> /usr/local/bin/q[pid 1802]: caught signal 11 (Segmentation fault),
> printing backtrace... 14 stack frames

Surely not. :) I'll look into that.

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] New 'where' syntax

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

Albert Graef scripsit:

> Well, in fact the manual was originally written at the beginning of the
> 1990s when I wasn't very familiar with the "official" FP jargon. Of
> course it has been overhauled many times since then, but somehow the
> term "qualifier" sticked. Maybe it's time to change it now...

To me, the term "guard" (which I think is due to Dijkstra ultimately)
connotes conditionals but not bindings, so I would prefer to retain
"qualifier" as a term for both bindings and conditionals.

-- 
In politics, obedience and support      John Cowan <co...@cc...>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan

[q-lang-users] Bug? New 'where' syntax

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

Albert Graef,

>So we already have two thumbs up now, nice. :) Did anyone find any
>bugs/flaws/gripes with the syntax yet?

I think so, see below. I wonder what John has to say about this?

>Ok, I guess it's about time for a first release candidate now.
>I'll do that as soon as I've updated the documentation.

Did you figure out the bug with specials like ifelse, cond, case, and
family running out of stack? Oops, I'll check this when I get a chance!

> Right, but note that the similarity is mostly syntactical. Q's 'where'
> clauses will still feel unfamiliar to most programmers because:
>
> (1) those local variables aren't really mutable (although they may be
> rebound);
>
> (2) 'where' clauses are both variable bindings *and* conditions (if a
> pattern match fails in a variable binding, the entire equation fails);
>
> (3) collections of several 'if' and 'where' clauses are processed in a
> "backward" fashion, consider e.g.: if X>Y where Y=bla Z where Z=foo X.

(3) takes some getting use to. For example:

func [] = [];
func [L|Ls]
where (X1,X2) = Ws
where (W|Ws) = L:
	     = [- X1 * X2] ++ func Ls if W > 0;
	     = [0] ++ func Ls if W = 0;
	     = [X1 * X2] ++ func Ls if W < 0;

main X= write (func X);

==> main [(25,10,1),(-1,10,3),(0,4,9),(3,8,2)]
[-10,30,0,-16]()

Trying (2): I know that the "where (X1,X2) = Ws is suppose to fail but is
it suppose to do the following?

==> main [(1,2,3,4),(0,3,1,4),(2,6,-1,-2)]
/usr/local/bin/q[pid 1802]: caught signal 11 (Segmentation fault),
printing backtrace... 14 stack frames
/usr/local/bin/q(__qq__print_trace+0x26)[0x804f786]
/usr/local/bin/q(__qq__segv_handler+0x7c)[0x804f84c]
[0xb7f39420]
/usr/local/bin/q(__qq__pushfun+0xa4)[0x8056e94]
/usr/local/bin/q[0x805b034]
/usr/local/bin/q[0x805cc0a]
/usr/local/bin/q[0x805d000]
/usr/local/bin/q(__qq__eval+0x4d)[0x805d24d]
/usr/local/bin/q(yyparse+0x4b68)[0x8076928]
/usr/local/bin/q[0x807805a]
/usr/local/bin/q(__qq__parsex+0x24)[0x80781d4]
/usr/local/bin/q(main+0x668)[0x8053358]
/lib/tls/libc.so.6(__libc_start_main+0xc8)[0xb7cceea8]
/usr/local/bin/q[0x804ea91]

Eddie

Re: [q-lang-users] New 'where' syntax

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

Albert Graef wrote:
> [...] the term "qualifier" sticked.

s/sticked/stuck/ Where's that spellchecker when you need it? :)

-- 
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] New 'where' syntax

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

Keith Trenton wrote:
> Wrt. "simple" labels, e.g., "qualifier" and "guard", if "guard" is already established, then why not go with it? Unless, of course, Q has a special use for "guard"; but it means the same, right?

Well, in fact the manual was originally written at the beginning of the
1990s when I wasn't very familiar with the "official" FP jargon. Of
course it has been overhauled many times since then, but somehow the
term "qualifier" sticked. Maybe it's time to change it now...

-- 
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] New 'where' syntax

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

Eddie Rucker wrote:
> Super Cool!

So we already have two thumbs up now, nice. :) Did anyone find any
bugs/flaws/gripes with the syntax yet?

Ok, I guess it's about time for a first release candidate now. I'll do
that as soon as I've updated the documentation.

> This is clean. It is like most other programming languages: introduce the
> local variable and initialize it before use. I think this will make it
> easier for people comming from other languages.

Right, but note that the similarity is mostly syntactical. Q's 'where'
clauses will still feel unfamiliar to most programmers because:

(1) those local variables aren't really mutable (although they may be
rebound);

(2) 'where' clauses are both variable bindings *and* conditions (if a
pattern match fails in a variable binding, the entire equation fails);

(3) collections of several 'if' and 'where' clauses are processed in a
"backward" fashion, consider e.g.: if X>Y where Y=bla Z where Z=foo X.

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] New 'where' syntax

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

 
Hello Albert -- 

--- Albert Graef <Dr....@t-...> writes:
- 
-        strip C S
-        where N = #S-1 if not null S:
-                = strip C $ sub S 0 (N-1) if S!N = C;
-                = strip C $ sub S 1 N if S!0 = C;
-        otherwise:  <<<<<
-                = S;

Got it! The use of the token 'otherwise' before the colon is a nice touch; the other example did not feature the 'otherwise' and suddenly, the ':' looked "alien" to me. ;-)

Thanks for pointing out my oversight!

Cheers,
Keith 
 

Re: [q-lang-users] New 'where' syntax

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

Albert Graef,

Super Cool!

>         fact N if N>0:          = N*fact (N-1);
>                otherwise:       = 1;

I think the guards look very similar to Erlang's guards. Compare this to
Erlang:

fact(N) when N>0 ->
    N * fact(N-1);
fact(0) ->
    1.

>         strip C S
>         where N = #S-1 if not null S:
>                 = strip C $ sub S 0 (N-1) if S!N = C;
>                 = strip C $ sub S 1 N if S!0 = C;
>         otherwise:
>                 = S;

> Here, the scope of the condition 'not null S' and the local definition
> 'N = #S-1' encompasses the first two equations.

This is clean. It is like most other programming languages: introduce the
local variable and initialize it before use. I think this will make it
easier for people comming from other languages.

Eddie

Re: [q-lang-users] New 'where' syntax

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

Keith Trenton wrote:
> - In Q this definition can now be written as follows:
> - clunky ENV VAR1 VAR1
> -    where just VAL1 = lookup ENV VAR1,
> -          just VAL2 = lookup ENV VAR2: <<<<<
> 
> Is that colon ':' following 'VAR2' correct? It doesn't look right, but I know that I have probably missed something along the way... (so I'm asking you nicely for clarification =).

Yes it is... Some kind of proper delimiter which terminates the list of
lhs qualifiers/guards was needed (both for readability purposes, and to
resolve actual ambiguities in the grammar). I first considered ',', but
this wasn't possible since ',' also delimits different definitions in a
'where' clause, and ';' looked awful (as if the equation ended
prematurely). I think that ':' is a fairly good choice; if properly
formatted, it makes the lhs qualifiers stick out like a kind of "case
labels", as shown in my revision of Eddie's original 'strip' example in
my previous post:

        strip C S
        where N = #S-1 if not null S:
                = strip C $ sub S 0 (N-1) if S!N = C;
                = strip C $ sub S 1 N if S!0 = C;
        otherwise:
                = S;

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