pure-lang-users Mailing List for Pure (Page 52)
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-05-01 19:14:12
|
Albert, So here is what someone needs to do to make Pure work on Ubuntu (64-bit): step 1: >From Synaptic package manager install: make g++ g++ 4.0 multilib flex bison libgmp3c2 libgmp3-dev readline5-dev ldtl-dev (Libor Spacek found this one) subversion **Steps 2 and 3 can be avoided by downloading: llvm_2.2-7_amd64.deb llvm-dev_2.2-7_amd64.deb then using the debian installer. step 2: Downloaded llvm 2.2 64-bit version from http://llvm.org/releases/download.html#2.2 step 3: >From a terminal: $ cd llvm-2.2 $ ./configure $ make $ sudo make install $ cd step 4: >From a terminal: $ svn co https://pure-lang.svn.sourceforge.net/svnroot/pure-lang pure-lang step 5: >From a terminal: $ cd pure-lang/pure/trunk $ make build=release $ sudo make install $ cd Does this look ok Albert? Eddie |
|
From: John C. <co...@cc...> - 2008-05-01 19:14:11
|
Albert Graef scripsit: > If you want a working Pure interpreter right away, you can install a 32 > bit Linux (yes, it works also on a 64 bit machine) and use that until > the 64 bit bugs are resolved. That's overkill. 64-bit kernels will run 32-bit userland processes fine, at least on Intel machines. You just need the -m32 switch to gcc. -- Some people open all the Windows; John Cowan wise wives welcome the spring co...@cc... by moving the Unix. http://www.ccil.org/~cowan --ad for Unix Book Units (U.K.) (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif) |
|
From: Michael Ben-Y. <sep...@mw...> - 2008-05-01 18:50:02
|
Albert Graef wrote: > (I hope you don't mind that I'm cc'ing this to the mailing list since > the reply should be interesting for others, too.) No problem. > There's however a practical issue there, due to the way term pattern > matching is implemented in the Pure compiler (which essentially is the > "left-to-right term acceptor" technique I invented for my master thesis, > see my article in the RTA 91 proceedings, Springer). Thanks. I'll have a look at this. > I still think that a KB completion module for Pure would be very useful, > for less ambitious applications in mathematical logic. E.g., if you have > a little equational theory (a free group, say), and you want to do some > computations in that group, you really want a complete set of equations > which decides the word problem in that theory. Group theorists would > probably be happy with that (although there surely are software packages > for group theory which already do this kind of stuff). I was imagining something more like an equational theory of combinators, with only one binary function symbol, representing composition, and plenty of constant symbols representing combinators, with equations defining their intended semantics. (Hopefully far more than just S, K and I combinators, of course, so that one can prove theorems about the sort of simple functions a person might actually write in an "untyped" functional language, such as Pure itself.) As someone with absolutely no experience in this, I ask: is KB completion hopelessly inefficient for such rich theories? > Yes, I that that a KB completion procedure would be a useful addition. > It could be just provided as a separate Pure module which programmers > can load if they need it. But as explained above, I don't see that it > would be feasible to incorporate it into the compiler itself. OK, that makes good sense. > Yes, that already works, you can use the eval function to execute > arbitrary Pure code at runtime. E.g.: Excellent. Thank you. >> I ask because the GPL then requires the resulting application to be GPLed >> since it includes Pure itself. A more permissive license, such as LGPL >> or BSD, is in order if Pure is to be used in this way in commercial >> applications. > > You're right, I haven't thought about that yet. But since I'm the author > and only copyright holder of the Pure software, I can do that without > any ado when the issue comes up. I'll probably switch to LGPL then. > Maybe I should do that right away, I will think about it. Good to hear. Kind regards, Michael |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 18:47:31
|
Michael Ben-Yosef wrote: > I was imagining something more like an equational theory of combinators, > with only one binary function symbol, representing composition, and > plenty of constant symbols representing combinators, with equations > defining their intended semantics. Yes, that should be an interesting application, and much more interesting for cs people than group theory. :) > As someone with absolutely no > experience in this, I ask: is KB completion hopelessly inefficient for > such rich theories? I have no idea. I've never used KB for anything but trivial examples which I did using pencil and paper. ;-) Guess you'll just have to try... 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-05-01 18:39:18
|
Libor Spacek wrote: > Why are "commands" not terminated by semicolons as well? Because they are special. Everything that's listed under "INTERACTIVE USAGE" in the manpage does *not* belong to the Pure language at all, and is parsed and processed in a *very* different way (more like shell command lines). > stats on; > stats: invalid parameter 'on;' (must be 'on' or 'off') > > Is this inconsistency intended? Yes. Those commands *are* special, they have nothing in common with Pure expression syntax, and that should be very clear. What I *could* do is require a special escape character, like the '!' in front of shell escapes. So you'd type something like: :stats on instead of just: stats on That would be an easy change in the parser. Personally, I think that this would be rather inconvenient. But I'll consider to do that change if a big majority prefers it that way. So let's have a poll. :) [ ] Yes, escape character please! :stats on [ ] No, keep it like it is! stats off > I have to remember which commands I defined and which were predefined and, > in each case, use or not use a semicolon. You *don't* define any commands. What you define are Pure functions and variables, and this is all done in the Pure syntax. The special commands are fixed and hard-wired, there's no way you can define new ones. 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: Tim H. <q...@st...> - 2008-05-01 18:20:31
|
Albert Graef <Dr....@t-...> writes: > Tim Haynes wrote: >> This is not a mac :) > > Sorry, I thought I recalled that you you were using a Mac. No offense. :) None taken. My other machine is a mac - we'll see what happens when I get around to that! Albert Graef <Dr....@t-...> writes: > Tim Haynes wrote: >> However, I have pinned it down. A default >> nice make clean depend all >> gives me nasty segfaults; appending and extra `build=release' does not. >> >> So there appears to be a difference in CFLAGS: >> -g -Wall -> FAIL >> -O3 -DNDEBUG -Wall -> HAPPY >> >> and I can run both versions of `fact', and `make check', correctly. >> >> This is good to know :) > > Indeed it is. :) So the segfault is somehow triggered by the extra > debugging code. Will have to look into that. But for the time being you > can just run the release build on 64 bit. ;-) Indeed. Trying to find a nice small script to port across to it now! ~Tim -- <http://spodzone.org.uk/> |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 17:48:24
|
Tim Haynes wrote: > However, I have pinned it down. A default > nice make clean depend all > gives me nasty segfaults; appending and extra `build=release' does not. > > So there appears to be a difference in CFLAGS: > -g -Wall -> FAIL > -O3 -DNDEBUG -Wall -> HAPPY > > and I can run both versions of `fact', and `make check', correctly. > > This is good to know :) Indeed it is. :) So the segfault is somehow triggered by the extra debugging code. Will have to look into that. But for the time being you can just run the release build on 64 bit. ;-) 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-05-01 17:45:07
|
Tim Haynes wrote: > This is not a mac :) Sorry, I thought I recalled that you you were using a Mac. No offense. :) -- 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-05-01 17:43:10
|
Libor Spacek wrote:
> What constitutes a passed test? Here is my test6.log:
>
> fact n/*0:1*/ = 1 if n/*0:1*/==0;
> fact n/*0:1*/ = n/*0:1*/*fact (n/*0:1*/-1);
> {
> rule #0: fact n = 1 if n==0
> rule #1: fact n = n*fact (n-1)
> state 0: #0 #1
> <var> state 1
> state 1: #0 #1
> }
> fact 4;
>
> It does not produce any value but when I do the factorial manually, it
> works and gives the right value, as I said.
Yes, that should be fine.
--
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-05-01 17:36:42
|
Gregory Michael Travis wrote: > Does this problem only happen when the equations are added at > run-time? If so, why? No, it's the term pattern matching algorithm that I use, which is *very* fast because it never backtracks, but that comes at the price that certain pathological pattern sets produce exponentially-sized automata. (That's pretty much the same as with deterministic versus nondeterministic finite string automata which are used for matching regular expressions.) Note that this isn't a deficiency in the algorithm. It's just that some pattern sets can't be matched deterministically, in a prescribed matching order, without an exponential number of states. You usually don't have these in manually written TRSs, but unfortunately in generated TRSs (like the ones produced by the Knuth-Bendix algorithm) they occur all too often. ;-) Also note that in the case that the size of the deterministic automaton explodes, a naive (backtracking) matching technique on the same pattern set will also be very slow, because it will have to backtrack a lot, giving you exponential complexity as well. So just falling back to a naive matching algorithm doesn't buy you anything either, at least not on the average. There has been some research on alternative techniques based on my original algorithm which process the subject term in other orders than left-to-right. I'm not sure whether pattern sets are known for which *each* such algorithm becomes exponential, but I strongly suspect that finding an optimal matching order (which would avoid an exponential matching automaton if it is possible at all) is an NP-hard problem anyway. I can't really go into the details of my algorithm here, but you can find that in the Rewriting Techniques and Application 1991 Conference Proceedings. Here's a bibtex entry of the article which I found on the web: http://dblp.uni-trier.de/rec/bibtex/conf/rta/Graf91 You should also be able to find other people's newer works by looking on Citeseer for papers citing my article. Unfortunately I don't think that my article is online for free somewhere, and I'm afraid that I've long lost the original TeX source. But you can still buy the RTA 91 proceedings, e.g., from amazon. And of course this volume should be in any good computer science library. ;-) If you have an ACM electronic subscription, you can also download a pdf of the proceedings here: http://portal.acm.org/citation.cfm?id=126537.126539&coll=GUIDE&dl=GUIDE (Of course, I still have my hardcopy of the proceedings, so if all else fails I could also scan the article and send it to anyone who wants to read it. But I can't just put it up on the web without violating Springer's copyright. You know, that was still in the bad old times when you had to sign over your copyright and your soul to get an article published.) Best, 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: Tim H. <q...@st...> - 2008-05-01 17:32:54
|
"Libor Spacek" <li...@gm...> writes: > OK, so is mine then because I get exactly the same: > l@ubuntu:~/pure-lang/pure/trunk/test$ file /bin/ls > /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for > GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped > > If it is any consolation, I was getting segmentation fault on the > factorial as well last night but it went away with Albert's fix this > morning, as I reported this morning. I am a bit worried about your > compilation Tim, and those manual fixes you did. Libor What manual fixes? As if make(1) clean wasn't enough, I cleaned out the directory entirely the hard way before the next svn update, long ago and at regular intervals since. However, I have pinned it down. A default nice make clean depend all gives me nasty segfaults; appending and extra `build=release' does not. So there appears to be a difference in CFLAGS: -g -Wall -> FAIL -O3 -DNDEBUG -Wall -> HAPPY and I can run both versions of `fact', and `make check', correctly. This is good to know :) ~Tim -- <http://spodzone.org.uk/> |
|
From: Libor S. <li...@gm...> - 2008-05-01 17:12:16
|
OK, so is mine then because I get exactly the same: l@ubuntu:~/pure-lang/pure/trunk/test$ file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped If it is any consolation, I was getting segmentation fault on the factorial as well last night but it went away with Albert's fix this morning, as I reported this morning. I am a bit worried about your compilation Tim, and those manual fixes you did. Libor 2008/5/1 Tim Haynes <q...@st...>: > "Libor Spacek" <li...@gm...> writes: > > > I know. With the previous Ubuntu (7.10 I think) I used to run k8 > which > > was somehow supposed to be more 64bit than the 64bit but, frankly, I > > never understood how or why and nothing on it ever worked, so I stuck > > to the standard installation this time. What do you mean "How about > > file /bin/ls ?" Can you be more specific? > > | zsh, sauce 5:48PM trunk/ % file /bin/ls > | /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for > GNU/Linux > | 2.6.8, dynamically linked (uses shared libs), stripped > > My OS is definitely 64-bit. > > ~Tim > |
|
From: Tim H. <q...@st...> - 2008-05-01 17:04:53
|
"Libor Spacek" <li...@gm...> writes: > I know. With the previous Ubuntu (7.10 I think) I used to run k8 which > was somehow supposed to be more 64bit than the 64bit but, frankly, I > never understood how or why and nothing on it ever worked, so I stuck > to the standard installation this time. What do you mean "How about > file /bin/ls ?" Can you be more specific? | zsh, sauce 5:48PM trunk/ % file /bin/ls | /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux | 2.6.8, dynamically linked (uses shared libs), stripped My OS is definitely 64-bit. ~Tim -- <http://spodzone.org.uk/> |
|
From: Libor S. <li...@gm...> - 2008-05-01 17:02:52
|
I know. With the previous Ubuntu (7.10 I think) I used to run k8 which was somehow supposed to be more 64bit than the 64bit but, frankly, I never understood how or why and nothing on it ever worked, so I stuck to the standard installation this time. What do you mean "How about file /bin/ls ?" Can you be more specific? -Libor > > The x86_64 is promising but your -generic in the kernel name is an > interesting departure. How about file /bin/ls ? > > ~Tim > |
|
From: Tim H. <q...@st...> - 2008-05-01 16:50:31
|
"Libor Spacek" <li...@gm...> writes: > Albert, > All those different 64bit systems are quite confusing. Anyway, this is > what my uname -a returns: > Linux ubuntu 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 > x86_64 GNU/Linux > Is that good? :) Since I installed an amd-64 ISO file, I assumed I was > running a 64 bit system... Hmmm. | zsh, sauce 5:46PM trunk/ % uname -a | Linux sauce 2.6.24-1-amd64 #1 SMP Thu Mar 27 16:52:38 UTC 2008 x86_64 GNU/Linux The x86_64 is promising but your -generic in the kernel name is an interesting departure. How about file /bin/ls ? ~Tim -- <http://spodzone.org.uk/> |
|
From: Tim H. <q...@st...> - 2008-05-01 16:46:24
|
Albert Graef <Dr....@t-...> writes: >> Pure can now compute factorials! :) I may even start some programming. >> >>> fact n = n*fact (n-1) if n>0; >>> = 1 otherwise; >>> fact 4; >> 24 > > Ahem, do you mean that you have it running on a 64 bit Ubuntu?? But Tim > just reported that it doesn't work on 64 bit yet (albeit on Mac), not Er... | pure: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux | 2.6.8, dynamically linked (uses shared libs), not stripped This is not a mac :) > even the latest revision!! Speaking of which, can we have a --version option that includes the svn build#? ;) svn update nice make clean depend all sudo make install .. | zsh, sauce 5:44PM trunk/ % ./pure | [...] | Loaded prelude from /usr/local/lib/pure/prelude.pure. | | > fact n = n*fact (n-1) if n>0; | > = 1 otherwise; | > fact 4; | zsh: segmentation fault (core dumped) ./pure Always at at runtime.cc:901. Am I doing something wrong here? ~Tim -- <http://spodzone.org.uk/> |
|
From: Libor S. <li...@gm...> - 2008-05-01 16:44:37
|
Albert, All those different 64bit systems are quite confusing. Anyway, this is what my uname -a returns: Linux ubuntu 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux Is that good? :) Since I installed an amd-64 ISO file, I assumed I was running a 64 bit system... Libor 2008/5/1 Albert Graef <Dr....@t-...>: > Libor Spacek wrote: > > Runs as far as test 7, which fails with segmentation fault. > > I notice you removed test 7 in revision 19 for that reason. > > Yep. I'm still working on that one, it's a bit trickier than I first > expected. > > > Pure can now compute factorials! :) I may even start some programming. > > > >> fact n = n*fact (n-1) if n>0; > >> = 1 otherwise; > >> fact 4; > > 24 > > Ahem, do you mean that you have it running on a 64 bit Ubuntu?? But Tim > just reported that it doesn't work on 64 bit yet (albeit on Mac), not > even the latest revision!! Can you please double-check that it's > *really* a 64 bit OS that you're running there? (What does uname -a say?) > > Albert > > |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 16:39:00
|
Libor Spacek wrote: > Runs as far as test 7, which fails with segmentation fault. > I notice you removed test 7 in revision 19 for that reason. Yep. I'm still working on that one, it's a bit trickier than I first expected. > Pure can now compute factorials! :) I may even start some programming. > >> fact n = n*fact (n-1) if n>0; >> = 1 otherwise; >> fact 4; > 24 Ahem, do you mean that you have it running on a 64 bit Ubuntu?? But Tim just reported that it doesn't work on 64 bit yet (albeit on Mac), not even the latest revision!! Can you please double-check that it's *really* a 64 bit OS that you're running there? (What does uname -a say?) 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: Libor S. <li...@gm...> - 2008-05-01 16:38:07
|
What constitutes a passed test? Here is my test6.log:
fact n/*0:1*/ = 1 if n/*0:1*/==0;
fact n/*0:1*/ = n/*0:1*/*fact (n/*0:1*/-1);
{
rule #0: fact n = 1 if n==0
rule #1: fact n = n*fact (n-1)
state 0: #0 #1
<var> state 1
state 1: #0 #1
}
fact 4;
It does not produce any value but when I do the factorial manually, it works
and gives the right value, as I said.
-Libor
2008/5/1 Tim Haynes <q...@st...>:
>
> OK - I was going to say, contrary to Libor, revision 19 is guaranteably
> bombing out for me on all tests so far. Will hang fire a bit and maybe do
> the 32-bit thing for a while :)
>
> ~Tim
>
|
|
From: Tim H. <q...@st...> - 2008-05-01 16:24:12
|
Albert Graef <Dr....@t-...> writes: > Libor Spacek wrote: >> I won't have time to test it on my machine until late this afternoon, as >> I am at work at the moment. Will do as soon as I get home. > > Please note that the interpreter bombs on 64 bit systems right now, so > don't bother with it right now, I'm working on it. > > If you want a working Pure interpreter right away, you can install a 32 > bit Linux (yes, it works also on a 64 bit machine) and use that until the > 64 bit bugs are resolved. OK - I was going to say, contrary to Libor, revision 19 is guaranteably bombing out for me on all tests so far. Will hang fire a bit and maybe do the 32-bit thing for a while :) ~Tim -- <http://spodzone.org.uk/> |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 16:10:31
|
Libor Spacek wrote: > I won't have time to test it on my machine until late this afternoon, as > I am at work at the moment. Will do as soon as I get home. Please note that the interpreter bombs on 64 bit systems right now, so don't bother with it right now, I'm working on it. If you want a working Pure interpreter right away, you can install a 32 bit Linux (yes, it works also on a 64 bit machine) and use that until the 64 bit bugs are resolved. 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: Libor S. <li...@gm...> - 2008-05-01 16:05:13
|
Why are "commands" not terminated by semicolons as well? stats on; stats: invalid parameter 'on;' (must be 'on' or 'off') Is this inconsistency intended? I have to remember which commands I defined and which were predefined and, in each case, use or not use a semicolon. This is complicated syntax for me.... |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 16:02:44
|
Tim Haynes wrote: > Well, the results have become more consistent, but not in a good way! :( > > Taking the simple fact example same as last night: > > | zsh, sauce 11:04AM trunk/ % cat test1.pure > | fact 0 = 1; > | fact n = n * fact (n-1); > | fact 4; > | > | zsh, sauce 11:04AM trunk/ % ./pure < test1.pure > | zsh: segmentation fault (core dumped) ./pure < test1.pure > > That's worse - segfault was previously on test2.pure (my flip-around) only. Ok, looks like I'll have to install a 64 bit Linux myself, so that I can step through the program in gdb and see exactly what's going on there. Will do that tonight. > Oh I see. Your check target is incremental and treats the log-file as proof > it's been done. :) Those logs aren't in svn, as they are generated files, so they first have to be built before you can run 'make check', but of course you need a working interpreter to do that which you don't have yet ... KABOOM! ;-) 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: Libor S. <li...@gm...> - 2008-05-01 15:44:05
|
OK, I have just tested revision 18. Compiles just fine. Runs as far as test 7, which fails with segmentation fault. I notice you removed test 7 in revision 19 for that reason. Pure can now compute factorials! :) I may even start some programming. > fact n = n*fact (n-1) if n>0; > = 1 otherwise; > fact 4; 24 Thanks for your rapid fixes! Libor |
|
From: Gregory M. T. <mi...@pa...> - 2008-05-01 14:27:11
|
Albert Graef <Dr....@t-...> sed: > There's however a practical issue there, due to the way term pattern > matching is implemented in the Pure compiler (which essentially is the > "left-to-right term acceptor" technique I invented for my master thesis, > see my article in the RTA 91 proceedings, Springer). This technique > yields very fast matching code (an essential prerequisite for a TRS > programming language), because it's deterministic (non-backtracking). > >.>><>>>> > *But* there are pathological cases of term sets where the automata are > exponential in size (that's also discussed in my paper). Now if you > start adding lots of overlapping equations to the running program, as > any form of Knuth-Bendix completion typically does, it might hit that > wall and the dynamic compilation as well as the program itself will > become very slow and unusable. :( Does this problem only happen when the equations are added at run-time? If so, why? |
6 messages has been excluded from this view by a project administrator.
){kind=link}