libera/#commonlisp - IRC Chatlog
Search
9:34:04
pve
Is there a function similar to "(setf macro-function)", but for symbol macros? I.e. something that can be used to install a symbol macro.
9:43:01
pjb
pve: there is not. You have to use the macro define-symbol-macro. You could do: (defun (setf symbol-macro) (new-expansion symbol) (eval `(define-symbol-macro ,symbol ,new-expansion))) and (defun symbol-macro (symbol) (macroexpand-1 symbol)) (symbol-macro 'foo) #| --> foo ; nil |# (setf (symbol-macro 'foo) '(car koo)) #| --> foo |# (symbol-macro 'foo) #| --> (car koo) ; t |# (let ((koo '(a . d))) foo) #| --> a |#
9:43:37
pjb
pve: but only for global symbol macros. For lexical symbol macros, you have to use symbol-macrolet.
9:44:22
pjb
Since macros are compilation-time objects, local symbol macros still have to be known at compilation-time, so you cannot use setf to mutate them.
13:52:08
lisp123
Would it have been smarter for CL to define all of its functions as defgenerics / defmethods instead?
13:56:13
_death
no, that wouldn't be particularly smart.. a generic function serves a dual role, one for callers and one for extenders.. simply taking an ordinary, nonextensible function (with a contract for callers) and making it generic would get you the worst of both sides
13:58:14
lisp123
pve: thanks, makes sense - I guess there is a cost of "looking up" the correct method to apply each time
13:58:59
lisp123
_death: could you expand? is it the loss of clarity from having different versions of a given function?
14:03:11
_death
consider a function like EQUAL.. for each pair of objects you can pass to it, there is a rule saying whether it returns true or false.. callers of EQUAL can rely on these fixed semantics.. if you just make it generic, suddenly EQUAL becomes some amorphous function that isn't very useful to callers.. consider function +.. making it a generic function would not be useful for extension, because it accepts any number of terms (including
14:06:57
_death
often you need to create one function that is meant to be called, and another function or set of functions that are meant to be extended
14:07:43
_death
could CL be more extensible? yes, but that work would involve much more than making all functions generic
14:10:57
_death
for an example of parroting caller interface with "shadow" GFs, look at Gray Streams.. the interface for extension is pretty similar to what the callers have, with some tweaks like different behavior on EOF or such.. some of the bad consequences are described in Franz's simple-streams section in their manual
14:11:46
lisp123
_death: "and you wouldn't want to specialise on every term" >>> Perhaps my understanding of generic functions is incorrect (likely), but from what I understand (and I was trying to google it now), if there is no method defined for the class in question, the method for a class it inherits from is used? i.e. the most specialised method is used
14:13:08
_death
lisp123: what I mean is, suppose you wanted to extend to vectors.. how would you define a + method for doing that..
14:13:26
beach
This discussion is a great example of why language design is hard, and why we need to be very careful before thinking that suggested changes are automatically good.
14:14:09
_death
lisp123: the solution in case might be to define two generic functions, UNARY-+ and BINARY-+ and have + call them as needed.. so one interface for callers and another for extenders
14:14:58
lisp123
_death: so to summarise, functions are meant to be called and we don't want to change their meaning, while generic functions are meant to be "user-defined" and when one sees it, they work with them in mind. Hence, its not good to make standard functions customizable, especially when multiple people work on the same codebase?
14:15:42
_death
lisp123: the point is that you don't always need or want to make things extensible, and when you do, you need to think it through
14:16:02
lisp123
beach: yes :-) I find one of the great beauties of Lisp is its clarity of concepts, that even mere mortal users start thinking at a higher level (and that helps improve their abilities - even though 90% of the time they are wrong ;)
14:17:46
beach
lisp123: What I find most impressive about Common Lisp is that, the more I study it (in order to implement it), the more I am impressed by how smart and knowledgeable the people were who created the standard.
14:18:20
lisp123
(my example came from writing my own 'remove-duplicates' for a certain list of objects and trying to avoid having to use a custom name such as remove-object-duplicates)
14:18:47
beach
lisp123: It has taken me decades to understand the language well enough to hope to implement it. It will take me another couple of decades to acquire enough knowledge to improve it.
14:20:19
lisp123
beach: at least you will know that what you are doing is on the frontier of Computer Science, whilst other languages keep re-applying the old concepts that CL already worked through
14:25:04
_death
more reasons that CL isn't very extensible in some parts is that it's an evolutionary step and had to take backwards compatibility into account.. also, CLOS was a new design and not everyone had lots of experience with it, and the idea of a CLOS-less subset of CL was in the air as well
14:27:00
beach
pve has a point as well, given that PCL was the best they could do at the time in terms of generic dispatch, generic functions would have had a significant cost associated with them.
14:28:09
lisp123
beach: nice, his article(s) on exceptional situations in lisp were A+, although I must admit I can't be bothered using conditions when I code lol (although I might for one use-case soon: when I use somebody else's packages and am not guaranteed of the behaviour of that package)
14:28:29
beach
That's part of what impresses me with the language. They didn't include features that they weren't absolutely sure could be implemented efficiently. Unlike people who create other languages like Python.
14:29:37
lisp123
Indeed, I think especially given the circumstances of processing power in the 70s and 80s
14:29:55
_death
if you have a language like Go, which didn't need to care for any previous codebases, you can see that some parts of its standard library are designed with extensibility in mind that makes things very convenient after adoption.. in CL you can create de-facto standards of extensibility, and it has more powerful tools to adapt the language, but it's more evolutionary and less "intelligent design".. of course, as time goes by, Go has to
14:30:32
lisp123
beach: I write 95% of my code, so I keep it all in my head and make sure it all works - as long as I don't open it up to the outside world, it hasn't been too much of an
14:31:29
beach
lisp123: Oh, dear. You must have debugging nightmares, with incorrect results propagating way too far along the way.
14:33:23
lisp123
beach: lol ;) I'm learning by struggling :-) I'm doing a lot of very conceptual work, so there are less moving pieces and rote code, so for now I'm spending all of my limited energy on the problem at hand. I think as my program evolves, I will switch over to a more robust phase
14:35:07
beach
I recommend the work of Bertrand Meyer about modularity. He made a lot of concepts clear, like preconditions, invariants, exceptional situations.
14:37:23
lisp123
I would say a little bit above newbie, but not professional. I dropped out of IT in University (switched to business), but I do all front-end web dev work without probolem and created my own (somewhat popular :) ) apps in Swift for IOS
14:38:24
beach
Here is a short description of his work: https://en.wikipedia.org/wiki/Design_by_contract
14:38:30
lisp123
but no formal training, so a lot of stuff I do very badly (error handling and writing proper commit messages seem to be common ones), and wouldn't be able to work in a team for sure
17:02:38
lotuseater
beach: Why did you choose the BSD license for SICL? (I don't know much about licensing yet.)
17:15:37
lisp123
(sorry to continue this topic among us non-lawyers, buts its an interesting one), but that would imply all emac packages are GPL?
17:16:08
lisp123
whereas people do release their packages under other licenses, so perhaps their view is different
17:18:43
jackdaniel
gpl seems to be often disregarded with passion based on fueled fud (me ceases offtopic ;)
20:45:06
aeth
Personally, I use permissive licenses for CL stuff where I'd consider the GPL in other languages because I want to encourage people to use CL. YMMV.
20:46:32
aeth
jfb4: I mean, if someone has to load up ECL to interface with some big, proprietary C/C++ program because they really, REALLY want to use my code, I consider that a win for CL.
20:59:50
aeth
You could use LGPL but idk how it would interact with being embedded as part of ECL, rather than as a separate C/C++ library
20:59:54
edgar-rft
it *can* be used with proptietary code but only when the proprietary code is laid open, too, what in practice is very unlikely to happen :-)
21:00:07
aeth
But always make sure that your code runs in ECL even if you never use it, at least imo
21:00:18
aeth
Because if a C programmer really, really wants your code, they're going to have to use ECL
21:04:45
jackdaniel
I have it fixed, but here comes an interesting (to me) fail: (loop for key in keys for pos = (position key head) collect (lambda (elt pos body)))
21:05:53
jackdaniel
because pos is modified destructively by loop, all collected lambdas will see the same pos value