pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
ln43 has quit [Quit: Connection closed]
Skyfire has quit [Ping timeout: 250 seconds]
Skyfire has joined #commonlisp
pve has joined #commonlisp
tophullyte has quit [Ping timeout: 248 seconds]
amb007 has quit [Ping timeout: 248 seconds]
amb007 has joined #commonlisp
psycomic has joined #commonlisp
<beach>
Generic functions are great not just because of what they are typically used for, but also because one can separate the definition of the function from its implementation, so that one can collect DEFGENERIC forms in a place where the protocol for a module is defined.
<beach>
Is there an analogous operator that can be used for ordinary functions? I am thinking maybe proclaiming its FTYPE or something like that.
<beach>
If not, and suppose we have fast generic dispatch, would it sometimes be a good idea to use a generic function where an ordinary function would work?
<hayley>
I think I've seen something like (defun name (lambda-list ...) (error "Should be replaced by now")) which is later redefined used in some bootstrapping scheme.
<beach>
Yeah, that will work too. But it's a bit unappealing.
<hayley>
Sure.
<beach>
Using a generic function in place of an ordinary function clearly violates the general rule that one should use the most specific construct that will have the desired effect.
gaqwas has quit [Ping timeout: 248 seconds]
contrapunctus has quit [Ping timeout: 240 seconds]
contrapunctus has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 276 seconds]
contrapunctus has left #commonlisp [#commonlisp]
<pl>
beach: I could see it hacked together with MOP - someone made a MOP-based package that precomputed dispatch in exchange for less runtime flexibility, but some of the mechanism could be reused
* pl
meanwhile wishes *features* conditionals weren't so popular in ASDF
<kakuhen>
#-(or everything you do not have) (uiop:not-implemented-error "some stuff i want")
<pl>
Trying to look into integrating lisp in bazel without SBCL-specificness of existing rules_lisp stuff or manually writing build files
<beach>
pl: I know how to make generic dispatch it efficient. I was wondering whether 1. There is a thing that can be done for ordinary functions, or 2. It would be acceptable to use a generic function instead?
<beach>
s/it//
<pl>
beach: now that I think of it, wouldn't a plain macro modifying the symbol slot be enough?
<beach>
Maybe so. That's what the temporary DEFUN does, no?
<beach>
But then it is likely that I get a warning when the function is (re-)defined.
<saturn2>
you could use a macro that ignores its input and does nothing
rain3 has joined #commonlisp
<beach>
I also want this construct to be used to verify calls and to avoid compile-time warnings when the function is called before the real one is defined, just like the pair DEFGENERIC/DEFMETHOD works.
<beach>
Otherwise, I could just put in a comment.
<beach>
That's why I was thinking of proclaiming an FTYPE.
<beach>
But that might not do the trick. And the effect may be implementation specific.
amb007 has quit [Ping timeout: 248 seconds]
amb007 has joined #commonlisp
<pjb>
beach: if you want to do that for normal functions, you can do it with (declaim (ftype (function (type-arg-1 … type-arg-n) type-result) fun1 fun2 ..)
<pjb>
)
<pjb>
beach: oh, that's what you mentionned eventuall :-)
<beach>
Yes, thank you. I think I could have figured that out. I was wondering whether it would have the desired effect, if the effect is standardized, whether there are any downsides to it, etc.
<pjb>
Well it has the effect that the compiler won't complain about "undefined" functions if it's not defined in the same compilation unit and not loaded before compiling the current unit.
<pjb>
But granted, it may be dangerous as any use of type declarations in CL: the compiler may assume you are guaranteeing the types, and skipping checks.
<beach>
Good point.
<pjb>
So perhaps we should use a custom declaration or macro.
<beach>
Maybe so. Thanks!
<pjb>
some package use macros definterface defimplementation, that validat that all the functions in definterface are implemented eventually (portabilityh packages using different backends often do that).
<pjb>
eg. swank, quicklisp.
contrapunctus has joined #commonlisp
<beach>
So let me think about the aspects I like about the DEFGENERIC/DEFMETHOD pair. First, with DEFGENERIC, the function exists, so the compiler can check calls to it. Second, the DEFMETHOD does not redefine the function, and the lambda list of the DEFMETHOD form must be congruent with that of the DEFGENERIC form.
<beach>
I guess a type proclamation with T being the only type might work then.
<pjb>
Hey! swank implements a body that will call an implementaiton provided or default implementation obtained from the symbol-plist of the functioname (defimplementation just store the new function in that symbol-plist), while quicklisp uses defgeneric/defmethod.
<pjb>
beach: yes. It's the less risky.
<pjb>
but if you want to be more precise/informative, using custom declarations (and have some tooling to process them) can be a good solution too.
<beach>
Is there a (preferably maintained) version of the Common Lisp pretty printer available online?
<beach>
I could go copy the code from some existing Common Lisp implementation, but if it exists in the form of a portable library, that would be idea.
<beach>
Should paragraph 6 be "The logical block immediately containing a conditional newline..." rather than "The section immediately containing a conditional newline..."?
attila_lendvai_ has quit [Remote host closed the connection]
attila_lendvai_ has joined #commonlisp
<edgar-rft>
lisp123_: no, they typed it blindly and no-one ever proof-read it
<lisp123_>
edgar-rft: I see. I saw some positive reviews (but its only a sample of 2 or 3 so doesn't say much), but there isn't really a copy available online to check
<beach>
It was apparently publish before the standard.