libera/#sicl - IRC Chatlog
Search
12:32:23
scymtym
beach: did you see the suggestion for an improved documentation string? (context: https://github.com/scymtym/architecture.builder-protocol/issues/12)
12:37:51
beach
There is still the problem that the cardinality is indicated as (:map KEY) whereas elsewhere it is (:map . KEY).
12:38:29
beach
That was part of my confusion, since I have not seen a cardinality indicated as (:map KEY) anywhere else.
12:43:48
beach
It is of course also a bit confusing that that cardinality designator (:map KEY-VAR) designates a cardinality of the form (:map . KEY).
12:46:39
scymtym
seems like using (:map . KEY-VAR), that is, an improper list, in the clause syntax would fix most of if not all of the issues?
12:47:24
scymtym
i can definitely make that change as :MAP relations have been extremely rare so far
12:49:42
beach
There are two things. One is that, elsewhere, a cardinality can be one of 1, ?, *, and (:map . KEY), but here it is (:map SOME-KEY), and it is not clear whether here you introduce yet another kind of cardinality, whether it is just a mistake, or whether the mistake is elsewhere.
12:50:53
beach
If the mistake is here, then there is a second thing, namely that a cardinarlity designator of the form (:map KEY-VAR) designates the cardinality (:map . SOME-KEY) rather than the cardinality designator being (:map . KEY-VAR). I am not sure why you would do that.
12:51:49
beach
And if you have a good reason for doing that, it should be pointed out in the documentation string.
12:52:37
beach
Like "Notice that the cardinality designator (:map KEY-VAR) is a proper list, but it designates the cardinality (:map . SOME-KEY) which is a dotted list".
12:59:57
scymtym
i think using only improper lists is the right call. the CARDINALITY-CASE code should be changed and the documentation should reflect that change
13:27:04
beach
Speaking of which, wouldn't the (:map . KEY) cardinality be ideal for use with something like the class options of DEFCLASS?
13:27:48
beach
For the longest time, I couldn't figure out what it might be used for, and then it occurred to me that this could be a perfect use case. But when I checked, it is not used there.
13:46:34
scymtym
that is a good idea. one problem could be the fact that the key of a relation with cardinality (:map . KEY) is stored in a relation argument. see https://gist.github.com/scymtym/c82fa4831e0f47d956205e796b6fd774 for an example. relations arguments (like initargs) are not nodes of the result tree, but the parser turns the name of an default initarg into a node
13:47:39
beach
I see. I hadn't realized that, because of my (still) partial understanding of that cardinality.
13:49:10
scymtym
extending relations to connect more than two nodes would turn the graph into a hypergraph and that would require a different graph construction protocol, i think. so the appropriate representation of default initargs in the current framework probably is one node for the default initarg, one child node for the name and one child node for the value form
13:51:03
scymtym
the map cardinality would be appropriate for things like hash tables with simple keys, sparse arrays or arrays of some rank different from 1. in those cases, the mere order of related child nodes is not sufficient as a key
15:13:34
scymtym
beach: as discussed, here (note the texinfo-documentation branch) is an initial rough texinfo conversion of the README: https://github.com/scymtym/s-expression-syntax/tree/texinfo-documentation/documentation
15:16:16
scymtym
all commits in the master branch are final. so i wouldn't want to push something half-finished that i plan to amend into the master branch
15:18:28
beach
I am not meant for this stuff: "git pull origin texinfo-documentation" results in fatal: couldn't find remote ref texinfo-documentation. It is possible that I misspelled things, because I am getting increasingly dyslexic over time.
15:20:32
scymtym
maybe you need git fetch --all before that to "discover" the new branch. i'm not sure
15:22:53
beach
"git fetch --all" did not give an error, but the subsequent "git pull origin texinfo-documentation" still results in the same message.
15:30:52
scymtym
yeah, i checking the logs to make sure /i/ wasn't assuming the wrong repository. but i was indeed referring to our discussion about documentation for the s-expression syntax library
15:31:23
beach
OK, I am again confused. "git branch" tells me I am still in the builder-protocol branch, but I see the documentation directory and its contents.
15:32:28
beach
Why do things have to be so hard? Especially things that are essentially uninteresting to the task at hand.
15:35:29
beach
But that doesn't explain why I can see the documentation files even though I am still in the builder-protocol branch.
15:36:51
scymtym
git pull integrates changes from a remote branch into the /current/ local branch, not the local branch corresponding to the remote branch
15:37:29
scymtym
git branch -m builder-protocol texinfo-documentation renames the local branch "builder-protocol" to "texinfo-documentation" which is the outcome you wanted, i think
15:39:21
beach
But then the renamed branch will also contain the previous contents of the builder-protocol branch, no?
15:40:25
scymtym
yes, but that should be ok. i made the texinfo-documentation branch by adding commits to the builder-protocol branch
15:44:22
beach
Oh, I guess I am not done. If one day I want to make a pull request, I also have to clone (copy?, what's the term) your repository into one of mine on GitHub, whereas now it is just on my local machine.
15:44:28
scymtym
i understand. i experience similar frustations in terms of not being able to make software do what i want it to do. in my case the issue is not with git but with crazy build processes surrounding the "unity" game engine
15:46:34
scymtym
you would have to "fork" the project on github, then change the "remote" configuration so that my project and your fork are each a remote, then push to your fork. but if it comes that, you can just publish an archive of the changes files on your webserver or send an email, if you want. whichever is easier
15:47:43
scymtym
current project for the university job. it would be hard to argue that the project is a research project, though
15:50:58
beach
I think today I will just build the documentation and see what it looks like. Improvements will have to wait.
16:07:34
jcowan
hayley: is your design better if you optimize it to apply only to standard-classes, since all other classes are immutable (not subject to `change-class`)?
16:16:48
moon-child
jcowan: afaik the plan for sicl is to make all classes which are not builtin-classes standard-classes
16:20:31
beach
Many instances of standardized classes are standard objects, but those standardized classes are not necessarily standard classes.
16:22:27
beach
For change-class to be allowed, the object would have to be an instance of a standard class. Though, it may be possible to allow other objects as well.
16:38:51
beach
So I guess the defined metaclasses are built-in-class, standard-class, structure-class, forward-referenced-class, and condition-class. I hope that's right. But instances of many built-in classes are also instances of standard-object. In fact, all of them are except instances of cons, character, fixnum, and single-float.
16:42:57
jcowan
It might be useful to have a cheap check whether an object is an instance of a subclass of standard-class, since those are the only objects whose racks are replaceable.
17:33:41
jcowan
beach (when you return): my point is that to verify if a rack is obsolete you have to check it against the class object, whereas if you know a rack cannot be obsolete (i.e. not a member of standard-class) you can spare the extra memory fetch.
17:34:17
jcowan
(e.g. something like all objects that aren't member of standard-class have generation 0)
22:11:52
sm2n
moon-child: here's some very wip code that uses it: <https://git.sr.ht/~sm2n/rapids/tree/trunk/item/rapids.lisp#L144>