Panicz Maciej Godek on Nostr: This month, I've been mainly focusing on bug fixing. I have somewhat mixed feelings ...
This month, I've been mainly focusing on bug fixing.
I have somewhat mixed feelings towards my recent work.
On one hand, I am quite happy with the approach I took to bug fixing, which nearly always begin with writing a test.
https://github.com/panicz/grasp/blob/main/src/test-regressions.scm
I believe that this is the right approach.
On the other hand, I am rather terrified with the representation that I chose for documents in GRASP.
More specifically, I initially thought about making GRASP just an editor of #Lisp 's lists (i.e. cons cells). In some sense, I felt that it was the right decision, because it forced me to represent dotted pairs properly, and it made me think about various aspects of editing.
At that time I was only getting started with Kawa, and I was treating it just as an implementation of Scheme. It took me a while until I started leveraging its type system, interfaces and the collections provided by #java
So I wanted my code to be as Lisp-like as possible, which meant using cons-cells everywhere.
So, a document was a singly linked lists of expressions.
The advantage of this approach was a certain familiarity. But it very quickly turned out to cause many complications.
The first complication was: how to represent whitespace between elements?
So I came up with an idea of storing them in weak key hash tables: pre-head-space, post-head-space, pre-tail-space and post-tail-space.
(I actually had to subclass Kawa's original "cons" cells, because they overrode the "equals" method in a way akin to Scheme's "equal?" predicate, so two identical expressions were always considered the same, which wasn't what I wanted)
Another problem was the fact that the empty list is a unique object, so it's hard to represent spaces between a pair of parentheses.
I initially solved this by introducing two other hash-tables, called null-head-space and null-tail-space.
(It should be clear that there's something fishy about this representation, because I need to go up one level to figure out the properties of some particular object)
But then it turned out that I have some other problems. The objects in Lisp, such as symbols or numbers, are immutable, while the whole point of the editor is to edit stuff.
So I came up with a weird "dual representation" of cons-cells. I introduced a parameter, called (cell-access-mode), whose values could either be CellAccessMode:Editing or CellAccessMode:Evaluating (it's an enumeration in Kawa).
I did that, because I wanted...
I have somewhat mixed feelings towards my recent work.
On one hand, I am quite happy with the approach I took to bug fixing, which nearly always begin with writing a test.
https://github.com/panicz/grasp/blob/main/src/test-regressions.scm
I believe that this is the right approach.
On the other hand, I am rather terrified with the representation that I chose for documents in GRASP.
More specifically, I initially thought about making GRASP just an editor of #Lisp 's lists (i.e. cons cells). In some sense, I felt that it was the right decision, because it forced me to represent dotted pairs properly, and it made me think about various aspects of editing.
At that time I was only getting started with Kawa, and I was treating it just as an implementation of Scheme. It took me a while until I started leveraging its type system, interfaces and the collections provided by #java
So I wanted my code to be as Lisp-like as possible, which meant using cons-cells everywhere.
So, a document was a singly linked lists of expressions.
The advantage of this approach was a certain familiarity. But it very quickly turned out to cause many complications.
The first complication was: how to represent whitespace between elements?
So I came up with an idea of storing them in weak key hash tables: pre-head-space, post-head-space, pre-tail-space and post-tail-space.
(I actually had to subclass Kawa's original "cons" cells, because they overrode the "equals" method in a way akin to Scheme's "equal?" predicate, so two identical expressions were always considered the same, which wasn't what I wanted)
Another problem was the fact that the empty list is a unique object, so it's hard to represent spaces between a pair of parentheses.
I initially solved this by introducing two other hash-tables, called null-head-space and null-tail-space.
(It should be clear that there's something fishy about this representation, because I need to go up one level to figure out the properties of some particular object)
But then it turned out that I have some other problems. The objects in Lisp, such as symbols or numbers, are immutable, while the whole point of the editor is to edit stuff.
So I came up with a weird "dual representation" of cons-cells. I introduced a parameter, called (cell-access-mode), whose values could either be CellAccessMode:Editing or CellAccessMode:Evaluating (it's an enumeration in Kawa).
I did that, because I wanted...