pure-lang-users Mailing List for Pure (Page 5)
Status: Beta
Brought to you by:
agraef
Menu
▾
▴
pure-lang-users — Discussion of the Pure programming language.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Eddie R. <er...@bm...> - 2008-09-04 12:46:56
|
On Wed, 2008-09-03 at 21:49 +0200, Albert Graef wrote: > Unfortunately, sf.net has a scheduled downtime of svn write tonight (or > rather this morning, 04:00 UTC), i.e., svn reads will work, but I won't > be able to commit anything. I'll try to do the overhauled list > generators and update the manual before that, but any further bugfixes > will probably have to wait until that ordeal is over... They seem to be down quite a bit :( > In the meantime, here's some stuff from SICP you can play around with: > > > ones = 1:ones&; > > integers = 1 : zipwith (+) ones integers&; > > let ints = integers; > > ints; > 1:<<thunk 0xb5fe1588>> > > take 10 ints; > [1,2,3,4,5,6,7,8,9,10] > > ints; > 1:2:3:4:5:6:7:8:9:10:<<thunk 0xb5fe1b28>> Uhm. Mine don't do that. I'm using revision 698 that latest. > ones = 1 : ones&; > integers=1 : zipwith (+) ones integers&; > let ints = integers; > take 10 ints; 1:{{thunk 0x7fe5e17d0488}} > > structure, it's just a normal list with a thunked tail, which makes > things a bit easier (and leaves the curly braces for something else ;-). Sounds good to me! e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-03 19:47:37
|
Eddie Rucker wrote: > OK. Compiles now. Hi Eddie, just FYI: In the latest from svn I also rewrote the better part of prelude.pure to make the list operations handle infinite lists, but that's not quite finished yet (I still have to do the list generator functions, and there might still be some bugs in the new code even though it passes all tests), so please consider this "experimental" for now. (And of course your bug reports are appreciated.) Unfortunately, sf.net has a scheduled downtime of svn write tonight (or rather this morning, 04:00 UTC), i.e., svn reads will work, but I won't be able to commit anything. I'll try to do the overhauled list generators and update the manual before that, but any further bugfixes will probably have to wait until that ordeal is over... In the meantime, here's some stuff from SICP you can play around with: > ones = 1:ones&; > integers = 1 : zipwith (+) ones integers&; > let ints = integers; > ints; 1:<<thunk 0xb5fe1588>> > take 10 ints; [1,2,3,4,5,6,7,8,9,10] > ints; 1:2:3:4:5:6:7:8:9:10:<<thunk 0xb5fe1b28>> Note the new & operator (postfix, binds stronger than anything else but function application) which does all the magic. It defers the evaluation of its operand until that value is actually needed somewhere (in which case evaluation and memoization happens automagically, as you can see above). So in difference to Q, there's no separate stream data structure, it's just a normal list with a thunked tail, which makes things a bit easier (and leaves the curly braces for something else ;-). Happy streaming! 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 |
|
From: Eddie R. <er...@bm...> - 2008-09-03 14:49:11
|
OK. Compiles now. e.r. On Wed, 2008-09-03 at 16:31 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > g++ -shared -o libpure-0.6.so expr.o interpreter.o matcher.o printer.o > > runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags > > --libs core jit native` -lreadline -lgmp > > /usr/bin/ld: runtime.o: relocation R_X86_64_32S against `a local symbol' > > can not be used when making a shared object; recompile with -fPIC > > Oops, sorry. This should be fixed now (r689). You'll have to do a > ./configure && make clean && make. > > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-09-03 14:29:32
|
Eddie Rucker wrote: > g++ -shared -o libpure-0.6.so expr.o interpreter.o matcher.o printer.o > runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags > --libs core jit native` -lreadline -lgmp > /usr/bin/ld: runtime.o: relocation R_X86_64_32S against `a local symbol' > can not be used when making a shared object; recompile with -fPIC Oops, sorry. This should be fixed now (r689). You'll have to do a ./configure && make clean && make. 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 |
|
From: Eddie R. <er...@bm...> - 2008-09-02 12:54:12
|
$ make install g++ -shared -o libpure-0.6.so expr.o interpreter.o matcher.o printer.o runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags --libs core jit native` -lreadline -lgmp /usr/bin/ld: runtime.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC runtime.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libpure-0.6.so] Error 1 g++ -shared -o libpure-0.6.so expr.o interpreter.o matcher.o printer.o runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags --libs core jit native` -lreadline -lgmp /usr/bin/ld: runtime.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC runtime.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libpure-0.6.so] Error 1 e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-02 09:13:45
|
Hi Rob, welcome back! Rob Hubbard wrote: > [I'm posting to both the Q and Pure mailing lists, although I'm only > subscribed to the former at present.] Note that your post didn't get to the Pure ml because you're not subscribed (same spam fighing measure as on the Q ml). > Sorry I've been so quiet about Q recently. Of course, I see that Q has > pretty much been superseded by Pure now. As a matter of fact, yes. It's just so much faster and better. :) There are still a few things missing, but I'm working on these. > I had been eagerly anticipating QCalc for Windoze, wondering whether > that has essentially been shelved now. This will happen at some point. Right now, there's other stuff that I need to fix up first. I'm currently working on lazy data structures, next thing will be support for matrices and vectors so that interfacing to GSL becomes a breeze. Other stuff that's already been implemented in svn since 0.5 is support for private symbols, unicode operator symbols, sentries (object finalizers), references and macros, so it's quickly getting to the point where most of Q's major features are provided in some way. > > 1:2:3:[]; > [1,2,3] > > 1+2; > 1+2 > So, lists worked as expected, but arithmetic didn't. Yes, as you suspected that's because the prelude wasn't found (1:2:3:[] works without that because [1,2,3] is just syntactic sugar that's built into the interpreter). > Perhaps the installer could have an "install for all users" option > (putting this variable in the system rather than user environment)? Right, I'll have to look into that, I'm running as admin myself so I never noticed this. > By the way, part of the reason for shying away from Pure up until now > was the mention of LLVM and MinGW; I thought installation of the > dependencies might be awkward (and I'm a lazy Windoze user, though I am > a fan of Cygwin). That's only true if you need to install LLVM from source (although it's not that difficult, if you use the install docs included in the Pure source, and the guide that Jiri has written on mingw installation). Fortunately, we already have ready-made packages for most popular systems now, and these are statically linked against LLVM. All other dependencies (basically, just the C library, libgmp and readline) are readily available on most systems. 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 |
|
From: Albert G. <Dr....@t-...> - 2008-09-02 08:37:14
|
Eddie Rucker wrote: > Was I wrong in reading that C was a descendant of BCPL to finish writing Unix? Yes, but it has come a long way from there, and IIRC the authors themselves did promote it as a general-purpose language at some point. (E.g., Pascal-vs-C controversy.) > If the committee added complex, why didn't the > committee add some string support like ==, !=, and friends? Well, this just wouldn't sit well with the arrays as pointers philosophy. OTOH, complex numbers support was an easy drop-in which didn't disrupt the existing library and compilers. > The SVN browser has been down for two days so I haven't been able to keep up with what is going on. Seems to be back up again. At least it works fine over here. Also, note there's a mailing list for the svn commits to which you can subscribe here (be warned that this has an awful lot of traffic at times): https://lists.sourceforge.net/lists/listinfo/pure-lang-svn That list is also archived, but as usual on sf.net the archive lags behind an awful lot. :( 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 |
|
From: Eddie R. <er...@bm...> - 2008-09-02 00:19:28
|
On Mon 01/09/08 7:08 PM , Albert Graef Dr....@t-... sent: > Well, C is supposed to be a general purpose language. Or when was the > last time you used it to do some *real* systems programming? ;-) Was I wrong in reading that C was a descendant of BCPL to finish writing Unix? If the committee added complex, why didn't the committee add some string support like ==, !=, and friends? I don't know about other programmers, but handling memory and strings in C is where I mess up the most. > PS: No news on the matrix/vector stuff yet, but in the meantime I have > thunks working, so Pure finally has lazy lists and all that stuff now. > (I still have to overhaul the prelude, though, so that the list > operations properly deal with infinite lists.) The SVN browser has been down for two days so I haven't been able to keep up with what is going on. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-02 00:06:20
|
Eddie Rucker wrote: > Doesn't built in complex seem kind of excessive for "systems programming?" Well, C is supposed to be a general purpose language. Or when was the last time you used it to do some *real* systems programming? ;-) Cheers, Albert PS: No news on the matrix/vector stuff yet, but in the meantime I have thunks working, so Pure finally has lazy lists and all that stuff now. (I still have to overhaul the prelude, though, so that the list operations properly deal with infinite lists.) -- 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 |
|
From: Albert G. <Dr....@t-...> - 2008-09-01 23:59:41
|
Eddie Rucker wrote: > Here is the reference. Thanks, the standard is fairly clear. With "mumbo jumbo" I actually meant all those silly macros specified by the standard which give the impression that this complex type is completely abstract when actually it's just two doubles (or two floats). Seems like overkill. -- 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 |
|
From: Eddie R. <er...@bm...> - 2008-08-31 15:23:11
|
Doesn't built in complex seem kind of excessive for "systems programming?" e.r. On Sun 31/08/08 9:45 AM , Eddie Rucker er...@bm... sent: > Here is the reference. > > http://books.google.com/books?id=svQJ7itfcGUC&pg=PA28&lpg=PA28&dq=C99+complex+internal+repres > entation&source=web&ots=0WpWVAZc9A&sig=NiX9RVOnpX6I01BHR_aIlfsZ > Xlc&hl=en&sa=X&oi=book_result&resnum=1&ct=result > Notice the title "C in a Nutshell." Sound familiar ;-) > > e.r. > > On Sat 30/08/08 7:33 PM , Albert Graef Dr.Graef > @t-online.de sent:> Eddie Rucker wrote: > > > Complex is indeed two doubles. I don't have > the> docs in front of me but I think it was defined > double z[2];> Now that's really simple. Then why the heck do > they have all that mumbo> jumbo in the ISO C99 spec? To scare people of > from using them? ;-)> > > -- > > 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> > > > > > > > |
|
From: Eddie R. <er...@bm...> - 2008-08-31 15:13:46
|
Here is the reference. http://books.google.com/books? id=svQJ7itfcGUC&pg=PA28&lpg=PA28&dq=C99+complex+internal+representation&source=web&ots=0WpWVAZc9A&sig=NiX9RVOnpX6I01BHR_aIlfsZXlc&hl=en&sa=X&oi=book_result&resnum=1&ct=result Notice the title "C in a Nutshell." Sound familiar ;-) e.r. On Sat 30/08/08 7:33 PM , Albert Graef Dr....@t-... sent: > Eddie Rucker wrote: > > Complex is indeed two doubles. I don't have the > docs in front of me but I think it was defined double z[2]; > Now that's really simple. Then why the heck do they have all that mumbo > jumbo in the ISO C99 spec? To scare people of from using them? ;-) > > -- > 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 > > |
|
From: Eddie R. <er...@bm...> - 2008-08-31 01:07:38
|
On Sat 30/08/08 7:33 PM , Albert Graef Dr....@t-... sent:
> Eddie Rucker wrote:
> > Complex is indeed two doubles. I don't have the
> docs in front of me but I think it was defined double z[2];
> Now that's really simple. Then why the heck do they have all that mumbo
> jumbo in the ISO C99 spec? To scare people of from using them? ;-)
I cannot find the source code? I would have thought it would have been defined like
struct { double real; double imag} complex but I think it was double z[2]. I'll do some more searching.
e.r.
|
|
From: Albert G. <Dr....@t-...> - 2008-08-31 00:31:56
|
Eddie Rucker wrote: > Complex is indeed two doubles. I don't have the docs in front of me but I think it was defined double z[2]; Now that's really simple. Then why the heck do they have all that mumbo jumbo in the ISO C99 spec? To scare people of from using them? ;-) -- 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 |
|
From: Eddie R. <er...@bm...> - 2008-08-30 23:26:06
|
On Sat 30/08/08 4:37 PM , Albert Graef Dr....@t-... sent: > Eddie Rucker wrote: > > Um... Is there some way from Pure to find out > the byte sizeof ints,> doubles, complex, etc? When the sizes change on > different machines> and/or compilers I'd like the library to > automatically handle this. > FWIW, system.pure now provides the following constants. These probably > aren't of much use for figuring out struct alignment, but at least they > provide the necessary information to malloc pointers to these types in a > portable manner. Also, you can test whether you're on a 64 bit system by > inspecting SIZEOF_POINTER. (BTW, I see no point in adding the long > double types right now, since these aren't supported by Pure in any > way.) Thanks! > Is it true that complex double is just two doubles, similar for complex > float? That would make things much easier, because a complex matrix > could be represented internally as a double matrix with twice the number > of columns. I guess that ISO C99 implementations are free to choose the > internal representation, though. Complex is indeed two doubles. I don't have the docs in front of me but I think it was defined double z[2]; e.r. |
|
From: John C. <co...@cc...> - 2008-08-30 22:06:24
|
Albert Graef scripsit:
> That's good to know, thanks! Yes, I agree, it would indeed be utterly
> insane to do it in a different way.
It's all about the weirdness of the Fortran EQUIVALENCE statement, which
lets you declare the exact overlap pattern of global storage, thus:
EQUIVALENCE(I(5), A(2,7))
where I is an integer vector and A is a floating-point matrix.
--
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
John Cowan <co...@cc...>
|
|
From: Albert G. <Dr....@t-...> - 2008-08-30 21:58:30
|
John Cowan wrote: > Probably so, but I can't imagine any C compiler choosing a representation > other than two consecutive floats, because Fortran requires that a > COMPLEX must take up the same space as two REALs. Nobody is going to > implement complex numbers in C in a way that's incompatible with Fortran > (other than C being row-major rather than column-major). That's good to know, thanks! Yes, I agree, it would indeed be utterly insane to do it in a different way. -- 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 |
|
From: John C. <co...@cc...> - 2008-08-30 21:52:23
|
Albert Graef scripsit: > Is it true that complex double is just two doubles, similar for complex > float? That would make things much easier, because a complex matrix > could be represented internally as a double matrix with twice the number > of columns. I guess that ISO C99 implementations are free to choose the > internal representation, though. Probably so, but I can't imagine any C compiler choosing a representation other than two consecutive floats, because Fortran requires that a COMPLEX must take up the same space as two REALs. Nobody is going to implement complex numbers in C in a way that's incompatible with Fortran (other than C being row-major rather than column-major). -- There are three kinds of people in the world: John Cowan those who can count, co...@cc... and those who can't. |
|
From: Albert G. <Dr....@t-...> - 2008-08-30 21:35:41
|
Eddie Rucker wrote: > Um... Is there some way from Pure to find out the byte sizeof ints, > doubles, complex, etc? When the sizes change on different machines > and/or compilers I'd like the library to automatically handle this. FWIW, system.pure now provides the following constants. These probably aren't of much use for figuring out struct alignment, but at least they provide the necessary information to malloc pointers to these types in a portable manner. Also, you can test whether you're on a 64 bit system by inspecting SIZEOF_POINTER. (BTW, I see no point in adding the long double types right now, since these aren't supported by Pure in any way.) > using system; > list -g SIZEOF* const SIZEOF_BYTE = 1; const SIZEOF_COMPLEX_DOUBLE = 16; const SIZEOF_COMPLEX_FLOAT = 8; const SIZEOF_DOUBLE = 8; const SIZEOF_FLOAT = 4; const SIZEOF_INT = 4; const SIZEOF_LONG = 4; const SIZEOF_LONG_LONG = 8; const SIZEOF_POINTER = 4; const SIZEOF_SHORT = 2; The complex sizes are for the ISO C99 complex float and double types. I don't know how portable that is, but gcc surely has them and they're also in POSIX. Is it true that complex double is just two doubles, similar for complex float? That would make things much easier, because a complex matrix could be represented internally as a double matrix with twice the number of columns. I guess that ISO C99 implementations are free to choose the internal representation, though. 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 |
|
From: Eddie R. <er...@bm...> - 2008-08-30 19:51:51
|
On Sat 30/08/08 1:36 PM , Albert Graef Dr....@t-... sent: > Well, CL hackers can follow their lineage back to the legendary days of > the holy MacLisp, when men were men and computers were hulking giants. > And Schemers can only look down in digust at the behemoth that CL is, > with its unhygienic macros and all that legacy stuff. ;-) :-O e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-30 19:31:44
|
On Sat 30/08/08 1:28 PM , Albert Graef Dr....@t-... sent: > Another related bit of trivia is that the Algol 60 design process nearly > stalled at some point because of the fierce debate over the decimal > separator. So flamewars over lexical issues have a really long tradition > in computer science. ;-) Yes, I remember reading about that in a PLT course! e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-08-30 18:34:51
|
Eddie Rucker wrote: > One of these days, I'm going to try to program something with common lisp to see what it is like. Maybe then I can figure out why the > common lisp folks and the scheme folks bicker and bite at each other all of the time. Well, CL hackers can follow their lineage back to the legendary days of the holy MacLisp, when men were men and computers were hulking giants. And Schemers can only look down in digust at the behemoth that CL is, with its unhygienic macros and all that legacy stuff. ;-) 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 |
|
From: Albert G. <Dr....@t-...> - 2008-08-30 18:26:17
|
Eddie Rucker wrote: > I could not find anything about the history of leaving off the leading 0 but it would make sense for FORTRAN programmers to do that > with punch cards. John may have a point there, but I've frequently seen seen it in handwriting by US people, too. It might also have something to do with the development of electronic calculators (although Fortran was earlier). But maybe there was some "prior art" which got picked up in the design of Fortran, too? I couldn't find anything definite on the web either, strange. Maybe we should ask someone from the Computer History Museum... Another related bit of trivia is that the Algol 60 design process nearly stalled at some point because of the fierce debate over the decimal separator. So flamewars over lexical issues have a really long tradition in computer science. ;-) 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 |
|
From: Eddie R. <er...@bm...> - 2008-08-30 17:14:27
|
On Sat 30/08/08 9:41 AM , John Cowan co...@cc... sent: > I suspect that ".5" got started in Fortran on the IBM keypunch > machines,where typing "0" was not only extra physical work just to push > down thekey, but made it that much more likely that you'd run off the end of > the card. I could not find anything about the history of leaving off the leading 0 but it would make sense for FORTRAN programmers to do that with punch cards. I lost my Web page (Dr. Math?) but I saw something about a company using leaving off 0s in front of the decimal point in probability to indicate that a probability can never be greater than one. All of my senior level probability and statistics books use leading zeros. Oh well. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-30 16:41:45
|
On Sat 30/08/08 10:40 AM , Albert Graef Dr....@t-... sent: > Eddie Rucker wrote: > > 1. ? > > That might be a C speciality, I'm pretty sure that this is neither > Pascal nor Algol syntax. (Pure also allows this, but only if followed by > a scale factor, as in 1.e-7.) > > But .5 has been supported by every programming language that I remember > right now (except Lisp), back to the venerable Algol 60, so there must > be some reason for that. At least Pure is in good company there. > > Just for the record, Haskell allows neither .5 nor 5., even if followed > by a scale factor. > mzscheme does but I don't know about common lisp. > (* .4 .5) 0.2 One of these days, I'm going to try to program something with common lisp to see what it is like. Maybe then I can figure out why the common lisp folks and the scheme folks bicker and bite at each other all of the time. e.r. |
6 messages has been excluded from this view by a project administrator.
