libera/#commonlisp - IRC Chatlog

21:12:43 Bocaneri ** NICK Guest7626

21:14:58 Guest7626 ** NICK Sauvin

21:21:57 dbotton I am trying to understand what (declare dynamic-extent XXX) is used for

21:22:06 dbotton https://www.irccloud.com/pastebin/ofXRpQuS/

21:22:50 dbotton it seems both uses are valid, but what use is the second version?

21:23:59 Bike in both cases it's quite possibly pointless since the list is in constant memory.

21:24:07 jackdaniel I was about to say that

21:24:24 Bike in the second case it is invalid (i.e. the declaration is a lie)

21:24:26 dbotton was just typing that I don't understand point at all

21:24:36 dbotton for that reason anyways

21:24:46 dbotton so when would it be used?

21:25:05 jackdaniel when you have a somewhat large data structure that you know that it does not escape the dynamic extent

21:25:15 jackdaniel then it may be allocated on the stack (i.e it does not touch the heap)

21:25:22 jackdaniel hence is faster (i.e does not cons)

21:25:54 jackdaniel of course the compiler may ignore that declaration whatsoever and go straight to the heap with it

21:26:31 dbotton I think I am having difficult understanding then when it would be deallocated off the stack

21:26:44 jackdaniel when the stack unwinds, then it will be simply forgotten

21:26:53 jackdaniel that's the thing with the stack, you don't need to deallocate things

21:27:03 dbotton yes understand that, but which stack. of the function?

21:27:30 dbotton so this is a hit to say that nothing escapes the function

21:27:41 dbotton then if that is the case #2 should be invalid

21:27:44 Nilby Yes. Dynamic extent says the thing won't be used after the function returns. The details of the exact optimization can change

21:28:15 dbotton so dynamic extent is same as lexical scope here?

21:28:26 dbotton and if that is the case what is #2 valid

21:28:47 jackdaniel #2 is invalid (as Bike pointed out), but nothing will crash, because that data is not allocated on the stack

21:28:56 jackdaniel you have quoted it, so it is in the constant memory either way

21:29:11 dbotton ok so #2 is an invalid hint

21:29:21 jackdaniel yes

21:29:29 dbotton to the compiler - that at least with scbl is not reported

21:29:44 jackdaniel it is your promise to the compiler

21:30:01 dbotton so I am a crook :(

21:30:10 dbotton got it

21:30:23 jackdaniel some implementations may decide to ignore the declaration /unless/ they can formally prove that the value does not escape

21:30:46 jackdaniel other implementations may trust you and then gleefully have a segmentation fault

21:31:03 jackdaniel and sometimes it may depend on optimization settings

21:31:43 dbotton so why is it called dynamic extent - it is local scope

21:31:57 dbotton lexical scope - sorry

21:32:45 dbotton I may be confused in the definition here of dynamic extent

21:33:01 jackdaniel scope (dynamic or lexical) is about names, while extent is about values

21:34:08 dbotton so dynamic extent = value is in lexical scope

21:34:19 jackdaniel no

21:35:04 jackdaniel (defun xxx (a) (print a)) (defun yyy () (let ((foo (list 1 2))) (declare (dynamic-extent foo)) (xxx (list* 1 foo)))))

21:35:43 jackdaniel the list named foo in yyy is available in xxx (and xxx is invoked in the dynamic extent of yyy), but foo is not available for xxx by name

21:38:26 dbotton so lexical and dynamic or "local" - downward - indefinite = global

21:38:41 jackdaniel of course what I did is an undefined behavior, because print returns its argument, and I'm returning the result of xxx, but that's beside the point

21:38:46 mfiano is that undefined behavior there?

21:38:55 mfiano ah ok ninjad

21:42:04 Nilby I don't want to add confusion, but print could call a print-object method that steals the object too.

21:42:57 jackdaniel "steals"?

21:43:29 Nilby Allows it to escape dynamic extent.

21:43:38 dbotton so if you are hinting dynamic-extent to compiler you should tell users of your function not to "steal" your object

21:43:55 dbotton or potentially a seg fault?

21:44:55 jackdaniel you should not let escape variables with dynamic extent to escape, in other words you should not call functions that may capture the variable outside of it

21:45:38 dbotton got it, sorry had it inside out

21:46:03 Nilby e.g. like when CLIM prints an object in a listener window.

21:47:16 jackdaniel Nilby: yes, I get it now, thanks

21:48:45 jackdaniel dbotton: scopes and extents are orthogonal

21:49:21 dbotton https://www.irccloud.com/pastebin/A4FRluBa/

21:50:02 dbotton are there any other things to be careful with using such a declare?

21:50:18 Nilby jackdaniel: Sorry, I know you're highly versed in CLIM. Maybe even CLOG can do something similar.

21:51:02 jackdaniel for example (block foobar (lambda () (return-from foobar))) ; -the returned function is defined in the lexical scope of the block, but escapes its dynamic extent (and invoking it will lead to a runtime error, unless you have a very peculiar implementation that travels in time)

21:54:12 dbotton thanks!

21:55:53 dbotton wonder if way to demo that graphically - should be able to show two time lines one for code and one for objects

21:57:36 jackdaniel strictly speaking the user is not allowed to write print-object methods specialized on system classes, but the point still stands about the capture if we replace a list with make-instance 'foo

21:57:55 jackdaniel good night \o