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

Re: [q-lang-users] Complex numbers

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

Rob Hubbard wrote:
>>unparse (rat P Q) = '(P over Q);
> 
> Should that go into rational.q, or is there a separate location for
> the 'unparse' stuff?

Yes, into rational.q. (In fact it doesn't really matter where that 
equation is, but keeping it with the data type is the most obvious 
choice.) But note that the little example I gave was just to illustrate 
the new custom unparsing scheme. You might consider to do it similarly 
in rational.q when Q 7.2 comes out, though.

> It would be good if the Complex type could follow similarly, and for
> both rectangular and polar coordinates as has been suggested.

Well, my immediate goal is to just change the concrete representation to 
an algebraic type and keep the rest of the interface as it is now, to 
provide as much backward compatibility as possible. Then I'll probably 
do a release candidate so that we can discuss what else needs to be added.

> 'Rat' rather than 'Rational'

No no, Rational is fine. :)

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] Complex numbers

[<bri...@co...>]

long-term suggestion made while strolling down the lane, whistling nonchalantly enjoying the spring flowers and sunshine:

 quaternions and octonians also as algebraic data types, together with the reals and the complexes under the class of the "Normed Algebras."  According to Hurwitz's theorem, these four are the only normed algebras (wishful thinking notwithstanding, there are no hexa-dekonians, or tri-deka-duonians, hexa-deka-tetronions, etc. :)

--
BBeckman http://weblogs.asp.net/brianbec http://data/tesla 
------------------------------------------------------------------------------------ 
| Type inference | Object initializers | Anonymous types | XML CRUD | 
| Extension members | LINQ | Relationships | Nested functions | 
| Nullable of T | Relaxed delegates | Dynamic identifiers | Duck typing | 
| Pattern matching | Contracts | AJAX | Iterators | 
| Continuations | REPL | Join Patterns | Transactions | 
| XML Streams | Code Literals | Morphisms | Embedded DSLs | 
------------------------------------------------------------------------------------

-------------- Original message -------------- 
From: John Cowan <co...@cc...> 

> Albert Graef scripsit: 
> 
> > Also, I'm about to turn complex numbers into an algebraic type now. If 
> > anyone wants to complain, now is your last opportunity. ;-) 
> 
> Excellent. Just let me know when you've settled on the constructors 
> for rationals and rectangular complex numbers, and I'll make sure they 
> get into my Chicken egg appropriately. I've asked Felix for help on 
> the bignum issue. 
> 
> -- 
> 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 
> 
> 
> _______________________________________________ 
> q-lang-users mailing list 
> q-l...@li... 
> https://lists.sourceforge.net/lists/listinfo/q-lang-users 

Re: [q-lang-users] Complex numbers

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

Albert Graef scripsit:

> Also, I'm about to turn complex numbers into an algebraic type now. If 
> anyone wants to complain, now is your last opportunity. ;-)

Excellent.  Just let me know when you've settled on the constructors
for rationals and rectangular complex numbers, and I'll make sure they
get into my Chicken egg appropriately.  I've asked Felix for help on
the bignum issue.

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

Re: [q-lang-users] Memory management in libqint

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

Albert Graef scripsit:

> Oops, not right, it's already there. qexprsym() should be what you need, 
> have you tried it? It returns zero if the argument is not a (function or 
> variable) symbol, and the symbol number otherwise.

I discovered that for myself last night, but was too tired to write
another email.  However, it still doesn't get the actual *name* of the
symbol.

Then it occurred to me that although it's rather heavyweight, once
I know I have a symbol I can use qprint() to return its name.  Likewise,
qmksym() is only useful for creating a qexpr for a well-known symbol;
it returns -1 if the symbol is not known.  So I'll use qparse() to
create a qexpr for a potentially-unknown symbol coming from Scheme.

The only remaining issues are on the Scheme side: how to create a
Scheme bignum from an mpz_t, and what to do about Q foreign objects
on the Scheme side (probably just wrap them in a specialized
Scheme type).

-- 
You're a brave man! Go and break through the            John Cowan
lines, and remember while you're out there              co...@cc...
risking life and limb through shot and shell,           http://ccil.org/~cowan
we'll be in here thinking what a sucker you are!
        --Rufus T. Firefly

Re: [q-lang-users] Release 7.1 Installation Failure

[<lg...@in...>]

Quoting Albert Graef <Dr....@t-...>:

> Larry Gregg wrote:
> > I just downloaded Qpad-7.1.msi  The installation failed with message =
"A
> > network error occurred while attempting to read from the file
> > 'C:\windows\installer\qpad-7.1rc3.msi'".
>
> Hmm, did you install RC3 before? If so, then try removing that version
> before installing the final release, maybe that helps. (That shouldn't
> actually happen, but apparently the "Advanced Installer" freeware that
> I'm using to build the MSIs has its problems with proper versioning.)
>
> HTH,
> 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 mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Yes, I did install RC3 first.  I will uninstall it and then install 7.1.

Thanks,

Larry Gregg

Re: [q-lang-users] Complex numbers

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

On 13/06/06, Albert Graef <Dr....@t-...> wrote:
> type Rat = private const rat P Q;
> public (over) P Q @ (/);
> P:Int over Q:Int = rat (P div D) (Q div D) where D = gcd P Q;
> unparse (rat P Q) = '(P over Q);

Should that go into rational.q, or is there a separate location for
the 'unparse' stuff?

> Also, I'm about to turn complex numbers into an algebraic type now. If
> anyone wants to complain, now is your last opportunity. ;-)

In the Rational code, the construction function rational takes a pair.
For 'deconstruction', I provide
    numerator
    denominator
and in the update I'm preparing, there's now a
    num_den
function returning the numerator and denominator in a pair.

It would be good if the Complex type could follow similarly, and for
both rectangular and polar coordinates as has been suggested.

So:
    public type Complex = private const cplx_rect X Y;

    //rectangular
    complex_rect (X, Y) = cplx_rect X Y; //takes a pair
    //polar
    complex_pol (R, Theta) = cplx_rect (R * cos Theta) (R * sin Theta);

    re (cplx_rect X Y) = X;
    im (cplx_rect X Y) = Y;
    rect (cplx_rect X Y) = (X, Y); //returns a pair

    abs (cplx_rect X Y) = sqrt (X^2 + Y^2);
    arg (cplx_rect X Y) = atan2 Y X;
    pol (cplx_rect X Y) = (abs (cplx_rect X Y), arg (cplx_rect X Y));

This means that, as rational and num_den are inverses; so are
complex_rect and rect, and complex_pol and pol.

I'm not sure about the naming, but I'd like to keep Rational as
consistent as possible with Complex. I'm happy to consider renaming my
symbols if desired (e.g. 'Rat' rather than 'Rational', 'num' rather
than 'numerator', swapping 'rational' with 'rat' to have the shorter
symbol public, num_den as something else,...).

Rob.

Re: [q-lang-users] Release 7.1 Installation Failure

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

Larry Gregg wrote:
> I just downloaded Qpad-7.1.msi  The installation failed with message "A 
> network error occurred while attempting to read from the file 
> 'C:\windows\installer\qpad-7.1rc3.msi'".

Hmm, did you install RC3 before? If so, then try removing that version 
before installing the final release, maybe that helps. (That shouldn't 
actually happen, but apparently the "Advanced Installer" freeware that 
I'm using to build the MSIs has its problems with proper versioning.)

HTH,
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] Complex numbers

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

Errata:

> type Rat = private const rat P Q;

Of course that should read:

public type Rat = private const rat P Q;

> The application to complex.q and rational.q is obvious. But I'm also 
> considering equipping the standard container types with unparsing rules, 
> e.g., the result of dict [(1,2),(3,4)] would then actually be printed as 
> dict [(1,2),(3,4)]. Any objections?

That is, "dict [(1,2),(3,4)]" would be printed instead of "dict::bin 2 
(1,2) dict::nil (dict::bin 1 (3,4) dict::nil dict::nil)". Besides being 
prettier this also serves the purpose of information hiding. Of course 
this kind of custom pretty-printing must be disabled in the debugger.

-- 
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] Complex numbers

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

John Cowan wrote:
> Albert Graef scripsit:
>>unparse (comp_rect X Y) = '(X+Y*i);
> 
> Sounds excellent to me.  Of course, there would be the risk that
> whatever the pretty-printer produced would not in fact parse
> and evaluate to the same thing, but that's the price you pay
> for sharp tools.

I've implemented this (in cvs now) and it works very nicely indeed. 
Here's a little example (Rob, you should find that interesting, too):

type Rat = private const rat P Q;
public (over) P Q @ (/);
P:Int over Q:Int = rat (P div D) (Q div D) where D = gcd P Q;
unparse (rat P Q) = '(P over Q);

==> 2 over 6 // the result is actually rat 1 3, which is unparsed as:
1 over 3

Note how the `over' operator behaves like a constructor (with equations) 
for Rat objects. The real constructor `rat' is never seen outside the 
module where the type is defined and can thus be hidden by making it 
private. Neat, isn't it? :)

The application to complex.q and rational.q is obvious. But I'm also 
considering equipping the standard container types with unparsing rules, 
e.g., the result of dict [(1,2),(3,4)] would then actually be printed as 
dict [(1,2),(3,4)]. Any objections?

Also, I'm about to turn complex numbers into an algebraic type now. If 
anyone wants to complain, now is your last opportunity. ;-)

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] Memory management in libqint

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

John Cowan wrote:
> Albert Graef scripsit:
>>That's right, I just put it on the TODO list for Q 7.2.
> 
> Good.  I'd appreciate it if you can expedite this, as it's a showstopper
> for me.

Oops, not right, it's already there. qexprsym() should be what you need, 
have you tried it? It returns zero if the argument is not a (function or 
variable) symbol, and the symbol number otherwise.

-- 
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] Release 7.1 Installation Failure

[Larry G. <lg...@ac...>]

People:

I just downloaded Qpad-7.1.msi  The installation failed with message "A 
network error occurred while attempting to read from the file 
'C:\windows\installer\qpad-7.1rc3.msi'".

Any help will be appreciated.

Larry Gregg

Re: [q-lang-users] Memory management in libqint

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

Albert Graef scripsit:

> mpz_t x;
> mpz_init(x);
> mpz_set(x, y); // y is the mpz_t to be copied

Thanks.

> Hmm, that's bad. But maybe there's a Lisp function which does this 
> check? I guess that Chicken's FFI lets you eval sexps?

I don't know about calling into Chicken, only out of it, though
I know there is such a capability.

> That's right, I just put it on the TODO list for Q 7.2.

Good.  I'd appreciate it if you can expedite this, as it's a showstopper
for me.

-- 
John Cowan   co...@cc...   http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940

Re: [q-lang-users] Memory management in libqint

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

John Cowan wrote:
> Not only that, but Chicken itself is now available as an egg (if you
> have a Chicken loaded, you can upgrade to a later version by installing
> the egg).  Which leads to a curious philosophical question....

... which was already answered two weeks ago on Slashdot. :)

> Which will involve poking about in the GMP docs to figure out how to
> copy an mpz_t, since Chicken's FFI doesn't provide any help as it does
> with strings.

mpz_t x;
mpz_init(x);
mpz_set(x, y); // y is the mpz_t to be copied

> Unfortunately, the FFI is not aware of whether bignums are available
> or not.

Hmm, that's bad. But maybe there's a Lisp function which does this 
check? I guess that Chicken's FFI lets you eval sexps?

> PROBLEM: there doesn't seem to be a way to convert a qexpr to a symbol
> number, the opposite of mksym.  I had assumed that issym does this, but
> the second argument is of type int, not int*, so it only tests if the
> qexpr is some specific, already-known symbol.  This is good for qistrue
> etc., but not for me.  I need to be able to find out which symbol it is
> so that I can return a corresponding Chicken symbol.

That's right, I just put it on the TODO list for Q 7.2.

-- 
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] Complex numbers

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

John Cowan wrote:
> And likewise "unparse (rat X Y) = '(X/Y)"?

Nope that won't work, because X:Int/Y:Int is a builtin which returns a 
floating point value. (No way to change this any more, this would just 
break too much existing code.) But Rob has a rational division operator 
'over' in his module, so unparsing to '(X over Y) would work in this case.

> [unparsing stuff...]
> Sounds excellent to me.  Of course, there would be the risk that
> whatever the pretty-printer produced would not in fact parse
> and evaluate to the same thing, but that's the price you pay
> for sharp tools.

O.k., I think I'll give it a go. (Actually I wanted to start writing a Q 
yacc in Q this week, but that can wait some more...)

-- 
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] Complex numbers

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

Albert Graef scripsit:

> unparse (comp_rect X Y) = '(X+Y*i);

And likewise "unparse (rat X Y) = '(X/Y)"?

> Of course this goes a long way to handle such simple things like complex 
> or rational numbers. But this feature could be useful for other data 
> types, too, in particular external types. What do you all think about 
> it? Is it "the right thing"?

Sounds excellent to me.  Of course, there would be the risk that
whatever the pretty-printer produced would not in fact parse
and evaluate to the same thing, but that's the price you pay
for sharp tools.

-- 
A few times, I did some exuberant stomping about,       John Cowan
like a hippo auditioning for Riverdance, though         co...@cc...
I stopped when I thought I heard something at           http://ccil.org/~cowan
the far side of the room falling over in rhythm
with my feet.  -- Joseph Zitt

Re: [q-lang-users] Memory management in libqint

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

Albert Graef scripsit:

> Well, if you can check whether that UTF-8 "egg" is loaded (what a funny 
> name for a module ;-) then you can omit the conversion if so.

Not only that, but Chicken itself is now available as an egg (if you
have a Chicken loaded, you can upgrade to a later version by installing
the egg).  Which leads to a curious philosophical question....

> In that case you should be able to check what kind of integer you have 
> in Chicken? Then just pass it as an mpz_t if it already is one (don't 
> forget to copy it since mpz_t objects become owned by Q when you pass 
> them to qmkmpz). 

Which will involve poking about in the GMP docs to figure out how to
copy an mpz_t, since Chicken's FFI doesn't provide any help as it does
with strings.

> When decoding a Q integer, you should convert to the
> smallest type able to represent the number (i.e., first try qisuint [if 
> there's a separate unsigned integer type in Chicken], then qisint and 
> finally qismpz).

Internally, unmodified Chicken has only fixnums (integers in the range
-2^30 to 2^30-1) and flonums.  The Chicken FFI, however, can deal in
longs and unsigned longs, which are converted to fixnums if possible and
flonums if not.  Therefore it does not seem to matter whether I use qisint
or qisuint first: the Chicken value will be the same in either case.

> If the number is only representable as a bignum but the 
> bignum "egg" hasn't been loaded in Chicken, then you must either give up 
> or convert it to something which fits into a machine integer (take the 
> lowest limb or something).

Unfortunately, the FFI is not aware of whether bignums are available
or not.  I'm not sure how to coerce Chicken to believe that an mpz_t
object is really a bignum internally.  If I can't find out or bignums
aren't loaded, I'll have to use ismpz_float and pass that to Chicken.

PROBLEM: there doesn't seem to be a way to convert a qexpr to a symbol
number, the opposite of mksym.  I had assumed that issym does this, but
the second argument is of type int, not int*, so it only tests if the
qexpr is some specific, already-known symbol.  This is good for qistrue
etc., but not for me.  I need to be able to find out which symbol it is
so that I can return a corresponding Chicken symbol.

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
        Sound change operates regularly to produce irregularities;
        analogy operates irregularly to produce regularities.
                --E.H. Sturtevant, ca. 1945, probably at Yale

Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> Is there some particular reason why complex numbers (in complex.q)
> are not a type Complex with a constructor comp_rect?  This
> would be helpful for clean conversion from and to Scheme, and would
> allow the addition of polar complex numbers if someone needs them.

No other than that mathematicians since Euler himself actually think of 
them as points in the complex plane. So pairs of numbers seemed to be 
the most obvious representation to me, at the time (several years ago) I 
wrote this module.

Incidentally, I've discussed this with Rob in private mail a few days 
ago, who reminded me of my own proposal on the ML to change this. I 
didn't get much feedback then, almost one year ago, so I eventually 
didn't bother to make the change. Maybe we can discuss this now and 
settle it once and for all.

I agree that the algebraic type representation has its advantages. It 
would make complex numbers a real type which could be used as a guard 
and which could even become a subtype of Num as it should be. And it 
would also be consistent with Rob's rational number representation, if 
his "Q+Q" module becomes part of the standard library in the future.

The only real problem I see is readability, compare (7,5) to something 
like "comp_rect 7 5". Rob's module has a similar issue (not that there's 
currently much that he can do about it), the rational number X/Y is 
represented as "rat X Y".

Therefore I'm currently considering the idea to provide a hook into the 
expression pretty-printer which would make it possible to define a 
custom unparsing for certain types of objects. (Of course the defined 
unparsing would have to be reparseable so that it can reconstruct the 
original object. Like compiled lambdas unparse into a lambda expression 
in Q 7.1.) Then you could define, say,

unparse (comp_rect X Y) = '(X+Y*i);

and have 'i' defined as complex 0 1 in complex.q, so that X+Y*i would 
actually reconstruct comp_rect X Y. Note that the unparse hook, or 
whatever we'd call this function, would in fact return a quoted term and 
not a string to the pretty-printer. That makes sure that the unparsing 
is at least something that is reparseable, and gives the pretty-printer 
a chance to figure out the proper precedence level for the expression.

Of course this goes a long way to handle such simple things like complex 
or rational numbers. But this feature could be useful for other data 
types, too, in particular external types. What do you all think about 
it? Is it "the right thing"?

> (Of course, it would be even cooler if 2i, which is currently
> the useless application of 2 to i, were syntax sugar for
> "comp_rect 0 2".)

Hmm, didn't we have enough of that syntax candy already with the last 
release? ;-) I'd prefer the X+Y*i notation I suggested above, that's 
almost as tidy and you don't need any special syntax to support that.

Opinions? Other ideas?

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] Memory management in libqint

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

John Cowan wrote:
> Ah, excellent.  Please add this note to the next release of qint.h.

Done (in cvs).

> The only remaining point of doubt is whether the argv array itself
> (as opposed to its strings) in execv(x) belongs to Q.

No, they belong to the caller.

> Chicken is 8-bit by default, but has a UTF-8 egg that changes all
> internal strings to UTF-8.  I'm not sure how to handle this yet;
> I may simply say that the UTF-8 egg is a prerequisite for the Q egg.

Well, if you can check whether that UTF-8 "egg" is loaded (what a funny 
name for a module ;-) then you can omit the conversion if so.

> Bignums are also an issue:  Chicken has none by default but does have
> a "full numeric tower" egg that uses MPZ.  I have to figure out how
> to determine the proper representation of a Chicken number in order
> to pass it to Q properly.

In that case you should be able to check what kind of integer you have 
in Chicken? Then just pass it as an mpz_t if it already is one (don't 
forget to copy it since mpz_t objects become owned by Q when you pass 
them to qmkmpz). When decoding a Q integer, you should convert to the 
smallest type able to represent the number (i.e., first try qisuint [if 
there's a separate unsigned integer type in Chicken], then qisint and 
finally qismpz). If the number is only representable as a bignum but the 
bignum "egg" hasn't been loaded in Chicken, then you must either give up 
or convert it to something which fits into a machine integer (take the 
lowest limb or something).

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] Complex numbers

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

Is there some particular reason why complex numbers (in complex.q)
are not a type Complex with a constructor comp_rect?  This
would be helpful for clean conversion from and to Scheme, and would
allow the addition of polar complex numbers if someone needs them.
The conversion of complex.q should be extremely straightforward.

(Of course, it would be even cooler if 2i, which is currently
the useless application of 2 to i, were syntax sugar for
"comp_rect 0 2".)

-- 
John Cowan      co...@cc...
        "Not to know The Smiths is not to know K.X.U."  --K.X.U.

Re: [q-lang-users] Memory management in libqint

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

Albert Graef scripsit:

> This isn't explicitly mentioned in the qint.h file, but all char* 
> parameters flagged as const belong to the caller and are not modified by 
> the API functions in any way. 

Ah, excellent.  Please add this note to the next release of qint.h.

> This should resolve all the "unknowns" in your list.

The only remaining point of doubt is whether the argv array itself
(as opposed to its strings) in execv(x) belongs to Q.

> You shouldn't have to wrap the unicode helper functions in your Scheme 
> interface, these are just provided as convenience functions to be used 
> if you need to convert/from Q's UTF-8 string encoding when constructing 
> or inspecting string qexprs (if your Scheme dialect has UTF-8 strings 
> then no conversion will be necessary). 

Chicken is 8-bit by default, but has a UTF-8 egg that changes all
internal strings to UTF-8.  I'm not sure how to handle this yet;
I may simply say that the UTF-8 egg is a prerequisite for the Q egg.

Bignums are also an issue:  Chicken has none by default but does have
a "full numeric tower" egg that uses MPZ.  I have to figure out how
to determine the proper representation of a Chicken number in order
to pass it to Q properly.

-- 
It was dreary and wearisome.  Cold clammy winter still held way in this
forsaken country.  The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
        --"The Passage of the Marshes"          http://www.ccil.org/~cowan

Re: [q-lang-users] Memory management in libqint

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

John Cowan wrote:
> The comments in qint.h saying which arguments and results belong to Q
> (that is, the calling application must not free them) and which must
> be freed by the application are incomplete.  For qexprs, I can control
> Q's behavior by using the qnewref, qfreeref, and qdispose functions,
> but for other argument types I need more details.

This isn't explicitly mentioned in the qint.h file, but all char* 
parameters flagged as const belong to the caller and are not modified by 
the API functions in any way. This should resolve all the "unknowns" in 
your list. The only actual error I spotted is here:

> 	qget* family: argument string belongs to Q

No, the strings passed are const char* so they belong to the caller.

> 	Unicode helpers: no information

You shouldn't have to wrap the unicode helper functions in your Scheme 
interface, these are just provided as convenience functions to be used 
if you need to convert/from Q's UTF-8 string encoding when constructing 
or inspecting string qexprs (if your Scheme dialect has UTF-8 strings 
then no conversion will be necessary). Anyway, the const char* args of 
these functions, again, belong to the caller and are not modified, and 
the returned result strings are dynamically allocated and have to be 
freed by the caller (unless, of course, the result string is to be 
passed to qmkstr() and thus becomes owned by the Q interpreter).

HTH,
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] Q 7.1 released

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

The subject line says it all. :) I released Q 7.1 last night and updated 
the website this morning (CEST). Get it while it's hot:

http://q-lang.sourceforge.net/download.html

The release notes are available here (this includes a fairly complete 
list of the changes in this release):

http://sourceforge.net/project/shownotes.php?group_id=96881&release_id=423913

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

[q-lang-users] Memory management in libqint

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

The comments in qint.h saying which arguments and results belong to Q
(that is, the calling application must not free them) and which must
be freed by the application are incomplete.  For qexprs, I can control
Q's behavior by using the qnewref, qfreeref, and qdispose functions,
but for other argument types I need more details.

Here's what I've gleaned so far:

	qstrerror: result string belongs to Q
	qexec* family: no information given, either about the
		string arguments or the vector of strings passed
		to qexecv and qexecvx
	qeval: no information given for string passed, but
		the result string must be freed by the application
	qparse: no information given for string passed
	qprint: the result string must be freed by the application
	qdef: no information given for string passed
	qget* family: argument string belongs to Q
	qmkmpz: mpz_t argument belongs to Q
	qmkstr: string argument belongs to Q
	qmkobj: object argument belongs to Q
	qmklistv: array of qexprs belongs to Q
	qmktuplev: array of qexprs belongs to Q
	qismpz: mpz_t object returned by reference belongs to Q
	qisstr: string returned by reference belongs to Q
	qisobj: object returned by reference belongs to Q
	qistuple: array of qexprs returned by reference
		belongs to Q
	Unicode helpers: no information

I need to know these things in order to correctly program Scheme
finalizers.  Please clarify and correct them.  Thanks.

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    co...@cc...

Re: [q-lang-users] Q 7.1 RC3 available

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

John Cowan wrote:
> First of all, the PDF and HTML manuals available from the home page are
> still 6.2; they should be updated with each release.

Oops, sorry.

Thanks a lot for proofreading, I really appreciate this a lot! 
Corrections are now in cvs, release to follow real soon now. :)

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 7.1 RC3 available

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

Albert Graef scripsit:

> John, I think you said you have some more corrections for the manual, 
> could you please send them to me? Thanks.

These notes reflect the info version distributed in the 7.1rc3 tarball.

First of all, the PDF and HTML manuals available from the home page are
still 6.2; they should be updated with each release.

Global note: "s.t." is another of those mysterious germanophone English
abbreviations unknown to native speakers.  All of them in the manual
should become "so that" except the one in 12.17.3, where "such that"
reads better.

Global note: for "we remark" use simply "note", in the imperative.
There are many instances of this in the manual.  There are also "we
also remark" and "we finally remark" which should be "also note" and
"finally note".

Don't forget to update the discussion of lambdas in 2.2 not to mention
lambda.q and the combinators.

In the discussion of normal forms in 2.4, it is claimed that lists are
always in normal form, whereas of course a list is in normal form iff
its members are: [1+2, 3+4] is not in normal form.

In 3, for "In difference to Prolog" read "Unlike in Prolog".  In "The
reserved words of the Q language are", move "are" to after the
parentheses.

In 4, in "the module identifier is derived automatically as" read simply
"the module identifier is automatically".

In 5, for "The Q language admits" read "The Q language allows", which
is less old-fashioned.  "It is enforced that" is unnatural; use "the
compiler enforces".

In 7.1, for "no such thing like" read "no exact equivalent of" or
something like that.

In 7.3, for "You can count on that" read "You can count on it that".

In 7.4, in "Local definitions also act as additional conditions in that",
omit "in that" and use a semicolon after "conditions".  Immediately after,
for "repeatedly refers" read "refers repeatedly".

In 7.6, for "redices" read "redexes".  ("Redeces" is not unknown, but
"redexes" is definitely the preferred form.)

In 7.7, in "The Q interpreter generates a runtime error in such cases"
for "in such cases" read "if it does not", for clarity.

In 7.10, for "misses an assigment operation" read "lacks an assignment
operation."

I have not reviewed chapters 10-12 or any appendix except C.

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
Objective consideration of contemporary phenomena compel the conclusion
that optimum or inadequate performance in the trend of competitive
activities exhibits no tendency to be commensurate with innate capacity,
but that a considerable element of the unpredictable must invariably be
taken into account. --Ecclesiastes 9:11, Orwell/Brown version