pure-lang-users — Discussion of the Pure programming language.

Re: [pure-lang-users] Numeric Arguments

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

Better still, as there is an internal structure associated with this extended
number representation, we could include a binary "exact" flag that can be 
interrogated by the user at any point to tell them which it is.

Libor

Re: [pure-lang-users] Numeric Arguments

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

Well, yes, Scheme seems to take a step in the right direction.
I notice that even Pure already does one of my listed promotions,
provided math.pure is used: sqrt(-2); 
So perhaps there are no objections to this in principle? ;)

I don't see the point of having a mixed type (1 1/3),
except perhaps for the prettyprinting purposes, if desired.

>  > (sqrt 1/5)
>  0.4472135954999579
>   We don't want and exact approximation to an irrational number do we?
>   Yes, I know that is really a rational number in disguise, but it lets
>   the user know that it really is an approximation instead of letting
>   them believe it is exact.

This is why I suggested that an exception is thrown at such times. 
(The bigint in the rational result will reach its preset "warning" limit 
whenever an irrational is produced.  However, the user
will mostly wish to continue with the calculation on the rational,
not being any worse off than having to switch everything over to
a separate "doubles code" at this point.

Libor

Re: [pure-lang-users] Numeric Arguments

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

Libor Spacek scripsit:

> Also, replace doubles with rationals. (All numbers with limited
> precision are de facto rationals anyway).  For pragmatic reasons place
> some limit on the size of the bigints and raise an exception when it
> is reached.

You really, really don't want to go there.  Operations on machine floats
are fast, as fast as integer math for the same word size, usually.
Dealing with equivalent rationals is very slow because of all the
conditional memory fetches you have to do.

In Scheme, the difference between hopelessly slow and acceptably fast
is often as simple as adding a judicious decimal point to some constant.

-- 
Where the wombat has walked,            John Cowan <co...@cc...>
it will inevitably walk again.          http://www.ccil.org/~cowan

Re: [pure-lang-users] Numeric Arguments

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

On Tue, 2008-07-08 at 15:05 +0100, Libor Spacek wrote:

> OK, fair enough. I was working up to the "mad" idea which is probably too revolutionary and upsetting to everyone.

Sorry, but I don't know enough to be upset ;-)

> The idea is that all the current numeric types become transparent (hidden) to the user. Promotions take place automatically (in the background) whenever a loss of information would otherwise occur, such as:
> and demotions too:

Scheme does some of this except numbers are separated into two groups
"exact" and "inexact." The only explicit conversions required are
between exact and inexact except were it really makes since like (sqrt
5). Demotions of inexact (floating point) to exact is the only thing
missing but for good reason see (sqrt 1/5) below.

Example:
 > (/ 4 3)
 1 1/3
   Note the space between 1 and 1/3. MzScheme returns a mixed number.
 > (/ 4.0 3)
 1.3333333333333333
 > (/ 4 3.0)
 1.3333333333333333
 > (sqrt 4.0) 
 2.0
 > (sqrt 4)
 2
 > (sqrt 4/9)
 2/3
 > (sqrt 1/5)
 0.4472135954999579
  We don't want and exact approximation to an irrational number do we?  
  Yes, I know that is really a rational number in disguise, but it lets 
  the user know that it really is an approximation instead of letting
  them believe it is exact.
 > (expt 4 1/2)
 2
 > (sqrt -4)
 0+2i
 > (expt -4 1/2)
 0+2i
 > (sqrt -4.0)
 0+2.0i
 > (expt
 > (inexact->exact 0.123)
 553942754166571/4503599627370496

e.r.

Re: [pure-lang-users] Numeric Arguments

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

On Tue, 08 Jul 2008 13:18:16 +0100, Albert Graef <Dr....@t-...> wrote:

> A division operator which returns ints only if x divides y? I don't
> think that this is a good idea, as you never know which type is
> returned. The rationale behind / is precisely that you *always* get a
> double result, same with '^'. That's the Algol philosophy and I think
> it's good; I won't change it.
>
> div/mod is another business; as long as they work consistently with the
> integer div/mod and they cover all appropriate cases including rationals
> I'm willing to add the extensions.
>
> Albert
>


OK, fair enough. I was working up to the "mad" idea which is probably too revolutionary and upsetting to everyone.

The idea is that all the current numeric types become transparent (hidden) to the user. Promotions take place automatically (in the background) whenever a loss of information would otherwise occur, such as:

int becoming too big -> bigint
x div y -> rational (if y does not divide x)
sqrt (-2) -> complex

and demotions too:

bigint that fits into an int -> int
rational that simplifies to an int or bigint -> int or bigint
complex with imaginary part == 0 -> real 

The hidden old style type would then be used only for deciding how to present the result. 

Also, replace doubles with rationals. (All numbers with limited precision are de facto rationals anyway).
For pragmatic reasons place some limit on the size of the bigints and raise an exception when it is reached.
I guess to really fly, this would need to be taken up by the processor manufacturers,
to add rational instructions.

The beauty of this scheme is that you could then get away with having just ::number type and nothing else and use only one common code for any calculations, instead of the current, frankly, mess.

Libor

Re: [pure-lang-users] Random

[Jiří S. <jir...@bl...>]

> g++ -g -O2   `llvm-config --cppflags` -c -o runtime.o runtime.cc
> In file included from D:/MinGW/include/windef.h:253,
>                   from D:/MinGW/include/windows.h:48,
>                   from runtime.cc:2518:
> D:/MinGW/include/winnt.h:3002: error: expected unqualified-id before 
> numeric con
> stant
> D:/MinGW/include/winnt.h:3002: error: expected `)' before numeric constant
> make: *** [runtime.o] Error 1
> 


// See http://www.math.keio.ac.jp/~matumoto/emt.html for the original 
sources.

#define N              (624)
#define M              (397)
#define K              (0x9908B0DFU)
#define hiBit(u)       ((u) & 0x80000000U)
#define loBit(u)       ((u) & 0x00000001U)
#define loBits(u)      ((u) & 0x7FFFFFFFU)
#define mixBits(u, v)  (hiBit(u)|loBits(v))



"N" from the above conflicts with "N" from the below (included from 
winnt.h):

typedef struct _IMAGE_SYMBOL {
	union {
		BYTE ShortName[8];
		struct {
			DWORD Short;
			DWORD Long;
		} Name;
		PBYTE LongName[2];
	} N;


Jiri

Re: [pure-lang-users] Random

[Jiří S. <jir...@bl...>]

Albert Graef napsal(a):
  > I added the Mersenne Twister now. See random/srandom in math.pure. Note
> that random returns a 32 bit machine int, so the numbers may be negative.
> 
Many thanks, but i cannot compile now under MinGW:

g++ -g -O2   `llvm-config --cppflags` -c -o runtime.o runtime.cc
In file included from D:/MinGW/include/windef.h:253,
                  from D:/MinGW/include/windows.h:48,
                  from runtime.cc:2518:
D:/MinGW/include/winnt.h:3002: error: expected unqualified-id before 
numeric con
stant
D:/MinGW/include/winnt.h:3002: error: expected `)' before numeric constant
make: *** [runtime.o] Error 1

:-(

Jiri

Re: [pure-lang-users] Patch to compile Pure with LLVM upstream

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

Jir(í Spitz wrote:
> Albert I'll have time to play with it in the evening. For now only one 
> remark. The type annotations improve the execution speed quite a lot, so 
> it is not upright to compare implementations without and with them.

All I can say that I added them to avltree.pure, and they didn't make
much of a difference in the examples I tried. The worst example I saw
was that deleting all 100000 (int) members from a tree took some 9%
longer than with the ::int tags.

-- 
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: [pure-lang-users] Random

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

Albert Graef wrote:
> Hmm, many algorithms in C libraries are crappier than what you'd come up
> with in a minute. How about the Mersenne twister? It's not
> crytographically secure, but otherwise it's very good. I still have an
> implementation of that in the Q codebase, shouldn't take longer than
> five minutes to add it to the library.

I added the Mersenne Twister now. See random/srandom in math.pure. Note
that random returns a 32 bit machine int, so the numbers may be negative.

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: [pure-lang-users] Numeric Arguments

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

On Tue, 2008-07-08 at 09:44 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > A reasonable manner suggests x = (x mod N) + (x div N) * N
> 
> ... where x div N is integer and abs (x mod N) < abs N I guess, with x
> mod N the same sign as x?

Yes.

> That implicit definition should work with any combination of real-valued
> operands (provided that N is nonzero, of course). Division of a complex
> by a real could be lifted from that, but I'm not sure whether we
> actually want it?

Please don't implement the complex stuff. Implementing mathematics
libraries is kind of like boxing, unless you spend a lot of time in the
ring, you are going to get your jaw jacked. In my *very humble opinion*,
if we want to implement anything, that would be mod and div operators
that obey Scheme's R6RS rules as you alluded to below.

> And we need to decide what to do with division by zero. Machine int and
> bigint division both raise a SIGFPE right now (at least on Linux), which
> is a bit inconvenient. ;-) They could be made undefined like in Q. That
> will complicate and slow down the code for machine int division, though;
> right now this is just a single sdiv instruction. Therefore I'd prefer
> to install a signal handler which maps SIGFPE to a corresponding Pure
> exception; that wouldn't incur runtime costs. In any case rational
> division should follow suit (it returns a floating point infinity right
> now). Opinions?

Hmmm. I really don't know. Playing around with computer mathematics is
one thing. Getting it right for the masses is a *monster*. Maybe bring
it up before other language designers and see what they say.

> Then it probably follows R5RS. AFAICT R6RS specifies div and mod (and
> variations) which work with all real (but not with complex) arguments.

It looks like they ditched quotient, remainder, and modulo for new functions div, div0, mod, mod0, div-and-mod, and div0-and-mod0.

I'm not sure I want to vote for anything right now.

e.r.

Re: [pure-lang-users] Numeric Arguments

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

Libor Spacek wrote:
> Oh, you will also need:
> 
> x::bigint ndiv y::double = bigint (x/y)
> 
> but hopefully, the idea is clear?

Yes, sure, but where's the code? :)

If someone is willing to code this and check that it really works (which
also entails writing a unit test), I'm going to add it to the library.

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: [pure-lang-users] Numeric Arguments

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

Libor Spacek wrote:
> I was not really thinking about rationals and complex numbers and anything else yet.

Yes, but at least the rationals have to work, too.

> Here are my defs for ndiv and slash (new /). In practice, you could of course just add
> these extra cases to the existing definitions without using new symbols:

This will have to be so, since I don't want to have more division
operators in the library, unless there's a *really* compelling reason
for them.

> infixl 7 slash;
> x::int slash y::int = x div y if x mod y==0;
> x slash y = x/y;

A division operator which returns ints only if x divides y? I don't
think that this is a good idea, as you never know which type is
returned. The rationale behind / is precisely that you *always* get a
double result, same with '^'. That's the Algol philosophy and I think
it's good; I won't change it.

div/mod is another business; as long as they work consistently with the
integer div/mod and they cover all appropriate cases including rationals
I'm willing to add the extensions.

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: [pure-lang-users] Patch to compile Pure with LLVM upstream

[Jiří S. <jir...@bl...>]

Albert Graef wrote:
> Added (examples/avltree.pure). It's a fairly simplistic implementation,
> but it compiles much faster than set.pure. OTOH, insert and delete take
> about twice as long compared to your implementation, which IIRC is
> consistent with the Q benchmarks that you did earlier. So I really
> wouldn't want to replace your version with it. ;-)
> 
Albert I'll have time to play with it in the evening. For now only one 
remark. The type annotations improve the execution speed quite a lot, so 
it is not upright to compare implementations without and with them.

Jiri

Re: [pure-lang-users] Patch to compile Pure with LLVM upstream

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

Hi Jiri,

Albert Graef wrote:
> Jiri Spitz wrote:
>> Maybe we could try the original Bird/Wadler algo and look at the 
>> compilation/execution speed trade-off.
> 
> Ok, will try that tomorrow.

Added (examples/avltree.pure). It's a fairly simplistic implementation,
but it compiles much faster than set.pure. OTOH, insert and delete take
about twice as long compared to your implementation, which IIRC is
consistent with the Q benchmarks that you did earlier. So I really
wouldn't want to replace your version with it. ;-)

I found that adding special case rules to avltree.pure only yields
marginal improvements (<10%), so you might be able to remove them from
your implementation, too, without taking a major performance hit. That
alone will make your modules load much faster, and there's some other
refactoring that we can do (like checking the balance factor in a guard
instead of matching it on the lhs) that will further reduce the number
of overlapping rules.

> Still the Pure version seems awfully slow given that Pure is supposed to
> run a lot *faster* than Q.

Rubbish, who said that? Oops, that was me. :)

In fact, all operations consistently outperform the corresponding Q
definitions by a factor of 5-7, if they're just plain Q definitions. The
only cases where Q is able to keep up with Pure is when operations are
involved that are actually implemented in C, like creating enumerations
and # on lists. Another factor is that Q has a more compact internal
list representation which makes some of these operations even faster.

For a bytecode interpreter Q indeed performs quite well on this stuff
(compared to the recursive benchmark where it sucks big time), but
that's because these definitions don't *do* much beyond pattern matching
and tree construction. I already mentioned in another thread that
there's still room for improvements in Pure there, in particular
inlining the runtime calls which construct symbol and application nodes
will surely help.

> Hmm, and it gets slower each time I run the
> members function. Something's wrong there. I will have to see whether
> the B/W implementation exhibits the same behaviour.

It's the same with my implementation. Will have to investigate.

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: [pure-lang-users] Numeric Arguments

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

Oh, you will also need:

x::bigint ndiv y::double = bigint (x/y)


but hopefully, the idea is clear?

L.

Re: [pure-lang-users] Numeric Arguments

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

I was not really thinking about rationals and complex numbers and anything else yet.
Just int, bigint and double, so far. Though I expect others could be
extended in the same "permissive" spirit.

Here are my defs for ndiv and slash (new /). In practice, you could of course just add
these extra cases to the existing definitions without using new symbols:

infixl 7 ndiv;
x::double ndiv y = int x div y;
x ndiv y::double = int (x/y);
x ndiv y = x div y;

> list slash
infixl 7 slash;
x::int slash y::int = x div y if x mod y==0;
x slash y = x/y;

I think they might be conformant with Eddie's implicit definition.

Libor


On Tue, 08 Jul 2008 00:29:05 +0100, Albert Graef <Dr....@t-...> wrote:

> Ok, do you have definitions of div and mod for all other cases? Note
> that then we also need definitions for the rational and complex numbers
> in math.pure.
>
> I must admit that I never gave this much thought. Pure inherited div and
> mod from Q which inherited them from Pascal which in turn inherited them
> (I guess) from Algol 60. I'm not against extending them in a reasonable
> manner. :)
>
> Albert
>

Re: [pure-lang-users] Numeric Arguments

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

Eddie Rucker wrote:
> A reasonable manner suggests x = (x mod N) + (x div N) * N

... where x div N is integer and abs (x mod N) < abs N I guess, with x
mod N the same sign as x?

That implicit definition should work with any combination of real-valued
operands (provided that N is nonzero, of course). Division of a complex
by a real could be lifted from that, but I'm not sure whether we
actually want it?

Then there's still the question whether x div n should be the same type
as x or n. x mod n is of course the same type as x.

And we need to decide what to do with division by zero. Machine int and
bigint division both raise a SIGFPE right now (at least on Linux), which
is a bit inconvenient. ;-) They could be made undefined like in Q. That
will complicate and slow down the code for machine int division, though;
right now this is just a single sdiv instruction. Therefore I'd prefer
to install a signal handler which maps SIGFPE to a corresponding Pure
exception; that wouldn't incur runtime costs. In any case rational
division should follow suit (it returns a floating point infinity right
now). Opinions?

> By the way, I noticed my MzScheme only accepts integers for both the
> modulo and remainder functions.

Then it probably follows R5RS. AFAICT R6RS specifies div and mod (and
variations) which work with all real (but not with complex) arguments.

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: [pure-lang-users] Patch to compile Pure with LLVM upstream

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

Jiri Spitz wrote:
> Maybe we could try the original Bird/Wadler algo and look at the 
> compilation/execution speed trade-off.

Ok, will try that tomorrow.

> Most operation with dict run some 5 times faster 
> with Pure than with Q but the members operation runs about 10 times 
> slower with Pure than with Q.

10 times *slower*?? I don't have this over here.

> let d = dict $ zipwith (=>) (1..100000) (1..100000);
> stats
> #members d;
100000
0.86s

==> def D = dict $ zip [1..100000] [1..100000]

==> #members D; stats
100000
0.81 secs, 300002 reductions, 265536 cells

Still the Pure version seems awfully slow given that Pure is supposed to
run a lot *faster* than Q. Hmm, and it gets slower each time I run the
members function. Something's wrong there. I will have to see whether
the B/W implementation exhibits the same behaviour.

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: [pure-lang-users] Numeric Arguments

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

On Tue, 2008-07-08 at 01:29 +0200, Albert Graef wrote:

> Ok, do you have definitions of div and mod for all other cases? Note
> that then we also need definitions for the rational and complex numbers
> in math.pure.
> 
> I must admit that I never gave this much thought. Pure inherited div and
> mod from Q which inherited them from Pascal which in turn inherited them
> (I guess) from Algol 60. I'm not against extending them in a reasonable
> manner. :)

A reasonable manner suggests x = (x mod N) + (x div N) * N. I didn't
make this up.

By the way, I noticed my MzScheme only accepts integers for both the
modulo and remainder functions.

e.r.

Re: [pure-lang-users] Numeric Arguments

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

Libor Spacek wrote:
> Both to accept all types of numerical arguments.

Ok, do you have definitions of div and mod for all other cases? Note
that then we also need definitions for the rational and complex numbers
in math.pure.

I must admit that I never gave this much thought. Pure inherited div and
mod from Q which inherited them from Pascal which in turn inherited them
(I guess) from Algol 60. I'm not against extending them in a reasonable
manner. :)

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: [pure-lang-users] Numeric Arguments

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

On Mon, 2008-07-07 at 23:50 +0100, Libor Spacek wrote:
> Eddie, you are right that C's fmod is different.
> What I was after was just "double mod int" which seems pretty innocuous
> to me. I have defined it myself and it saved me lots of lines of repetitious
> might also benefit from its addition.

Ok. In this case it seems logical to convert the int parameter to double
and use fmod to me.

e.r.

Re: [pure-lang-users] Patch to compile Pure with LLVM upstream

[Jiri S. <jir...@bl...>]

Albert Graef wrote:
> So the new builder class isn't any faster, that's bad news. :(
> 
> Jiri, I think we might have to work around this for a while. I'll have a
> look at those babies tomorrow and see how I can massage some of the
> definitions so that the matching automata don't get that big.
> 
Maybe we could try the original Bird/Wadler algo and look at the 
compilation/execution speed trade-off. The executions speed in Pure vs. 
Q is often inscrutable. Most operation with dict run some 5 times faster 
with Pure than with Q but the members operation runs about 10 times 
slower with Pure than with Q. Maybe the difference between that two 
implementations of AVLT will not be that big as with Q and the 
compilation will be surely much faster.

Jiri

Re: [pure-lang-users] Patch to compile Pure with LLVM upstream

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

Rooslan S. Khayrov wrote:
> Uh, no. (Unfortunately I don't have time to closely follow Pure
> development, but Q loveliness made me to try out its successor :-) )

Once you tried it there's no going back. ;-) No, seriously, if you give
it a whirl, let me know what you think.

> So, real compilation time for sets and dict is 3-4 secs, contrary to
> 1-1.5 for other modules.

So the new builder class isn't any faster, that's bad news. :(

Jiri, I think we might have to work around this for a while. I'll have a
look at those babies tomorrow and see how I can massage some of the
definitions so that the matching automata don't get that big.

Good night,
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: [pure-lang-users] Numeric Arguments

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

Eddie, you are right that C's fmod is different.
What I was after was just "double mod int" which seems pretty innocuous
to me. I have defined it myself and it saved me lots of lines of repetitious
code to duplicate everything for ::int and ::double, so I thought others
might also benefit from its addition.

I note what Albert had to say on the matter and it is OK by me.
It is no big deal, I can live with my own definition if it is not added.

Albert did mention div which is a similar beast. 
Various misguided historical precedents notwithstanding, 
I would prefer the following behaviour:

Both to accept all types of numerical arguments.
div to "narrow" ie. if either argument is an int, return int
/ to "widen", ie. if either argument is a double, return double

This is more forgiving and consistent, therefore imho more in the "pure" spirit.
However, I guess ultimately it is just a personal preference.

L.


On Mon, 07 Jul 2008 22:20:35 +0100, Eddie Rucker <er...@bm...> wrote:

>> > // mod of a double
>> > x::double mod y::int = (x - intx) + (intx mod y) when intx = (int x) end;
>>
>> If memory serves me, Common Lisp has this, but not any Algol-like
>> language I know. I can add it to math.pure if there's enough demand.
>
> I've had to deal with this once in Pascal somewhere before but I cant
> recall. In that occasion I found that mod(double, double) may be defined
> in two ways in order to stay consistent with something else ... Dang I
> can't find it on google.
>
> I don't know if you should add "double mod double" to the list or not
> but I sure would hate to have to look it up again. If memory servers me
> (probably doesn't) C's definition of fmod really should be called frem
> instead because there is a difference between real mod and real
> remainder. I guess I better shut up now before I stick my foot in my
> mouth.
>
> e.r.
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> pure-lang-users mailing list
> pur...@li...
> https://lists.sourceforge.net/lists/listinfo/pure-lang-users
> 

Re: [pure-lang-users] Patch to compile Pure with LLVM upstream

[Rooslan S. K. <kh...@gm...>]

Albert Graef wrote:

> Did you run these with -i? Otherwise the interpreter is not really
> compiling anything (it's all done lazily).

Uh, no. (Unfortunately I don't have time to closely follow Pure
development, but Q loveliness made me to try out its successor :-) )

So, real compilation time for sets and dict is 3-4 secs, contrary to
1-1.5 for other modules.

-- 
Best regards,
Rooslan