q-lang-users

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

Tim Haynes wrote:
> It might be that we have more folks
> coming with significant Haskell experience, in which case that's a
> non-issue.

Yes, I think that most ppl interested in trying out Q will already have 
seen a subset of, say, Lisp, ML, Haskell or Prolog, so they will have a 
broader perspective and will not complain if syntactic things are not 
like in C.

> So on average, I'm still 50-50 about it. :)

So how would you vote when you'd be forced to pick one of the 
alternatives? :)

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

[q-lang-users] Improper tuples and user-defined operators

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

Albert Graef scripsit:

> "Improper" tuples are vital in symbolic computations, e.g., you will 
> often find them as a pattern in lambdas or "case" constructs. Redefining 
> this syntax to something else would thus not only raise orthogonality 
> concerns, it would also kill Q's reflective capabilities.

Ah, quite so.  I wasn't thinking about patterns, where improper tuples are
clearly useful.  It still leaves me with the problem of how to map them
to Scheme, however.  Probably as a list whose first element is "q-tuple".

Another point: it would be useful to me to have a qint.h function that
reports which symbols are operators and which are not, so that when the
Scheme user writes "(q-call over 1 2)" I can pass the symbol "(over)"
rather than "over" to the qmkapp() function.  Probably the Right Thing
is to return the precedence level, for the benefit of someone trying
to reconstruct the infix representation, or 0 if the symbol is not
an operator.

-- 
John Cowan  co...@cc...   http://ccil.org/~cowan
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."

Re: [q-lang-users] Improper tuples and user-defined operators

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

John Cowan wrote:
> Another point: it would be useful to me to have a qint.h function that
> reports which symbols are operators and which are not, so that when the
> Scheme user writes "(q-call over 1 2)" I can pass the symbol "(over)"
> rather than "over" to the qmkapp() function.  Probably the Right Thing
> is to return the precedence level, for the benefit of someone trying
> to reconstruct the infix representation, or 0 if the symbol is not
> an operator.

Ok, I've put that on my TODO list for 7.2 final.

-- 
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] Improper tuples and user-defined operators

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

John Cowan wrote:
> Another point: it would be useful to me to have a qint.h function that
> reports which symbols are operators and which are not [...]

Hi John, this is in cvs now. The function is called qsymprec() and 
returns -1 for an ordinary function symbol, and the precedence level in 
the range 0..9 for an operator symbol.

I've worked through my TODO list for Q 7.2 now, so expect a second 
release candidate later tonight.

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 7.2 RC1 Issue 2: Notation

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

On 21/06/06, John Cowan <co...@cc...> wrote:
> I'm beginning to wonder if this unparsing is the Right Thing after all:
> it makes it harder to see what is a normal form and what is not.  If you
> type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back
> "1 over 5+2 over 3*i", as if the expression were in fact in normal
> form.  But it's not; the underlying normal form is "complex::complex
> (rational::rat 1 5) (rational::rat 2 3)", which is then effectively
> denormalized for printing purposes.

There is a problem of thinking that an expression has not been
understood, certainly.

Perhaps the system could indicate whether an expression is in normal
form in some other way (perhaps optionally), and provide the normal
form upon request (perhaps through a new function).

However, I think unparsing is a *big* step forward. I really didn't
like seeing the internal representation of a value, and was frustrated
by not being able to do anything about it. I didn't really see the
point of the unparsing stuff until I saw it in action.

Please, please keep the unparsing.

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

Rob Hubbard wrote:
> Please, please keep the unparsing.

I certainly will. :) (See my reply to John's remark in this thread.)

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