Anybody willing to decipher Forth program
in [Lisp]
|
From: Tamas K Papp on 15 Mar 2010 07:03 On Mon, 15 Mar 2010 11:58:18 +0100, Nicolas Neuss wrote: > Eli Barzilay <eli(a)barzilay.org> writes: > >> [a very good technical post] > > and ends with > >> [In any case, this opst probably has an even higher number of flame >> hooks, so I'll plonk this thread too.] > > Why are you so defensive? IMO, these lines are the only flame-bait in > your post because you assume that your audience is not capable of > discussing technical points. > > I have taken again a look at the PLT homepage, and liked very much what > I have seen. I am a little in doubt, if PLT can with good conscience be I feel the same, PLT looks very, very interesting. I keep looking at it from time to time, even though deadlines always prevent me from trying it out in a "serious" project - but one of these days I will take the plunge :-) Nicolas, if you experiment with PLT Scheme, please post your experience w.r.t performance of numerical code. Tamas
From: Hugh Aguilar on 15 Mar 2010 15:30 On Mar 14, 4:31 am, Nicolas Neuss <lastn...(a)kit.edu> wrote: > That junk output was probably OK (the text was too short for finding the > correct unique solution by this decryption technique). I also checked > only that my optimized version produced the same output as Helmut's > original CL version (and I was quite confident that Helmut did check the > output against the original Forth program). > > 19 seconds sounds quite reasonable. I would be really interested in how > that code and the procedure to compile and call it looks like. Junk output is not okay! This kind of result indicates a bug: The seed is: 263384622 The file is: d s Gyvx)Od] O(a)P7X6 p7 ~I If the text file is short then that means that there are multiple keys that encrypt the file identically. LC53 will return the first key that it finds that decrypts the file, which may not be the original key used to encrypt the file, but that key should correctly decrypt the file. The result shown above is not decrypting the file correctly, so there must be a bug in the program. We are a little bit early to be comparing benchmark times when we are getting gobbledygook results! I'm guessing that all of these buggy programs are the result of PRNG not doing the arithmetic the same. Arithmetic is a lot more fuzzy than most people imagine --- it varies between systems. For example, in ANS- Forth there *two* division functions provided (FM/REM for floored division and SM/REM for symmetric division); apparently the standards committee couldn't decide which definition of division was more common, so they provided both. I would recommend testing PRNG by giving it a key and running it a few times, printing out the generated key each time. Compare that to PRNG running on a system that does work (my LC53 was tested on SwiftForth and 32-bit GForth) to see if they are the same.
From: Hugh Aguilar on 15 Mar 2010 16:09 On Mar 14, 8:03 am, refun <re...(a)nospam.gmx.com> wrote: > In article <m3zl2bstee....(a)winooski.ccs.neu.edu>, e...(a)barzilay.org says... > > > As a purely anecdotal example, I have > > not seen any practical example of a CL program that defines a new > > language for some purpose, whereas this is quite common in PLT, to the > > point of defining a new language that is used in a few files and > > nowhere else. > > DSL's and embedded languages everywhere when I look at Common Lisp. > Most introductory and more advanced CL book touch the subject in one way or the > other. > > Various CL books show examples of embedding other languages in Lisp. > PAIP shows a Lispy Prolog interpreter and compiler , A Scheme interpreter and > compiler, and a number of other Domain Specific Languages. It usually keeps the > languages Lispy and avoids defining real syntaxes which gives one the > possibility of using real macros. I think the key word here is "lispy." Forth is also much ballyhoo'd for supporting DSLs. As a practical matter, this only works when the DSL is forthy. For example, it is easy to write an assembler in Forth so long as the assembler is forthy in the sense that it uses postfix notation (the instruction is *after* the operands). I've done this, and I've also used assemblers written by other people (see my book slide-rule.pdf for examples of SwiftForth's Pentium assembly language). When you write Forth DSLs while remaining true to Forth, you get to retain the advantages of Forth. For example, in assembly language your operands don't have to just be raw data (literal numbers or names of variables), but they can be segments of Forth code that calculate the operand in some way. This is what "refun" meant in his post when he said: "avoids defining real syntaxes which gives one the possibility of using real macros." Compile-time code is strong magic --- this is how powerful programs get developed! As I've said before --- I consider Forth to largely be an overgrown and ultra- sophisticated macro assembler. If I had to write a program that had an overriding concern for speed, I would use a Forth assembler, but I would not necessarily make the application program similar to Forth. I would pass parameters in registers rather than on any stack, as that is generally faster. All of the Forth programming that I would do would be compile-time code rather than run-time code. I've never written a traditional assembler (a clone of MASM, for example) in Forth, but I expect that doing so would be just as big of a pain in the butt as it would be in any other language (maybe even Lisp, although I don't know enough about Lisp to say), and the result would be just as big of a pain in the butt to use as MASM is. If I had to do this unpleasant job, I would be more likely to use ANTLR than either Forth or Lisp.
From: Hugh Aguilar on 15 Mar 2010 16:59 On Mar 13, 7:57 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > There are lots of things in CL that are 'weaker' than what some > > Scheme offers - but more practical. > > This is inflammatory nonsense. I'm talking about a more expressive > system -- ones that makes it possible to write better code. In > practice. On the subject of practicality, would anybody here consider PLT Scheme to be a bad choice for my slide-rule program? I looked over the online documentation (including Eli's website), and it looks pretty good, so that is where I'm leaning. Keep in mind that I have never written a GUI program in my life, so I am defining practicality as being super- simple and ultra-well-documented. Keep in mind that if I go with PLT Scheme I'm not committing myself for life; I do retain the option of switching to CL later on. I might end up learning both PLT Scheme and CL and using them for different domains. Right now though, the only "domain" I'm interested in is the slide-rule program. If anybody thinks that CL would be a superior choice, can you indicate which version of CL and which libraries I should use? > And now that this went all the way into subjective redundantism, I'll > plonk this thread. I don't know what "subjective redundantism" is. I've never heard the term "plonk" either, but I suppose that it means he's going to go sulk. Lets all mellow out! A big part of the reason why I chilled out on comp.lang.forth is because the people tend to go around and around, and then they leave by the same door as in they came --- nobody ever learns anything, but they just further solidify their already-solid opinions. http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3/1af5b2fdf6d5e413?q=LC53&lnk=ol&
From: Raffael Cavallaro on 15 Mar 2010 21:51
On 2010-03-15 16:59:13 -0400, Hugh Aguilar said: > I don't know what "subjective redundantism" is. Each correspondent repeating his own personal, otherwise unsuppored opinion. Not a term in common use. > I've never heard the > term "plonk" either In common use: to killfile a thread or poster - i.e., to add that thread or poster to a list that one's newsreading software will not display. warmest regards, P.S. as regards your more important question, PLT scheme has awlays been an excellent choice for cross-platform lisp-family gui development, especially if one wants high quality, extensive documentation. It has only gotten better in recent years thanks in no small part to just in time compilation and significant improvements in numerical performance. FWIW, Paul Graham, who made his name and fortune using common lisp, chose it as the platform on which to write arc, his dialect of lisp. -- Raffael Cavallaro |