Anybody willing to decipher Forth program
in [Lisp]
|
From: Hugh Aguilar on 18 Mar 2010 15:58 On Mar 17, 2:26 pm, roland.kaufm...(a)networld.at wrote: > >>>>> "Ray" == Raymond Toy <toy.raym...(a)gmail.com> writes: > > > On 3/16/10 5:59 PM, Hugh Aguilar wrote: > >> LC53 is just a toy program; nobody who knows anything about encryption > >> would use the linear-congruential system. I did think of one use for > >> LC53 though. This would be a text-editor that is designed specifically > >> for women to write their diaries, and in which they use LC53 > >> encryption to prevent their boyfriends from reading the text. Assuming > >> that no women are computer programmers (true as far as I know), they > >> will never find out how easy it is to crack the LC53. I may write this > > > Oh, come on! Of course there are computer programmers who are women. I > > know some myself. And just because they're not programmers doesn't mean > > they wouldn't be able to crack LC53. There are quite a few women > > mathematicians too. > > For example, Joan Boyar who wrote > ... I actually knew who Joan Boyar was already. I just meant that I've never met a woman programmer personally --- at least not one who didn't rely heavily on cut-and-paste programming and who would endlessly discuss software design, but never actually write any software. Of course, there are a lot of men who do that too... I've never been to college, so I've never been required to believe in feminism. If you guys are feminists, then I apologize for offending you! :-)
From: Pascal Costanza on 19 Mar 2010 08:34 On 18/03/2010 20:58, Hugh Aguilar wrote: > On Mar 17, 2:26 pm, roland.kaufm...(a)networld.at wrote: >>>>>>> "Ray" == Raymond Toy<toy.raym...(a)gmail.com> writes: >> >> > On 3/16/10 5:59 PM, Hugh Aguilar wrote: >> >> LC53 is just a toy program; nobody who knows anything about encryption >> >> would use the linear-congruential system. I did think of one use for >> >> LC53 though. This would be a text-editor that is designed specifically >> >> for women to write their diaries, and in which they use LC53 >> >> encryption to prevent their boyfriends from reading the text. Assuming >> >> that no women are computer programmers (true as far as I know), they >> >> will never find out how easy it is to crack the LC53. I may write this >> >> > Oh, come on! Of course there are computer programmers who are women. I >> > know some myself. And just because they're not programmers doesn't mean >> > they wouldn't be able to crack LC53. There are quite a few women >> > mathematicians too. >> >> For example, Joan Boyar who wrote >> ... > > I actually knew who Joan Boyar was already. I just meant that I've > never met a woman programmer personally --- at least not one who > didn't rely heavily on cut-and-paste programming and who would > endlessly discuss software design, but never actually write any > software. Maybe you should spend some time outside of a cave every now and then. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Nicolas Neuss on 20 Mar 2010 10:06 Eli Barzilay <eli(a)barzilay.org> writes: > Nicolas Neuss <lastname(a)kit.edu> writes: > >> Yes, actually these are the things (together with Typed Scheme) >> which especially caught my attention. My ideal of a programming >> language would contain a (universally used) CLOS-like OO, it would >> allow (optional) type declarations (integrated with CLOS, of >> course), compilation to fast code, hygienic macros, and (if >> possible) try to prove code to be correct in the ACL way. > > Heh, that's a long list of things to work on... FWIW, Yes, but IMO all these are really desirable features, and for every single feature there are already reference implementations. So I think we can be quite sure that they also will be contained in the feature list of "Limit Lisp". > * Typed scheme will probably talk to the compiler to generate faster > code at some point in the future, but it's unknown when that will > happen; > > * The object system that is usually used in PLT (eg, for representing > GUI objects) is not swindle, so they're two separate systems > (swindle might be able to treat the plt object system as its own > objects as it does structs (which is similar to how they're done in > CLOS), but that requires someone to do the gluing work); > > * Typed scheme requires declarations, because unlike the types-as- > suggestions that you see in CL it does actually typecheck the code. > But it is a type system that is aimed at idiomatic Scheme code, > which means that it's quite different from ML/Haskell/etc -- the > main difference is that it has subtypes, and also that it has an > `Any' type. > > * As for a prover -- the dracula package > (http://www.ccs.neu.edu/home/cce/acl2/) is working with ACL2, but > there's no theorem prover in plt (yet...). Thanks for this report. It looks as if both PLT and CL have still some way to go until they reach my "Limit Lisp" above. Which one is nearer at the moment depends very much on which metric is used. For me, CL feels nearest, especially because I like CLOS and I do not want to make much compromises with respect to performant code (I did already when choosing Lisp:-). But I can imagine that for others (putting, say, the emphasis more on hygienic macros or call/cc) PLT is the right choice. >> Since PLT Scheme seems to be headed in exactly this direction, I >> could imagine that there will be a point when it becomes very easy >> to add to such a strong language also a Common Lisp compatibility >> module which would make the conversion of existing CL code >> straightforward. > > Yes, my guess is that this wouldn't be hard for various levels of > compatibility and tradeoffs. It's just that nobody had a sufficiently > strong itch so far. What is nice about Lisp in general is that all the different surface syntaxes are relatively easily transformable into each other, at least for a large part of code. That is, if PLT (or Clojure, or maybe also Qi on top of both) would be first arriving at "Limit Lisp" it would not be difficult to create a module supporting my favorite CL-like syntax (and interoperating seamlessly with the rest of the system). Nicolas
From: David Thole on 20 Mar 2010 07:56 Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > On Mar 17, 2:26 pm, roland.kaufm...(a)networld.at wrote: >> >>>>> "Ray" == Raymond Toy <toy.raym...(a)gmail.com> writes: >> For example, Joan Boyar who wrote >> ... > > I actually knew who Joan Boyar was already. I just meant that I've > never met a woman programmer personally --- at least not one who > didn't rely heavily on cut-and-paste programming and who would > endlessly discuss software design, but never actually write any > software. Of course, there are a lot of men who do that too... > > I've never been to college, so I've never been required to believe in > feminism. If you guys are feminists, then I apologize for offending > you! :-) I wouldn't really say that everyone's a feminist here - but I have met a few female computer programmers though. WICS is common at the university here (Women in Computer Science) - but honestly I see way more females in the acaemic part of the univeristy rather than the administrative part (where I work full time). The one woman programmer I know transitioned way more into project management and "product champion" than programmer at this point than actually doing programming. -- David http://www.thedarktrumpet.com/
From: Eli Barzilay on 22 Mar 2010 01:55
Nicolas Neuss <lastname(a)kit.edu> writes: > Eli Barzilay <eli(a)barzilay.org> writes: > >> Nicolas Neuss <lastname(a)kit.edu> writes: >> >>> Yes, actually these are the things (together with Typed Scheme) >>> which especially caught my attention. My ideal of a programming >>> language would contain a (universally used) CLOS-like OO, it would >>> allow (optional) type declarations (integrated with CLOS, of >>> course), compilation to fast code, hygienic macros, and (if >>> possible) try to prove code to be correct in the ACL way. >> >> Heh, that's a long list of things to work on... FWIW, > > Yes, but IMO all these are really desirable features, and for every > single feature there are already reference implementations. So I > think we can be quite sure that they also will be contained in the > feature list of "Limit Lisp". Some of your points are far off because of deeper problems. For example, yes there are theorem provers that can prove code correct, but they're usually not things that the average programmer can deal with and they're not useful for average project sizes and they still require a proper language specification. Another example is your mention of "(optional)" for types -- sound type systems are *very* different from those that allow optional type declarations (mostly for optimizations), and in addition it's unclear whether this can be dealt with when you have something as dynamic as CLOS. Given such problems, the meaning of your "Limit Lisp" is questionable. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! |