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

[q-lang-users] ANN: Q 7.7 RC1 is out!

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

Hi all,

after several night shifts filled with documentation updates and some
more bug-slashing, I've finally uploaded the first candidate for the
forthcoming Q 7.7 to sourceforge. Here is the direct download link:

http://dfn.dl.sourceforge.net/sourceforge/q-lang/q-7.7rc1.tar.gz

A summary of the changes in this release can be found in the NEWS file
contained in the package.

Have fun with it, and please report any bugs and portability issues that
you find. :)

Please note that not all addon modules have been tested with the new
release yet, and the native Windows port isn't ready yet either; I'll
start working on this asap. Also, the auto-indent of the Emacs mode
doesn't work very well with the new left-hand qualifiers right now, but
that will of course be fixed before the final release, too.

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

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

Rob Hubbard wrote:
> Alternatively, is there any way of issuing a warning if the lexer's
> action is affected by the presence of an operator definition when
> parsing a sequence of punctuation characters to form a symbol? Again,
> probably not, as I can't see a good rule or heuristic to distinguish
> likely intended parses from unintended ones...

I thought about this myself, but to do this right the lexer would have
to look ahead in the input and perform a considerable amount of
backtracking, which would be a major performance killer. So I decided
against it.

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

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

Albert Graef wrote:
> 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.

Ok, this is now implemented as well. So you can now dissect a 'Function'
object (a.k.a. compiled lambda) simply as follows:

==> var fact = \N.if N>0 then N*fact(N-1) else 1; fact
\X1 . if X1>0 then X1*fact (X1-1) else 1

==> def \PAT.BODY = fact; PAT; BODY
X1
if X1>0 then X1*fact (X1-1) else 1

I think that this is quite neat. I also overhauled the definition of
equality on 'Function' objects in prelude.q so that it uses the
corresponding view instead of comparing string representations of the
objects.

There's one (last?) issue I want to work on for the current release,
namely the notion of syntactic equality for external types such as
'Function' which have an associated view. Right now external objects are
considered syntactically equal only if they are the same object (i.e.,
pointer equality). AFAICS, this is the only thing that makes sense if
there is no printable representation -- given that syntactical equality
must always be defined, for any kinds of objects.

But now that external types may have views, it makes sense to test
syntactic equality on such types by comparing the corresponding views.
This is consistent with the "two expressions are syntactically equal if
they print out the same in the interpreter" rule for normal objects.

I will also remove the current definition of (=) for Function objects,
as it's just syntactic equality, and there's no real notion of semantic
equality on functions which is also decidable, so it makes sense to
leave (=) undefined on these objects.

Is anyone fine with that? Will it break any of your existing code? Only
programs directly dealing with Function objects (comparing them with (=)
and (==)) might be affected.

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

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

On 31/05/07, Albert Graef <Dr....@t-...> wrote:
> > Rob Hubbard wrote:
> >> It seems that now, introducing a new symbol will affect the way that
> >> code is parsed. This is something I find a little worrying.
> >
> > You're right. Right now the lexer inspects the symbol table to partition
> > punctuation symbols. I agree that this is a bad idea since it makes the
> > syntax depend on the declared operator symbols. I will fix that right
> > away.
>
> Well, it sounded like a good idea, but actually it isn't. ...

Shame, but I agree with your decision, given the problems you
described, that the breakage would after all be too severe and the
resulting behaviour too inconvenient.

Thanks too for all the (attached) detail about symbol parsing.

I wonder whether there's any scope for Q itself to issue warnings
about some or all punctuational operator declarations. This might not
be too 'noisy' if only one such warning was given. Then again, perhaps
this isn't such a good suggestion.

Alternatively, is there any way of issuing a warning if the lexer's
action is affected by the presence of an operator definition when
parsing a sequence of punctuation characters to form a symbol? Again,
probably not, as I can't see a good rule or heuristic to distinguish
likely intended parses from unintended ones...

Rob.

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

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

Eddie Rucker wrote:
> What about Python:
> 
>>>> 2+3j + 2-4i
> (4-1j)

Yes, Scheme offers something similar. But this is just builtin syntax;
you can't match against a pattern like X+Yj. In Q you can now do that:

coords (X+:Y) = (X,Y);

I wonder whether this is compelling enough so that you might be willing
to put up with the unfamiliar X+:Y syntax? :)

Anyway, assuming that we want Complex to have a virtual constructor (I
do, if only for consistency with Rational), I'd say that (+:) is as at
least as good as any other, so I'm going to stick with it for now. Note
that if you don't like this then you can always get the old X+i*Y
pretty-printing back by just adding the old definition of Complex's view
to your programs:

  view C:Complex = if Y<0 then '(X-~(-Y)*i) else '(X+Y*i)
    where (X,Y) = re_im C;

Of course then you lose the ability to pattern-match against complex
values, but the standard library doesn't depend on that.

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

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

On 01/06/07, Eddie Rucker <ed...@bm...> wrote:
> Albert Graef wrote,
>
> > I don't know any other language that has an
> > infix operator to create complex numbers, does anyone else?
>
> What about Python:
>
> >>> 2+3j + 2-4i
> (4-1j)
>
> Eddie

But beware that Python doesn't really get this quite right:

    >>> (1+2j) * (3+4j)
    (-5+10j)

    >>> 1 + (2j*3) + 4j
    (1+10j)

    >>> 1+2j * 3+4j
    (1+10j)

That is, the '+' and '*' operators have their usual precedences. There
is no 'special' high-precedence operator for complex construction.

Also, the latest 'C' standard (C99?) has support for imaginary and
complex numbers, but I'm not sure of the lexing details...

Rob.

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

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

Albert Graef wrote,

> actually Haskell-compatible. I don't know any other language that has an
> infix operator to create complex numbers, does anyone else?

What about Python:

>>> 2+3j + 2-4i
(4-1j)

Eddie

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

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

Keith Trenton wrote:
> Then why not '+i' (as in X+iY)? I understand about the colon; can the Q interpreter parse '+i' as intended?

Nope. It's either punctuation or an identifier, but not both.

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

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

John Cowan wrote:
> Keith Trenton scripsit:
>>  
>> Hello John -- 
>>
>> --- John Cowan <co...@cc...> scripsit:
>> - How about "+|*", which actually does look like "+ i *"?
>>
>> True enough, but as my "less is more" preference wrt. typing extra
>> characters has a higher precedence, my vote stays with '+:' (X+:Y).

I have to agree with Keith here.

> What about "+*", then?  The colon is only relevant because of a
> rule of Haskell lexical syntax that does not apply to Q.

True enough, but the current solution ((:+) aliased to (+:)) has the big
advantage that it looks familiar (for Haskell programmers anyway) and is
actually Haskell-compatible. I don't know any other language that has an
infix operator to create complex numbers, does anyone else?

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

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

 
--- John Cowan <co...@cc...> scripsit:
- What about "+*", then? The colon is only relevant because of
- a rule of Haskell lexical syntax that does not apply to Q.

Then why not '+i' (as in X+iY)? I understand about the colon; can the Q interpreter parse '+i' as intended?

In any event, Albert has already implemented '+:'. =)

Cheers,
Keith 
 

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

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

Keith Trenton scripsit:
>  
> Hello John -- 
> 
> --- John Cowan <co...@cc...> scripsit:
> - How about "+|*", which actually does look like "+ i *"?
> 
> True enough, but as my "less is more" preference wrt. typing extra
> characters has a higher precedence, my vote stays with '+:' (X+:Y).

What about "+*", then?  The colon is only relevant because of a
rule of Haskell lexical syntax that does not apply to Q.
> Cheers,
> Keith 
>  
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users

-- 
All Norstrilians knew what laughter was:        John Cowan
it was "pleasurable corrigible malfunction".    co...@cc...
        --Cordwainer Smith, Norstrilia

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

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

 
Hello John -- 

--- John Cowan <co...@cc...> scripsit:
- How about "+|*", which actually does look like "+ i *"?

True enough, but as my "less is more" preference wrt. typing extra characters has a higher precedence, my vote stays with '+:' (X+:Y).

Cheers,
Keith 
 

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

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

Keith Trenton scripsit:

> One suggestion: is it not possible to implement '+:' _AND_ ':+',
> with the latter form serving as a "safety net" for thick-fingered
> Haskell programmers?

How about "+|*", which actually does look like "+ i *"?

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"

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

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

Keith Trenton wrote:
> One suggestion: is it not possible to implement '+:' _AND_ ':+', with the latter form serving as a "safety net" for thick-fingered Haskell programmers?

Yes sure, that's a good idea. In fact, I've already implemented it! So
(+:) is now the "official" constructor, with (:+) provided as an alias
for Haskell aficionados.

Ok, is everybody happy with that now? Or can at least live with it?

> Maybe a warning could be printed to indicate that '+:' is the preferred form for expressing complex numbers (X+:Y)

Unfortunately that's not possible, since the compiler doesn't even
"know" about (+:) and (:+); they're defined in the standard library.

Hmm, maybe we need a new '__do_not_use_that_or_else__' modifier in
symbol declarations which causes the interpreter to print a nasty
warning when such a symbol is used. On repeated use of some such symbol
the interpreter might then explode. ;-)

> Did I just pour another bucket of water over my head? ;-)

I could use some of that. ;-) I have a terrible headache today. Probably
the weird weather over here, one day it's already summer with 30C (86F),
the next day we have rain and 10C (50F). It's killing me. Best April
weather (in contrast, April was nice and sunny and no rain at all).

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

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

Albert Graef wrote:
> (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.)

Ok, that should be fixed now, too, and call-by-pattern-matching should
work as well. So the following now also works from the command line,
just as in scripts:

==> def (A%B,C%D) = (6%4-1,2%3+2)

==> def {X,Y|_} = {1,3..}

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

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

 
Hello Albert -- 

--- Albert Graef <Dr....@t-...> writes: 
- Hmm, for me X:-Y looks too much like a '-' where there should be '+'.

I was thinking too small (i.e., 0:-1) and not looking at the bigger picture (i.e., all X:+Y). My bad.

One suggestion: is it not possible to implement '+:' _AND_ ':+', with the latter form serving as a "safety net" for thick-fingered Haskell programmers?

Maybe a warning could be printed to indicate that '+:' is the preferred form for expressing complex numbers (X+:Y)

Did I just pour another bucket of water over my head? ;-)

Cheers,
Keith 
 

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

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

Eddie Rucker wrote:
> Put this on a college Algebra or Calculus test:
> -2^2 =
> (a) -4 (b) 4
> All most all of the students will put (b). This is the same gotcha that I
> have to point out to students all the time. Strange though, they have no
> problem with X=2, -X^2=-4.

Well, at least Q does the right thing there. :)

  ==> -2^2
  -4.0

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

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

> Rob Hubbard wrote:
>> It seems that now, introducing a new symbol will affect the way that
>> code is parsed. This is something I find a little worrying.
> 
> You're right. Right now the lexer inspects the symbol table to partition
> punctuation symbols. I agree that this is a bad idea since it makes the
> syntax depend on the declared operator symbols. I will fix that right
> away.

Well, it sounded like a good idea, but actually it isn't. Applying a
naive "maximal munch" rule breaks quite a lot of existing code, since
code like '[0..#B-1]' then becomes a syntax error ('..#' is flagged as
undefined, instead of parsing it as two lexemes '..' and '#'). Just
excluding special lexemes like '..' from the maximum munch rule doesn't
work either since then you couldn't define an operator like '.*' or ':+'.

So I guess that we'll just have to live with the fact that if you
declare an operator symbol then you're actually changing the lexical
syntax of the language (which is already the case with operators like
(xor) anyway, it's just not so blatantly obvious). I'll add a warning
about this to the manual.

Note, however, that the module system does help with stuff like this,
since just adding an operator to your own script doesn't change the way
that, say, the standard library modules are parsed, since your
definition is not in scope there. It's just that you have to be careful
with your own operator declarations. If you declare an operator like
'public (..#) X Y;' then you can't write something like '[0..#B-1]' in
the scope of that definition and expect it to mean '[0 .. #B-1]'. If you
do silly things like that (i.e., introduce an operator symbol which ends
in something which can also be interpreted as a unary operator) then you
get what you called for. ;-) Sharp knife and all that...

Ok, here's the "maximal munch" rule as it is implemented right now. I
actually think that it works pretty well; at least it doesn't disrupt
any existing code that I've tried.

MAXIMAL MUNCH RULE. Operator symbols consisting of punctuation are
generally parsed using the "longest possible lexeme" a.k.a. "maximal
munch" rule. More precisely, this means that in a _declaration_ like
'public (+-&%) X Y;' the symbol being declared always extends up to the
closing ')' delimiter. Outside of declarations, however, the "longest
possible lexeme" refers to the longest prefix of the input such that the
sequence of punctuation characters actually forms a _valid_, i.e.,
declared or reserved, symbol. Thus, e.g., '..#' will actually be parsed
as '.. #' (reserved '..' symbol followed by a '#' operator).

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

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

Albert Graef,

> John Cowan wrote:
>> 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".
>
> Well, syntactically the '-' in '-2' is a unary minus, although
> semantically, it's still a number and not an explicit application of
> minus. IMHO, that's the only reasonable way to implement it, since I
> want '-2' and '-X' to be parsed in the same manner.

Put this on a college Algebra or Calculus test:
-2^2 =
(a) -4 (b) 4
All most all of the students will put (b). This is the same gotcha that I
have to point out to students all the time. Strange though, they have no
problem with X=2, -X^2=-4.

Sorry, I just had to toss in my 2 cents.

Eddie

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

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

Hi Rob,

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

Yes, Unicode all the way through. :) Just like you can have arbitary
Unicode letters in identifiers, you can have arbitrary Unicode
punctuation in operator symbols.

(BTW, I'd appreciate it very much if our non-Western-locale users could
check that those Russian/Japanese/whatever identifiers and operators
still work. For me, the unicode.q example works ok, but I don't have
many scripts using non-ASCII characters to test, so please let me know
if you find any bugs there. Alexander? Keith? Anyone else?)

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

Ok, I've attached a little description of the lexical operator symbol
syntax I wrote while working on these things, to be included in the
manual later.

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

No, that would make the syntax too confusing IMHO. Function symbols must
now be legal identifiers, punctuation is only allowed in operator symbols.

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

You're right. Right now the lexer inspects the symbol table to partition
punctuation symbols. I agree that this is a bad idea since it makes the
syntax depend on the declared operator symbols. I will fix that right
away. Of course this means that 5--3 won't be legal any more (unless
you've declared a (--) operator). But I think that this is a minor
issue, and anyway the compiler will catch it if you've written anything
like that in your scripts.

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

I think that, as pointed out above, '--' should actually be an error if
you haven't declared it as an operator. Implicit declaration of
operators is a bad idea, IMHO. It's much too easy to mistype them. The
compiler would then just silently munge almost all arbitray line noise;
it might even happily parse many Perl scripts. ;-)

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

Hmm, I'm not sure what you think about here?

> [Can of worms! Sorry.]

No need to feel sorry, I'm glad you opened it! I want to fix all those
quirks before release. ;-)

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

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

Rob Hubbard wrote:
> If mixed operators are not allowed, [...]

No, they aren't. You can either have a sequence of punctuation symbols
or an identifier, but not both in the same symbol. (Actually, I could
change the lexical syntax to make that possible, but I don't think that
this would be a good idea.)

> [...] what about the thing that looks a
> little like 'i': use something like (+:*) or (+|*) or (+!*)?

That was my idea with '+:'. I can easily read that as "plus i times".
'+!' looks nice to me, too. ('+:' might confuse Haskell programmers as
they'll easily mistype it as ':+'.)

> Alternatively, what about allowing mixed multi-character operator and
> function names delimited by something, such as [brackets]: 0[+i*]1.

That's not possible. The parens/brackets/braces are reserved delimiters
which cannot occur in an operator symbol.

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

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

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

Hmm, for me X:-Y looks too much like a '-' where there should be '+',
sorry. Also, you might want to use ':-' for logical purposes (say, if
you want to write a Prolog interpreter 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] New stuff in cvs: multichar ops, views

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

Alexander Nickolsky wrote:
> Great news. BTW, how can I build Q for windows without installing
> cygwin ?

Not yet. :( I still have to work on the native Windows port. I'll do
that as soon as RC1 is out.

You could try to grab the big zip file with the Windows sources from Q
7.6, and replace the Q sources in there with the latest cvs, but I don't
know how well that works after the bundled regex and glob stuff is gone...

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

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

John Cowan wrote:
> 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".

Well, syntactically the '-' in '-2' is a unary minus, although
semantically, it's still a number and not an explicit application of
minus. IMHO, that's the only reasonable way to implement it, since I
want '-2' and '-X' to be parsed in the same manner.

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

Well, X+Y*i doesn't work here since '+' is not a virtual constructor of
Complex, so while you can use this for pretty-printing (as we did in Q
7.6), you can't write stuff like 'foo (X+Y*i) = ...'. So, to make
matching against the view work, the head symbol of the view must be a
virtual constructor of the type and that's the purpose that ':+' serves.
We could have something like 'X:+Y*i' instead of just 'X:+Y' but that
seems redundant.

What's so bad about 'X:+Y'? I can easily read ':+' aloud as "+i times".

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

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

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

What about 0+i*1 if the constructor could be (+i*)? I don't know if
this kind of mixed operator is allowed, nor whether it would be a good
idea to do so.

If mixed operators are not allowed, what about the thing that looks a
little like 'i': use something like (+:*) or (+|*) or (+!*)?

Alternatively, what about allowing mixed multi-character operator and
function names delimited by something, such as [brackets]: 0[+i*]1.

Yes, that's still pretty ugly.

Rob.