<Bike>
jcowan: oh, the semantics... i see. i have actually considered it before in the scheme arguments context. i was trying to come up with a decent IR
pranavats has joined #commonlisp
snits has quit [Ping timeout: 268 seconds]
jolby has quit [Quit: Client closed]
jolby has joined #commonlisp
snits has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
Oladon has quit [Quit: Leaving.]
jmdaemon has joined #commonlisp
<beach>
aeth, nij-: pjb is right. For a list, use (result '()). (result nil) means that result is initialized to be a Boolean value or a default value.
Oladon has joined #commonlisp
<aeth>
:o
<aeth>
I always thought that the WWBD (what would beach do) would be (result (list)) instead
<aeth>
seems the most 'object oriented' I guess?
<beach>
aeth: In no way does (result '()) suggest immutability. How could you build up an immutable list? It would have to be mutated to be built.
<aeth>
you would probably build up an immutable list from '() with tail recursion and CONS (or LIST*), probably contained to a LABELS, although that's not fully portable because tail recursion might not work
<aeth>
in a functional way, anyway
<beach>
The control structure being used does not influence mutability. And Common Lisp does not have an operator to turn a list you built up into an immutable one.
<aeth>
yes, it's just by convention
<aeth>
sadly. Would be nice if literals were checked outside of function/file scope because mutating them can cause issues.
<beach>
I thought I saw some information that SBCL now allocates literals in read-only space. Or did I just dream that?
<aeth>
oh, maybe my SBCL is too old
<aeth>
they update monthly; I don't
<beach>
Me neither.
<Bike>
it does that as of 2.2.7, which is from the end of july
<aeth>
I got warnings (that still worked) when I mutated literals in the REPL (and if you mess around with it just a bit and e.g. pass it into another function to SETF it there, you can make it not even warn)
<aeth>
2.2.4
<beach>
Yes, that would be undecidable.
<aeth>
but at least it should fail at runtime instead of mutating literals
<aeth>
if that's what it does now
<beach>
That's the only option, as doing it at compile time would be undecidable.
<aeth>
It would be interesting to see whose code breaks
<Bike>
i wonder if putting it in read only space might actually make it easier to detect illegal mutations. since if the constant is just in normal space it could be interleaved with non-constants, so you can't just guard the whole page or whatever
<beach>
At compile time you mean?
<smlckz>
have a look at the simpson function: http://sprunge.us/A6QOpA how can i make the inner loop faster?
<aeth>
just run your program in compile time and you can do anything at compile time :-p
<aeth>
EVAL-WHEN is magical
<Bike>
i meant runtime detection
<Bike>
since compile time detection is obviously impossible as you said
<Bike>
no matter how many times you run it at compile time
<aeth>
(if anyone is missing my joke, it would be done at compile time... for the file that calls it inside of an EVAL-WHEN, but that would in effect be the run time of the relevant function calls... I think)
<aeth>
(then just store the final output in a constant, too, and you get a very fast runtime program at the cost of compile time)
<beach>
Bike: Not sure what you mean. The fact that the space is read-only would be enough to detect attempts to mutate. You would get a signal at the OS level.
<Bike>
yeah, i was just wondering if keeping it in read only memory would make detection easier than not doing so
<Bike>
and i suppose the answer is yes
<Bike>
just thinking back to the times i've had very frustrating problems that turned out to be due to accidentally mutating a literal
<beach>
Yeah, those are tough ones.
<jcowan>
I'm struggling now with Scheme's rules about immutability: a literal can be mutable or immutable depending on the implementation
<aeth>
Bike: wouldn't you have to add to the type tag otherwise?
<aeth>
I mean, if you didn't do it the way this is currently being done
akoana has joined #commonlisp
<Bike>
aeth: what are you talking about
<Bike>
if you mean a new type/tag for immutability, you wouldn't necessarily need that, since you could rely on low level os traps like beach said
SR-71 has joined #commonlisp
<smlckz>
are features a good way to implement something like `#ifdef debug\n <print statements>\n #endif`?
anticomputer_ has quit [Quit: quit]
anticomputer has joined #commonlisp
jolby has joined #commonlisp
kuao has quit [Quit: Connection closed for inactivity]
SR-71` has joined #commonlisp
SR-71 has quit [Ping timeout: 244 seconds]
<beach>
smlckz: That would fairly quickly make the code incomprehensible.
tyson2 has quit [Remote host closed the connection]
<beach>
smlckz: Ideally, you would use a debugger to debug your code. Unfortunately, the FLOSS Common Lisp implementations are not very good with debugging support. See my paper http://metamodular.com/SICL/sicl-debugging.pdf in which I describe the state of things.
<beach>
smlckz: Another problem with your idea is that the output you get when you activate the debug flag will be huge, and very likely at the same time not enough for the problem you are trying to debug.
<beach>
smlckz: Yet another problem is that you would need to recompile the code to activate the debug flag. So you are not debugging the same code as the one that exposed the problem.
SR-71 has joined #commonlisp
SR-71` has quit [Ping timeout: 244 seconds]
<beach>
smlckz: You are better off adding a (BREAK) in the code you want to debug, and then hitting C-c C-c in SLIME to activate it. It doesn't solve the fundamental problem, but it is better than many other ideas.
szkl has quit [Quit: Connection closed for inactivity]
makomo has quit [Ping timeout: 265 seconds]
cosimone has joined #commonlisp
cosimone has quit [Remote host closed the connection]
azimut has joined #commonlisp
aartaka has quit [Ping timeout: 264 seconds]
aartaka has joined #commonlisp
ebrasca has joined #commonlisp
cosimone has joined #commonlisp
ec has quit [Quit: ec]
ec has joined #commonlisp
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
jolby has quit [Quit: Client closed]
shka has joined #commonlisp
aartaka has quit [Ping timeout: 265 seconds]
aartaka has joined #commonlisp
jmdaemon has joined #commonlisp
morganw has joined #commonlisp
son0p has quit [Killed (NickServ (GHOST command used by son0p-))]
son0p has joined #commonlisp
son0p has quit [Killed (NickServ (GHOST command used by son0p-))]
son0p has joined #commonlisp
son0p has quit [Killed (NickServ (GHOST command used by son0p-))]
son0p has joined #commonlisp
son0p has quit [Killed (NickServ (GHOST command used by son0p-))]
son0p has joined #commonlisp
son0p has quit [Killed (NickServ (GHOST command used by son0p-))]
son0p has joined #commonlisp
cosimone has quit [Remote host closed the connection]
luna-is-here has quit [Quit: luna-is-here]
tyson2 has quit [Remote host closed the connection]
thuna` has joined #commonlisp
luna-is-here has joined #commonlisp
son0p has quit [Remote host closed the connection]
son0p has joined #commonlisp
cosimone has joined #commonlisp
orestarod has joined #commonlisp
Gnuxie_ has joined #commonlisp
tyson2 has joined #commonlisp
cosimone` has joined #commonlisp
cosimone has quit [Ping timeout: 250 seconds]
ttree has joined #commonlisp
jmes has joined #commonlisp
<jmes>
Is there a way to make an array with only one type in it such that I can define a method on arrays containing only that type?
<jmes>
Sorry that's kind of two questions in one. To be more clear I'm interested in the second question and thought the first was a way to get there.
<jmes>
i.e. I want to have (fn type-1-array) match a different method than (fn type-2-array).
<Shinmera>
methods match on classes, not types.
<Shinmera>
so no, you cannot, at least not with CLOS. There's other projects out there that do that stuff, but I haven't used any of em so I can't vouch.
<jmes>
Shinmera: Ah gotcha, also I didn't forget about the Kandria feedback I owe you. I've been so busy for the last few weeks (and will continue to be for a while...)
<Shinmera>
That's alright, you don't owe me anything :) Any help is appreciated
<jmes>
Well I'm on the winning side trading some feedback for the experience ;)
<Bike>
jmes: what are you trying to do overall? it's possible you could do something like e.g. define struct wrapper classes to specialize on
<Shinmera>
Yeah I've done the struct wrapping for a number of things but it always feels dirty :(
<Shinmera>
Particularly if all you want to wrap is a single value. Ech.
<jmes>
Bike: Yeah I think that could be viable solution, but I hold the same sentiment as Shinmera.
<Shinmera>
Another, possibly worse thing, is to store the "type" in the first element of the array, though then the array can't be specialised anymore. The function would then use that first element to pass it to a secondary gf which then dispatches on it.
<jmes>
That could work too but makes the code more complex for the other operations on the array
<Shinmera>
Finally you could read out the first element, use type-of and then again pass to a secondary gf.
<Shinmera>
caveat of that is it only works for arrays with at least one element.
<Shinmera>
you can trade that caveat if you know for sure your arrays in question are specialised. in that case you can use array-element-type.
<jmes>
To answer your question, Bike, I have some cl-autowrapped C arrays of different types and I want a generic function to extract their elements to lisp arrays or lists or whatever works best. I may just make different extraction functions for each.
<Shinmera>
In that case you could use extensible sequences and define a type per array type, which holds the pointer and extracts or sets elements "on the fly"
<Shinmera>
rather than actually translating the array to lisp.
<Shinmera>
I've done that in cl-gltf, for example.
akoana has joined #commonlisp
<jmes>
I'm intrigued, but I'm not informed enough fully digest what that means. I think you've given me enough keywords to start learning though.
<Shinmera>
it's a protocol to define new sequence types
<jmes>
Thanks, I happen to have just opened that page
<Shinmera>
so you just write functions that translate, say, (elt array n) into (cffi:mem-aref (pointer array) :float n)
<Shinmera>
and so forth.
Krystof has quit [Ping timeout: 268 seconds]
cowboy8625 has quit [Ping timeout: 244 seconds]
<jmes>
So ARRAY here is just a pointer straight out of autowrap? This would be perfect I think.
<Shinmera>
no, array is a struct or class you define that holds the pointer.
<Shinmera>
you need a custom type.
<Shinmera>
but you can then treat that instance as if it were a sequence in user code.
asarch has quit [Client Quit]
<jmes>
Okay gotcha, I see what to do on your trivial-extensible-sequences page
<Shinmera>
of course, you trade this for all the perils that come with foreign memory allocation.
<jmes>
Yeah, I have other functionality in place for memory management already. This should fit into my current model on the lisp side of things.
<Shinmera>
Cool :)
cowboy8625 has joined #commonlisp
<jmes>
heavy italics on *should*
<Shinmera>
I have yet to figure out a good allocation model for Alloy :(
<Shinmera>
for Trial I have one that "works" but I'm not exactly happy with it.
<jmes>
I'm interested in Alloy, I will take a deeper look at it one day... Perhaps when I have a more skilled eye.
<jmes>
For what I'm doing memory management is implemented rather simply, and there is certainly room for error since a user could free stuff on their own if they wanted.
<jmes>
It's something along the lines of: initialize this stuff in this scope, execute body, free this stuff on leaving scope. But a little more fancy.
<Shinmera>
well if you can do everything in dynamic extent then yeah it's pretty simple :)
tyson2 has quit [Remote host closed the connection]
<Shinmera>
Though it does also force certain annoying patterns onto code.
<jmes>
Yeah I'm not able to do everything in dynmaic extent but the default behaviour is to assume that's what the user wants and then there is some complexity added to facilitate other approaches.
<lagash>
beach: nice paper, it says "The technique presented in this paper is yet to be implemented" but that's two years old, no? What's the status these days?
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 244 seconds]
cosimone` has quit [Ping timeout: 268 seconds]
Everything has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 252 seconds]
Lord_of_Life has joined #commonlisp
prokhor__ has quit [Ping timeout: 260 seconds]
Josh_2 has quit [Ping timeout: 248 seconds]
makomo has joined #commonlisp
<lagash>
or should I ask that on #sicl ?
rgherdt_ is now known as rgherdt
waleee has joined #commonlisp
cowboy8625 has quit [Quit: WeeChat 3.5]
<Shinmera>
You'll probably get a response when he's awake.
<Bike>
which paper is this?
cercopith__ has quit [Remote host closed the connection]
igemnace has quit [Remote host closed the connection]
kuao has joined #commonlisp
cosimone has joined #commonlisp
<mathrick>
it's a bit crummy that NIL is not a valid method qualifier (because it's a list, so it's indistinguishable from an empty lambda list)
<mathrick>
makes it hard to do stuff like (defmethod my-function-with-custom-combination :destroy-all-humans nil () ...)
cage has quit [Quit: rcirc on GNU Emacs 27.1]
tyson2 has joined #commonlisp
tyson2` has joined #commonlisp
<Shinmera>
can just use NULL for that
<Shinmera>
oh wait, nvm
jolby has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
morganw has quit [Remote host closed the connection]
<jcowan>
Yes, not much point in specializing on objects of type NULL.
zyni-moe has joined #commonlisp
<Shinmera>
that's noth what I meant.
<Shinmera>
but also there is, if you want to catch NIL.
<mathrick>
jcowan: actually, there is a very good point, because NIL is actually a symbol before it's a list, so you need NULL if you want to treat symbols differently from lists
<mathrick>
but in this case, it's not a type
zyni-moe has quit [Client Quit]
aartaka has quit [Ping timeout: 264 seconds]
<jcowan>
Oh, I was mixing up type NULL with type NIL (which of course is not a class; why would it be?)
_cymew_ has quit [Ping timeout: 265 seconds]
Guest5933 has quit [Quit: WeeChat 3.6]
tyson2 has quit [Remote host closed the connection]
Oladon has joined #commonlisp
tyson2` has left #commonlisp [ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
tyson2 has joined #commonlisp
Everything has quit [Quit: leaving]
rgherdt has quit [Remote host closed the connection]
causal has joined #commonlisp
orestarod has quit [Ping timeout: 268 seconds]
shka has quit [Ping timeout: 265 seconds]
orestarod has joined #commonlisp
aartaka has joined #commonlisp
OlCe has joined #commonlisp
aartaka has quit [Ping timeout: 250 seconds]
thuna` has quit [Remote host closed the connection]
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
pve has quit [Quit: leaving]
son0p has quit [Ping timeout: 268 seconds]
Oladon has quit [Quit: Leaving.]
sjl has quit [Ping timeout: 252 seconds]
Gnuxie_ has quit [Quit: Leaving]
sjl has joined #commonlisp
puchacz has quit [Quit: Client closed]
pillton has joined #commonlisp
Andrew has joined #commonlisp
orestarod has quit [Ping timeout: 268 seconds]
szkl has joined #commonlisp
sjl has quit [Ping timeout: 268 seconds]
Oladon has joined #commonlisp
flip214 has quit [Read error: Connection reset by peer]