ebrasca has quit [Remote host closed the connection]
skin has joined #commonlisp
tyson2 has joined #commonlisp
Krystof has quit [Ping timeout: 264 seconds]
edgar-rft has joined #commonlisp
skin has quit [Ping timeout: 260 seconds]
skin has joined #commonlisp
contrapunctus_ has joined #commonlisp
random-nick has quit [Ping timeout: 252 seconds]
skin has quit [Ping timeout: 276 seconds]
markb1 has quit [Ping timeout: 248 seconds]
skin has joined #commonlisp
markb1 has joined #commonlisp
kagev has quit [Ping timeout: 255 seconds]
kagev has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
kagev has quit [Ping timeout: 253 seconds]
dcb has quit [Quit: MSN Messenger v2.16.1]
tibfulv_ has joined #commonlisp
tibfulv has quit [Ping timeout: 240 seconds]
kagev has joined #commonlisp
pfd has quit [Quit: Client closed]
pjb has quit [Ping timeout: 265 seconds]
tibfulv_ is now known as tibfulv
kagev has quit [Ping timeout: 256 seconds]
skin has quit [Ping timeout: 260 seconds]
kagev has joined #commonlisp
bilegeek has quit [Quit: Leaving]
bilegeek has joined #commonlisp
euandreh has quit [Ping timeout: 260 seconds]
bilegeek has quit [Client Quit]
skin has joined #commonlisp
wilfred has joined #commonlisp
msavoritias has quit [Ping timeout: 240 seconds]
rtoy has quit [Quit: rtoy]
jeosol has quit [Quit: Client closed]
Bocaneri has joined #commonlisp
Bocaneri is now known as Guest2961
Sauvin has quit [Ping timeout: 255 seconds]
Guest2961 is now known as Sauvin
kevingal_ has quit [Ping timeout: 252 seconds]
kevingal has quit [Ping timeout: 252 seconds]
nij- has joined #commonlisp
Brucio-61 has quit [Ping timeout: 260 seconds]
markb1 has quit [Ping timeout: 260 seconds]
jcowan has quit [Ping timeout: 252 seconds]
griffinmb has quit [Ping timeout: 252 seconds]
griffinmb has joined #commonlisp
jcowan has joined #commonlisp
Brucio-61 has joined #commonlisp
markb1 has joined #commonlisp
pjb has joined #commonlisp
<wilfred>
if I define a function (defun has-missing-var (x) y) and call it (has-missing-var 1), the USE-VALUE restart doesn't let me use X.
<wilfred>
am I doing something wrong?
<wilfred>
if I try to use X I just get another UNBOUND-VARIABLE error, but this time for X rather than Y
<jackdaniel>
arguments to a function are passed part of the lexical environment
<jackdaniel>
compiler may and usually will fiddle with these for optimization purposes
<jackdaniel>
on some implementations high debug optimization quality (debug 3) will cause the compiler to make these variables available at runtime like you suggest (but it is not guaranteed)
<wilfred>
interesting, thanks
<wilfred>
on sbcl it looks like (declare (optimize (debug 3))) produces the same behaviour FWIW
<jackdaniel>
I see, then I have no further insight :(
<pjb>
wilfred: it's true about lexical variables being optimized out, but you would also need the restart to be called in the right frame. You have to consider how and where the restart is called.
<pjb>
wilfred: for example, assuming the function read-new-value in clhs restart-case, if the restart is written like this: (restart-case (has-missing-var 1) (use-value (val) :interactive read-new-value val))
<pjb>
then what will happen is that the new expression will be read, and then EVAL is called to get a value!
<pjb>
EVAL evaluates expressions in the NIL lexical environment, ie. it only knows global bindings.
<pjb>
If the parameter is accessible, you'd have to use some implementation specific debuggin function to get access to it.
<pjb>
So it depends on whether EVAL or some other evaluation function is used by the function that reads the new value, and whether you can use a function such as (sb-debug:var 'x) to get the value of the local variable. (I expected this (sb-debug:var 'x) to work, but it doesn't in my sbcl…).
<pjb>
wilfred: ^
czy has joined #commonlisp
shka has joined #commonlisp
euandreh has joined #commonlisp
igemnace has joined #commonlisp
poselyqualityles has quit [Quit: Using Circe, the loveliest of all IRC clients]
Krystof has joined #commonlisp
mgl has joined #commonlisp
czy has quit [Remote host closed the connection]
lucasta has quit [Ping timeout: 252 seconds]
lucasta has joined #commonlisp
jmdaemon has quit [Ping timeout: 248 seconds]
pve has joined #commonlisp
LW has joined #commonlisp
jello_pudding has quit [Quit: WeeChat 3.8]
jello_pudding has joined #commonlisp
foretspaisibles has joined #commonlisp
lucasta has quit [Quit: Leaving]
minion has quit [Read error: Connection reset by peer]
specbot has quit [Remote host closed the connection]
minion has joined #commonlisp
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
wilfred has quit [Quit: Connection closed for inactivity]
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
specbot has joined #commonlisp
Gleefre has joined #commonlisp
<mgl>
I have two loops nested, each with its own implicit block. Is there a somewhat elegant way to RETURN from the outer one when in the inner, or there is no avoiding a RETURN-FROM with a named block? Discounting THROW and such.
<jackdaniel>
you may name the loop so you won't need to explicitly type (block foo ...), other than that I think that it is the most elegant way (to use return-from)
<jackdaniel>
(loop named my-exit repeat 4 do (loop repeat 3 do (print "HI") (return-from my-exit)))
<semz>
tbh I'd find it very counterintuitive if a return (rather than return-from) inside a loop was actually referring to an outer loop
<mgl>
Ah, I didn't know about NAMED. Thank you!
<jackdaniel>
sure
jello_pudding has quit [Quit: WeeChat 3.8]
rogersm has joined #commonlisp
DouglasRMiles[m] has joined #commonlisp
contrapunctus_ is now known as contrapunctus
rgherdt has quit [Ping timeout: 260 seconds]
rgherdt has joined #commonlisp
Krystof has quit [Ping timeout: 252 seconds]
nij- has joined #commonlisp
mgl has quit [Quit: Client closed]
Brucio-61 has quit [Ping timeout: 260 seconds]
nij- has quit [Ping timeout: 246 seconds]
Krystof has joined #commonlisp
Brucio-61 has joined #commonlisp
LW has quit [Quit: WeeChat 3.8]
mgl has joined #commonlisp
Krystof has quit [Ping timeout: 240 seconds]
foretspaisibles has quit [Ping timeout: 245 seconds]
karlosz has joined #commonlisp
beach has joined #commonlisp
dra has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
foretspaisibles has joined #commonlisp
random-nick has joined #commonlisp
beach has quit [Ping timeout: 248 seconds]
rogersm has quit [Quit: Leaving...]
cage has joined #commonlisp
edgar-rft has quit [Quit: Leaving]
morganw has joined #commonlisp
cage has quit [Remote host closed the connection]
zacque has joined #commonlisp
pjb has quit [Remote host closed the connection]
scymtym has joined #commonlisp
pjb has joined #commonlisp
foretspaisibles has quit [Ping timeout: 245 seconds]
kopiyka has quit [Remote host closed the connection]
kopiyka has joined #commonlisp
easye has quit [Ping timeout: 264 seconds]
david` has joined #commonlisp
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
foretspaisibles has joined #commonlisp
scymtym has quit [Ping timeout: 260 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
Gnuxie has quit [Ping timeout: 246 seconds]
luffy[m]1 has quit [Ping timeout: 246 seconds]
JonBoone[m] has quit [Ping timeout: 246 seconds]
loke[m] has quit [Ping timeout: 246 seconds]
foretspaisibles has quit [Ping timeout: 245 seconds]
foretspaisibles has joined #commonlisp
Gleefre has quit [Ping timeout: 245 seconds]
foretspaisibles has quit [Client Quit]
Gnuxie has joined #commonlisp
Brucio-61 has joined #commonlisp
JonBoone[m] has joined #commonlisp
loke[m] has joined #commonlisp
tyson2 has joined #commonlisp
<char[m]>
Is there any hope to reinitialize a built in class like list? I want to add a super class to it that I can then use as a method parameter specializer that will include list and the other siblings.
easye has joined #commonlisp
<mfiano>
No
luffy[m]1 has joined #commonlisp
<Bike>
indeed there is not. but if you just want a new kind of equence rather than a new kind of list, some implementations (sbcl, abcl, clasp) let you do that as a special extension.
<ixelp>
GitHub - Shinmera/trivial-extensible-sequences: Portability library for the extensible sequences protocol
<Shinmera>
char[m]: List is not a built in class, either.
tyson2` has joined #commonlisp
<Shinmera>
Oh wait, it is? heck. I misremembered
<edwlan[m]>
That’s interesting
<char[m]>
I just want list, but be able to call it as different class. This different class should be owned by me (not something like built in sequence; also sequence is just one, what if I want more than just one; also also, sequence is not the concept I'm after). A custom super class added in post seems like the obvious choice. I'm okay doing sacrilegious to get what I want.
<edwlan[m]>
I don’t think it will work
<edwlan[m]>
Even if you could do it
<Shinmera>
just wrap your list in a structure
<edwlan[m]>
What problem are you trying to solve?
<char[m]>
edwlan[m]: If I could do it, then how would it not work?
easye has quit [Ping timeout: 246 seconds]
<edwlan[m]>
Because the system classes are special
<edwlan[m]>
And the rules about them are to allow otherwise unsafe optimizations
<char[m]>
Shinmera: If I wrap, then I have something that is actually not a list and is annoying to work with.
<Shinmera>
Damn, guess I better just stop programming. Too annoying.
<edwlan[m]>
You can make a generic wrapped list structure with the extensible sequences protocol
<Shinmera>
What you're asking can't be done and is a very bad idea. You've been told multiple times now, so maybe it's time to explain what you're actually trying to solve and why so people can give you suggestions that are useful.
<edwlan[m]>
And then treat it like a sequence
<char[m]>
Shinmera: very funny. Your suggestion might end up being my best bet though.
<edwlan[m]>
Typically you don’t need to do this because you can specialize generic functions on any class you like
<edwlan[m]>
So you don’t need a base class for most useful uses of this trick
<mfiano>
Yes, it is a bad idea.
<mfiano>
Also, XY problems are bad in general.
<edwlan[m]>
Which is why you should tell us more about the problem rather than your attempted solution
tyson2` has quit [Remote host closed the connection]
tyson2 has quit [Write error: Connection reset by peer]
<char[m]>
I've already stated what I'm going for. I don't have a specific use case at the moment; I'm going for something a kin to traits as in scala or rust. The new super class would not modify the behavior of the built-in classes.
<char[m]>
I don't think it is really and XY because the whole point is to nominally refer to list+the other siblings. My solution seems to work well for user defined classes; I just hit a brick wall with the built-ins.
<skin>
Traits in rust are just like Golang interfaces, right?
<jackdaniel>
nobody cares
<char[m]>
skin: similar but more static.
<edwlan[m]>
You don’t need this
<skin>
right, right. So it's interesting because
<edwlan[m]>
Generic functions do this without the base class
<skin>
generic functions give you all the power of traits BUT
<char[m]>
jackdaniel: that's okay, it is mainly for my own enjoyment/research.
<skin>
there's to `typep` that you can use to figure out what traits a particular type "has" because
<jackdaniel>
char[m]: I was referring to comparing rust with golang on common lisp channel
<skin>
what functions work with what types are decoupled in Common Lisp
<skin>
jackdaniel: Yeah, but I was getting to the point of explaining what it is in CL
<jackdaniel>
skin: there is a library implementing traits in common lisp
<skin>
char: inheritance of classes is robust though, so if you need `typep` capabilities you can still do that.
<ixelp>
GitHub - scymtym/traits: PROTOTYPE
<jackdaniel>
the header says that it is a prototype, so be warned ,)
<skin>
Fascinating. Will read.
<char[m]>
edwlan: I'm aware, I think it might be nice to be able to say "if a class had this super class, then it is guaranteed to have these methods".
<char[m]>
jackdaniel: thanks, I looked for an existing library before, but couldn't find one.
<edwlan[m]>
That’s just not how object oriented design works in Common Lisp
<skin>
Yes, it would be nice. But generic functions disavow this in favor of flexibility
<edwlan[m]>
You design your application in terms of protocols of generic functions
<skin>
Now you can dispatch based on more than one argument
<skin>
so it's a tradeoff :shrug:
<edwlan[m]>
And then you only define classes when you need a particular specialization.
<skin>
Thinking, though, there are *lots* of things that you _can_ do. symbol property lists come to mind. The use of explicit metadata might solve this conundrum
<mariari>
jackdaniel: huh I was thinking of rolling my own interface system that gave warnings if the user didn't implement all the methods
<skin>
Easy enough to use a design pattern around that problem
<skin>
make a base class with no members, and implement a bunch of generic functions on it, all throwing not implemented errors
<skin>
as I think about it tho that would not solve
<mariari>
skin: yeah I do that with `subclass-responsibility' which mimics the smalltalk behavior
<mariari>
it's not a bad pattern, you just don't get warnings on which methods you haven't implemented yet until it hits the branch
<skin>
Interesting I'll look it up
<jackdaniel>
there is no need to implement methods that signal "not implemented" errors
<jackdaniel>
it is enough to rely on the generic function signaling the no-applicable-method error
jeosol has quit [Quit: Client closed]
<skin>
fair enough.
<jackdaniel>
in CL the operator cl:throw throws, while cl:signal signals - quite different mechanisms both implementation and semantic -wise
<skin>
sorry, mixing my parlance. Of course, "signal" is the proper term
<jackdaniel>
(i.e signal may be "handled" without unwinding the stack)
<skin>
I couldn't wrap my head around signals but then I bought this book and it straightened me out
<ixelp>
The Common Lisp Condition System: Beyond Exception Handling with Control Flow Mechanisms | SpringerLink
<skin>
Would highly recommend
<NotThatRPG>
skin: You can use MIXIN classes to capture things like traits: dispatch generic functions based on the mixin classes that correspond to traits (assuming I correctly know what traits are -- like interfaces in other languages?)
<skin>
yeah
Brucio-61 has quit [Remote host closed the connection]
<jackdaniel>
I think that traits solve quite a different problem
<NotThatRPG>
That's typically what I do...
<skin>
yeah so
<jackdaniel>
namely the problem of /knowing/ that your class /does not/ implement a certain part of the protocol
<skin>
golang interfaces solve two problems. CL generic functions solves one of those problems better than go and the other not at all
<jackdaniel>
(i.e to warn you ahead of time)
<skin>
the first problem is first-argument type-based function dispatch. CL knocks this out of the park
<NotThatRPG>
Oh, traits look sort of like augmenting behavior by attachment/delegation instead of by inheritance?
<edwlan[m]>
You could write a macro that defines a bunch of generic functions at once
<jackdaniel>
also as a side note regarding mixins - ALWAYS put a mixin **before** the base clase
<jackdaniel>
class*
<edwlan[m]>
And errors if you don’t define all of them
<skin>
the second is type introspection. "what functions work on this type?"
<NotThatRPG>
@jackdaniel: +1
pfd has quit [Quit: Client closed]
<mfiano>
Common Lisp has Julia-like interfaces (actually the other way around, but for example purposes)
<skin>
Still scratching my head at hat second one though
<edwlan[m]>
skin: CL solves that
<skin>
Indeed?
<edwlan[m]>
compute-applicable-methods
<edwlan[m]>
Or whatever
<skin>
oh yeah! forgot about htat
<edwlan[m]>
And swank has functions to do the exhaustive search
<skin>
Huh. Well, nevermind then. That's the answer to the trait question then
<NotThatRPG>
edwlan[m]: the one problem with C-A-M is that people sometimes add a default method that raises some kind of unimplemented function error. I have seen a lot of code with that, but I have come to prefer simply getting the no method error...
<edwlan[m]>
M-x slime-who-specializes will show you all the generic functions that specialize
<edwlan[m]>
on that class
<edwlan[m]>
NotThatRPG: yeah
<skin>
I use vim tho :P
<edwlan[m]>
Slimv has this
<edwlan[m]>
(I think)
<edwlan[m]>
But you can call the relevant function from swank
<skin>
oh interesting. I actually don't even use that. I use just the plain old REPL side by side with vim
<mfiano>
Julia solves the trait problem with its implicit interfaces like CL, by ignoring a fundamental design aspect of CL generic functions.
<edwlan[m]>
Not having a connected repl means you're missing out on the CL experience, IMO
<mfiano>
A generic function forms a protocol.
<mfiano>
Or a set of them
<skin>
It's just, I tried it and it felt worse.
<skin>
all it really gives you is the ability to conveniently copy and paste into a buffer, along with some annoying pop-up windows that just make the interface more busy
<mfiano>
Not in Julia. You can't really have that when generic function arity can be overloaded.
<mfiano>
and still be specializable, with complex rules
<mfiano>
Ugh, back to CL :)
<edwlan[m]>
The connected repl gives autocomplete, preciseish jump to definition and “who references”
<edwlan[m]>
Doc popups, etc.
<skin>
jump to definition isn't perfectly solved by vim's `#`/`*`, but close enough. I don't like autocomplete, I use `apropos` and `describe` from the repl well enough. "who references" sounds nice though.
<edwlan[m]>
Jump to definition in slime works for things like DEFMETHOD and such
<edwlan[m]>
I can’t imagine not having it now :)
<mfiano>
Basically generic functions are too general in some languages that try to mimic CLOS, such as Julia, quite a few Scheme implementations of a subset of CLOS, and other languages I've come across. I don't think interfaces as they are found in mainstream languages are the right way to solve the problem they are even trying to solve. It seems more like an admittance of a faulty object model.
<char[m]>
Scymtym's traits library uses method specializers instead of classes. I'm not sure of the semantics of that, but I guess it would not be possible to use it as a type specifier. It also seems to just use defmethod implementing the trait, so I'm not sure how it keeps track of stuff.
<skin>
Well, maybe i'll look into it again. It just felt like more overhead at the time, I'll give it another go. but I've done this in the past and always felt like people are making a big deal out of a glorified tcp-managed copy-paste pipeline
<skin>
still, that does sound interesting
Brucio-61 has joined #commonlisp
<jackdaniel>
method specializer is either a class or an eql-specializer, so you are all good
<jackdaniel>
if one could define a method specializer that looks up an arbitrary type that would be tricky
<edwlan[m]>
I think sbcl has some support for extensible specializes
<jackdaniel>
because you can't decide on the type precedence
<jackdaniel>
(in some cases)
<mfiano>
just do what the real languages do and force it to be known right now: (eql #.(whatever))
<jackdaniel>
for example types (integer 1 10) and (integer 8 15) - which specialization should be used for the integer 9?
<char[m]>
edwlan: it seems to be using that.
<edwlan[m]>
I was wondering about eql specializers the other day: do implementations typically store a strong reference to the method and the object referenced?
<edwlan[m]>
From the generic function
<jackdaniel>
eql-specializer references the object, and the eql-specializer is referenced by its method
<edwlan[m]>
But are they strong or weak references?
<jackdaniel>
(so yeah, usually it won't be garbage collected unless the method is removed)
<jackdaniel>
s/usually//
<edwlan[m]>
If the generic functions were adjusted to use weak references appropriately, that could be fixed, right?
mgl has quit [Quit: Client closed]
<jackdaniel>
all your methods would be garbage collected instantly :)
<edwlan[m]>
The reason I’m wondering is I’ve occasionally thought it would be nice to have a function attach a bunch of methods to whatever you pass into it
<edwlan[m]>
You’d have to store a reference from the object somehow, I guess
<edwlan[m]>
I dunno, it seems like there should be a way to solve this
* jackdaniel
shrugs
<jackdaniel>
(and leaves the office , see you later \o)
<edwlan[m]>
Because a function like (act-as-foo thing) would be useful for some of these sorts of asks
<edwlan[m]>
But would cause gc issues otherwise
lucasta has joined #commonlisp
_cymew_ has joined #commonlisp
tyson2 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<char[m]>
mfiano: why do you say it's a bad idea to add a behaviorless superclass to a built-in class? I would just like to understand better.
radioseven has joined #commonlisp
riccardocariboni has joined #commonlisp
riccardocariboni is now known as nakuaga
nakuaga has quit [Quit: nakuaga]
nakuaga has joined #commonlisp
<mfiano>
Sorry, but I'm not really sure how to teach that any better than we already did.
cage has joined #commonlisp
dcb has joined #commonlisp
nakuaga has quit [Ping timeout: 252 seconds]
nakuaga has joined #commonlisp
nakuaga has quit [Ping timeout: 248 seconds]
radioseven has quit [Ping timeout: 265 seconds]
ebrasca has joined #commonlisp
masinter has quit [Ping timeout: 240 seconds]
masinter has joined #commonlisp
attila_lendvai has joined #commonlisp
jello_pudding has joined #commonlisp
ns12 has joined #commonlisp
skin has left #commonlisp [#commonlisp]
Bocaneri has joined #commonlisp
Bocaneri is now known as Guest8107
Sauvin has quit [Ping timeout: 276 seconds]
attila_lendvai_ has joined #commonlisp
attila_lendvai has quit [Ping timeout: 248 seconds]
mason has left #commonlisp [#commonlisp]
jello_pudding has quit [Ping timeout: 252 seconds]
tyson2 has joined #commonlisp
pjb has quit [Remote host closed the connection]
tyson2 has quit [Remote host closed the connection]
cage has quit [Quit: rcirc on GNU Emacs 28.2]
tyson2 has joined #commonlisp
Krystof has joined #commonlisp
tyson2 has quit [Ping timeout: 240 seconds]
tyson2 has joined #commonlisp
pfd has joined #commonlisp
lucasta has quit [Read error: Connection reset by peer]
Krystof has quit [Ping timeout: 240 seconds]
nij- has joined #commonlisp
Jach has quit [Ping timeout: 265 seconds]
jello_pudding has joined #commonlisp
jello_pudding has quit [Client Quit]
jello_pudding has joined #commonlisp
Cymew has quit [Ping timeout: 246 seconds]
Jach has joined #commonlisp
_cymew_ has quit [Ping timeout: 265 seconds]
Krystof has joined #commonlisp
sjl has quit [Quit: WeeChat 3.6]
ebrasca has quit [Remote host closed the connection]
sjl has joined #commonlisp
kevingal has quit [Ping timeout: 265 seconds]
jeosol has joined #commonlisp
kevingal_ has quit [Ping timeout: 276 seconds]
nij- has quit [Ping timeout: 260 seconds]
Bocaneri has joined #commonlisp
Bocaneri is now known as Guest4154
nij- has joined #commonlisp
Guest8107 has quit [Ping timeout: 240 seconds]
Krystof has quit [Ping timeout: 240 seconds]
Guest4154 is now known as Sauvin
chrcav has quit [Ping timeout: 255 seconds]
chrcav has joined #commonlisp
Krystof has joined #commonlisp
attila_lendvai_ has quit [Ping timeout: 246 seconds]
pfd has quit [Quit: Client closed]
shka has quit [Ping timeout: 250 seconds]
tyson2 has quit [Ping timeout: 260 seconds]
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
jeosol has quit [Quit: Client closed]
skin has joined #commonlisp
bjorkintosh has quit [Quit: Leaving]
Krystof has quit [Ping timeout: 240 seconds]
jeosol has joined #commonlisp
ebrasca has joined #commonlisp
kevingal has joined #commonlisp
ebrasca has quit [Remote host closed the connection]
kevingal_ has joined #commonlisp
morganw has quit [Remote host closed the connection]
rgherdt has quit [Remote host closed the connection]