libera/#sicl - IRC Chatlog
Search
11:09:31
beach
scymtym: I think I managed to fork your repository, add my fork as a remote, make a change, and push that change to my fork.
11:21:41
scymtym
i good thing that got lost in the transition from org-mode to texinfo is handling of listings. org-mode has syntax highlighting for listings and, more importantly, can evaluate the code in the listing and include the output in the document. i'm not sure whether it's worth the effort to try and build similar behavior into the Makefile
11:22:57
scymtym
i also used this functionality to include documentation strings in the dictionary section. that's my main reason for considering it
12:13:44
beach
scymtym: Is it OK if I just start a new chapter named Node kinds and relations, with a section for Node kinds and a section for Relations?
12:14:28
beach
For the node kinds, I would then list each node kind with an itemized list of the relations in which that kind is used, and whether it is on the left or on the right.
12:16:44
beach
I mean, the important part is to get the information in there. The structure can be changed later I guess. I don't know whether you already have some ideas for the documentation structure that is different.
16:19:35
moon-child
beach: jcowan said 'all other classes are immutable (not subject to `change-class`)'. What I meant was that I think other classes _are_ subject to change-class, and that that consideration therefore doesn't apply; not some trivia about the class hierarchy
16:21:11
beach
I didn't read what jcowan said. I only answered what I thought was a statement about SICL.
16:24:04
beach
Either way, what objects are allowed by CHANGE-CLASS is a choice that is separate from the way the objects are represented.
16:24:55
beach
Even though a double float is a standard object, I probably wouldn't want it ti be possible to change it into an instance of some other class.
16:26:53
moon-child
well, the obvious difficulty there is that reference semantics are not uniform for numbers and integers
16:27:30
moon-child
(that said, I think it is possible to express a consistent semantics in which you can change-class on numbers, and implement it performantly)
16:28:21
beach
It is not clear that I would want it to be possible to change an array into (say) a stream.
16:28:35
moon-child
gtg, but: I don't think there's anything notionally problematic about being able to change an array into something else
16:34:16
Bike
change-class is pretty inimical to a lot of optimizations. if you could change-class a simple-array, the compiler would probably have to check that an object remains a simple-array for every array operation, instead of just checking it once.
16:37:35
Bike
i don't know if that's "notionally" problematic. it's certainly possible to let the programmer change-class arrays and stuff, but i don't think it's a good idea
16:38:35
jcowan
Just so. If structs have any benefits at all, it lies IMO in their immutability of structure.
17:50:56
Bike
and similarly, even if simple arrays and non simple arrays are represented identically, which as i recall is the case in sicl, it could make sense to impose restrictions on what you can do with the former
17:51:29
Bike
no, i remember now, in sicl every array is a simple-array, so the compiler wouldn't be able to do this kind of optimization