| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> then a synthesis emerges, and a generation of people who haven't had that added burden of complexity can just use the "final" version
<0> I simplify, but I hope you get the idea
<0> and I think that the strong reductionism of wanting to understand everything in a tool is potentially harmful if you approach it the wrong way
<0> I say this as a physicist, who are subject to this temptation
<0> um
<0> + grammar
<0> the issue is that that's worthwhile, but only if you don't have to understand the entire microdetail of everything at once -- if you can abstract away systems or layers and treat them as boxes when you don't _need_ the detail
<0> and I think clim actually does that, while allowing you to get at lower layers when you need to
<1> that's a very nice way of putting it.
<1> ... and it mirrors how I think of Common Lisp. It is very complex, but I can get things done by knowing only a tiny fraction of it. Then, when I really need to, I can dig into the details of some crucial aspect of it.
<2> beach: I would also appreciate it if there was a way to delay the computation of sizes/shapes of output-records (next generation)
<3> krystof: you're talking about the problem of leaky abstractions.
<2> as in clos's finalize-inheritance
<1> antifuchs: what do you need it for?
<2> beach: I noticed that e.g. filling-output in cl***ic clim has problems if there is an output record boundary in the middle of a word
<2> this cries for a delayed line break insertion mechanism, but dynamic-extent output recording mechanics in there prevent that
<0> eructate: if you like, except that I find that the programmer's desire for non-leaky abstractions is usually thwarted by the real world, which is inherently leaky
<2> of course, that would be only a nice-to-have feature (:
<4> beach,xophe: I think I understand what you mean, and I'm not in favour of oversimplified "Wirth-" systems, but still my feelings on CL/CLOS/CLIM is messy details and special cases and the short answer always being wrong.
<0> lukego: I am happy to concede that CL and CLOS are not purely designed, but influenced by backward-compatibility and mindshare-compatibility issues
<0> and I'm even happier to concede that CLIM isn't even finished as a design, and it shows in several places
<0> I should also say that I have relative lack of experience of other languages and other GUI toolkits
<4> examples that keep flashing in my mind: what if you accidentally modify in-place a quoted form in macroexpansion (i.e. innocently mangle internal compiler data structure), Scott McKay "simplicity of implementation is irrelevant", no answers given (or asked) on basic questions like "how do I know the heap isn't mangled if I'm working with signal handlers or INTERRUPT-THREAD", etc
<4> the trouble is that Erlang has all of this stuff nailed and Erlang people wouldn't dream of allowing such nasty cases to exist, but I'm totally bored with Erlang by now :)
<0> mm. ML has a different set of things nailed (e.g. "what if I add 1 to a string?")
<3> it does seem to me like you have some good points there.
<0> it nails them by disallowing them entirely
<0> it is entirely possible that current implementations of CL give you too much frayed rope to stop you from hanging yourself
<5> Krystof: sometimes it's useful...
<3> lukego: but for the first point, it's not usual to destructively manipulate a macro expansion, is it?
<2> and sometimes it tells you it's a frayed knot...
<2> argh argh argh
<3> I can't even imagine a case where you could.
<0> but some of them (e.g. OpenMCL) are likely to have the threads/signals issue sorted out
<4> I'm not a purist so probably if other people's Lisp programs actually started working on my computer I would probably lose all these impressions and celebrate Lisp :)
<1> antifuchs: I don't see why the problem of output-record boundary in the middle of a word should be a problem.
<0> not been playing with gsharp recently?
<6> lukego, i'm using document reader in gnome
<4> eructate: (defmacro foo (&body body) (frob body))
<6> google is able to html-ize it nicely
<3> well, yes, but normally the functions called from macro aren't just general frob-functions, they're frob-code functions specifically for that purpose.
<7> I remember that somebody reported an sbcl bug with compilation of something or the other looping infinitely
<7> and it turned out due to them using mappend on the source code
<4> eructate: "normally" is symptomatic of what I complain about :)
<7> err.. not mappend, but mapcan
<3> honestly I can't sympathize.
<2> beach: the filling-output implementation I worked with here flushes the stuff that is not part of e.g., a presentation before starting invoke-with-new-output-record on the filling-stream; so if the word doesn't fit on the line, it will either be broken in an improper place or extend past the fill-column. both are unpleasant
<3> mmh yes mapcan =(
<0> I can: mistakes happen, and the failure mode should not be catastrophic
<2> but as I said, it would be nice to have (:
<4> Xophe: hm but can you really sort out signals? e.g. it's one thing to make CONS atomic but it's seemingly intractable to make the application-level unstated heap invariants safe
<8> bye
<4> y'know like (defun marry (a b) (setf (so a) b) (setf (so b) a))
<4> jsnell: interesting :-) I had never heard of an actual incident before
<0> lukego: actually that is a fair point. I don't know. (there's a CLOS problem that emarsden found using closure: one thread gets interrupted and asked to do something while it is in the middle of recomputing a CLOS generic function cache)
<0> lukego: well, maybe the app should have to declare its critical sections
<3> boggle
<4> Krystof: Unix has this basically solved if you ignore fine-grained signal handlers. bundle everything together in a process and if it needs to be interrupted then just kill it and toss the whole possibly-broken heap away in a flash of Segmenation fault'age
<0> what does Erlang do?
<4> Krystof: IMO Unix/Erlang have solved this problem ultimately well by providing a new abstraction that is both very easy to "think with" and lacks all of the bad characteristics
<4> in erlang each process/thread has its own heap. there's no interrupt-driven signal handling for corrupting any one heap either
<3> I haven't played with Erlang as much as I had hoped to... are you familiar with Act1 / Omega / Plasma? how does it compare?
<4> if it compared at all with any of those I would probably be familiar with them :-)
<0> I suppose then the answer might be to program in Lisp in erlang-style/Unix-style abstractions
<0> a bit of a glib answer, I concede
<4> lot of loose wires and rules for the programmer to remember
<3> lukego: Those are all Actor languages.
<0> lukego: only until the rules are abstracted properly!
<3> I was unable to discern any difference between the Erlang model and Actors. So I hoped you had a more nuanced idea since you evidently spent some time hacking Erlang.
<4> I see three main ways to solve cl***es of programming error: provide new abstractions to "think in" where the problem can't occur (Erlang), rely on your own disipline of steel and mock "those other people" who slip up (Lisp/C), or keep the dangerous abstractions but bolt on some complicated automated-nagging machine (ML)
<4> eructate: I have no idea what "the Erlang model" is. it's, like, a whole programming language
<3> a short while before, you were saying it solves some problem in an elegant way. I didn't think there would be any ambiguity.
<4> Krystof: well taking the example of "Macros shouldn't modify their arguments" -- isn't this about as helpful as "C functions must not exceed their stack allocations"?
<3> boggle?
<4> ok there is a further important distincation: if a macro modifying its argument in Lisp caused an immediate predictable runtime error instead of "undefined behaviour" (that could in practice be just about anything) then that would reduce the problem by 99% IMO
<3> if lisp had a separation between mutable and immutable objects that might be possible
<4> (you're all witnesses that I invnted the word distincation btw)
<0> eructate: it does
<3> uh, no.
<0> see under "clhs quote"
<3> Baker has a whole paper on that
<3> and why if that distinciton existed there would only need to be one equality predicate
<4> (42 t nil) looks much like a list of immutable objects
<0> admittedly the consequences are unspecified of modifying such an object, but the concept of immutable objects is there
<3> that's not what immutable means.
<1> what prevents an implementation from just putting immuatable objects on a read-only page?
<3> lisp has constant objects but they are not required to be immutable
<3> e.g. programming errors modifying such objects need not be prevented
<0> "The consequences are undefined if literal objects (including quoted objects) are destructively modified."
<4> beach: nothing that I can think of. but not disallowing a solution is different to providing a solution :-)\
<0> eructate: that's not the same as saying that CL doesn't have the separation, just that implementations don't enforce the separation
<3> further, there is no way of programmatically identifying objects not to be modified (which is what luke has been talking about re: macro arguments for the past half hour)
<1> lukego: granted
<0> eructate: quote them
<3> just in case you weren't with us for that
<4> IMO each occurence of "consequences are undefined" is a huge gaping problem in the spec
<0> lukego: for your macros, I agree that the standard macro defining operator is dangerous
<4> or really, each "consequences are undefined" that is left undefined in the implementation is a problem
<0> the difference between the Lisp macro and the C stack is that Lisp allows the definition of a different, safe, macro mechanism by the user
<0> lukego: I agree there
<3> krystof: are you really so clueless that you think quote marks its value to be unmodifiable or are you just being obnoxious?
<0> excuse me?
<0> I am claiming that a valid implementation technique for CL would be, on processing of (quote <anything>), to move <anything> to a read-only area and trap user attempts to modify it
<0> are you saying that that's not valid?
<3> indeed it isn't
<0> why?
<3> (defun test1 () (let ((foo 9)) (declare (special foo)) (test2 'foo)))
<3> (defun test2 (var) (incf (symbol-value var)))
<4> Krystof: these things resist simple solutions in Lisp. how would this work in the case of self-evaluating mutable objects that are used in e.g. EVAL?
<0> eructate: I will concede that there might be issues to sort out with what counts as a destructive modification, and that the symbol value probably isn't one
<1> eructate: you can argue that the symbol is not part of <anything>
<3> not convincingly
<3> also, this business about moving
<1> eructate: well, if it *is* part of it, then you can argue that the package of the symbol is also part of it, and all other symbols in that package, etc.
<3> is not consistent with requirements to not coalesce constants in COMPILE etc
<0> I can solve anything with an extra layer of indirection
<0> I can preserve the objects eqlity even when moving it around the address space
<3> well, I don't know what you are personally able to do, but a copying gc must do that
<0> lukego: was your last question about this same read-only-constant thing?
<4> oh I was just thinking that explaining all the details of quote moving things into read-only space would probably take a 10-page paper to cover :)
<0> I think it probably would, yes
<0> I don't think it is invalid, despite what eructate thinks (so I'm clearly clueless) but it doesn't really solve the problem in any case, because then you will come along and write a macro that mutates the symbol-value slot of something and we're back to square one
<4> but in the end I am not so much worried that e.g. horrible things happen when you modify macro argument lists, but there seems to be a generally feeling that people are not worrying about covering all the cases and are leaving undefined anything inconvenient
<0> lukego: pfdietz had a dream of an implementation which signalled whenever anything undefined happened
<4> I want a system where I can learn by experiment
<0> plt scheme has a beginner's mode
<4> sounds unlikely to be what I want.
<0> well, yeah. You want to learn by experiment, but you don't want to be stopped from using the liquid nitrogen and nitroglycerine
<4> but e.g. in Erlang pretty much everything is defined. e.g. if you say "1 < true" you will get the well-defined result "true"
<4> ok well I guess Lisp will give you a predictabl eerror in that case.
<9> is it still too early for a Practical CLIM book
<4> maybe Emacs would make a better example than Erlang. Emacs is a simple language extended with simple but powerful abstractions (windows, buffers, text with properties, not much else). you can learn the abstractions quite quickly and then you can understand the programs in terms of those abstractions quite easily
<3> in many cases signalling an error depends on "safe or system code" or other considerations
<4> maybe the same is true of CLIM. truly I've spent more time trying to compile it than trying to use it :)
<4> </whiningbastardmode?
<9> i wish there were a shorter synonym of the verb 'canonicalize'
<0> lukego: (< 1 t) is not defined to signal in CL. (Ain't life great?)
<0> not even in safe code
<10> hmm, clisp do signal an error with that?
<0> it is not defined not to signal an error either, hypno
<0> implementations can do whatever they like (except that if they signal an error it has to be a type-error)
<10> a "grey" area in the standard, eh?
<0> no, it's clearly spelt out
<7> clhs 1.4.4.3
<11> http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
<12> Jasko: I think I figured it out... I noticed there is a Lisp menu that appears, but only when you have certain files selected.
<13> rr: intern?
<9> i think i'll go with distill
<9> accdg. to clhs, (ALPHANUMERICP x) == (OR (ALPHA-CHAR-P x) (NOT (NULL (DIGIT-CHAR-P x))))
Return to
#lisp
or
Go to some related
logs:
#asm
wine ubutun
upgrading to glibc2.4 in debian
cannot stat fglrx.ko
Somni is
ubuntu change locales
ubuntu modem scorpio agere softmodem
bcm 4303 ubuntu ndiswrapper
linux thunar symbolic link create
#freedesktop
|
|