freenode/lisp - IRC Chatlog
Search
20:34:56
shka_
i would rather call a generic function then play around with different ways of selecting restarts
20:38:08
dbotton
_death from that post "if you want the compiler to smack you in the face if you do it anyway, I'd say you have an attitude problem that needs readjustment" - I wonder what that says about me...
20:40:33
phoe
shka_: conditions are more or less extension points; they're equivalent to generic functions, especially with this approach that beach and scymtym have been using recently, e.g. inside eclector
20:40:58
phoe
where you have a client of sorts as an argument to each GF, and you can specialize on it to add your own functionality
20:41:13
phoe
and then you have a *client* dynavar that you can rebind to turn this functionality on or off
20:41:18
_death
dbotton: also check his next message in the thread (the one mentioning epistemological assumptions)
20:43:10
shka_
phoe: in theory yes, but in practice i find them usually worse option for the extension
20:44:21
phoe
if it's conditions, then to be honest, so do I - the GF approach is cleaner wherever you know what your code should do at a given moment
20:45:44
scymtym
i found the condition system uniquely suited to this: https://github.com/scymtym/more-conditions#tracking-and-reporting-progress-of-operations
20:48:19
shka_
overall, i think that condition system is pretty much specialized tool that can be pressed into service for other tasks
20:48:45
phoe
the condition system is handy when your code doesn't have full information about how it should act
20:48:57
scymtym
shka_: sure, but i didn't find the complications from threads problematic in practice. more like a cost paid once for being able to report progress of operations from anywhere in the code (and having the same code work fine if progress notification are not handled)
20:49:12
phoe
if you don't have really exceptional situations then standard control flow is enough in all cases, by definition
20:52:01
shka_
i just propose to skip the extra crust for things that are not exceptional situations
20:53:01
phoe
sure, the only real practical advantage there is that HANDLER-CASE and SIGNAL are already built-in so you don't need to define your own dynavar and use it
20:54:28
dbotton
is seems a bit more readable then a dynavar but that could be because I am not used to seeing it
20:56:03
dbotton
I think this shows the colossal failure of trying to translate c/ada/pascal etc -> lisp they are way to different
20:57:08
dbotton
I still keep adding notes to myself, but there is clearly reason no one has done a simple chart like between c <-> pascal etc
21:00:30
shka_
cl is actually not that difficult to learn, and the only major obstacle is that it is different
21:03:58
dbotton
I obviously am getting the basics, but mastery like all things takes time, and changing the pattern of software design is the more difficult part
21:05:17
dbotton
_death "I actually think C++ is ideal only for programmers without any ethics." ..... ugh....
21:07:06
dbotton
This has been one of those moments between those two posts and today to realize that I just flew to a foreign land and foreign customs and "patients grass hopper" said to me by some ancients many times
21:09:18
p_l
phoe: Scheme is literally, at its base, a language you're supposed to learn in one university lecture
3:59:42
beach
scymtym: I like the idea of using conditions for reporting progress. Never thought about that.
7:48:44
beach
phoe: It's your fault. Because of your message about the book, I now can't get the song by the Who "I'm free" out of my head.
8:24:10
scymtym
beach: yeah, as i said, it worked very well for me. but as shka_ mentioned, a little extra work is needed to make the approach work across multiple threads