Panicz Maciej Godek<p>When I started porting <a href="https://functional.cafe/tags/GRASP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GRASP</span></a> to <a href="https://functional.cafe/tags/Kawa" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Kawa</span></a> <a href="https://functional.cafe/tags/Scheme" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Scheme</span></a>, I originally wanted to use good ol' cons-cells to represent documents</p><p>This turned out to be problematic, and I'm still suffering from that idea, but I think that it was, in some ways, fruitful</p><p>Usually we understand OO's classes/objects as things that bundle together properties and methods, where properties are object-specific variables</p><p>If we represent a cons-cell as an OOP object, it will have at least two properties - the "head" (or "car") and the "tail" (or the "cdr")</p><p>If we wish to add new properties, we usually need to resort to inheritance</p><p>(An alternative view is that a cons-cell is something that satisfies an interface consisting of four methods: getCar, getCdr, setCar and setCdr and that we abstract the storage cells away)</p><p>But there is another technique of bundling data with objects. Assuming that an object is a bearer of unique identity, we can store additional information in hash tables. In particular, in Lisps there is the notion of "weak key hash tables", i.e. hash tables that do not prevent their stored keys to be garbage-collected</p><p>A good name for this kind of information is "attribute": things *have* or *possess* their properties, but we can *attribute* some characteristics to those things</p><p>Properties, therefore, are unique, objective and essential to objects, while attributes are subjective, and are present "in our looking" rather than "in the world"</p><p>For example, a screen position of some object is not its property, but it is something that can be attributed to that object by different views (because you can render the same object many times on one screen)</p><p>I originally thought that I should use such attributes to represent whitespace and comments around the contents of cons cells, and so I created some nice wrappers around hash tables, using Per Bothner's "generalized set!" (aka SRFI-17), so that I can write things such as:</p><p>(define-attribute (attribue key) <br> default-expression)</p><p>(set! (attribute 'x) 42)</p><p>I like this so much more than all the hash-table-set! and hash-table-ref and other functions for dealing with hash-tables, and I wonder why this syntax isn't available in the core Scheme</p><p>I can also use it with non-weak keys, and in that case, I call such entities "mappings". (And I like those names, because they focus on the function of named things, rather than some irrelevant implementation details, like "being a hash table")</p><p><a href="https://functional.cafe/tags/PlottingScheme" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PlottingScheme</span></a></p>