freenode/#sicl - IRC Chatlog
Search
7:32:35
beach
I don't think splittist meant literally "the same thing"; just that the protocols would be the same and the choice could go either way then.
7:36:02
jackdaniel
yes, but if each component is meant to be an application then extra work is required to ensure, that it works without sibling components
9:00:09
scymtym
regarding yesterday's discussion of source information and condition reports: i my experience with in-buffer indicators and output for batch tools, this has worked best: the condition report mentions things by name (function FOO, variable BAR, fourth argument, etc.) but does not involve locations. the condition contains a list of "annotations", each consisting of a kind (error, warning, context, etc.), a "role" ("first definition",
9:00:09
scymtym
"second definition", "superfluous argument", "form of incompatible type", etc.) and a location. example of multiple source locations for a single condition in a batch setting: https://techfak.de/~jmoringe/bad-reader-conditionals-2.png the condition report is in the first line, the kind determines the underline color and the role is the text besides the underline. for in-buffer indication, the annotations are applied directly to the
9:00:09
scymtym
source as in the second climacs example: https://techfak.de/~jmoringe/second-climacs-error.png
9:06:02
scymtym
this is another (very old) example: https://techfak.de/~jmoringe/eclector-cst-toy.png
9:26:41
beach
In your batch output, do you list the entire input file, or just the places with issues, surrounded by some lines of context?
9:28:07
beach
And, in what situation(s) would you use information about the name of a function or a variable?
9:30:10
beach
The list "(error, warning, context)" seems strange to me. The first two appear to be condition subclasses, but what is the meaning of "context"?
9:31:53
beach
I also don't understand what a "role" is from your description, and none of the roles in the list is in the example output, so it is hard to tell what a role such as "superfluous argument" would be.
9:33:13
beach
I mean, the word "superfluous" suggests "it's OK to have it, but you really don't need it", but I see no such possible situations.
9:34:37
beach
Does "second definition" mean that there is more than one definition of the same name in one file?
9:40:07
scymtym
to answer the first question, only excerpts are shown. if annotations are close to each other, the excerpts are merged. otherwise locations in different files or far apart locations are shown as separate excerpts
9:41:58
scymtym
for the second question, names of variables or functions are things that could be mentioned in condition reports - as opposed to locations. so "In function BAR, call to undefined function FOO" as apposed to "In function BAR, in file bar.lisp, line 100, call to undefined function FOO"
9:44:33
scymtym
the (non-exhaustive) list (error, warning, context) characterizes an annotation as pertaining to something that is definitely wrong, that is suspicious/possibly wrong/problematic or something that is not itself wrong but is involved in a problem
9:50:06
scymtym
for the role, i have failed to give consistent examples. the idea is that the role explains what an annotation means in the context of "its" condition. if the condition is MULTIPLE-DEFINITIONS-WITHIN-A-SINGLE-FILE, the report could be "The function ~A is defined ~R times within a single file". this condition would have multiple annotations and the role of the i-th annotation would be (format nil "~:R definition" i). in this scenario,
9:50:07
scymtym
would probably use the kind "context" for the first annotation and the kind "error" for the subsequent ones
12:00:07
beach
heisig: Did you say you are about to modify the SICL specification? If so, what chapter (so that we can avoid creating GIT conflicts)?
12:01:51
heisig
Oh, have chapters disappeared? I am still viewing the PDF I generated a few days ago.
12:03:28
heisig
Hmm, time to pull and recompile. But in any case, I will make sure there are no git conflicts on my side, and I will notify you before I push things.
12:07:24
beach
I did some considerable modifications to the section on compiler macros, given the call-site optimization technique.
12:09:58
beach
scymtym: As I mentioned the other day, I am reluctant to mention the function in which a problem occurs, in case that function is the result of a macro expansion. It seems to me that it would be better to just show source location.
12:12:09
scymtym
beach: or course, that's mostly orthogonal. i was mainly pointing out that i would keep source locations out of the condition reports. annotations as described above are what i ended up with for handling source locations in conditions
12:13:41
beach
scymtym: Can you say a bit more about the objectives of this work of yours? Should I plan for removing CST-to-AST and replacing it with a library that you will turn this work into?
12:17:04
scymtym
i was mentioning this more as a design pattern kind of thing. that said, there is also code which only focuses on the source location reporting and is not tied to a particular use-case. regardless of all that, i'm still working on the s-expression-syntax library that could be used for CST to AST conversion with good error reporting and source tracking
12:18:57
beach
I think it would be fantastic if there were such a library. Then SICL developers, as well as developers of other Common Lisp systems could get rid of a lot of code.
12:22:15
scymtym
the library does exist: https://github.com/scymtym/s-expression-syntax . i'm struggling (and have been for some time) to make actually usable for everyone
12:23:15
beach
Do you need some help with your struggle? Are there any particular obstacles that seem difficult to overcome?
12:35:11
scymtym
the main obstacle is lack of time while simultaneously getting distracted with urgent seeming things
12:36:01
scymtym
when i find time, i work on cleaning up the parser generator library on which the s-expression-syntax library depends as well as working towards full coverage for the s-expression-syntax
12:37:00
scymtym
the latter is extra slow because i try to get the AST presentation right by testing it in an editor with semantic highlighting
13:07:46
scymtym
beach: the "future" branch of https://github.com/scymtym/parser.packrat should be enough to use the s-expression-syntax library
13:33:02
scymtym
beach: did it work for you? i tried the github versions in a fresh environment and everything seemed to work. if so, (s-expression-syntax:parse 'list t '(let ((a 1)))) should return a list-based AST
13:41:35
scymtym
what do you mean by "my own repository"? if you already have one, isn't it also cloned from github?
13:44:15
scymtym
the system definition is in the repository root directory so it should be picked up without any additional tweaking
13:45:09
scymtym
can you check that repository? as i said the definition all systems should be in the repository root
13:45:30
scymtym
concretely, there should be a s-expression-syntax.expression-grammar.asd in the s-expression-syntax repository
13:46:36
beach
I removed my local copy of the s-expression-syntax repository since it is in quicklisp.
13:47:37
beach
I used to have a symbolic link in local-projects to a clone of your repository, and I removed the symbolic link so that it would use the Quicklisp version instead.
13:49:41
beach
I took your advice (ql:quickload :s-expression-syntax) to mean that s-expression-syntax was in Quicklisp.
13:50:33
scymtym
i suggested that way of loading the system because it will automatically install missing dependencies from quicklisp even if the system itself is not in quicklisp
13:53:14
scymtym
great. try (s-expression-syntax:parse 'list t '(defun foo (a &optional (declare (type integer a)) (+ a b)))) for a more interesting result
13:56:56
scymtym
to parse CSTs, load s-expression-syntax.concrete-syntax-tree and do something like (let ((s-expression-syntax.expression-grammar:*client* (make-instance 's-expression-syntax.concrete-syntax-tree::cst-client))) (s-expression-syntax:parse 'list t (cst:cst-from-expression '(let ((a 1))))))
14:13:01
beach
Now, let's think about this situation for a while. Let's say some Common Lisp implementation would like to use your stuff for their native compiler. Then, they would either have to first already have a complete system to load your stuff, or else they would have to use the SICL bootstrapping technique.
14:14:42
beach
So either 1. SICL will be the only client. 2. Other implementations would have (at least) two compilers, or 3. I would have to make the SICL bootstrapping technique possible for implementations other than SICL.
14:16:40
beach
scymtym: I mean, these libraries of yours are not the only ones that we try to make other implementations use, and all the SICL modules that we claim can be used by other implementations are now written using the full Common Lisp language.
14:17:59
beach
I suppose there is still the option for other implementation of writing an initial compiler or interpreter and then bootstrapping the rest of the system from there.
14:19:51
beach
On the other hand, the SIC bootstrapping procedure makes very few assumptions about object representation. At least I think so.
14:24:43
beach
Looks good. I'll proofread, but slowly, because I need to fix dinner for my (admittedly small) family today.
14:25:55
beach
The preposition used in the AMOP is "to" for "specialized to", and "on" is used for methods "on" a generic function (I think).
14:26:26
beach
I first thought this was a quirk because the authors of the AMOP had foreign-sounding names, but I think the are mostly native speakers of English.
14:29:48
beach
Your phrase "it must supply a client object to these generic functions that can be clearly distinguished..." sounds like it is the generic functions that can be distinguished. Maybe "it must supply a client object to these generic functions, and that object must be distinguished..."
14:32:51
beach
Hello shka_. Short English lesson: "advice" in English is not countable. It's like "water" or "air". "I need a piece of advice" or "I need some advice'.
14:37:46
heisig
Yes, the AMOP talks about methods "specialized to" a particular class. I will fix that.
14:45:51
scymtym
shka_: i have mostly worked with unconventional parsing techniques like packrat and derivation-based parsing. that said, smug and esrap are probably both fine unless your language has something unusual like indentation as syntax or complicated context dependencies
14:46:34
scymtym
cl-yacc corresponds to a more conventional approach but i found it less convenient to use
14:50:15
shka_
scymtym: thanks, i will go with maxpc for now because documentation feels easier to digest
14:51:06
scymtym
shka_: if performance isn't much of a concern and the language isn't super complicated, anything should be fine, really
16:17:25
beach
I think I will take the rest of the day (what little is left of it) off. I have a lot of information to digest with respect to s-expression-syntax and the implications for both existing modules and a more global strategy.