Re: [q-lang-users] Q in FC6

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

Tim Haynes scripsit:

> c) A minor (probably only visual) niggle. This strikes me as having
> a few too many commas for my sanity:
> 
>  | ==> import odbc
>  | 
>  | ==> def H=odbc_connect "DSN=pgstraw"
>  | 
>  | ==> sql H "select count(*) from gallery" ()
>  | [("count",),(1770,)]
>  
> I have both unixODBC and iODBC installed; on this box, Q's odbc.so is
> linked against unixODBC; neither iodbctest nor isql hint at a second
> column; versions of Q >=6.2incl exhibit this spare comma. 

No.  That's the way that Q (>=6.2, as you say) represents a tuple
with one element.  The syntax used to be just "(1770)", but that meant
different things in different contexts: it meant a tuple if the parens
were redundant, or just a plain expression of the parens were necessary
because of operator priorities.

I successfully argued that this was obnoxious, and Q was changed to use
the same syntax as Python: the final element in a tuple MAY be followed
by a comma, and MUST be if it is the only element.  Naturally, the
unparser follows the same rule, inserting the final comma only in
singletons.

> I note I can type [1,2,3,] into the interpreter and get back [1,2,3]
> for my trouble (so I'd expect the above resultset display to be
> normalized too). Am I missing some update somewhere?

Lists can't be confused with simple parens, so the final comma is
never necessary and the unparser will not generate it.

-- 
Kill Gorgun!  Kill orc-folk!            John Cowan
No other words please Wild Men.         co...@cc...
Drive away bad air and darkness         http://www.ccil.org/~cowan
with bright iron!   --Ghan-buri-Ghan    http://www.ccil.org/~cowan