libera/#sicl - IRC Chatlog
Search
13:26:44
beach
scymtym: Suppose we were to write some documentation for the s-expression-syntax library. Would you then document each node kind and each relation separately? I mean as opposed to grouping them by special operator or standard macro. I am thinking "yes", because many node kinds are used for several different operators.
13:28:41
scymtym
beach: i agree. node kinds as well as relations occur in many different contexts. and some node kinds such as variable binding (or whatever the exact name is) don't correspond to any first class concept
13:29:46
scymtym
i will have to read it after running an errand. but feel free to write it down in the meantime
13:29:47
beach
Would you start some documentation with your favorite markup, and then fill in one or two items? That way, I could continue filling in.
13:30:15
beach
scymtym: Also a question (for later): If I were to use the s-expression-syntax library to write (say) a macro expander for DEFCLASS, should I then define a method on RELATE that calls one of my own generic functions with the CAR of the relation, since the relation seems to always be a CONS?
14:35:43
scymtym
beach: regrading the second question: it is correct that most parser-like clients i have written recently use conses to specify relations (for the benefit of generic tools like the LIST builder). however, shouldn't https://github.com/scymtym/architecture.builder-protocol/blob/master/src/protocol.lisp#L139 take care of the issue you describe?
14:38:58
scymtym
NORMALIZE-RELATION turns a "relation designator" (which is probably not defined anywhere at this point) into two values as follows: NON-CONS-RELATION-NAME → NON-CONS-RELATION-NAME, * and (RELATION-NAME . CARDINALITY) → RELATION-NAME, CARDINALITY
14:40:44
scymtym
you mean you don't see nested calls where RELATION is the car of the "outer" RELATION argument?
14:41:15
beach
This link you just showed me seems to call RELATE recursively with the CAR, but I don't see that in the trace.
14:43:20
scymtym
is there a method on RELATE specialized to your builder class but not specialized in the RELATION parameter?
14:44:05
beach
Let me check. I am using the (modified) example(s) from the s-expression-syntax library.
14:48:04
scymtym
yes, the LIST builder stores relations of the form (RELATION-NAME . CARDINALITY) as-is so that it can later query the CARDINALITY
14:49:59
beach
When I read your code, I find that the tools that are available to us are insufficient. At least the tools I often use such as grep. This situation gives me ideas for required features of an IDE.
14:52:26
scymtym
in this specific case, the design may simply be less than ideal. although some of the issue is due to the conflict between keeping simple cases simple and supporting more complex cases
14:53:24
beach
I guess I'll find out as I learn more. It is not clear at this point whether the design is ideal or not.
14:56:06
beach
I am hoping that, as I learn more, I will have more helpful feedback, and more sophisticated questions.
14:56:32
scymtym
beach: regarding the tree printing system: i will try to push that today. but since you seem to prefer clouseau in general: there is a dedicated system for inspecting trees in clouseau that should already be in the repository
14:59:50
scymtym
right, if i remember correctly, i pushed the s-expression-syntax library early since you were interested in it
15:00:37
beach
I was just surprised, because I tried to substitute DEFCLASS for DEFUN in the first example, but it failed in the ECASE for the cardinality.
15:01:05
beach
So I used the second example since it doesn't have that ECASE, but then it couldn't find the tree-printing package.
15:10:24
scymtym
sorry to hear. i will have a look at the example to see whether i can make it more clear and less error prone
15:11:14
scymtym
by the way, before i push the printing system, does this main interface seem appropriate: (defun serialize (builder tree stream &key peek-function printers) …)? forget about PEEK-FUNCTION and PRINTERS for now
15:11:52
beach
I don't see a problem with it, but my opinion probably can't be trusted at this point.
15:15:17
scymtym
that would also somewhat match CL:PRINT and friends by having the object parameter before the stream parameter
15:17:55
beach
Don't work too hard. I don't think I am going to check it out today. I have had a long day already, and I am about to quit my programming activities for the day.
15:18:32
scymtym
it's fine. i have wanted to push this out for a long time (around six years, i think) and always got distracted
15:22:52
scymtym
beach: regarding the documentation of the s-expression-syntax library (if you have a little more time): in my mind, the existing README file has some of the required sections. do you consider the content insufficient or the "framing" as a README the problem?
15:24:08
beach
The content is probably fine. But I was thinking you might want some "real" documentation at some point, maybe in Texinfo.
15:25:19
beach
I mean, the contents of the README is not sufficient for "real" documentation, because it lacks the documentation for the node kinds and relations, as we discussed.
15:25:23
scymtym
i see and that's true. i'm undecided in terms of waiting for doclang (working title) though
15:27:31
scymtym
yeah. and a "domain" for technical documentation of common lisp code with concepts like "generic function", parameter and so on. i can probably steal a lot of that from the dpans-conversion code
15:28:59
beach
I was thinking a CLIM-based simplistic editor that would keep the tree structure, and let the user just type text for a single sentence or a single paragraph at a time.
15:30:28
scymtym
hard to say. that approach would also enable certain conveniences such as dragging list items to change the order
15:32:39
beach
So such a thing might have two windows. One for editing text in (say) a single paragraph, and one for the result.
15:33:05
beach
But gestures would be needed to add a paragraph at a particular point, or to modify the tree.
15:33:54
scymtym
yes. i think the Jetbrains "Meta Programming System" has some good ideas for structure editing issues
15:34:05
beach
It is tempting, because a simplistic CLIM-based editor could then evolve to something somewhat useful.
15:35:04
scymtym
to get back to the original question, maybe texinfo is the right call at this point in time
15:35:48
beach
Do you want me to start it? That would require a bit of reading up on Texinfo on my part, but it is doable.
15:36:19
beach
My memory is (and always has been) crap, so even though I have written Texinfo documents in the past, I don't remember much.