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

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

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

Rob Hubbard wrote:
> This is a rare occasion where I *strongly* disagree. The purpose of
> (+:) is to form complex numbers syntactically, when they are in some
> sense 'atomic' or 'literal' semantically.

I see your point, but note that in common mathematical notation complex
numbers aren't atomic either (unless you write them as pairs), so you
face the same kind of problem.

But let's assume, just for fun, that X+:Y really is atomic, how should
foo 2 +: 3 be parsed? Or -2+:3 ? I think that it would be rather
surprising if -2+:3 returned (-2)+:(-3). Note the parentheses; these
would be obligatory if (+:) had, say, the same precedence as (.).

I really think that 'X+:Y' should be seen as an abbreviation for 'X+i*Y'
(in fact, that's just how it is implemented, but this doesn't count in
this discussion). Consequently, '+:' should have the same precedence as
'+', anything else is just awkward in subtler but equally annoying ways,
as pointed out above.

>    ==> 1+:2 * 3+:4
>    1+:10 // is wrong (and surprising)

I have no problem with that if I read '1+:2*3+:4' as '1+i*2*3+i*4'.

BTW, this apparent weirdness is somewhat mitigated in Haskell because
Haskell's ':+' is non-associative (which makes sense in Haskell since
':+' only takes Real operands there). But why should we arbitrarily
limit the scope of Q's '+:' when it can be applied to complex operands
just as easily? Besides, this also makes '+:' work exactly analogous to
exact division '%' which is a Good Thing, IMHO.

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

[<ed...@ri...>]

<p><br /> This seams to be the same argument as the -1 thingy. Do we want -=
1 to mean - is an operator and 1 is a number or -1 to be an integer? Is 1+:=
2 a complex number or is 1+:2 and operator to create a complex number from =
reals 1 and 2? Too bad white space isn't significant because, then you coul=
d have the best of both worlds - 1 (with space) as a unary minus and -1 wit=
h no space as an integer; 1 +: 2 (with space) as a constructor for a comple=
x number and 1+:2 as complex number.</p><p>1+:2 * 3+:4 =3D=3D&gt; 11+:2</p>=
<p>1 +: 2 * 3 +: 4 =3D=3D&gt; 1+:10</p>I wish I new more about PL theory.<p=
>&nbsp;Eddie<br /><br /><br /><strong>On Wed Jun 27 18:15 , Albert Graef  s=
ent:<br /><br /></strong><blockquote style=3D"border-left: 2px solid rgb(24=
5, 245, 245); margin-left: 5px; margin-right: 0px; padding-left: 5px; paddi=
ng-right: 0px;">John Cowan wrote:<br />=0D
&gt; I have mixed feelings about it.  Scheme of course does not have infix<=
br />=0D
&gt; operator priorities, but does allow complex constants of the form 3+4i=
,<br />=0D
&gt; which is equivalent to (make-rectangular 3 4).  So tight binding feels=
<br />=0D
&gt; right to me.  OTOH, Haskell compatibility is a strong argument; on the=
<br />=0D
&gt; gripping hand, Haskell may simply have gotten this wrong, as C did wit=
h &amp;&amp;<br />=0D
&gt; and ||.<br />=0D
<br />=0D
Well, I see a rationale behind this, as :+ really is an addition<br />=0D
operator, so there is a case for treating it as such.<br />=0D
<br />=0D
Albert<br />=0D
<br />=0D
-- <br />=0D
Dr. Albert Gr&quot;af<br />=0D
Dept. of Music-Informatics, University of Mainz, Germany<br />=0D
Email:  <a href=3D"javascript:top.opencompose('Dr....@t-...','','',=
'')">Dr....@t-...</a>, <a href=3D"javascript:top.opencompose('ag@mu=
wiinfa.geschichte.uni-mainz.de','','','')">ag...@mu...schichte.uni-mainz=
.de</a><br />=0D
WWW:    <a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttp%3A%2F%2Fww=
w.musikinformatik.uni-mainz.de%2Fag">http://www.musikinformatik.uni-mainz.d=
e/ag</a><br />=0D
<br />=0D
-------------------------------------------------------------------------<b=
r />=0D
This SF.net email is sponsored by DB2 Express<br />=0D
Download DB2 Express C - the FREE version of DB2 express and take<br />=0D
control of your XML. No limits. Just data. Click to get it now.<br />=0D
<a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttp%3A%2F%2Fsourceforg=
e.net%2Fpowerbar%2Fdb2%2F">http://sourceforge.net/powerbar/db2/</a><br />=
=0D
_______________________________________________<br />=0D
q-lang-users mailing list<br />=0D
<a href=3D"javascript:top.opencompose('q-l...@li...',=
'','','')">q-l...@li...</a><br />=0D
<a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttps%3A%2F%2Flists.sou=
rceforge.net%2Flists%2Flistinfo%2Fq-lang-users">https://lists.sourceforge.n=
et/lists/listinfo/q-lang-users</a><br />=0D
</blockquote>=0D
</p><BR>=

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

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

 
Hello All -- 

--- Rob Hubbard <hub...@gm...> writes:
- The purpose of (+:) is to form complex numbers syntactically,
- when they are in some sense 'atomic' or 'literal' semantically.

I'm with Rob on this one: '+:' is not simply another way of saying '+'. It should always do the right thing wrt. PoLS (Principle of Least Surprise).


--- Rob Hubbard <hub...@gm...> writes:
- Python get this wrong...Haskell certainly gets this wrong.
- Please don't let Q follow suit and also get this wrong.

*** AND ***

--- John Cowan <co...@cc...> writes:
- Haskell may simply have gotten this wrong, as C did with && and ||.

If compatibility with Haskell (i.e., low precedence) leads to incorrect results (i.e., *surprise*), then let's not be compatible.

Let's add an explanation to the manual that warns Haskell programmers to expect to "get their sums right with Q". ;-)

Cheers,
Keith 
 

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

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

Hello,

On 28/06/07, Albert Graef <Dr....@t-...> wrote:
> Well, I see a rationale behind this, as :+ really is an addition
> operator, so there is a case for treating it as such.

This is a rare occasion where I *strongly* disagree. The purpose of
(+:) is to form complex numbers syntactically, when they are in some
sense 'atomic' or 'literal' semantically.

For (+:) to bind so weakly (i.e. as if it is an ordinary addition
operator) makes its behaviour surprising. Python get this wrong, but
only because it really does just use the ordinary + operator. Haskell
certainly gets this wrong.

Please don't let Q follow suit and also get this wrong.

   ==> 1+:2 * 3+:4
   1+:10 // is wrong (and surprising)
   -5+:10 // is right

Rob.

Re: [q-lang-users] improvement to Q

[<ed...@ri...>]

<html>=0D
=0D
<P><BR>
Ok :) I promise I looked for this function. I guess I overlooked it many ti=
mes. I wonder what other goodies I've overlooked many times?</P>=0D
<P>Eddie<BR>
<BR>
<BR>
<B>On Wed Jun 27 18:52 , Albert Graef &lt;Dr....@t-...&gt; sent:<BR>
<BR>
</P></B>=0D
<BLOCKQUOTE style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5p=
x; BORDER-LEFT: #f5f5f5 2px solid; MARGIN-RIGHT: 0px"><A href=3D"javascript=
:top.opencompose('ed...@ri...','','','')">ed...@ri...=
</A> wrote:<BR>
<FONT color=3Dred>&gt; I hope other Q users don't boo me but, I would like =
to see x^n return</FONT><BR>
<FONT color=3Dred>&gt; integer results when x is an integer and n is a natu=
ral number. Maybe</FONT><BR>
<FONT color=3Dred>&gt; even return a rational when n is a negative integer.=
</FONT><BR>
<BR>
The pow function already does this:<BR>
<BR>
=3D=3D&gt; whos pow<BR>
<BR>
pow external function symbol defined in /usr/share/q/lib/clib.q<BR>
pow X1 X2<BR>
<BR>
=3D=3D&gt; pow 2 64<BR>
18446744073709551616<BR>
<BR>
=3D=3D&gt; pow 2 (-2)<BR>
1%4<BR>
<BR>
=3D=3D&gt; pow (2%3) (-2)<BR>
9%4<BR>
<BR>
So if you prefer to have this as an operator, simply define:<BR>
<BR>
public (^^) X Y @ (^);<BR>
<BR>
X:Num^^Y:Num =3D Z where Z:Num =3D pow X Y;<BR>
<BR>
If you want to have the operator work with floats as well, just add:<BR>
<BR>
X:Num^^Y:Num =3D Z where Z:Num =3D X^Y;<BR>
<BR>
A while ago there was a heated discussion over whether (^) should<BR>
provide that functionality but, as John already pointed out, it's really<BR>
better to have two different operations here, for various reasons.<BR>
<BR>
Albert<BR>
<BR>
-- <BR>
Dr. Albert Gr"af<BR>
Dept. of Music-Informatics, University of Mainz, Germany<BR>
Email: <A href=3D"javascript:top.opencompose('Dr....@t-...','','','=
')">Dr....@t-...</A>, <A href=3D"javascript:top.opencompose('ag@muw=
iinfa.geschichte.uni-mainz.de','','','')">ag...@mu...schichte.uni-mainz.=
de</A><BR>
WWW: <A href=3D"parse.pl?redirect=3Dhttp%3A%2F%2Fwww.musikinformatik.uni-ma=
inz.de%2Fag" target=3D_blank><FONT color=3Dred>http://www.musikinformatik.u=
ni-mainz.de/ag</FONT></A><BR>
</BLOCKQUOTE>=0D
</html><BR>=

Re: [q-lang-users] Views and Virtual Constructors

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

John Cowan wrote:
> What comes to mind at once is to allow a complex number to be constructed
> in rectangular form and then matched in polar form, or vice versa.
> At present, the rectangular form is privileged, and adding your own
> view rules only makes the polar form privileged.  There is no way to
> make them equals.

This is true, but concrete algebraic types also have only a single,
canonical representation, and this is what views are supposed to mimic.
I concede that there is a case for generalizing this and allow multiple
views, like floating point numbers can be printed in 'fix' or 'std'
formats. I must think a bit more about this...

-- 
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] improvement to Q

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

ed...@ri... wrote:
> I hope other Q users don't boo me but, I would like to see x^n return
> integer results when x is an integer and n is a natural number. Maybe
> even return a rational when n is a negative integer.

The pow function already does this:

==> whos pow

pow             external function symbol defined in /usr/share/q/lib/clib.q
                pow X1 X2

==> pow 2 64
18446744073709551616

==> pow 2 (-2)
1%4

==> pow (2%3) (-2)
9%4

So if you prefer to have this as an operator, simply define:

public (^^) X Y @ (^);

X:Num^^Y:Num = Z where Z:Num = pow X Y;

If you want to have the operator work with floats as well, just add:

X:Num^^Y:Num = Z where Z:Num = X^Y;

A while ago there was a heated discussion over whether (^) should
provide that functionality but, as John already pointed out, it's really
better to have two different operations here, for various reasons.

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] Two proposed improvements to Q

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

John Cowan wrote:
> These are some changes I thought up while reviewing Q in a Nutshell.
> 
> 1) Q currently can't import names selectively from a module.  I propose
> the Python syntax for this:
> 
> 	from <module> import <name>,<name>,...;
> 
> and a variant that exports as well as importing:
> 
> 	from <module> include <name>,<name>,...;

Yes, the syntax seems reasonable, I already have this on my TODO list.

One related question is whether prelude.q should really import all the
standard library modules. This is convenient, but also a source of
"namespace pollution". E.g., one might discuss whether clib.q and
stdtypes.q should be imported explicitly in user programs. (Of course
this raises backward compatibility issues.)

> 2) Now that Q has ML-style reference cells (which are not documented
> anywhere in the Q manual that I can see)

References have actually been around since Q 3.x, IIRC, but they are
implemented in clib and thus documented in Section 12 of the manual:
http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC137

> adding general mutable
> (but fixed-length) vectors is an easy extension: one simply adds a
> few equations to the standard library for treating tuples of cells
> properly.

Which operations do you have in mind? I mean, you can already create a
tuple of references, e.g., like this: 'tuple [ref ():I in [1..N]]', and
then assign with 'put (V!I) X' and retrieve a value with 'get (V!I)'.

> Following that, byte vectors (mutable byte strings) would also be
> a useful addition for dealing with large quantities of homogeneous
> data; these have to be done in C, but would be far more efficient
> than any alternative representation.

Yes, actually I've had something like this on my TODO list for a while,
in order to provide better support for numeric and signal processing
applications. But this also means that there should be appropriate
functions for dealing with C vectors and matrices of integer and float
values. Maybe a SWIG interface to the GNU Scientific Library or the
Octave library would be in order? Any volunteers for such a project?

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

John Cowan wrote:
> I have mixed feelings about it.  Scheme of course does not have infix
> operator priorities, but does allow complex constants of the form 3+4i,
> which is equivalent to (make-rectangular 3 4).  So tight binding feels
> right to me.  OTOH, Haskell compatibility is a strong argument; on the
> gripping hand, Haskell may simply have gotten this wrong, as C did with &&
> and ||.

Well, I see a rationale behind this, as :+ really is an addition
operator, so there is a case for treating it as such.

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] Views and Virtual Constructors

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

Albert Graef scripsit:

> I don't see right now what the more elaborate view notions buy you that
> you cannot achieve just as easily with some appropriate access
> operations and a 'where' clause. Someone please set me straight if I'm
> missing something important there. ;-)

What comes to mind at once is to allow a complex number to be constructed
in rectangular form and then matched in polar form, or vice versa.
At present, the rectangular form is privileged, and adding your own
view rules only makes the polar form privileged.  There is no way to
make them equals.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

Re: [q-lang-users] Views and Virtual Constructors

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

Rob Hubbard wrote:
> That is, is there a way for 'overlapping' views to be defined for use
> by the new pattern matching feature on virtual constructors?

No, not with the notion of views that Q currently implements. This is
the same kind of "alternative views" feature also discussed in the "New
stuff in cvs: multichar ops, views" thread.

To implement this feature, a more powerful notion of views would be
needed, which has something like the "value input feature", see
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns for a discussion
of various approaches. The notion of views proposed there for Haskell
allows this, effectively, by specifying the particular 'view' routine to
invoke when matching the pattern. Then you could write something like:

  foo (mylist_view1 -> mylist_cons H T) = ...;
  bar (mylist_view2 -> mylist_join X Y) = ...;

But I don't really see the point in this, as you can already have as
many ordinary access operations on an ADT which deliver as many
different concrete representations of the data as you want, and match
against these inside a 'where' clause:

  foo L:MyList = ... where mylist_cons H T = mylist_view1 L;
  bar L:MyList = ... where mylist_join X Y = mylist_view2 L;

This isn't much clumsier and doesn't require any special kind of view
implementation.

For me, views, in the spirit of Wadler's original proposal, are just a
convenience to make an ADT look like a concrete algebraic type with its
own "canonical" representation in terms of a given set of constructors.
In Q this virtual representation is then also used for pretty-printing,
so that you have "what you see is what you (can) get" in terms of
pattern-matching. This is convenient, simple and straightforward to use.
I don't see right now what the more elaborate view notions buy you that
you cannot achieve just as easily with some appropriate access
operations and a 'where' clause. Someone please set me straight if I'm
missing something important there. ;-)

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] improvement to Q

[<ed...@ri...>]

<p><br />Oops!</p><p>Should be </p><p>public (^^) X N @ (^);<br />=0D
X^^0 =3D 1;<br />=0D
X^^1 =3D X if (issym X) or (X   0);<br />=0D
     =3D _FAIL_ otherwise;<br />=0D
X^^N:Int <br />=0D
  if N&gt;1:<br />=0D
     =3D W*W where W =3D X^^(N div 2) if N mod 2 =3D 0;<br />=0D
     =3D X*(X^^(N-1)) if N mod 2 =3D 1;<br />=0D
  otherwise:<br />=0D
     =3D 1%(X^^(-N));</p><p><p>to handle cases like X^^3.</p><p> I hope the=
 not equals operator shows up after the &quot;X^^1 =3D&quot; pattern. The e=
mail program I have to use sux! It is suppose to turn the HTML crap off but=
 won't <strong>:~/</strong></p></p><p>Eddie&nbsp;</p><BR>=

Re: [q-lang-users] improvement to Q

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

ed...@ri... scripsit:

> I would like to see x^n return integer results when x is an integer and
> n is a natural number. Maybe even return a rational when n is a negative
> integer. 

I think having a new operator like ^^ (or **) is better, both for
backward compatibility and to avoid slipping in and out of bignums;
in the general case, Q floats are way more efficient than Q integers.

-- 
They tried to pierce your heart                 John Cowan
with a Morgul-knife that remains in the         http://www.ccil.org/~cowan
wound.  If they had succeeded, you would
become a wraith under the domination of the Dark Lord.         --Gandalf

[q-lang-users] improvement to Q

[<ed...@ri...>]

<p><br />Albert Graef:</p><p>I hope other Q users don't boo me but, I would=
 like to see x^n return integer results when x is an integer and n is a nat=
ural number. Maybe even return a rational when n is a negative integer. In =
the meantime</p><p>public (^^) X N @ (^);<br />X^^0 =3D 1;<br />X^^1 =3D X =
if X  0;<br />&nbsp;&nbsp;&nbsp;&nbsp; =3D _FAIL_ otherwise;<br />X^^N:Int =
<br />&nbsp; if N&gt;1:<br />&nbsp;&nbsp;&nbsp;&nbsp; =3D W*W where W =3D X=
^^(N div 2) if N mod 2 =3D 0;<br />&nbsp;&nbsp;&nbsp;&nbsp; =3D X*(X^^(N-1)=
) if N mod 2 =3D 1;<br />&nbsp; otherwise:<br />&nbsp;&nbsp;&nbsp;&nbsp; =
=3D 1%(X^^(-N));</p><p>Example:</p><p> =3D=3D&gt; 2^^3<br />8<br />=3D=3D&g=
t; 2^^(-3)<br />1%8<br />=3D=3D&gt; -2^^2<br />-4<br />=3D=3D&gt; (-2)^^(-2=
)<br />1%4&nbsp;</p><p>Eddie<br /> =0D
</p><BR>=

[q-lang-users] Two proposed improvements to Q

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

These are some changes I thought up while reviewing Q in a Nutshell.

1) Q currently can't import names selectively from a module.  I propose
the Python syntax for this:

	from <module> import <name>,<name>,...;

and a variant that exports as well as importing:

	from <module> import <name>,<name>,...;

and a variant that exports as well as importing:

	from <module> include <name>,<name>,...;

This makes "from" a reserved word, but I think that is a small price
to pay for the added convenience of being able to bring in specified
names only without the risk of unintended namespace pollution.

2) Now that Q has ML-style reference cells (which are not documented
anywhere in the Q manual that I can see), adding general mutable
(but fixed-length) vectors is an easy extension: one simply adds a
few equations to the standard library for treating tuples of cells
properly.

Following that, byte vectors (mutable byte strings) would also be
a useful addition for dealing with large quantities of homogeneous
data; these have to be done in C, but would be far more efficient
than any alternative representation.

-- 
Is not a patron, my Lord [Chesterfield],        John Cowan
one who looks with unconcern on a man           http://www.ccil.org/~cowan
struggling for life in the water, and when      co...@cc...
he has reached ground encumbers him with help?
        --Samuel Johnson

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

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

Albert Graef scripsit:

> Considering the precedence of '+:' a.k.a. ':+', I can see that it would
> be convenient to have a higher priority for some uses, but wouldn't that
> confuse Haskell programmers where ':+' has the same precedence as '+'?
> After all the current representation was meant to be more or less
> compatible with Haskell.

I have mixed feelings about it.  Scheme of course does not have infix
operator priorities, but does allow complex constants of the form 3+4i,
which is equivalent to (make-rectangular 3 4).  So tight binding feels
right to me.  OTOH, Haskell compatibility is a strong argument; on the
gripping hand, Haskell may simply have gotten this wrong, as C did with &&
and ||.

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

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

Sorry for chiming in so late, I'm still trying to catch up on my email.

Rob Hubbard wrote:
> Upon a little further thought, I would want only (+:) to be available
> for pattern matching. If the presence of a (-:) operator would upset
> the pattern matching, then I'd withdraw the suggestion in any case...

Unfortunately, with the current Wadler view system, you can't define
alternative views like that. I.e., if you define a view which returns
X+:Y and X-:Y for the two half-planes, then you'll also have to write
rules matching against both. That's why I didn't include '-:' in the
first place, in fact I had the same idea a while back. ;-)

For more elaborate kinds of views, so-called value input would be needed
which would allow you to pick a certain variation of a view in the lhs
pattern. One such proposal can be found on the Haskell site. Also, a
while back LtU mentioned an ICFP07 submission from the Microsoft FP
team, which also discusses a generalized view mechanism (for F#, IIRC).
I still have to take a closer look at that. I know that some of you guys
are on this list, maybe you could comment on that? :)

Considering the precedence of '+:' a.k.a. ':+', I can see that it would
be convenient to have a higher priority for some uses, but wouldn't that
confuse Haskell programmers where ':+' has the same precedence as '+'?
After all the current representation was meant to be more or less
compatible with Haskell.

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

Thanks John,

On 27/06/07, John Cowan <co...@cc...> wrote:
> > On the subject of (+:), I wondered whether there could be another
> > operator (-:) having the meaning "-i*", just as (+:) has meaning
> > "+i*". ...
>
> This is clever but not really necessary, I think.

I think it would genuinely make complex values more readable and more
'natural' to express. My thinking is that (-:) is somewhat like a
"unary minus for the complex part" (although it's a binary operator).

Upon a little further thought, I would want only (+:) to be available
for pattern matching. If the presence of a (-:) operator would upset
the pattern matching, then I'd withdraw the suggestion in any case...

Rob.

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

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

Rob Hubbard scripsit:

> I think that the last here is the wrong result. Could the precedence
> of (+:) be raised? I think that (+:) should bind more tightly even
> than (^) exponentiation, so perhaps it should have the precedence of
> (.) function composition.

+1

> On the subject of (+:), I wondered whether there could be another
> operator (-:) having the meaning "-i*", just as (+:) has meaning
> "+i*". Then rather that this:

This is clever but not really necessary, I think.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

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

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

Hello Albert and all,

Here's what the new complex operators do in Q7.7:

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

    ==> 1 +: (2*3) +: 4
    1+:10

    ==> 1+:2 * 3+:4
    1+:10

I think that the last here is the wrong result. Could the precedence
of (+:) be raised? I think that (+:) should bind more tightly even
than (^) exponentiation, so perhaps it should have the precedence of
(.) function composition.

On the subject of (+:), I wondered whether there could be another
operator (-:) having the meaning "-i*", just as (+:) has meaning
"+i*". Then rather that this:

    ==> 5 - sqrt (-16)
    5.0 +: -4.0

the result would be

    ==> 5 - sqrt (-16)
    5.0-:4.0

which looks closer to "5.0 - i 4.0", and is I think prettier.

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

Thanks,
Rob.

[q-lang-users] Views and Virtual Constructors

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

Hello Albert,

[This is not urgent -- it's just a question out of curiosity.]

Suppose I wish to have two separate virtual constructor sets for my
own type. As an artificial example, here's a type MyList that behaves
just like a 'Q' list:

	public type MyList
			= virtual mylist_cons Head Tail, mylist_nil
			| virtual mylist_join Left Right, mylist_singleton Elt
			| private const mylist List;

	mylist_nil = mylist [];
	mylist_cons Head (mylist Tail) = mylist [Head | Tail];

	mylist_join (mylist Left) (mylist Right) = mylist (Left ++ Right);
	mylist_singleton Elt = mylist [Elt];

	view (mylist []) = 'mylist_nil;

	view (mylist [Head | Tail]) = '(mylist_cons Head Tail)
		where Tail = mylist Tail;

	view (mylist [Elt]) = '(mylist_singleton Elt);

	view (mylist Elts:List) = '(mylist_join Left Right)
		where Left = (mylist (take N Elts)), Right = (mylist (drop N Elts))
		where N = (#Elts) div 2;

Suppose I have a list

	==> def L = mylist [1,2,3,4]

I'd like to perform pattern matching like this:

	==> def (mylist_cons H T) = L; H; T
	1
	mylist_cons 2 (mylist_cons 3 (mylist_cons 4 mylist_nil))

or like this:

	==> def (mylist_join X Y) = L; X; Y
	mylist_cons 1 (mylist_cons 2 mylist_nil)
	mylist_cons 3 (mylist_cons 4 mylist_nil)

The trouble is: the latter of these does not work because the second
view definition 'hides' the third and fourth, in that the match will
always succeed if it reaches the second.

Do you know of a way around this please?

That is, is there a way for 'overlapping' views to be defined for use
by the new pattern matching feature on virtual constructors?

(I imagine not.)

Thanks,
Rob.

Re: [q-lang-users] Q tutorial

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

Keith Trenton wrote:
> OTOH, I think that your writing style "under sells" Q (in comparison to the "marketing efforts" seen from many scripting languages), but this is strictly a matter of opinion. In any event, *modesty* has its own charms!

Occupational disease, I guess. -- If I read something that's all
sunshine and glowing results, I'm always skeptical. ;-)

But if you find some formulations that are overly cautious then please
let me know, so that I can massage them a little.

I've just uploaded v0.4, for which I already processed most of John's
remarks; maybe not quite the final version yet, but the deltas are
getting smaller.

http://downloads.sourceforge.net/q-lang/qnutshell-0.4.pdf?download

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] Q tutorial

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

Keith Trenton wrote:
> Hmmm... Could we please hold off on mirroring this tutorial until version 0.5 (or higher)?

Yes sure, no hurry.

> ...and give your ever so human* proofreaders a little more time to help polish what is proving to be one tasty apple.

I'm currently processing a big batch of corrections from John, so take
your time. I'll upload v0.4 asap.

> PS: Did you purge the reference to CLOS from the tutorial? That was not my intention, but I stand by my opinion (which was made partly in jest ;-).

Yup. There's already enough stuff in the "Future Work" section to keep
me busy the next couple of years. ;-)

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] Q tutorial

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

 
Hello Albert -- 

--- Albert Graef <Dr....@t-...> writes:
- Hmm, maybe some of the folks over at LtU
- might be interested in this as well?

Hmmm... Could we please hold off on mirroring this tutorial until version 0.5 (or higher)?

...and give your ever so human* proofreaders a little more time to help polish what is proving to be one tasty apple.

TIA! :-D

*bound by the constraints of our local spacetime, aka "real life" ;-)

Cheers,
Keith 

PS: Did you purge the reference to CLOS from the tutorial? That was not my intention, but I stand by my opinion (which was made partly in jest ;-).

PPS: What I meant in my earlier email (wrt. CLOS) was that many people consider CLOS as something "cobbled together and the bolted on" to Lisp.
 

Re: [q-lang-users] Q tutorial

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

 
Hello Albert -- 

--- Albert Graef <Dr....@t-...> writes:
- Thanks to all who mailed corrections (yes, Keith, I mean you ;-).

You're welcome! =)

I failed to find any new items worth commenting on after my last email. OTOH, I think that your writing style "under sells" Q (in comparison to the "marketing efforts" seen from many scripting languages), but this is strictly a matter of opinion. In any event, *modesty* has its own charms!

--- Albert Graef <Dr....@t-...> writes:
- Ok, I just uploaded version 0.3 of the tutorial.

More meat for the grinder... ;-D  I'll have another go at it!

Cheers,
Keith