q-lang-users

[q-lang-users] Speeding up Q

[Dr L. S. <li...@gm...>]

In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.

Have any of you considered writing a Q -> C translator, which would then compile to native code using a standard (gnu) C compiler?
It seems to me (perhaps naively) a potentially easier and quicker route to a considerable efficiency gain rather than writing fully blown JIT compiler, plus lots of native compilers?

Furthermore, given the simple re-writing nature of Q, writing a translator may prove to be relatively easy?

Libor

Re: [q-lang-users] Speeding up Q

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

Dr Libor Spacek wrote:
> In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.

Did you read my mind? ;-)

Actually, being on vacation right now, I started playing around with
LLVM. In the beginning that was just for fun, but then I began writing a
"tiny demo interpreter" to see how well it works out. Well, actually
it's not quite so tiny any more, after hacking away on it for two weeks,
in some ways it's already much better than Q, with a much cleaner
syntax, a more minimalistic and dynamic design, real closures (local
functions, yay!) and a few other goodies.

The interpreter environment including parser and abstract term rewriting
code generator is already working and I'm currently doing the final
touches on the TR -> LLVM JIT code translator. I'm not ready to unveil
it just yet, but I'll follow up as soon as I have something that can at
least evaluate 1+1 => 2. :)

The language and interpreter are codenamed "Pure" a.k.a. the "Pure
Universal Rewriting Engine", and I do have a preliminary manpage for it,
which I'm attaching as a little teaser. ;-)

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] Speeding up Q

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

Albert Graef wrote:
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)

Oh, and how about a little example program? ;-)

-- 
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] Speeding up Q

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

Albert Graef wrote:
> Oh, and how about a little example program? ;-)

... and the prelude, as it stands now. This actually illustrates the
language much better than the example. (Sorry for the email bombardment,
I should really think twice before pressing "Send".)

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] Speeding up Q

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

I'm looking forward to Pure. Since I have a new 64bit machine and the
amount of work (Institutional Research stuff) has picked up, I've
abandoned Q temporarily. 

One question:
How easy will it be to port the libraries to Pure?

Eddie

On Mon, 2008-03-31 at 13:13 +0200, Albert Graef wrote:
> Dr Libor Spacek wrote:
> > In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.
> 
> Did you read my mind? ;-)
> 
> Actually, being on vacation right now, I started playing around with
> LLVM. In the beginning that was just for fun, but then I began writing a
> "tiny demo interpreter" to see how well it works out. Well, actually
> it's not quite so tiny any more, after hacking away on it for two weeks,
> in some ways it's already much better than Q, with a much cleaner
> syntax, a more minimalistic and dynamic design, real closures (local
> functions, yay!) and a few other goodies.
> 
> The interpreter environment including parser and abstract term rewriting
> code generator is already working and I'm currently doing the final
> touches on the TR -> LLVM JIT code translator. I'm not ready to unveil
> it just yet, but I'll follow up as soon as I have something that can at
> least evaluate 1+1 => 2. :)
> 
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)
> 
> Cheers,
> Albert
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ q-lang-users mailing list q-l...@li... https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Eddie Rucker wrote:
> I'm looking forward to Pure. Since I have a new 64bit machine and the
> amount of work (Institutional Research stuff) has picked up, I've
> abandoned Q temporarily. 

Ugh, sorry to hear that. :( The good news is that Pure should be 64
bit-ready right from the start.

> How easy will it be to port the libraries to Pure?

Well, I guess that it shouldn't be too hard to write an implementation
of libq for Pure so that most existing Q modules could be reused right
away, at least if they do all their expression manipulation through the
official libq interface.

In any case, simple modules implemented in C or C plugins talking to Q
should be fairly easy to port, as you will be able to just link/dlopen
Pure and C modules together and do *direct* Pure<->C calls! :)

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] Speeding up Q

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

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

[snip]
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)

I sense a pun behind that somewhere:

  haskell -> clean
  Q       -> pure  ? ;)

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

Re: [q-lang-users] Speeding up Q

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

Tim Haynes wrote:
> I sense a pun behind that somewhere:
> 
>   haskell -> clean
>   Q       -> pure  ? ;)

So let the rewriting begin (sorry, couldn't resist). But I guess you're
lacking a rewriting rule Clean -> Q somewhere. :)

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] Speeding up Q

[Dr L. S. <li...@gm...>]

Since Tim Haynes mentioned Clean, I would be interested 
to know what you see as the main advantages/differences 
of Pure over Clean?

Libor

Re: [q-lang-users] Speeding up Q

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

Dr Libor Spacek wrote:
> Since Tim Haynes mentioned Clean, I would be interested 
> to know what you see as the main advantages/differences 
> of Pure over Clean?

Well, I probably shouldn't be talking about Pure as if it already
existed (just in case you're wondering if Pure was an April fools joke
after all -- no, it's not!). But my brain is hurting after hours of
coding the LLVM code generator for the pattern-matching automaton, so I
might as well use this as an excuse for a little coffee break. And it
can't hurt to build up some more hype in advance. ;-)

Btw, this might also be a nice read in this context:
http://www.lisperati.com/landoflisp/

Here's a *very* brief rundown of the main features of these languages
(sorry if this comes over as a bit simplistic, but I'm afraid that I
can't go into all the subleties and more esoteric features here):

- Haskell: purely functional (monads for side-effects), lazy
- Clean: dito, but "uniqueness" types for side effects
- ML: impure (allows side-effects), eager (there are lazy versions)

These all belong to the "Hindley-Milner strongly typed" camp, with all
the safety and inconveniences that offers. In addition, with Haskell and
Clean you also have to jump through hoops to get side effects, which is
good for the compiler writer and also greatly facilitates optimization
and auto-parallelization, but is a *big* inconvenience for many
programmers who actually want to *use* those languages for real-world
problems. Moreover, while pervasive laziness seems like a good feature,
it does have its performance penalties and, more importantly, it
sometimes makes it harder to write good programs (space leaks issue).

In contrast, Q and Pure are dynamically typed and allow side-effects
(well, Pure itself is in fact purely functional but it allows "unsafe"
calls into C without any ado), which is more in line with Lisp-like
languages. They also offer Lisp-like reflection capabilities, which is
something where *all* the languages from the strongly typed camp fall
short. In Q, the reflectiveness is limited to expressions, but in Pure
it will be much broader, allowing fully dynamic modifications of the
running program as in Lisp. Q also supports lazy evaluation through its
user-definable special forms (which is kind of like the "futures" in
Alice ML, but the "thunking" is handled automatically). Pure doesn't
have this right now, but it won't be hard to add.

I also think that Pure's syntax is nicer, better than ML's somewhat
complicated definition syntax and Haskell's layout-based block structure
(call me old-fashioned, but free-format languages were invented for good
reasons). But YMMV.

But the biggest difference between all those languages (including Lisp)
and Q/Pure is that the latter are based on general term rewriting rather
than the lambda calculus, which essentially boils down to the simple
feature that there is no distinction between "constructors" and "defined
functions". This might not seem like a big deal, but it makes the
language much more expressive:

1. You can have constructor equations, which is great for expressing
axioms like associativity or idempotence.

2. You can do symbolic calculations involving expressions with free
variables.

3. You can extend the definition of any function or operator to your own
data structures, at any time.

Unless you want to do symbolic algebra, 1 and 2 probably are not much
more than a convenience, but I consider 3 really as a major advantage,
because it gives you much better ad-hoc polymorphism than even Lisp.

Now Haskellers might argue that they have type classes for that, but
you'll have to jump through a lot of hoops to achieve the same kind of
polymorphism, while in Q/Pure it's just there, without even *planning*
for it. To me, that's the most striking advantage of term rewriting as a
programming language. Of course, this comes at a price: In a TR language
the only "argument mismatch" exceptions that you get any more are those
in guards (if the condition doesn't evaluate to a truth value), unless
you explicitly add definitions which throw such exceptions. Whether you
like that pretty much depends on which kind of programmer you are: do
you want a sharp knife, or are you worried about accidentally cutting
your feet off? ;-)

Hope that this clarified the differences a bit.

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] Speeding up Q

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

Dear Albert : 

Would you be so kind as to give a tiny example of a 'constructor' versus a
'defined function' to clarify how they're different in the lambda calculus
but not so in TR?  My memory of lambda is that it's just the following

T ::= x | \x.T | T T  and a reduction rule (\x.T) y ~~> T[y/x] when y not
free in T

So I'm at a bit of a loss to know what you mean by a constructor here. What
did I miss?

Best,
Brian

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Albert
Graef
Sent: Wednesday, April 02, 2008 5:22 AM
To: Discuss the Q language.
Subject: Re: [q-lang-users] Speeding up Q

Dr Libor Spacek wrote:
> Since Tim Haynes mentioned Clean, I would be interested 
> to know what you see as the main advantages/differences 
> of Pure over Clean?

Well, I probably shouldn't be talking about Pure as if it already
existed (just in case you're wondering if Pure was an April fools joke
after all -- no, it's not!). But my brain is hurting after hours of
coding the LLVM code generator for the pattern-matching automaton, so I
might as well use this as an excuse for a little coffee break. And it
can't hurt to build up some more hype in advance. ;-)

Btw, this might also be a nice read in this context:
http://www.lisperati.com/landoflisp/

Here's a *very* brief rundown of the main features of these languages
(sorry if this comes over as a bit simplistic, but I'm afraid that I
can't go into all the subleties and more esoteric features here):

- Haskell: purely functional (monads for side-effects), lazy
- Clean: dito, but "uniqueness" types for side effects
- ML: impure (allows side-effects), eager (there are lazy versions)

These all belong to the "Hindley-Milner strongly typed" camp, with all
the safety and inconveniences that offers. In addition, with Haskell and
Clean you also have to jump through hoops to get side effects, which is
good for the compiler writer and also greatly facilitates optimization
and auto-parallelization, but is a *big* inconvenience for many
programmers who actually want to *use* those languages for real-world
problems. Moreover, while pervasive laziness seems like a good feature,
it does have its performance penalties and, more importantly, it
sometimes makes it harder to write good programs (space leaks issue).

In contrast, Q and Pure are dynamically typed and allow side-effects
(well, Pure itself is in fact purely functional but it allows "unsafe"
calls into C without any ado), which is more in line with Lisp-like
languages. They also offer Lisp-like reflection capabilities, which is
something where *all* the languages from the strongly typed camp fall
short. In Q, the reflectiveness is limited to expressions, but in Pure
it will be much broader, allowing fully dynamic modifications of the
running program as in Lisp. Q also supports lazy evaluation through its
user-definable special forms (which is kind of like the "futures" in
Alice ML, but the "thunking" is handled automatically). Pure doesn't
have this right now, but it won't be hard to add.

I also think that Pure's syntax is nicer, better than ML's somewhat
complicated definition syntax and Haskell's layout-based block structure
(call me old-fashioned, but free-format languages were invented for good
reasons). But YMMV.

But the biggest difference between all those languages (including Lisp)
and Q/Pure is that the latter are based on general term rewriting rather
than the lambda calculus, which essentially boils down to the simple
feature that there is no distinction between "constructors" and "defined
functions". This might not seem like a big deal, but it makes the
language much more expressive:

1. You can have constructor equations, which is great for expressing
axioms like associativity or idempotence.

2. You can do symbolic calculations involving expressions with free
variables.

3. You can extend the definition of any function or operator to your own
data structures, at any time.

Unless you want to do symbolic algebra, 1 and 2 probably are not much
more than a convenience, but I consider 3 really as a major advantage,
because it gives you much better ad-hoc polymorphism than even Lisp.

Now Haskellers might argue that they have type classes for that, but
you'll have to jump through a lot of hoops to achieve the same kind of
polymorphism, while in Q/Pure it's just there, without even *planning*
for it. To me, that's the most striking advantage of term rewriting as a
programming language. Of course, this comes at a price: In a TR language
the only "argument mismatch" exceptions that you get any more are those
in guards (if the condition doesn't evaluate to a truth value), unless
you explicitly add definitions which throw such exceptions. Whether you
like that pretty much depends on which kind of programmer you are: do
you want a sharp knife, or are you worried about accidentally cutting
your feet off? ;-)

Hope that this clarified the differences a bit.

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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Brian Beckman wrote:
> Would you be so kind as to give a tiny example of a 'constructor' versus a
> 'defined function' to clarify how they're different in the lambda calculus
> but not so in TR?  My memory of lambda is that it's just the following

I should have worded that more carefully. Of course, pure lambda
calculus doesn't have constructor symbols (they're emulated using
lambdas), but Haskell, ML et al have them. I was actually talking about
the constructor discipline in pattern-matching definitions in Haskell et
al. In a sense these are just rewriting rules, but there are two
different classes of symbols, the defined functions which occur as head
symbols in the definitions, and the constructor symbols which occur in
the argument patterns. Consequently, in Haskell, ML etc. there's just no
way you can write a rule like

foo (foo x) = x;

expressing the idempotence of a "function" foo, or

Bar (Bar x y) z = Bar x (Bar y z);

for making a binary "constructor" Bar right-associative. But in TR,
these kinds of rules are just normal business.

In a sense, these are all just conveniences. After all, lambda calculus
is as universal as term rewriting and they can easily emulate each
other. But rewriting rules are just *so* much more convenient, otherwise
why would there be pattern-matching in virtually every modern FPL (and
there's even a Lisp dialect which has them)? TR languages go all they
way there, by just abolishing the artificial segregation between
functions and constructors.

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] Speeding up Q

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

I think I see :)  At the risk of being tiresome, I think you're saying that
in something like this in Haskell

data Maybe a = Nothing | Just a

we get a type constructor "Maybe" and a type variable "a" on the left-hand
side, and a pair of data constructors, which are just ordinary functions
(?!) -- on the right-hand side, and "a" gets punned from a type variable on
LHS into an ordinary data-variable of type a on the RHS. At least, that's
how I understand it (perhaps very poorly :) The TYPE constructor, "Maybe,"
is NOT available for Haskell's pattern matching, but the data constructors
are, by design

f :: Num a => Maybe a -> a
f (Just x) = x
f Nothing  = 0

In Q, this distinction doesn't even arise, correct?  And if not, is the
reason that data constructors like "Maybe" don't exist?  And, if so, isn't
the reason simply that a "kinded" type system can't exist in Q or other TRS,
and that type-checking must always be dynamic because and there's only one
KIND of thing (a function) and patterns are perforce just over functions?
Or am I way off?

Apologies for being so far off the deep end :)

 

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Albert
Graef
Sent: Wednesday, April 02, 2008 11:13 AM
To: Discuss the Q language.
Subject: Re: [q-lang-users] Speeding up Q

Brian Beckman wrote:
> Would you be so kind as to give a tiny example of a 'constructor' versus a
> 'defined function' to clarify how they're different in the lambda calculus
> but not so in TR?  My memory of lambda is that it's just the following

I should have worded that more carefully. Of course, pure lambda
calculus doesn't have constructor symbols (they're emulated using
lambdas), but Haskell, ML et al have them. I was actually talking about
the constructor discipline in pattern-matching definitions in Haskell et
al. In a sense these are just rewriting rules, but there are two
different classes of symbols, the defined functions which occur as head
symbols in the definitions, and the constructor symbols which occur in
the argument patterns. Consequently, in Haskell, ML etc. there's just no
way you can write a rule like

foo (foo x) = x;

expressing the idempotence of a "function" foo, or

Bar (Bar x y) z = Bar x (Bar y z);

for making a binary "constructor" Bar right-associative. But in TR,
these kinds of rules are just normal business.

In a sense, these are all just conveniences. After all, lambda calculus
is as universal as term rewriting and they can easily emulate each
other. But rewriting rules are just *so* much more convenient, otherwise
why would there be pattern-matching in virtually every modern FPL (and
there's even a Lisp dialect which has them)? TR languages go all they
way there, by just abolishing the artificial segregation between
functions and constructors.

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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Oh, I think I see even more clearly, now. The data constructors "Just" and
"Nothing" are not quite ordinary functions ... they're a special kind of
function that is permitted -- by special rules -- to participate in pattern
matching.  But in TRs, any function is permitted in the pattern position
because there's just one kind of function.  Right?

It always seems right to me to reduce the number of special cases.

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Brian
Beckman
Sent: Wednesday, April 02, 2008 5:45 PM
To: 'Discuss the Q language.'
Subject: Re: [q-lang-users] Speeding up Q

I think I see :)  At the risk of being tiresome, I think you're saying that
in something like this in Haskell

data Maybe a = Nothing | Just a

we get a type constructor "Maybe" and a type variable "a" on the left-hand
side, and a pair of data constructors, which are just ordinary functions
(?!) -- on the right-hand side, and "a" gets punned from a type variable on
LHS into an ordinary data-variable of type a on the RHS. At least, that's
how I understand it (perhaps very poorly :) The TYPE constructor, "Maybe,"
is NOT available for Haskell's pattern matching, but the data constructors
are, by design

f :: Num a => Maybe a -> a
f (Just x) = x
f Nothing  = 0

In Q, this distinction doesn't even arise, correct?  And if not, is the
reason that data constructors like "Maybe" don't exist?  And, if so, isn't
the reason simply that a "kinded" type system can't exist in Q or other TRS,
and that type-checking must always be dynamic because and there's only one
KIND of thing (a function) and patterns are perforce just over functions?
Or am I way off?

Apologies for being so far off the deep end :)

 

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Albert
Graef
Sent: Wednesday, April 02, 2008 11:13 AM
To: Discuss the Q language.
Subject: Re: [q-lang-users] Speeding up Q

Brian Beckman wrote:
> Would you be so kind as to give a tiny example of a 'constructor' versus a
> 'defined function' to clarify how they're different in the lambda calculus
> but not so in TR?  My memory of lambda is that it's just the following

I should have worded that more carefully. Of course, pure lambda
calculus doesn't have constructor symbols (they're emulated using
lambdas), but Haskell, ML et al have them. I was actually talking about
the constructor discipline in pattern-matching definitions in Haskell et
al. In a sense these are just rewriting rules, but there are two
different classes of symbols, the defined functions which occur as head
symbols in the definitions, and the constructor symbols which occur in
the argument patterns. Consequently, in Haskell, ML etc. there's just no
way you can write a rule like

foo (foo x) = x;

expressing the idempotence of a "function" foo, or

Bar (Bar x y) z = Bar x (Bar y z);

for making a binary "constructor" Bar right-associative. But in TR,
these kinds of rules are just normal business.

In a sense, these are all just conveniences. After all, lambda calculus
is as universal as term rewriting and they can easily emulate each
other. But rewriting rules are just *so* much more convenient, otherwise
why would there be pattern-matching in virtually every modern FPL (and
there's even a Lisp dialect which has them)? TR languages go all they
way there, by just abolishing the artificial segregation between
functions and constructors.

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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Brian Beckman wrote:
> Oh, I think I see even more clearly, now. The data constructors "Just" and
> "Nothing" are not quite ordinary functions ... they're a special kind of
> function that is permitted -- by special rules -- to participate in pattern
> matching.  But in TRs, any function is permitted in the pattern position
> because there's just one kind of function.  Right?

Right, exactly. Constructors *only* get used in the patterns, and
functions *only* get used in the head position in front of the patterns.
That is what's called the constructor discipline. Of course, you *can*
program like this with TRSes, too (I think that the term "constructor
discipline" actually comes from TRS theory), but it's not required.
TRSes are therefore conceptually much simpler.

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] Speeding up Q

[Libor S. <li...@gm...>]

On Wed, 02 Apr 2008 13:21:43 +0100, Albert Graef <Dr....@t-...> wrote:

> ..... Whether you
> like that pretty much depends on which kind of programmer you are: do
> you want a sharp knife, or are you worried about accidentally cutting
> your feet off? ;-)
>
> Hope that this clarified the differences a bit.
>
> Cheers,
> Albert

Albert,

Thank you for that clear answer! Now I am even more looking forward to trying out Pure. I was never one of those who believe that sharp knives should be banned. That kind of thinking leads to "Hello World!" program in "only" two pages of J... code ;-)

It is often argued that safety is important. In my view, however, those who can program don't need it and those who cannot program only make more mistakes the longer the program is and should be doing something else anyway. 

Libor

Re: [q-lang-users] Speeding up Q

[Libor S. <li...@gm...>]

On Wed, 02 Apr 2008 13:21:43 +0100, Albert Graef <Dr....@t-...> wrote:

> Btw, this might also be a nice read in this context:
> http://www.lisperati.com/landoflisp/

Wonderful cartoon. I loved that "Hidley Milner Type Checker"!
Holy awesomeness!!! :)

Re: [q-lang-users] Speeding up Q

[Libor S. <li...@gm...>]

On Wed, 02 Apr 2008 13:21:43 +0100, Albert Graef <Dr....@t-...> wrote:

> But the biggest difference between all those languages (including Lisp)
> and Q/Pure is that the latter are based on general term rewriting rather
> than the lambda calculus, which essentially boils down to the simple
> feature that there is no distinction between "constructors" and "defined
> functions". 

This is my take on this. Any comments?

Functors (identifiers of defined functions), operators, and constructors are essentially one and the same thing.  After all, we could define new operators by functions ever since Algol68 and there was equivalence between constructors and functors since Prolog .(A,B) = [A,B]. 

So I think you are doing the right and natural thing to acknowledge this and to incorporate it onto your language design by essentially removing those unnecessary distinctions from the matcher requirements as well. At least this is how I understand your 
main point.

Now here is a new idea: 

At the moment, you write (in Q or Pure): square X = X*X;

Suppose that we remove the requirement that any functor/operator/constructor be present on the L.H.S. as well? So now we can, whenever we want to, turn this into an anonymous function (lambda expression):
 X = X*X;
by simply omitting the functor (and possibly using -> instead of =). 
Simply written as any other rule with the = sign, it would become a macro, in this case a dangerously recursive one. However, there is use for ordinary text replacement macros of similar forms.

You could then also write this: var Square = (X = X*X); without the lambda and dot syntactical baggage.
Square is now a function variable, which can be applied simply as: Square X

I like this because it makes very clear and obvious the comparison between the constant function definition square and the
variable function definition Square. Notice that they were both initialised with exactly the same expression/value/R.H.S., the only
difference being that one is a constant and the other is a variable holding the same value.

I know, most of this is just "reinventing" lambda calculus but, at the very least, I think my suggestion could lead to a neater syntax, getting rid of the pesky \ and . which had me puzzled when I first saw them. I had no idea what they were until I was told somewhere deep down the manual, that \ stands for lambda.

Libor

Re: [q-lang-users] Pure

[Libor S. <li...@gm...>]

Albert,

How are you getting on with LLVM and Pure?
You went suddenly quiet about it but some of us are still here,
looking forward to an early release of Pure.

Libor

Re: [q-lang-users] Pure

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

Yea, how is everything Albert? 

I've got one more killer week and then I'm going to get to work on the
wrapping GSL. I'll be so glad to have some play time with Q.

Eddie

On Fri, 2008-04-25 at 21:45 +0100, Libor Spacek wrote:
> Albert,
> 
> How are you getting on with LLVM and Pure?
> You went suddenly quiet about it but some of us are still here,
> looking forward to an early release of Pure.
> 
> Libor
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Pure

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

Hi friends,

well, it was quite a bit more work than I expected, but it finally
works! :) And I already have the Pure->C interface, exceptions
(catch/throw) and a considerable part of the system module working
(basic I/O, printf/scanf, glob, regex). Nicely enough, I can write most
of the wrappers in Pure now.

BTW, the present version is some 30-40 times faster than Q on naive fib,
IIRC. I was hoping for more, but it's already 7 times faster than Python
2.4 on the recursive benchmark from the shootout, and it certainly makes
Hugs look very bad; MZ Scheme is still a bit faster, though. So I guess
it's fast enough -- and there's no doubt that the generated code can
still be improved. ;-)

Still working on a few examples, too tired to do a prerelease tonight.
Maybe tomorrow. For the time being, get LLVM 2.2 up and running on your
machines, you'll need it. ;-)

Cheers,
Albert

Eddie Rucker wrote:
> Yea, how is everything Albert? 
> 
> I've got one more killer week and then I'm going to get to work on the
> wrapping GSL. I'll be so glad to have some play time with Q.
> 
> Eddie
> 
> On Fri, 2008-04-25 at 21:45 +0100, Libor Spacek wrote:
>> Albert,
>>
>> How are you getting on with LLVM and Pure?
>> You went suddenly quiet about it but some of us are still here,
>> looking forward to an early release of Pure.
>>
>> Libor

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

[Libor S. <li...@gm...>]

Albert,

It is great to hear about your progress!

I suspect the answer to beating even more languages lies in making your 
matcher as fast as possible, so that it can approach the speed of a fixed
function call that most other languages use.

You probably know a lot more about this but if I was implementing Pure I would
start by converting all operators/functors/constructors to the same internal
representation, such as *(X,Y) instead of X*Y and then have a very efficient
indexing scheme (hashing?) for locating the LHS of the next equation to invoke. 
In this example, I know I only need to look for functor "*" with two arguments.

I have installed Ubuntu 4.08, which was, unexpectedly, a pain in the neck.
It comes with an old version of LLVM available and that installed easily.
Next I will have a go at a manual installation of LLVM 2.2.

Regards, Libor

On Sun, 27 Apr 2008 04:22:22 +0100, Albert Graef <Dr....@t-...> wrote:

> Hi friends,
>
> well, it was quite a bit more work than I expected, but it finally
> works! :) And I already have the Pure->C interface, exceptions
> (catch/throw) and a considerable part of the system module working
> (basic I/O, printf/scanf, glob, regex). Nicely enough, I can write most
> of the wrappers in Pure now.
>
> BTW, the present version is some 30-40 times faster than Q on naive fib,
> IIRC. I was hoping for more, but it's already 7 times faster than Python
> 2.4 on the recursive benchmark from the shootout, and it certainly makes
> Hugs look very bad; MZ Scheme is still a bit faster, though. So I guess
> it's fast enough -- and there's no doubt that the generated code can
> still be improved. ;-)
>
> Still working on a few examples, too tired to do a prerelease tonight.
> Maybe tomorrow. For the time being, get LLVM 2.2 up and running on your
> machines, you'll need it. ;-)
>
> Cheers,
> Albert

Re: [q-lang-users] Pure

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

Hi everybody, and sorry for the latency...

Libor Spacek wrote:
> It is great to hear about your progress!

I have some more news. The Pure project was just approved by the sf.net
staff, so I can now set up a website and source code repository. After
finding and fixing a few more bugs in the compiler today I should be
ready for an initial release tomorrow.

For your bookmarks:
The project page: http://sf.net/projects/pure-lang/
The website will be here once it goes live: http://pure-lang.sf.net/

> I suspect the answer to beating even more languages lies in making your 
> matcher as fast as possible, so that it can approach the speed of a fixed
> function call that most other languages use.

I doubt it. The pattern-matching code is already as good as I can make
it, I challenge you to do any better! ;-) (In fact, the compiler *will*
already compile a call to a definition like foo x = ...; to just a
simple function call.)

AFAICS, if one really wants to get C-like performance, then you have to
avoid boxed values at all costs. Which pretty much means static strong
typing. If you don't believe me, have a look at the recursive benchmark:
http://shootout.alioth.debian.org/debian/benchmark.php?test=recursive&lang=all

(Well, there's a Lisp at an astonishing performance factor of 3.1 there,
but if you take a look at the benchmark code then you'll find that it's
riddled with type annotations.)

Pure is currently around factor 34 (measured against the C benchmark,
with gcc 4.1, -O3 on AMD), and actually I'm quite happy with that. After
all there's more interesting stuff to program than Ackerman and
Fibonacci functions. ;-)

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

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

> I have some more news. The Pure project was just approved by the sf.net
> staff, so I can now set up a website and source code repository. After
> finding and fixing a few more bugs in the compiler today I should be
> ready for an initial release tomorrow.

Ok, a minimal website is now online at http://pure-lang.sf.net/, and
both the SVN repository and the 0.1 release are now available.

I've also set up a mailing list pure-lang-users for discussion (member
posts only) and another one (pure-lang-svn) for SVN commits. You can
subscribe to these here: http://sourceforge.net/mail/?group_id=226193

The pure-lang-svn list may still need a few hours to be created, but
pure-lang-users should be working already, and I will heartily welcome
everyone who joins me 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] Pure

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

Hi Albert,

When I run make, I get the following error:

flex -o lexer.cc lexer.ll
lexer.ll:610: unrecognized rule

Eddie

On Tue, 2008-04-29 at 14:58 +0200, Albert Graef wrote:
> > I have some more news. The Pure project was just approved by the sf.net
> > staff, so I can now set up a website and source code repository. After
> > finding and fixing a few more bugs in the compiler today I should be
> > ready for an initial release tomorrow.
> 
> Ok, a minimal website is now online at http://pure-lang.sf.net/, and
> both the SVN repository and the 0.1 release are now available.
> 
> I've also set up a mailing list pure-lang-users for discussion (member
> posts only) and another one (pure-lang-svn) for SVN commits. You can
> subscribe to these here: http://sourceforge.net/mail/?group_id=226193
> 
> The pure-lang-svn list may still need a few hours to be created, but
> pure-lang-users should be working already, and I will heartily welcome
> everyone who joins me there. ;-)
> 
> Cheers,
> Albert
>