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

Re: [pure-lang-users] Numeric Arguments

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

Albert Graef scripsit:

> (In Q realvalp requires that the 
> imaginary part is an exact zero, which would be rather inconvenient in 
> Pure because that rules out most complex values in polar representation.)

The problem is that floating-point underflow gives 0 silently, so a result
can become real when mathematically it should not.  Is polar representation
a major consideration in Pure?  I don't know any language supporting
complex numbers where it is.

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

Re: [pure-lang-users] C float

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

Albert Graef wrote:
> uint x::int = if x>=0 then bigint x else x+0x100000000L;
> [...]
> Maybe I should add those definitions to primitives.pure?

Done.

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

Albert Graef wrote:
> Eddie Rucker wrote:
>>   > rationalp 1;
>>   0
>>
>> Oops, Albert 1 is a rational number, so I think rationalp has a bug?
> 
> No, I only implemented the syntactic number predicates so far, still
> have to add the semantic ones.

These are implemented now. (Mostly untested so far.) They should work 
the same as in Q, except that realvalp considers any complex value with 
zero imaginary part a real value. (In Q realvalp requires that the 
imaginary part is an exact zero, which would be rather inconvenient in 
Pure because that rules out most complex values in polar representation.)

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] C float

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

Eddie Rucker wrote:
> Does FLW mean Famous Last Words?

Right. :) That's why I want to do those tests...

-- 
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] C float

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

Does FLW mean Famous Last Words?

e.r.

On Wed 13/08/08  5:41 PM , Albert Graef Dr....@t-... sent:
> Eddie Rucker wrote:
> > Maybe. My concern was mostly the parameters to a
> C function in a library> where one of the arguments was an unsigned
> int.
> Just pretend that it's an int in the extern declaration. That should 
> just work (FLW), even if you pass it a bigint (which gives you the 
> necessary range to represent all unsigned int values).
> 
> I'll write some test programs later this week to verify that the C 
> interface does the right thing in all these cases.
> 
> > I don't know maybe I shouldn't be so
> concerned.
> "Don't worry, be happy." :)
> 
> Albert (still in vacation mode, obviously ;-)
> 
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr.Graef
> @t-online.de, ag...@mu...WWW:    http://www.musikinformatik.uni-mainz.de/ag
> 
> 

 

Re: [pure-lang-users] C float

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

Eddie Rucker wrote:
> Maybe. My concern was mostly the parameters to a C function in a library
> where one of the arguments was an unsigned int.

Just pretend that it's an int in the extern declaration. That should 
just work (FLW), even if you pass it a bigint (which gives you the 
necessary range to represent all unsigned int values).

I'll write some test programs later this week to verify that the C 
interface does the right thing in all these cases.

> I don't know maybe I shouldn't be so concerned.

"Don't worry, be happy." :)

Albert (still in vacation mode, obviously ;-)

-- 
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] C float

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

On Wed, 2008-08-13 at 23:34 +0200, Albert Graef wrote:

> Under all circumstances, the C interface should behave as if the C int 
> type is "cast" to the Pure int type and vice versa (using truncation and 
> sign extension as necessary), if that's not the case then please report 
> it and I will fix it. I think that this is the most reasonable way to 
> implement the marshalling of C ints considering the limited repertoire 
> of integer types available in Pure.

I don't know yet. If it doesn't cause any problems then we should leave it alone.

> Of course, this means that a C unsigned int return value will become 
> negative in Pure if it's big enough. But that can be easily undone with 
> the following little Pure function which takes a Pure int x and returns 
> a bigint equal to (unsigned)x in C:
> 
> uint x::int = if x>=0 then bigint x else x+0x100000000L;
> 
> This carries over to unsigned 8, 16 and 64 bit ints accordingly:
> 
> ubyte x::int = if x>=0 then x else x+0x100;
> ushort x::int = if x>=0 then x else x+0x10000;
> ulong x::bigint = if x>=0 then x else x+0x10000000000000000L;
> 
> These always use the smallest Pure int type capable of holding the 
> result: int for ubyte and ushort, bigint for uint and ulong. (Note that 
> in the case of 64 bit values the C interface returns a bigint, that's 
> why ulong takes a bigint parameter.)
> 
> Maybe I should add those definitions to primitives.pure?

Maybe. My concern was mostly the parameters to a C function in a library
where one of the arguments was an unsigned int. We certainly cannot pass
a bigint can we? I know we can treat a signed int or unsigned the same
and I don't see it as much of a problem. I just get a bad feeling when
arithmetic is involved on a parameter during the call. I don't know
maybe I shouldn't be so concerned.

e.r.

Re: [pure-lang-users] C float

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

Eddie Rucker wrote:
> Then from Pure:
>  > using "lib:/t2.so";
>  > extern int foo(int);
>  > let a = 2147483646;
>  > foo (a div -1);
>  -2147483645

Nothing wrong there, a div -1 == -2147483646 in signed arithmetic, so 
foo (a div -1) == -2147483646+1 == -2147483645.

> Now, the following C program gives different results:
> [...]
>   unsigned int a = 2147483646;
> 
>   printf("%d\n", foo(a/-1));

Note that the 'a/-1' here does *unsigned* arithmetic (because you 
declared a as such), which means a/-1 == a/0xffffffffU == 0 != 
-2147483646 == (signed)a/-1. If you declare a as a signed int in your C 
program, you'll get exactly the same result as with Pure.

Under all circumstances, the C interface should behave as if the C int 
type is "cast" to the Pure int type and vice versa (using truncation and 
sign extension as necessary), if that's not the case then please report 
it and I will fix it. I think that this is the most reasonable way to 
implement the marshalling of C ints considering the limited repertoire 
of integer types available in Pure.

Of course, this means that a C unsigned int return value will become 
negative in Pure if it's big enough. But that can be easily undone with 
the following little Pure function which takes a Pure int x and returns 
a bigint equal to (unsigned)x in C:

uint x::int = if x>=0 then bigint x else x+0x100000000L;

This carries over to unsigned 8, 16 and 64 bit ints accordingly:

ubyte x::int = if x>=0 then x else x+0x100;
ushort x::int = if x>=0 then x else x+0x10000;
ulong x::bigint = if x>=0 then x else x+0x10000000000000000L;

These always use the smallest Pure int type capable of holding the 
result: int for ubyte and ushort, bigint for uint and ulong. (Note that 
in the case of 64 bit values the C interface returns a bigint, that's 
why ulong takes a bigint parameter.)

Maybe I should add those definitions to primitives.pure?

HTH,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] C float

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

John Cowan wrote:
> Casting away const is always safe: const essentially documents how the callee
> uses the argument or its referent.

Exactly. The most important thing you have to keep in mind is that if a 
C routine returns a const pointer, you're not supposed to modify the 
data in Pure. And if a C routine takes a const pointer as argument, you 
can pass it any pointer from Pure (malloced memory, string, etc.) and be 
confident that the C routine won't modify it. Pure also takes care of 
marshalling Pure strings from/to the system encoding if the 
corresponding C type in the Pure extern declaration is char*. That 
usually does the right thing for const char* arguments and return values 
on the C side.

Where things get a bit messy is when you have to pass *non-const* 
pointers as arguments or get them as results. A non-const pointer 
_argument_ is most likely used to return results; in that case you'll 
usually have to malloc some memory to be passed for that parameter, 
maybe initialize the data as required by the C function and decode the 
results and free the memory after the function returns. A non-const 
pointer _return value_ (which isn't also a non-const parameter, such as 
in strcpy) often indicates data malloced by the C routine which is 
supposed to be freed by the caller (i.e., the Pure program).

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] C float

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

On Wed, 2008-08-13 at 11:16 -0400, John Cowan wrote:
> Eddie Rucker scripsit:
> 
> > Thanks. What about const and unsigned parameters?
> 
> Casting away const is always safe: const essentially documents how the callee
> uses the argument or its referent.

Ok. I understand this one.

> Unsigned does need explicit support to consistently get the right results:
> in particular, a too-big unsigned value should become a bignum.

Hmm. I didn't even think about big numbers. I was worried about the
following scenario:

Some C library called f2.so defined by:

unsigned int foo(unsigned int a) {
  return a + 1;
}

Then from Pure:
 > using "lib:/t2.so";
 > extern int foo(int);
 > let a = 2147483646;
 > foo (a div -1);
 -2147483645

Now, the following C program gives different results:

#include <stdio.h>

unsigned int foo(unsigned int a) {
  return a + 1;
}

int main() {
  unsigned int a = 2147483646;

  printf("%d\n", foo(a/-1));

  return 0;
}

Results:
 :~$ ./a.out
 1

e.r.

Re: [pure-lang-users] C float

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

Eddie Rucker scripsit:

> Thanks. What about const and unsigned parameters?

Casting away const is always safe: const essentially documents how the callee
uses the argument or its referent.

Unsigned does need explicit support to consistently get the right results:
in particular, a too-big unsigned value should become a bignum.

-- 
Man has no body distinct from his soul,              John Cowan
for that called body is a portion of the soul        co...@cc...
discerned by the five senses,                        http://www.ccil.org/~cowan
the chief inlets of the soul in this age.  --William Blake

Re: [pure-lang-users] C float

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

On Wed, 2008-08-13 at 16:41 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > If a function is defined in a C library as a float. How are we suppose
> > to access it from Pure?
> 
> Ok, this is implemented now. Pure double arguments are truncated to 
> float, and returned float results are expanded back to Pure doubles 
> again. E.g.:
> 
>    > extern float expf(float);
>    > expf 1.0;
>    2.71828174591064
> 

Thanks. What about const and unsigned parameters?
So far, I've imported stuff like

int foo(const char *bob, unsigned int hope) {

as

extern int foo(char *, int);

However, I fear that some arithmetic (division?) on a variable before
passing it to foo might get me some big bad ugly bug one day that will
be near impossible to track down.

e.r.

Re: [pure-lang-users] C float

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

Eddie Rucker wrote:
> If a function is defined in a C library as a float. How are we suppose
> to access it from Pure?

Ok, this is implemented now. Pure double arguments are truncated to 
float, and returned float results are expanded back to Pure doubles 
again. E.g.:

   > extern float expf(float);
   > expf 1.0;
   2.71828174591064

-- 
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] C float

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

Eddie Rucker wrote:
> If a function is defined in a C library as a float. How are we suppose
> to access it from Pure?

Right, I'll have to add a 'float' type to 'extern' declarations. That 
should be easy to do, I have it on my TODO list now.

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

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

Albert Graef wrote:
> Ok, I think that all the showstoppers are fixed now. I still have some 
> minor things on my TODO list for the 0.5 release, the most annoying 
> being a minor memleak related to catch/throw, [...]

This is now fixed as well, so all known bugs have been fixed now.

I also added some stuff to handle signals and map them to Pure 
exceptions, see examples/signal.pure for an example.

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

[pure-lang-users] C float

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

If a function is defined in a C library as a float. How are we suppose
to access it from Pure?

e.r.

Re: [pure-lang-users] timex

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

Albert,

Thanks for the fix, yes, it works just fine now.
Also, thank you for the references, I will look them up.

Cheers,
Libor

On Mon, 11 Aug 2008 20:32:29 +0100, Albert Graef <Dr....@t-...> wrote:

> Libor Spacek wrote:
>>> timex (\_ -> tailqueens 4);
>> Segmentation fault
>
> This should be fixed now (r465). Libor, can you please check if your
> tailqueens now behaves as expected?
>
> Ok, I think that all the showstoppers are fixed now. I still have some
> minor things on my TODO list for the 0.5 release, the most annoying
> being a minor memleak related to catch/throw, but for most purposes the
> current trunk seems to be ready for everyday use again. :)
>
> Cheers,
> Albert
>
> P.S.: Googling around a bit more I came across Bernhardsson's algorithm
> which might be similar to your technique, see
> http://portal.acm.org/citation.cfm?doid=122319.122322. I couldn't find a
> free version of that paper, but a brief description of the algorithm can
> be found on the German wikipedia page:
> http://de.wikipedia.org/wiki/Damenproblem#Explizite_L.C3.B6sung. Also,
> here is an extensive bibliography on the problem which might be
> interesting: http://www.liacs.nl/~kosters/nqueens/index.html.
>

Re: [pure-lang-users] timex

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

Libor Spacek wrote:
>> timex (\_ -> tailqueens 4);
> Segmentation fault

This should be fixed now (r465). Libor, can you please check if your 
tailqueens now behaves as expected?

Ok, I think that all the showstoppers are fixed now. I still have some 
minor things on my TODO list for the 0.5 release, the most annoying 
being a minor memleak related to catch/throw, but for most purposes the 
current trunk seems to be ready for everyday use again. :)

Cheers,
Albert

P.S.: Googling around a bit more I came across Bernhardsson's algorithm 
which might be similar to your technique, see 
http://portal.acm.org/citation.cfm?doid=122319.122322. I couldn't find a 
free version of that paper, but a brief description of the algorithm can 
be found on the German wikipedia page: 
http://de.wikipedia.org/wiki/Damenproblem#Explizite_L.C3.B6sung. Also, 
here is an extensive bibliography on the problem which might be 
interesting: http://www.liacs.nl/~kosters/nqueens/index.html.

-- 
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] Swapping Symbols and Integers

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

David Baird wrote:
>> Something like... code generation? :)
> 
> Doh!  I thought that was somewhere around step 5 :-P  I'll have to rethink this.

Well, there's a lot of stuff that can be done on the AST, but for things 
like peephole optimization, register allocation, constant folding, 
inlining of runtime routines, tail call elimination etc. you definitely 
need to consider the target code (which most often is an abstract 
assembler-like code which then gets translated to the real native code, 
at least nowadays).

In principle, you could also design your own AST representation of the 
target and apply your optimizations to that, but some kinds of 
optimizations are pretty hairy, so why reinvent the wheel when there's 
already something as comprehensive as LLVM out there?

> Thank you for all your generous feedback.

No sweat. :) It would be cool if you could try Pure and provide some 
feedback on how well it works for your purposes.

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] dyld: Library not loaded: libpure-0.4.dylib

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

Ryan Schmidt wrote:
> Adding "-install_name $(prefix)/lib/libpure-0.5.dylib" to the line  
> after that did the trick, thanks!
> 
> http://trac.macports.org/changeset/38884

Fixed in r464, so you should be able to eliminate that changeset now.

I also added some configury for the (DY)LD_LIBRARY_PATH selection. 
Please let me know whether it works for you.

It goes without saying that this needs a reconfigure. ;-)

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] llvm 2.3 - good news

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

Jiri Spitz wrote:
> I do not see any measurable slowdown now.

Great, then I consider this fixed. :)

-- 
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] llvm 2.3 - good news

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

Albert Graef napsal(a):
> Right, the new code is faster for JIT compilation, but slower on 
> execution for small list values. I worked around that now by adding a 
> minimum bound for the size of lists/tuples to which the new list 
> generation code is applied. Please check whether it's ok for you now.
> 
The speed is back as it used to be before the fixes.

> Using #set(1..1000000) as a test example, over here r462 still seems to 
> be a tad slower than r436, but that's probably due to some other, 
> unrelated fixes I did to the environment-handling code, which also incur 
> some (small) runtime cost; I'll have another look at that tomorrow.
I do not see any measurable slowdown now.

Thanks,

Jiri

Re: [pure-lang-users] llvm 2.3 - good news

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

Albert Graef wrote:
> One further avenue of working around LLVM's deficiencies there would be
> to optimize the case that the expression to be evaluated is a constant
> (number, string or list/tuple of constants), in which case I could just
> skip the compilation step and directly convert the compile time
> expression to a pure_expr* instead. I'll try that tomorrow.

This is now implemented as well. In most cases, constant expressions at 
the toplevel aren't compiled any more but are directly converted to the 
runtime expression data structure. That makes assigning a big constant 
list to a global variable much faster.

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] llvm 2.3 - good news

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

Jiri Spitz wrote:
> Thanks, but I am still not happy. The memory consumption is OK now, but 
> my 1 M set example runs two times slower than before :-( .

Right, the new code is faster for JIT compilation, but slower on 
execution for small list values. I worked around that now by adding a 
minimum bound for the size of lists/tuples to which the new list 
generation code is applied. Please check whether it's ok for you now.

Using #set(1..1000000) as a test example, over here r462 still seems to 
be a tad slower than r436, but that's probably due to some other, 
unrelated fixes I did to the environment-handling code, which also incur 
some (small) runtime cost; I'll have another look at that tomorrow.

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] llvm 2.3 - good news

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

Albert Graef wrote:
>> The code compiles much faster now. However, your latest changes made the 
>> execution memory eager and my favourite test 'set (1..1000000)' caused 
>> my PC swap to death. It seems the code isn't tail recursive anymore.
> 
> Fixed (r459).
> 
Thanks, but I am still not happy. The memory consumption is OK now, but 
my 1 M set example runs two times slower than before :-( .

Regards,

Jiri