freenode/#sicl - IRC Chatlog
Search
11:00:24
lukego
but I think there are definite genres of program that have different performance limits. for some it will be memory bandwidth, for others execution units, for others latency at various levels of the memory hierarchy, etc.
11:03:22
lukego
I'd like to try static analyzers some time but I've always relied on CPU performance counters coupled with staring at disassembly
11:46:37
lukego
(intel have some interesting docs about this e.g. a "top down" method to try and work out where your performance bottlenecks are by following a flowchart to tell you which performance counters to consult, partly automated by some open source tooling they've published)
11:46:50
lukego
and I guess VTune is free now which is probably a hundred times better than any method I've used
12:53:19
scymtym
i'm experimenting with an approach for considering context in the highlighting style computation: https://techfak.de/~jmoringe/semantic-highlighting-2.png . note how, for example, variable, function and type names are bold when they appear in a "definition" context and not bold when they appear in a "reference" context. i will try to upload a document that outlines the approach and open questions later today
13:32:10
beach
scymtym: That seems like a great idea to me. In general, I am in favor of somewhat subtle hints in the form of font, color, background, etc., at least when possible, rather than some more spectacular indications that can distract the developer.
13:34:23
scymtym
beach: sure. however, i'm not really designing the aesthetics and ergonomics at this point. i'm currently trying to highlight all things in different ways based on what /could/ make sense later, so that i can collect the technical requirements
13:35:23
beach
Then I'll just say that I think it is a great idea to distinguish between defining occurrences and using occurrences.
13:40:01
scymtym
i'm trying to initially list all requirements and later accept or reject individual ones for implementation based on usefulness, implementation difficulty, etc.
13:45:07
splittist
at least one of the old lisp systems used to UPCASE symbols in the (equivalent of?) COMMON-LISP package. I wonder what a 'rainbow symbols' (in analogy to 'rainbow parens' would look like?
13:48:05
splittist
I guess one could also mark out the symbols in extended LOOP forms that will be treated as loop keywords. This would require an extensible LOOP to report such symbol names, of course.
13:48:36
scymtym
another possibility would be (slightly) underlining symbols for which documentation (not necessarily a docstring) is available. this could also consider the namespace so that (list …) would link to the entry for function and (let ((list …)) …) wouldn't link anywhere
13:49:41
beach
I think you have given all this a lot of thought and I think many of your ideas sound quit good to me.
13:49:43
scymtym
right. i haven't done underlining and background colors so far because other hints are easier to do in the CLIM-based demo. but i definitely want to include those
13:52:00
splittist
a thin border around the format controls in a format string (not that the system can know to what use a string will be put).
13:55:12
scymtym
the system can parse format control strings but, as you point out, knowing which string is a format control string can at best be estimated conservatively
13:55:33
splittist
a faint menacing throb for ERROR; an arrow connecting the GO to the TAG; a mechanical typewriter animation for TERPRI; STOP ME BEFORE I ...
13:56:03
scymtym
that said, identifying STRING in (format <anything> STRING …) is not out of the question
13:57:11
scymtym
i totally want arrows between uses and definitions. but probably only when you place the cursor/pointer over one
13:59:01
scymtym
drracket does it this way: https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmiro.medium.com%2Fmax%2F1520%2F1*5T7UGXxXcn9oqLAoyh23pw.png&f=1&nofb=1
14:02:32
jackdaniel
perhapsa presentation method highlight-presentation-pair modelled after http://bauhh.dyndns.org:8000/clim-spec/23-3.html#_1172 ;?
14:04:45
scymtym
jackdaniel: that's a good point. i haven't found an appropriate mechanism in CLIM yet. so far (for example in clouseau) i (ab)use HIGHLIGHT-PRESENTATION for such things
14:58:41
heisig
scymtym: Your demos and ideas are always super impressive. Thank you for sharing them.
15:00:13
heisig
I usually prefer very modest syntax highlighting. Too much different colors and font styles can easily be overwhelming.
15:01:50
heisig
So macros should look different than functions, because they may have non-obvious semantics.
15:02:13
heisig
And I like to have each level of parentheses in a different color, so that I don't accidentally mess up indentation.
15:02:20
beach
heisig: I think if the fonts, colors and styles carry some information, you would soon get used to it. But I agree that totally arbitrary things like highlighting every keyword, is really hard to read.
15:03:38
scymtym
heisig: thanks. i believe there is usually an indirection such that a pattern which matches a certain part of the input is not mapped to a concrete highlighting style but some sort of name which can be mapped to a concrete highlighting style in a "theme". i think doing something similar will be easy and will not affect the hard parts of the architecture much
15:04:33
heisig
Another thing I'd love to have is that lexical variable definitions and their use have the same color, at least once shadowed variables are involved.
15:04:39
beach
heisig: Exactly my point. Traditional highlighting does not assist in any way, so it becomes annoying.
15:07:21
scymtym
heisig: identical colors for definitions and associated uses is a very interesting idea. it also adds new requirements i haven't considered before
15:08:18
heisig
I am just trying to recall all the things that caused me trouble in the past, and that could have been avoided by syntax highlighting.
15:12:33
beach
How many nested levels of scope does a program typically have. It would be interesting to consider a particular color for each level. But at the same time, avoiding a complete fruit salad, of course.
15:13:08
beach
Then, for example, it would be totally obvious when a variable refers to an outer scope.
15:14:24
heisig
My proposal would be to only start the fruit salad for variables that are shadowed at least once.
15:16:47
beach
In fact, pretty much anything that reflects semantics would be WAY better than what we now have.
15:18:12
beach
I mean, consider what we get with things like (let ((defmethod... or (let ((check-thing...
15:39:40
beach
All that the version in SICL does is to convert a list of symbols to an integer representing a bitmap.
15:46:34
scymtym
this is what i have so far for the highlighting approach: https://techfak.de/~jmoringe/editor-design/semantic-highlighting.html
15:57:00
beach
scymtym: I see I need to read this document very carefully, but I would already like to point out a missing comma that changes the meaning with respect to what I think you want to say...
15:58:19
beach
"The above example only considers the abstract syntax tree which is insufficient in general". The meaning as it stands is that the syntax tree is insufficient. And the example only considers insufficient syntax trees.
16:01:19
beach
I'll continue reading, and trying to understand the traversal example, but it may be too late in the day for me to make sense of it. If so, I'll get back to you when I am in better shape.
16:03:15
beach
You probably want to say "The above example considers only the abstract syntax tree" [and not any other kind of notation], as opposed to what you are saying, namely "The above example only CONSIDERS the abstract syntax tree" [but it doesn't really do anything with it].
16:03:54
beach
In the spoken language, the meaning is usually clear no matter where you put the "only", but not necessarily in the written language.
16:06:33
scymtym
right. this subtlety exists in german as well. the difference between meanings is usually illustrated by speaking the sentences with exaggerated emphasis like you did by writing CONSIDERS
16:07:05
beach
The traversal example is probably incorrectly indented, which makes it hard to see what the columns mean. In particular the "v role in parent node" is way out to the right.
16:09:26
scymtym
i wrote the stack states with the top to the left and the bottom to the right. the indentation seems correct here
16:10:14
scymtym
i think the traversal example is confusing when written like this, but i didn't want to reverse the order of stack elements for the section that gives the semantics as lisp programs
16:11:48
scymtym
i could place the comment over the line that has the "(type-name name)" node. maybe that would work better?
16:14:52
Bike
beach: yeah, the attributes are pretty simple right now. the main thing they do so far is let the compiler know things like "the function argument to mapcar doesn't escape" so that it can determine closures only need dynamic extent
16:18:09
beach
Bike: I have a system cleavir-attributes that is nowhere used. It has an ASDF file, a package definition, and a 51-line file attributes.lisp. The .lisp file has many lines of comments, and three functions: MAKE-ATTRIBUTES, DEFAULT-ATTRIBUTES, and HAS-BOOLEAN-ATTRIBUTE-P.
16:19:02
beach
MAKE-ATTRIBUTES turns a list of names into a bitmap. DEFAULT-ATTRIBUTES returns 0, HAS-BOOLEAN-ATTRIBUTE-P calls LOGBITP to check whether a bit is set.
16:19:06
Bike
that's pretty much all there is in the s expressionists cleavir as well, but if you're not using it i suppose you could delete it
16:19:31
Bike
it's in its own system because it's used in a couple different systems so it didn't seem to fit well in any of them
16:20:08
beach
I won't delete it if it is useful. But I thought maybe since it is nowhere used, it was obsolete. I'll keep it.
16:28:03
beach
scymtym: I still don't understand <DEFCLASS> and I don't understand the absence of FOO in the AST.
16:33:13
beach
scymtym: And when you say "NAME is the role of the TYPE-NAME node", it is not clear what kind of animal TYPE-NAME is. Is it also the name of the node, so that you mean "NAME is the role of the node named TYPE-NAME"? Or is it a type, so that you mean "NAME is the role of the node with the type TYPE-NAME"?
16:37:14
scymtym
beach: "NAME: <DEFCLASS>" and "NAME: %FOO" are "node properties", not actual nodes. maybe i should put them on the same line as "their" node or just omit them
16:41:21
scymtym
there is a relationship. the slot is represented as a node of kind SLOT-DEFINITION which has a child of kind VARIABLE-NAME. the role of the VARIABLE-NAME within the SLOT-DEFINITION is NAME. the node of kind VARIABLE-NAME also has a property "NAME: %FOO" which references the symbol %FOO from the concrete syntax layer
16:42:30
scymtym
i made the tree manually because the actual representation is a bit more complicated
16:43:36
beach
I guess we just witnessed a very typical example of /me not being able to "fill in the blanks" that normal people would.
16:45:59
beach
I think dinner is imminent here. I should pick this up tomorrow, hopefully a bit smarter after some sleep.
16:46:05
scymtym
no, in the past, other people had trouble with this particular tree representation as well. but having this "role" relation between parents and children has proven very useful so i just have to explain it better
16:47:24
beach
I think I understand its importance. But see my "what kind of animal is TYPE-NAME" remark. I still don't understand that.
16:48:13
beach
It looks like a kind of "type" to me. At least when I look at the DOCUMENTATION role.
16:50:17
beach
One child of the DEFCLASS node has the role DOCUMENTATION, and it is of "type" LITERAL [my interpretation], and the value is bar [why not "bar"?].
16:53:12
scymtym
i extended the explanation of the textual tree notation and put it at the beginning of the "Running Example" section. i hope that change clarifies things at least a bit