| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> kpreid: I have the intention, but time is a factor...
<1> kpreid: in what areas would Haskell expand a Lispers brain?
<1> *lisper's
<2> around the ears.
<1> Besides syntax. :)
<3> And the syntax seems to 'fix' a lot of traditional issues like screw-ups due to priority rules in parsing (e.g. in C is a+++b a++ + b or a + ++b?) or evaluation (the usual please excuse my dear aunt sally thing, along with more or less arbitrary rules for other things).
<1> yain: :)
<0> schlick: indeed.
<2> kpreid: what would you say about substituting haskell with ocaml in this exercise?
<0> schlick: I think you got the idea :-)
<3> So... Am I completely off base? Is it normal to start wanting to see everything in s-expressions? Are macros a bad substitution for parsers/lexers (***uming the syntax is consistent with Lisp)?
<4> schlick: macros are possibly not what you're looking for, inasmuch as they tend to facilitate embedding a new language within the existing semantic framework of Common Lisp, not completely replacing those semantics
<4> schlick: however, I don't think you're completely off base, and writing a "compiler" from a language expressed in s-expressions to ordinary Common Lisp is not difficult either, and is a good way of implementing a new language
<4> ETOOMANYAND
<3> Not familiar with that abbreviation.
<4> it's not an abbreviation; I was just commenting on my own run-on sentence :-)
<4> that's a UNIX-style errno for "too many and-separated clauses in sentence"
<3> I have a hairbrained idea of trying to implement a language suite. I'd like to have one language from each paradigm, all with a common linking ABI (native code), that avoid traditional language mistakes and have nice features. To experiment with the idea I though I could use macros to make extension languages, and have them use Lisp as the ABI.
<3> In the end it'd need to generate ***embly and whatnot, but it seemed like a good way to play with the idea with less effort. Maybe see how I might mess up before I invest too much effort.
<5> luis: (a) static typing can be non-evil; (b) monadic IO and other monads, parser combinators, and in general, wild and wonderful abstractions; (d) making pure-functional code pretty; (e) a more-generic-than-the-usual-language syntax while still having infix operators
<0> kpreid: as yain, I'm curious. How about ML?
<5> yain: I can't say; I haven't learned OCaml. But from what I've heard, it would be a worse choice for this purpose, being less of the extreme position than Haskell
<2> yeah, it's very lispy, IMHO.
<3> Probably nobody cares about my opinion but I know of at least one thing interesting about SML/NJ. There's the "first cl*** concurrency".
<2> I was going to learn haskell, but all this monadic stuff makes my head spin.
<6> A bad point for OCaml is that it uses modulo arithmetic on integer type (like in C), unlik Haskell.
<5> yain: persevere!
<6> (but there is library for bignum in ocaml)
<2> cods: there is a module for bignums.
<2> yeah.
<2> kpreid: you think I should... hm.
<5> yain: I can try to help with that, if you like...
<2> kpreid: I guess if you point me to a paper/website (or book) which explains this that would be good enough.
<5> yain: I don't know of a good one offhand, I just know it myself...
<3> chandler: Opinion? PLANNER was in Lisp... I figure a slightly tweaked Godel with s-expression syntax can't be too far off?
<5> yain: in the case of the IO monad, it can be said that the program's main function returns a value which states what it should do, plus the function to invoke to find out what to do next
<2> kpreid: I just read that last line 10 times and I don't understand it. :)
<2> kpreid: but thanks, if I have questions I'll bug you. ;P
<3> yain: I think I can find a page for you I read once a few months ago.
<3> http://web.cecs.pdx.edu/~antoy/Courses/TPFLP/lectures/MONADS/Noel/research/monads.html
<5> yain: (loop for (operation next) = (list nil user-main) then (funcall next (perform operation)))
<5> bad structure, really, but that's sort of the idea
<5> the more correct version would involve a few generic functions
<5> that is, that form is what the Haskell runtime does; user-main would be the pure function written in Haskell
<0> my main problem with that approach is that it strikes me as a bit awkward...
<3> Sorry if the language questions bothered anybody... I'd like input on what Common Lisp implementation to choose for good speed, for use on Unix, preferably open source. I've come to believe CMU-CL but I don't know.
<0> not a bad choice; sbcl is good too
<3> What would be the user-visible difference between the two?
<7> schlick: user-visible to you, the developer, or to the end-users of your product?
<0> schlick: sbcl has native threads on some platforms, and is generally a bit better maintained. Code can be faster. It is behind cmucl in a few areas. The latter _compiles_ a lot faster, and is a bit more benign and forgiving in certain aspects. But also less hackable (dificult to build). Iirc, ymmv, etc :-)
<0> I have both installed.
<8> prxq, lirc,ymmv?
<9> I've heard that cmucl has better xref support, which allows slime to do a better job at zipping you from place to place. But it's not bad in sbcl.
<7> prxq: could you tell me more about what aspects of cmucl are more forgiving?
<9> I think DEFCONSTANT is a good example of the difference in philosophy. SBCL will signal an error if you redefine a constant to something that's not EQL to the last definition. I think CMUCL just redefines it quietly.
<7> Yes, that's the sort of thing I thought was meant; that actually seems more helpful to me.
<9> cmucl users don't need help ;)
<7> I may be the exception to that rule.
<3> alpheus_home: Sorry for going idle. I had to pay my rent.
<3> alpheus_home: I ment user visible to me. I was thinking of finding a Common Lisp implementation to play with in Emacs through SLIME (it looks like that's the preferred IDE). I'd like it to be fairly fast, since, potentially, I might have it do fairly expensive analysis of source code.
<7> schlick: ah, OK. I don't use sbcl much, so I can't help you compare, but I can't recommend SLIME highly enough.
<10> What makes cmucl less helpful when you screw up?
<3> rtoym: I don't know, but I was going with what was said: (11:44:15) timjr: I think DEFCONSTANT is a good example of the difference in philosophy. SBCL will signal an error if you redefine a constant to something that's not EQL to the last definition. I think CMUCL just redefines it quietly.
<10> Hmm. I don't think it quietly redefines it. It gives a continuable error.
<3> I don't have both installed to confirm or deny.
<3> I was just asking for suggestions.
<9> rtoym: sorry, I guess that's changed. My cmucl is an old snapshot from '03.
<10> I'm not sure either. But whenever I change a defconstant, I get a continuable error.
<7> rtoym: IIRC, when compiling a form that uses an unexported symbol from another package, the error is pretty generic, along the lines of simple-read-error.
<9> rtoym: yeah, but what if you recompile one that didn't change? (defconstant foo "asdf"), e.g.
<10> Oh, right. Yeah, I think cmucl misses that.
<7> "Attempt to load a file having a compile-time read error." ... would be nice if something pointed to the point of the error, or just said "pack:foo isn't external in the package pack"
<10> alpheus_home: Easy enough to test. (defun foo () kernel:dd-pi/4) gives a reader error that says kernel:dd-pi/4 is not exported.
<10> Oh. At load time. Yeah, that would be nice.
<7> my test was slime C-c in the form, and the error is in C::DO-CALL
<10> I wonder why slime doesn't notice the reader error in that case.
<7> OK, so if I just use slime-eval-last-expression, instead, the problem is solved.
<3> Hmm, I'm looking at the benchmarks on the cmucl page and it looks like there isn't a huge difference between cmucl and sbcl. So, overall, sbcl will be more helpful, error message wise?
<7> I don't think we've proved that yet ;)
<3> Hmm, I always hit the hard decisions.
<10> Just pick one. Personally, any of clisp, cmucl, sbcl would be good to start with.
<7> With a standard language, you have the luxury of building with several, and maybe catching a portability problem early.
<3> It looks like clisp fairs pretty poorly in the benchmarks. Of course I won't run up on a problem with that real soon, but I kind of like to settle into one setup and not change for a long time, so making good decisions up front can pay off for me. So I agonize a lot.
<3> Right now I think I may settle on SLIME and sbcl.
<3> Are there any other tools I should look at?
<11> alpheus_home: Amen ... I have 9 CLs on my desktop, and 5 on my laptop ... portability testing is just a 'M-- M-x slime' away.
<9> well, one reason to go for sbcl is that it comes with asdf and asdf-install, so you can just (require :asdf-install) and then start fetching packages
<12> schlick: that is also what I use currently ... (I am a beginner too ;) ) and I am pretty happy with that ... still get every several minutes the feeling "that stuff is so amazing, why have I not tried lisp earlier"
<10> Benchmarks might show clisp as slow, but in practice I have not problem with it's slowness, except when crunching numbers.
<10> Er, no problem
<10> Thwap. "its"
<3> esden: I'm rather annoyed with myself for using Emacs like Pico for about 10 years before having the little light go on. :P Oh well. I'd already eyeballed Lisp's syntax some while reading about programming language design/implementation. I thought I liked it, but now I'm starting to want everything in it.
<3> I tend to worry when I think something is /too/ good of an idea, but I can't find anything wrong with the syntax. It seems optimal for everything.
<12> schlick: I did not use emacs before ... and I still have some problems getting used to it ... and I am not yet sure if I will ... I used vim very extensivly for years before
<12> schlick: but because of the slime integration Emacs is somehow a must ...
<3> esden: I had to use VI (not VIM this was "back in the day" before VIM :P ) in college. VIM is much better, but the Esc thrashing has always bothered me. I usually just want to do one command, then return to editing, so having to pop in and out of the command mode manually bothers me. VI (the one I used) couldn't do nearly as much as Emacs can, but it looks like VIM has narrowed the gap some.
<12> schlick: yes cl***ic vi is a mess ... the first thing I do on a machine is looking if vi starts vim ... if not install it ... and make sure it runs in incompatible mode ;)
<13> esden: Heh, SysV vi ****s, but nvi is the best thing ever. Short load time :)
<3> esden: If this gives you an idea what it was like, the arrow keys, delete, and backspace didn't work. Someone coming from a DOS Edit background seeing this does not react kindly at first. ;)
<13> esden: And something that kicks even more *** is emacs-multi-tty
<13> esden: lets you get instant startup with emacsclient :)
<3> esden: Oh... I should also mention that this was on VMS.
<12> pipeline: have not tried nvi ... i know some people that love it
<12> pipeline: emacs-multi-tty?
<3> VMS might be described as (to give an accurate impression) "the OS where "CD" was 'improved' by changing it into "SET DEFAULT=DISK$SYSTEM:[FULL.PATH.GOES.HERE]"
<3> I didn't like that much either. :P
<12> schlick: urgh ... yes that sounds pretty much like VMS ;)
<3> I hated VMS with a p***ion.
<12> lol
<14> perldoc -f ayn rand for the novel
<12> ok ... I go back to Practical Common Lisp ...
<3> I did find a trick that made it easier to live with. I found out that if I ran kermit there was a built in CD command that worked more or less like you'd expect, and you could launch programs from it, so my "shell" became kermit. :P
<3> And we had Teco. The editor that put hair on your chest, and your brain!
<3> I should add something about walking barefoot through snow 12 feet deep, and liking it, here, but I'd be fibbing about that. :P
<6> Just wondering: Given the name CLEAN-STRING, how to name it to specifiy that it is destructive ? NCLEAN-STRING, N-CLEAN-STRING, CLEAN-STRING-N ? (otherwise, defaulting to CLEAN-STRING-DESTRUCTIVE) (the function is replacing "invalid" characters in a string.)
<12> thanks to Teco you became a real man ;)
<15> hi
<3> Hi? :)
<3> Are there any things to watch out for in Common Lisp? Scope is lexical, and order of evaluation is fixed/standardized, I hear (if not please let me know).
<3> Ooh, quiet. Did I ask a bad question?
<16> schlick: yes, correct. but these are just 10% of the important details
<17> Scope is lexical unless declared dynamic, and the order of evaluation could be munged with macros, but don't do that, you'll just confuse yourself.
<16> schlick: my recommendation would be "just do it". you get the most ideas quite quickly, and in the worst case, ask here or in #cl-gardeners
<3> What is "#cl-gardeners" (where does the "gardeners" come in?).
<3> cliini: I consider a fixed order of evaluation a desirable feature. I was just curious if there was something that might bight me.
<7> http://www.lispniks.com/cl-gardeners/
<7> schlick: doesn't that depend on your background and unknown ***umptions?
<3> Possibly. I have fairly strong notions of what I consider "surprising". ***uming someone doesn't play (English) language lawyer with me, the gist is "I want the language to do what I said, and only what I said, specifically not what *it* wants, and if I wasn't explicit enough I want it to fail and expect me to be more explicit".
<3> Some people would say only ***embly is like that. I disagree. It's perfectly possible for a language to not "think for you" or "***ume". So far I've been pretty pleasantly surprised piddling around in Emacs Lisp. ***uming I don't screw up the syntax somewhere it behaves exactly like I'd expect every time (so far...).
<7> The thing that bit me hardest was my prejudice against IDEs. I know (knew) vi better than most people do, and had the C-on-Unix work habits so deeply embedded that I really resisted getting good with Emacs. Lisp is so interactive that one really must know an editor that knows how to work with Lisp.
<3> One reason for seeking out common Lisp is once I got interested in Emacs Lisp I kept hearing about all the stuff it can't do, so I thought I'd like to at least get a little experience with those things.
<3> I doubt I'll have that problem. I've never been the "macho man" kind of programmer. If I can avoid some work, I will. I like IDEs and, in general, big powerful tools, so long as they don't get in the way, or think for me. For instance, I really hate Microsoft Office's tendency to "correct" my formatting. Sure, that's clever, but it's also wrong most of the time. :P
<3> I keep expecting something bad to happen because so far Lisp macros appear very nice, where I'd be afraid to use them in C or C++ unless forced to. Order of evaluation was fixed (a sore spot in C/C++). The syntax is to die for IMO. Usually when a lot of good things happen to me I expect something bad to follow. :P
<8> is there a way to get all defun's defmacro's defvar's(and so on) listened in slime?
<7> I think I agree with you about "surprising".
<7> mc__: slime-apropos-package and slime-apropos-all might help
<8> alpheus_home, thank you
<8> hm no thats not what i was looking for but also nice
<8> i meant how to see everything i defined at the REPL
<18> too late.
<8> so that i do not have to copy every function/macro to a file(for later use) when i defined it
<7> It's easier to put them in a file first, then evaluate them at the point of definition in the file.
<18> next time try google: ibcl site:paste.lisp.org
<3> Is there something along the lines of The Vaults of Parn***us, The Python Cheese Shop, or CPAN for Common Lisp?
<18> mc__: ibcl does what you want.
<1> Whhoo hoo. Portugal wins.
<11> schlick: ASDF-Install?
<11> schlick: Comes with SBCL and a few other impls.
<8> pjb, thank ill google for it
<0> luis: felicita,cao :-)
Return to
#lisp
or
Go to some related
logs:
#web
sasldblistusers2 local_recipient_maps db
suse downgrade yast
#debian
#linux
ralink rt2600 linux
#web
PEAR via WebMarshal
how to decode IONCUBE
ubuntu wrong fs type, bad option, bad superblock
|
|