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

Re: [q-lang-users] where

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

Tim Haynes wrote:
> "Rob Hubbard" <hub...@gm...> writes:
> 
>> If you wish to use "let" syntax, then the "let" clause could end in
>> "in" rather than a semi-colon:
> 
> Absolutely! It's one of the few ML-isms I still bother remembering - I
> always read `let' as `let blah... in' in scheme and haskell.
> 
>>     let N = #S - 1 in
>>       strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

Note that the analogy here is purely syntactical. With an ML-style let x
= y in z, y may only depend on variables bound in the context of the let
expression, not on any variable bound inside z.

The more I think about this, the less I like the idea. In lambda
calculus based languages like ML, the scope of a local definition never
extends across multiple function definitions either. Now in term
rewriting the basic unit of definition is not a function definition, but
the equation. (Indeed the term rewriting machinery doesn't even have an
idea what a "function" is. It just rewrites expressions according to the
equations, and function application is just an expression like any other.)

So, while I see the utility of this, it's at least questionable whether
it fits the basic design of the language. And it doesn't seem to be such
a big deal since we already have other means (if-then-else etc.) to
accomplish the same.

You could even define your own let and letrec special forms in terms of
lambda if you really need them. Let would be fairly straightforward,
letrec might be a little challenge, though, because it involves fixed
points. So where are the lambda hackers who want to take up the
challenge? ;-) I think you'll even find some code for "let" in older
versions of the former lambda.q module. And a version of the Y
combinator which works in Q can be found in the fixpt.q example.

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

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

Albert, Rob, Tim:

Ok! No Dr. or Mr. ;) Understood.

I really didn't mean to open a can of worms ;)

This is somewhat related to the topic at hand. I've seen Fortran's
"common," Algol's (scheme, pascal, ada, etc...) block structure, lisp's
dynamic scoping, and global variables. Is there another method of sharing
variables? Someone will probably mention OOP, but I just see it as an
extension of block structure to include functions or procedures. I'm not
intending any one of these as a solution to problem below, I'm just
curious.

Eddie

> foo X = ... Y ... where ... if ...,
>       = ... Y ...,
> where Y = ...;

> But that's awkward to parse, since the entire collection of
> equations
> must be in memory before you can start generating code.

-------------------
>   let T2 = 2*T in
>      let S = T2+1 in
>        f T = sin S
>      //"end let"
>    and also
>      let P = T2-1 in
>        g T = cos P;
>      //"end let"
>    //"end let"

> would still be ambiguous: which "let" does the "and also" match? An
> "end let" would just produce blocks, which Albert has already
> indicated would not be in keeping with Q. It's a problem.

-------------------
> If need be, how about some kind of (= , , , ...)  form for
> constructing a
> scope?
> It's a bit Scheme of me, but hey :)

Re: [q-lang-users] where

[Tim H. <q...@st...>]

"Rob Hubbard" <hub...@gm...> writes:

> If you wish to use "let" syntax, then the "let" clause could end in
> "in" rather than a semi-colon:

Absolutely! It's one of the few ML-isms I still bother remembering - I
always read `let' as `let blah... in' in scheme and haskell.

>     let N = #S - 1 in
>       strip C S = strip C $ sub S 0 (N-1) if (S!N = C);
> 
> that would prevent it looking like a separate definition.
> 
> Further definitions sharing the let clause could be separated by
> something like "and also" (as opposed to "and" or "and then"). I can't
> see a way to provide elegant, "Q-ish" nesting without a terminating
> delimiter for a let clause though. This:
> 
>     let T2 = 2*T in
>       let S = T2+1 in
>         f T = sin S
>       //"end let"
>     and also
>       let P = T2-1 in
>         g T = cos P;
>       //"end let"
>     //"end let"
> 
> would still be ambiguous: which "let" does the "and also" match? An
> "end let" would just produce blocks, which Albert has already
> indicated would not be in keeping with Q. It's a problem.

OK, I've only half been following this, but is there some potential for
using tuples/braces to delimit such a list of local-scope assignments? 
If need be, how about some kind of (= , , , ...)  form for constructing a
scope? 
It's a bit Scheme of me, but hey :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] where

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

If you wish to use "let" syntax, then the "let" clause could end in
"in" rather than a semi-colon:

    let N = #S - 1 in
      strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

that would prevent it looking like a separate definition.

Further definitions sharing the let clause could be separated by
something like "and also" (as opposed to "and" or "and then"). I can't
see a way to provide elegant, "Q-ish" nesting without a terminating
delimiter for a let clause though. This:

    let T2 = 2*T in
      let S = T2+1 in
        f T = sin S
      //"end let"
    and also
      let P = T2-1 in
        g T = cos P;
      //"end let"
    //"end let"

would still be ambiguous: which "let" does the "and also" match? An
"end let" would just produce blocks, which Albert has already
indicated would not be in keeping with Q. It's a problem.

Rob.

PS. It's just "Mr."  :-(  but I'm perfectly happy being referred to as
just "Rob".

Re: [q-lang-users] where

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

Eddie Rucker wrote:
> My thinking was about the use of if then else, cond, and case statements
> and infinite recursion causing a segment fault on Linux.

Understood. But that's a bug that will eventually be fixed. We don't
change the language just to work around bugs in the interpreter. ;-)

> However, the real
> solution to my problem happens to be assert.q. Somehow I overlooked this.
> Shame on me! Bug hunting just got a lot easier.

BTW, the interpreter also has a full-blown symbolic debugger. It needs
some time to get used to it, but it's quite useful. See
http://q-lang.sourceforge.net/qdoc/qdoc_16.html#SEC161

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

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

Eddie Rucker wrote:
> Dr. Graef and (Mr? Dr?) Hubbard,

No need to throw around titles here, we're all friendly people. ;-)

That reminds me of a "Hägar the Horrible" strip in which Hägar asks his
medical doctor, Dr. Zook, whether he is allowed to call him by his first
name. "Yes sure," Dr. Zook replies. "So what's your first name?" asks
Hägar. The reply: "Doctor." :)

Ok, back on topic...

> Of all of the functions in mathematics that I've ever seen, if a "where
> clause" is given at the end of a piecewise function, the variables and/or
> functions denoted by "where" are global to all of the "pieces."

That's true, although some mathematicians (me included) occasionally use
local "where" clauses in branches, too. A syntax which closely mimics
this style could maybe look like this:

foo X = ... Y ... where ... if ...,
      = ... Y ...,
where Y = ...;

But that's awkward to parse, since the entire collection of equations
must be in memory before you can start generating code.

> let N = #S - 1;
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

This looks like the "let" and the following equation(s) are totally
unrelated. Not a good syntax IMHO.

> Another idea, so that wheres are nested:
> 
> f X Y Z
>   where A = ... ; // global to all equations belonging to f
>      = ...;
>      = ...;
>   where B = ... ; // global to all equations below this and belonging to f
>      = ...;
>      = ...;
>   where C = ... where D = ...;
>      = ...;

That's a neat idea, but still not fully general. What if you want A to
be defined only in eqns #1 and #2 and B only in eqns #3 and #4? You need
some kind of block structure to do that. And IMHO block structure looks
messy in equational programs, at least in a free-format language like Q
where you need explicit brackets to indicate the block structure.

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

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

Albert Graef,

My thinking was about the use of if then else, cond, and case statements
and infinite recursion causing a segment fault on Linux. I was thinking
that the global "where" would cut down on some typing. However, the real
solution to my problem happens to be assert.q. Somehow I overlooked this.
Shame on me! Bug hunting just got a lot easier.

Thanks!

Eddie

> Albert Graef wrote:
>> Of course there's an existing solution to this, namely Haskell's
>> guarded
>> equation syntax, but that also looks fairly messy IMHO. Oh well, I
>> guess
>> I'll have to take another look at Miranda to see if Turner already
>> solved that problem.
>
> I just checked that, and AFAICT in Miranda there are no local
> definitions shared by different equations either. Given that most of
> these usage cases can be handled quite conveniently with if-then-else
> and case, I'm not really convinced that we need the proposed extension.
> Other opinions?
>
> 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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] where

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

Dr. Graef and (Mr? Dr?) Hubbard,

Of all of the functions in mathematics that I've ever seen, if a "where
clause" is given at the end of a piecewise function, the variables and/or
functions denoted by "where" are global to all of the "pieces." In Q's
case it is very similar to

f x = cond (Condition1, Expression1 with A;
            Condition2, Expression2 with A;
            Condition3, Expression3 with A;
            ...
            ConditionN, ExpressionN)
      where A = ...;

However, a local "where clause" for each equation is a handy feature of
Q.  In math books and papers, symbols are usually defined with "Assume
..." or "Let ..." and then go on to define a function based on the those
symbols. That is why I put a "letting" statement where I did (Although
Mr. Hubbard's use of where looks better).  Perhaps maybe:

let N = #S - 1;
strip C S = strip C $ sub S 0 (N-1) if (S!N = C);
          = ...

or

This might mess things up since "let N" looks like any other equation.
Making "let" a keyword might be a solution, but, then again, since "let
N" looks like any other equation, it doesn't stand out and might get lost
in larger definitions.

Another idea, so that wheres are nested:

f X Y Z
  where A = ... ; // global to all equations belonging to f
     = ...;
     = ...;
  where B = ... ; // global to all equations below this and belonging to f
     = ...;
     = ...;
  where C = ... where D = ...;
     = ...;



Eddie

> Rob Hubbard wrote:
>> Perhaps the "where" (and even "if" for a common conditional) keywords
>> could be used for the "letting" clauses (assuming the grammar doesn't
>> then become ambiguous, and assuming the language can be extended
>> consistently in this way).
>
> Yes, this could be done. Looks a bit weird, though:
>
> strip C S where N = #S-1
>            = strip C $ sub S 0 (N-1) if (S!N = C);
>            = strip C $ sub S 1 N     if (S!0 = C);
>            = S                       otherwise;
>
> Maybe we can invent a syntax that better mimics the way that
> mathematicians actually write these things?
>
> Also, you might then want to nest those shared definitions. E.g., have
> another shared variable which is only defined for the second and third
> equation. I don't see how this can be done in a free-format language
> without introducing some form of bulky begin ... end brackets.
>
> Of course there's an existing solution to this, namely Haskell's guarded
> equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
> I'll have to take another look at Miranda to see if Turner already
> solved that problem.
>
> --
> 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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] where

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

Albert Graef wrote:
> Of course there's an existing solution to this, namely Haskell's guarded
> equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
> I'll have to take another look at Miranda to see if Turner already
> solved that problem.

I just checked that, and AFAICT in Miranda there are no local
definitions shared by different equations either. Given that most of
these usage cases can be handled quite conveniently with if-then-else
and case, I'm not really convinced that we need the proposed extension.
Other opinions?

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

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

Rob Hubbard wrote:
> Perhaps the "where" (and even "if" for a common conditional) keywords
> could be used for the "letting" clauses (assuming the grammar doesn't
> then become ambiguous, and assuming the language can be extended
> consistently in this way).

Yes, this could be done. Looks a bit weird, though:

strip C S where N = #S-1
           = strip C $ sub S 0 (N-1) if (S!N = C);
           = strip C $ sub S 1 N     if (S!0 = C);
           = S                       otherwise;

Maybe we can invent a syntax that better mimics the way that
mathematicians actually write these things?

Also, you might then want to nest those shared definitions. E.g., have
another shared variable which is only defined for the second and third
equation. I don't see how this can be done in a free-format language
without introducing some form of bulky begin ... end brackets.

Of course there's an existing solution to this, namely Haskell's guarded
equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
I'll have to take another look at Miranda to see if Turner already
solved that problem.

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

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

Perhaps the "where" (and even "if" for a common conditional) keywords
could be used for the "letting" clauses (assuming the grammar doesn't
then become ambiguous, and assuming the language can be extended
consistently in this way).

Rob.

On 09/10/06, Eddie Rucker <ed...@bm...> wrote:
> Thanks Dr. Greaf for giving the reason. I will use case, cond, if then
> else constructs for these situations.
>
> I understand that language decisions can be difficult. Would using a
> "letting" statement as in the following example be bad or ugly? I'm
> starting to be a bit curious about language design but I don't want to
> waste much of your time on this.
>
> example:
>
> strip C "" = "";
> strip C S letting N = #S-1
>            = strip C $ sub S 0 (N-1) if (S!N = C);
>            = strip C $ sub S 1 N     if (S!0 = C);
>            = S                       otherwise;
>
> Eddie
>
> Eddie Rucker wrote:
> > Given the following script
> >
> > // strip character C from the left and right sides of a string
> > strip C "" = "";
> > strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
> >           = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
> >           = S                       otherwise;
> >
> > Is it possible to have another type of local variable defined
> at the end
> > of a list of equations that would apply to all of them?
>
> No. I actually thought about this problem before. As local
> variables are
> maintained on the expression stack, it probably wouldn't be that
> difficult to modify the VM to handle such shared qualifiers (as
> long as
> they share the same left-hand side). But I haven't been able to
> come up
> with a good syntax to support that in the language.
>
> So the solution is indeed to use case or if-then-else in such
> situations
> instead.
>
> 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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

[q-lang-users] where

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

Thanks Dr. Greaf for giving the reason. I will use case, cond, if then
else constructs for these situations.

I understand that language decisions can be difficult. Would using a
"letting" statement as in the following example be bad or ugly? I'm
starting to be a bit curious about language design but I don't want to
waste much of your time on this.

example:

strip C "" = "";
strip C S letting N = #S-1
           = strip C $ sub S 0 (N-1) if (S!N = C);
           = strip C $ sub S 1 N     if (S!0 = C);
           = S                       otherwise;

Eddie

Eddie Rucker wrote:
> Given the following script
>
> // strip character C from the left and right sides of a string
> strip C "" = "";
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
>           = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
>           = S                       otherwise;
>
> Is it possible to have another type of local variable defined
at the end
> of a list of equations that would apply to all of them?

No. I actually thought about this problem before. As local
variables are
maintained on the expression stack, it probably wouldn't be that
difficult to modify the VM to handle such shared qualifiers (as
long as
they share the same left-hand side). But I haven't been able to
come up
with a good syntax to support that in the language.

So the solution is indeed to use case or if-then-else in such
situations
instead.

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

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

Eddie Rucker wrote:
> Given the following script
> 
> // strip character C from the left and right sides of a string
> strip C "" = "";
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
> 	  = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
> 	  = S                       otherwise;
> 
> Is it possible to have another type of local variable defined at the end
> of a list of equations that would apply to all of them?

No. I actually thought about this problem before. As local variables are
maintained on the expression stack, it probably wouldn't be that
difficult to modify the VM to handle such shared qualifiers (as long as
they share the same left-hand side). But I haven't been able to come up
with a good syntax to support that in the language.

So the solution is indeed to use case or if-then-else in such situations
instead.

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

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

Given the following script

// strip character C from the left and right sides of a string
strip C "" = "";
strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
	  = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
	  = S                       otherwise;

Is it possible to have another type of local variable defined at the end
of a list of equations that would apply to all of them? For example, the
"where N = #S-1" is on both lines. This is not a good example, but what
if I have a list five or more equations, the same where clause on each
line seems a waste of typing. I understand that "where" should apply to
the equation that it corresponds to instead of all of them because you
might not want the local variable apply to the other equations in the
list.

I know a where clause could be applied to cond, case, and if then else.

Eddie

Re: [q-lang-users] symbolic algebra system in Q

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

Albert Graef wrote:
> there are good books on the subject

Here is a more recent one which looks very nice and, judging from the
toc, is very thorough and complete.

http://www.amazon.com/Modern-Computer-Algebra-Joachim-Gathen/dp/0521826462

-- 
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] symbolic algebra system in Q

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

Anthony wrote:
> How possible is it to create a symbolic algebra system
> in Q at least to the level of Calculus I,
> differentiation and some simple integration.

Q is no magic bullet for symbolic algebra. It makes simplifying terms
much easier since this is built into the language, but this is only the
basic functionality of a CAS and you still have to implement all the
other symbolic algebra algorithms. All this has been done as open source
before (e.g., http://www-fourier.ujf-grenoble.fr/~parisse/giac.html,
this is by the same guy who also wrote the CAS for the HP 48/49
calculators), and there are good books on the subject (e.g.
http://www.amazon.com/Computational-Algebraic-Theory-Graduate-Mathematics/dp/0387556400).
It's just that someone has to pick up the ball and *do* it. Maybe you
want to give it a try yourself?

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.5 fails build under OpenBSD

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

Julian Fondren wrote:
> clib.c: In function `__F__clib_sys_vars':
> clib.c:1907: error: `ERA' undeclared (first use in
> this function)
> clib.c:1907: error: (Each undeclared identifier is
> reported only once
> clib.c:1907: error: for each function it appears in.)
> clib.c:1908: error: `ERA_D_T_FMT' undeclared (first
> use in this function)
> clib.c:1909: error: `ERA_D_FMT' undeclared (first use
> in this function)
> clib.c:1910: error: `ERA_T_FMT' undeclared (first use
> in this function)
> clib.c:1912: error: `ALT_DIGITS' undeclared (first use
> in this function)
> 
> I've tried to hack around this before, removing two
> instances of those variables, and the result is a
> silent failure later in the build process, running a Q
> program.  So I'd like to solve this properly.

Replacing those constants with a sentinel value in clib.c should do the
trick, i.e., something like:

#ifdef __OpenBSD__ /* or whatever OS-specific constant is defined */
#define ERA (-1)
...
#define ALT_DIGITS (-1)
#endif

(The proper way to do that would be to add some checks for those
constants in configure.in, though.)

If that again leads to the "silent failure" that you mentioned then
please report that here so that I can try to figure it out.

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.5 fails build under OpenBSD

[Julian F. <mip...@ya...>]

I build it with just
  CFLAGS="-L/usr/local/lib -I/usr/local/include -Os
-pipe -mcpu=xscale" ./configure
  gmake

and then the build breaks down;

gmake[4]: Entering directory
`/usr/ports/jul/q-7.5/modules/clib'
if /bin/sh ../../libtool --tag=CC --mode=compile gcc
-I/usr/local/include -L/usr
/local/lib -pipe -Os -DHAVE_CONFIG_H -I. -I. -I../..
-I../../libq -I../../glob -
I../../regex    -g -O2 -MT clib.lo -MD -MP -MF
".deps/clib.Tpo" -c -o clib.lo cl
ib.c; \
then mv -f ".deps/clib.Tpo" ".deps/clib.Plo"; else rm
-f ".deps/clib.Tpo"; exit 
1; fi
mkdir .libs
 gcc -I/usr/local/include -L/usr/local/lib -pipe -Os
-DHAVE_CONFIG_H -I. -I. -I.
./.. -I../../libq -I../../glob -I../../regex -g -O2
-MT clib.lo -MD -MP -MF .dep
s/clib.Tpo -c clib.c  -fPIC -DPIC -o .libs/clib.o
In file included from clib.c:63:
/usr/include/malloc.h:4:2: warning: #warning
"<malloc.h> is obsolete, use <stdli
b.h>"
clib.c: In function `ictowcs':
clib.c:693: warning: passing arg 2 of `libiconv' from
incompatible pointer type
clib.c: In function `icfromwcs':
clib.c:714: warning: passing arg 2 of `libiconv' from
incompatible pointer type
clib.c: In function `__F__clib_sys_vars':
clib.c:1907: error: `ERA' undeclared (first use in
this function)
clib.c:1907: error: (Each undeclared identifier is
reported only once
clib.c:1907: error: for each function it appears in.)
clib.c:1908: error: `ERA_D_T_FMT' undeclared (first
use in this function)
clib.c:1909: error: `ERA_D_FMT' undeclared (first use
in this function)
clib.c:1910: error: `ERA_T_FMT' undeclared (first use
in this function)
clib.c:1912: error: `ALT_DIGITS' undeclared (first use
in this function)
clib.c: In function `__F__clib_iconv':
clib.c:9182: warning: passing arg 2 of `libiconv' from
incompatible pointer type
gmake[4]: *** [clib.lo] Error 1
gmake[4]: Leaving directory
`/usr/ports/jul/q-7.5/modules/clib'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/usr/ports/jul/q-7.5/modules/clib'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/usr/ports/jul/q-7.5/modules'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/jul/q-7.5'
gmake: *** [all] Error 2


I've tried to hack around this before, removing two
instances of those variables, and the result is a
silent failure later in the build process, running a Q
program.  So I'd like to solve this properly.

Any ideas?  Any information you'd like?

Thanks,
Julian Fondren


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[q-lang-users] symbolic algebra system in Q

[Anthony <ad...@ke...>]

A simple question: 

How possible is it to create a symbolic algebra system
in Q at least to the level of Calculus I,
differentiation and some simple integration.

Perhaps some enterprising person can do this for the
next version of Q. 

LOL, and if it's as hard as I think it is, perhaps we
will have peace in the middle east before then.

But I think it would be instructive to see how such a
CAS can be implemented.  

Re: [q-lang-users] Strong examples of Q equational programming wanted

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

Greg Buchholz wrote:
>     Hmm, I don't know if I see what you are saying.  The simplification
> routine is interleaved with the recursive differentiation relation.
> Every time we reconstruct a term, we see if there is a simplification
> that applies.  And I don't think any of the current reconstructions
> require more than one simplification to get rid of the extra 1 and 0
> terms.  Of course, if we tried to implement a fancier CAS this might not
> hold. 

I guess you're right. It's hard to see through all the possible
interactions even between only a handful of rules...

-- 
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] Strong examples of Q equational programming wanted

[Greg B. <gr...@sl...>]

Greg Buchholz wrote:
> 
> Maybe you could provide an example of what you mean?

    OK, I took another look at symbolic.q and above the differentiation
routine there are a few equations like...

  (X+Y)*Z     = X*Z+Y*Z;
  X*(Y+Z)     = X*Y+X*Z;
  
  X+(Y+Z)     = (X+Y)+Z;
  X*(Y*Z)     = (X*Y)*Z;

...In order to implement that, we'd have to add additional (recursive)
relations like...

  simp((X+Y)*Z,A+B) :- simp(X*Z,A),simp(Y*Z,B).
  simp(X*(Y+Z),A+B) :- simp(X*Y,A),simp(X*Z,B).

  simp(X+(Y+Z),A+B) :- simp(X+Y,A), simp(Z,B).
  simp(X*(Y*Z),A*B) :- simp(X*Y,A), simp(Z,B).

...is that what you were hoping to see?  The complete file is at...

    http://sleepingsquirrel.org/lisp/diff.prolog


Greg Buchholz

Re: [q-lang-users] Strong examples of Q equational programming wanted

[Greg B. <gr...@sl...>]

Albert Graef wrote:
> Have you actually tried the Prolog solution? 

    Yes.  But I haven't tested it extensively, so there could be an
error lurking in there.  And the previous program isn't quite as
functional as the Q version, since it doesn't automatically know how to
normalize integer arithmetic, but a couple of extra lines could cure
that...

    simp(X*Y,Z) :- integer(X),integer(Y), Z is X*Y, !.
    simp(X+Y,Z) :- integer(X),integer(Y), Z is X+Y, !.
 
> It looks to me as if those rules only apply to the toplevel terms, so
> some recursive descent would be needed. (In Q this is implicit because
> of the evaluation strategy.)

    Hmm, I don't know if I see what you are saying.  The simplification
routine is interleaved with the recursive differentiation relation.
Every time we reconstruct a term, we see if there is a simplification
that applies.  And I don't think any of the current reconstructions
require more than one simplification to get rid of the extra 1 and 0
terms.  Of course, if we tried to implement a fancier CAS this might not
hold. 

Maybe you could provide an example of what you mean?

Greg Buchholz

Re: [q-lang-users] Bug?

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

John Cowan wrote:
> Chicken does it somehow; I've sent Felix an email asking him to
> explain it.

Thanks, that info would be most helpful.

> Then a garbage collector evicts
> any Scheme objects to the heap and longjmp()s back to start over,
> since all the C call frames are garbage.

I'm afraid that with Q it's not quite the same, as I'd actually have to
catch the C call stack overflow asap and generate a Q exception, and all
this has to be done without thrashing the C stack. But anything would be
better than just bailing out with a segfault...

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] ANNOUNCE: q-lang egg version 1.0 for Chicken Scheme available!

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

Great. :) Downloaded it, will give it a whirl tomorrow.

John Cowan wrote:
> This egg (Chicken Scheme library) makes available the facilities of the
> Q language to Chicken programmers.  Q is an eager functional language
> based on equational term rewriting.

-- 
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] Strong examples of Q equational programming wanted

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

Have you actually tried the Prolog solution? It looks to me as if those
rules only apply to the toplevel terms, so some recursive descent would
be needed. (In Q this is implicit because of the evaluation strategy.)

Greg Buchholz wrote:
> ...and a Prolog solution...
> 
> 
> diff(X,X,1).
> diff(U+V,X,Z) :- diff(U,X,Up), diff(V,X,Vp), simp(Up+Vp,Z),!.
> diff(U*V,X,C) :- diff(U,X,Up), diff(V,X,Vp),
>                  simp(U*Vp,A), simp(V*Up,B), simp(A+B,C),!.
> diff(_,X,0).
> 
> simp(0*X,0).
> simp(X*0,0).
> simp(1*X,X).
> simp(X*1,X).
> simp(0+X,X).
> simp(X+0,X).
> simp(X,X).

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