#grasp — Public Fediverse posts

Today I made a first commit in the #GRASP repository since over a month.

I've been having difficult times getting up to speed with that project.

One reason for that was the desire to have a version of GRASP running in the browser. Another was the fact which I already mentioned, namely that my company's office has moved closer to my home, so I could no longer hack on GRASP on my way to work.

However, things have changed drastically a week ago, because I parted from my company, and now I am unemployed.

I also rented a co-working office with the plan to improve (and finally release) GRASP - hopefully before I run out of savings and be forced to look for another job.

So, when I wasn't working on GRASP, what was I working on?

- I developed jsssssssss, a self hosting (Something Similar to) Scheme to JavaScript translator
- I tried participating with my friend in the Lisp Game Jam (and while we eventually decided not to submit the fruit of our cooperation - because there was too much JavaScript and too little Scheme in it, the effect was that it advanced my friend's work on his book)
- and for the last two weeks, I've been wrestling with an implementation of the Hindley-Milner type system as an extension to Scheme, because I wanted to use it as a base of the POORMANS system (I can't call this attempt a complete success, but I have toy implementations of algorithms W and M, and I learned about Jacques Herbrand, so I'm kind of glad that I tried)

I think that I needed a break from that project, and also that at some point I will have to do a rewrite - a one that would hopefully run in the browser as well.

I'm not sure whether to use jsssssssss or Hoot (my project has a much smaller memory footprint, but is also much less mature) - maybe I'll try targetting both?

In either case, I decided to improve the current implementation of GRASP to the point of making it usable. I may have to backtrack from some of the design decisions that I made along the way. I also hope to return to my work on the book.

So much for now.

It's been a while since I wrote a report on the progress of #GRASP

In large part, it's because things haven't been going too well lately. The fact that I no longer commute to work by train has a negative impact on my productivity.

I will likely start renting a co-working office starting next month. I'm also in the process of switching jobs.

So, my last few weeks were a kind of a mental diarrhea, when I was figuring out what to do next.

So I had a lot of ideas and very little accomplishments.

My current attitude is that in order to finish GRASP, I will have to start developing it from scratch. Maybe not entirely from scratch, because I think some parts of its design are completely fine, but I will probably start a new project, and just move some bits of the old one as I'll be needing them.

But this also leads me to the position of figuring out certain current shortcommings of GRASP. One of the problems is that I'm unable to run it in the browser. So last week I made a very simple Scheme to JS translator. (I call it jsssssssss, which stands for "JavaScript Scrounged from a Sophisticated Superset of a Simple Subset of Scheme or Something Similar")

Another thing is that I'd like to decouple GRASP from Kawa, and possibly be able to run it on top of other Scheme implementations. But I don't want to give up on the affordances that I get from Kawa, and in particular its type system, and so I'm looking for a way to transplant that system to some other Schemes, refining it along the way. It consists of a few components, including
- a subsystem for interface-based object-orientation
- a record system
- type signatures

The system is going to be very similar to what I developed on top of Kawa, and described a while ago around here (under the #PlottingScheme tag). I originally thought of making a #lang for Racket, because I was hoping that I could use RacketScript to target the browser, but it turned out that RacketScript doesn't really suit my needs.

I still think of targetting Racket though, because it has its own object-orientation system that I think aligns fairly well with that of Kawa.

I would of course also want to have that system available in jsssssssss, and perhaps I will also try to make a version that works with Chez.

The system's name is POORMANS, which stands for Portable Object-Orientation/Reflection Module Across Numerous Schemes.

The development of jsssssssss made me revisit the old compiler that I wrote for my...

You think you're super-smart because you know how to exit vim?

You brag among your colleagues about being a proficient user of ed?

You no longer edit files in Emacs, because your elisp functions do that for you?

Then try edit anything in #GRASP, and see how far you can go.

I bet not too far.

#GraspChallenge

In February, I've been mostly involved with developing a simple physics engine for #GRASP

It is tangential to the editor itself, and completely inessential - but I felt that I had to write it, because a few months earlier I wrote a collision detection algorithm.

It mostly works, although there are some issues with collision detection, and the physical objects sometimes get through the walls.

But I wonder whether I would want to devote more time to this venture.

I've found that there is a physics engine written in Java called dyn4j, and I probably would be able to integrate it with GRASP easily, without all the burden of development and debugging (although that wasn't the purpose of this exercise).

Other than this, February wasn't a good month for me. I've spent the bigger part of it being sick and lying in bed, and despite working according to schedule, I feel that I've lost the rhythm.

Besides the office of the company that I work for has moved significantly closer to my home, so I no longer commute by train, and don't have that spare time to write code on my phone.

I think that I'm currently going through a sort of a crisis. I'm trying to figure out the way to monetize my work, because I will most likely be parting from my company in a few months.

I applied for a coworking office in a nearby technological park, and if my submission gets accepted, I plan to spend there one or two hours a day, doing some GRASP-related things.

Currently I will be focusing more on writing the book that I started writing. (At this moment, I'm around 4000 words, and while there's some room for improvement regarding the text, I am somewhat happy about what I already have. I plan to write around 80000 words, so it seems I'm at 5%, but of course this is hard to measure precisely.)

There are more things that I've been unhappy about, though. Recently, I started spending way too much time on X (formerly Twitter), partially due to the political events, but I also tried become more politically aware regarding the upcoming presidential elections in Poland. I find it terribly ironic that X (formerly Twitter) is still a place where the political discourse seems to be happening. But my overall impression is that interactions have gotten better than they used to be (I don't know if these are interactions with people or bots though).

In the early December of 2024 I made a list of things that I would like to fix before releasing #GRASP. I wrote it in a paper notebook, and even made some rough estimates for fixing them. I felt excited, because it seemed that the moment when I can start releasing GRASP (to @fdroidorg, at least initially) is really close.

Now that we're in the middle of January, I haven't touched almost any of those points.

I feel that GRASP is already mature enough that I could try pushing the release, and despite all the bugs, willing people could still find it useful, or at least worthy to play around with.

But even if editing was made flawlees, the current state of GRASP is still far from its "grand vision", which is a tool that would blend documents/books with applications, written in a way to promote code understandability.

So, here's the list of things that I wanted to fix:
- automatic workspace persistence
- using keyboard to navigate the menus
- proper search&replace
- drag&drop editing of strings and comments
- fully functioning undo (it has some bugs)
- scroll-bars
- hyper-textual help documents
- proper serialization and deserialization of extensions

I still want to do all those things. But I want to do that in the atmosphere of fun, rather than self-imposed pressure.

Other things that I'd like to have certainly include opening and closing boxes (by double-tapping on their left paren), scaling boxes to different sizes (and maybe changing their rotations as well?), and "pulling-the-rug splicing".

However, at this moment I feel that trying to live-code visual applications in GRASP is much cooler, and a much better driving force for the development.

Of course, if you fear that you're missing out by not using GRASP (which is probably true), feel free to join the project and help me release it sooner. (It's currently GPL, but I've been thinking about making it AGPL)

And don't be afraid to reach out ask questions - including some very basic ones.

Also, I decided to stop obligating myself to write monthly reports. I'm now switching to a more organic form of writing about GRASP, namely - whenever I feel like it (like, right now).

(If I'm going to "feel like writing about it once a month", it's going to get a bit cringy, but I guess I'll be OK with that)

One thing that I'm relatively happy about is the design of the animation system in #GRASP

Since GRASP can run in graphical environments as well as in terminal, all the rendering is mediated by the interface called Painter.

Painter is not a clear-cut, elegant abstraction. It has about 100 methods, and I think of it as a whimsical artist.

And among those, there is a method with the following signature:

(play! animation::Animation)::void

where Animation is a very simple interface, defined in the following way:

(define-interface Animation ()
;; if this method returns #f, it means
;; that the animation has ended and can
;; be discarded by the animation system
(advance! timestep/ms::int)::boolean)

Now, the three clients of GRASP provide very different implementations of the play! method (and each of them is fairly complex): the AWT version uses a javax.swing.Timer to advance the animations, the terminal version uses java.util.concurrent.ScheduledThreadPoolExecutor:scheduleAtFixedRate, and the Android version uses android.os.Handler:postDelayed (as if that meant anything to you)

All three clients use a fixed tick period of 40ms, which would ideally amount to 25 frames per second - but this is neither documented nor guaranteed (which is why the advance! method receives the time delta from the previous call that it can rely on)

Currently there are three use cases for the animation system. One is screen repositioning, another is the visual stepper, and the last one is used for panning to the next search result.

#GRASP

https://www.youtube.com/watch?v=tiCsPavgG9M

While I think that I failed to fulfill any of the objectives that I set to myself for December, it was a month that filled me with hope - I managed to fix some of the most annoying bugs, and made #GRASP actually usable (although currently mainly for myself, because there's still one small bug that would probably confuse a lot of people if they tried to use it).

Another highlight of December was that I had a few days off from computers in general, and I think that I needed that badly (and I still have almost an entire week of vacation ahead of me).

Overall, I don't remember 2024 as a particularly good year; I remember spending a lot of time on improving the vertical cursor movement (and it still needs some improvement), and likewise a lot of time on modifying the build system (and it blows occasionaly for unknown reason).

I'm not particularly worried about those problems, because I wanted to implement all the essential features before polishing the details, and I feel that - while there's probably still a lot of refactors (and possibly a big rewrite) ahead of me, the essetnials are already in place.

I think that the main highlight for 2024 was my participation in the spring Lisp Game Jam, which resulted in a game that I made for my daughter, and Causal Islands. Going to Milan for ICFP/Scheme workshop was also an adventure, but a very costly one (and I'd say that the vibe of the conference was a bit too academic to my taste). I was a bit disappointed that I coudn't meet WIll Byrd, but I'm very happy to have met Michael Ballantyne.

Overall, though, I think I had more fun watching live streams from SPLASH (and I felt it was a truly epic event, especially the LIVE workshop).

As to the plans for 2025, I have an ambition to make a follow-up of my Causal Islands talk, if it is going to be organized (I hope it will): I would like to have implemented all the things that I talked about.

There's also going to be Programming Conference in Prague in the beginning of June, and there's a direct train connection from Gdynia to Prague. In is unclear yet what the program is going to be, but if they will have an event that could accomodate a GRASP demo, I think I'd be eager to submit (although it can be difficult to reconcile with family life).

I'm also considering European Lisp Symposium (which takes place in Zurich in May), but I'll most likely have to skip it.

When it comes to the development plans, my priority is to have GRASP released...

My first attempt at what would become #GRASP was in September 2016, when I was working on a structure editor running in the SLAYER framework that I was developing at the time. It wasn't called GRASP yet, though - I called it "Butterfly", because of the XKCD strip about "real programmers", but I didn't get very far.

SLAYER was based on Guile, and I ended up implementing something akin to Racket's Big Bang (which I didn't know about at that time), and I have spent considerable effort to find a way to represent stuff in Scheme in a nice way (I developed a library for working with lists of interspersed keywords and values, but I was never happy about that).

I think I may have been on a trajectory to build something similar to @disconcision 's Fructure, but I broke my laptop, and it took me a while to recover the latest changes from the disk (which I think eventually happened in 2018; until then, I was working on a small Intel Atom-based netbook that I borrowed from a friend, and on which I wrote "A Pamphlet Against R").

Then I started to look for a nice way of putting rectangles into other rectangles, which took the form of "The Draggable Rectangle Challenge" that I published on Quora (I was a Quora addict at that time)

https://eidolon-language.quora.com/Draggable-rectangle-challenge-part-I-the-introduction

I wrote a highly idiosyncratic solution in Racket, which nevertheless had its charm, but it ran terribly slowly on my friend's Raspberry Pi, and I haven't figured out any way to run it on Android.

The editor window title was "GRASP LIMB", where "GRASP" stands - of course - for GRAphical Scheme Programming, and "LIMB" is meant to be a pun on LISP's backronym "Lots of Irritating Superfluous Parentheses"; "LIMB" was meant to stand for "Lots of Intriguing Movable Boxes".

I started figuring out a way to build Android applications - I had to buy additional 2GB of RAM to my laptop to make Android Studio to run, and when (after breaking another laptop) I finally found a way to build Android apps in Termux, without Android Studio, it turned out to be a huge productivity booster to me - I could finally do programming in places where I wouldn't be able to use the laptop, and this setup prompted some of the design of GRASP.

I made the first version on/for the phone in the spring of 2020, mainly on the toilet (and it shows: https://www.youtube.com/watch?v=BmZ39IfElzg), and in 2021 I wrote what I thought would be the "final version" - but in both cases, the development eventually stalled.

When I started porting #GRASP to #Kawa #Scheme, I originally wanted to use good ol' cons-cells to represent documents

This turned out to be problematic, and I'm still suffering from that idea, but I think that it was, in some ways, fruitful

Usually we understand OO's classes/objects as things that bundle together properties and methods, where properties are object-specific variables

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")

If we wish to add new properties, we usually need to resort to inheritance

(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)

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

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

Properties, therefore, are unique, objective and essential to objects, while attributes are subjective, and are present "in our looking" rather than "in the world"

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)

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:

(define-attribute (attribue key)
default-expression)

(set! (attribute 'x) 42)

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

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")

#PlottingScheme

Some implementations of #Scheme provide a syntax for defining optional and keyword arguments that is akin to the one that can be found in #CommonLisp, or - relatedly - in DSSSL. For example, in Kawa they can be used like this:

(define (f arg1 ... argN
#!optional
(opt1 default1) ... (optM defaultM)
#!key
(key1 val1) ... (keyL valL))
<body>)

The default values are optional, and if they are not given, instead of "(key val)" or "(opt default)" one can simply write "key" or "opt", respectively.

I really don't like this syntax, for the same reason I prefer Scheme's

(define (f args ...) body)

to Common Lisp's

(defun f (args ...) body)

namely, because Scheme exposes symmetry between definitions and their usages.

However, there is no symmetry between using #!optional and #key and using them.

For this reason I have defined - in Kawa - a define/kw macro, which lets me write

(define/kw (cut-selection!
at: cursor ::Cursor := (the-cursor)
to: range ::integer := (the-selection-range)
in: document := (the-document))
::void
...)

instead of

(define (cut-selection! #!key
(at ::Cursor (the-cursor))
(to ::integer (the-selection-range)
(in (the-document)))
::void
...)

I like it for a few reasons.

First, like regular Scheme definitions, it exposes symmetry between definitions and their usages.

Second, the Common #Lisp style requires to remember two special keywords: #!optional and #!key, whereas the thing I came up with requires knowing only one special keyword, namely := (which is short and therefore I think fairly easy to remember)

Third, it lets me name arguments differently than keywords used to invoke those arguments.

One day - perhaps after I release #GRASP - I plan to fork Kawa, and to provide this syntax in the core "define"/"lambda" forms, instead of the Common Lisp style.

(I recall that @dpk did a review of different ways of handling optional/keyword arguments in various Scheme implementations. My syntax wasn't included, because I haven't announced it anywhere, although I have experimented with its implementation for Guile many years ago in the (grand scheme) glossary)

#PlottingScheme

Since Twitter has long been deceased, I thought that maybe bringing up the static vs. dynamic debate could cheer some people up :D

For along time, I have been using #Scheme with no type annotations, and I had no problem with that. I was using variable names that would hint what the underlying type would be, and it became my good habit to provide usage examples alongside definitions.

But I was looking at other languages, such as #Haskell, #ML or #Shen, and thinking how to incorporate static type annotations into Scheme.

One candidate was "A Type Notation For Scheme" by Gary Leavens et al. I also took a look at Typed #Racket, and I didn't like either of them. #Guile 's object system - GOOPS - contains CLOS-like system of defining generic method, where I could write

(define-method (m (a <A>) (b <B>)) ...)

where <A> and <B> are names of classes. But I didn't like that, since it wasn't compatible with my "grand scheme" syntax with destructuring everywhere, and it felt somewhat arbitrary (e.g. in C the type name comes before the argument name, which is the exatly opposite order).

I also considered Racket's contract system, and its cheap rip-off, Clojure's spec, but I found both cumbersome.

The solution came from the place I didn't expect. In the early 2022 I started using #Kawa Scheme for developing a new iteration of #GRASP, and Kawa turned out to provide a system of type annotations.

Functions can be annotated like this

(define (f arg-1::type-1 arg-2::type-2)
::result-type
...)

and the :: sequence is always read as a separate token.

The type system has a limited support for generic types, but expressions in type positions are macro-expanded, which means that there is no limit on the expressiveness of this type system.

In the worst case, I can just have my type signature macro-expand to java.lang.Object.

While the stuff that Kawa comes with is in my opinion a bit bare-bones, I leveraged macros to define three ways for defining new types:

- define-type, for defining records, e.g.

(define-type (Rect width: real height: real))

- define-object, for defining classes ("define-class" was already taken by Kawa)

(define-object (Name args)::Interface
(define (method args ...)::type ...)
...
(SuperClass))

- define-interface for, well, defining interfaces

(define-interface Interface (Supers ...)
(method args ...)::type
...)

I also have a pattern matcher that can destructure records

#PlottingScheme

I don't feel as if August has been a particularly good month for #GRASP

My main focus was on the improvement of usability regarding file management. I wanted to implement workspace persistence, and while I made some steps towards that goal, there's still so much more to be done.

So what I actually did:
- extracted the content of the "welcome screen" from a string inside 'assets/init.scm' (which is evaluated upon startup) into a separate file, called "assets/intro.scm".

- splitted one big module (consisting of over 2000 lines of code) into a few smaller modules (the biggest one is around 900 lines, which could be better, but is kinda OK)

- hooked a callback which is meant to be called "near exit" (which is a bit tricky on Android) so that it could be used to persist the workspace

- wrote a little function to persist hash tables (which can be found here on mastodon under the #SchemeBites hash-tag - I thought it's a neat idea to share some nice snippets of Scheme that fit on one screen of code)

I also handled my Scheme Workshop submission, and I'm really so happy to be going there (especially after seeing the program).

For the last week, I've mainly been trying to GRASP the A* search algorithm. I'm not hoping to make it for the Workshop, but I made the visual evaluator in a window of enlightenment that started almost exactly a year ago, and I was hoping that maybe this year a similar thing could happen. (It probably won't, because I've been super-tired with my day job lately, and I had almost no vacation this year.)

Anyway, working on A* is nice, because I mainly do it in my (paper) notebook, so I don't have to be glaring at the screen and twisting my thumbs.

I don't have any specific plans for September. My key highlight is of course the Workshop, so I might try to pimp up the visual stepper a bit. I think it would be awesome if I managed to fix support for lists, but it is more likely that I will focus on some random and tiny usability issues.

I plan to continue working on A*, because it excites me.

I have a few more exciting things on my list of things to do, including:
- the ability to scale (and perhaps rotate?) particular expressions
- search facility
- collapsing/expanding boxes
- module viewer

But I would also like to publish GRASP, which requires bug fixing (which is no fun).

I'm probably going to focus more on the fun things, but I'll try not to forget usability.

I've recently been preparing a presentation of "the concept of Emacs" for youtube as a part of a series explaining #GRASP.

#Multics #Emacs was mentioned in various important sources, including Richard Stallman's paper describing his experiences with the development of the GNU Emacs, as well as in the interview with James Gosling, who explicitly pointed to his experience with Multics Emacs as the key motivation for the development of Emacs for UNIX.

I tried to find a picture of the author of Multics Emacs - preferably from the times when it was still being developed - to include in my presentation. However, this turned out to be very hard.

Fortunately, it was very easy to find the BernardGreenberg.com website,
which claimed to have been designed in 2021, but whose set of stylistic choices is a clear reference to the early web of the 1990s.

Among various eye-and-mind-candies, such as a green-tinted photo of an iceberg, there was a link to a subpage containing an instruction how to assemble an operational e-mail address that could be used to contact the author.

I did just that, and asked for the photo. But what I got in return, exceeded my wildest expectations. I got an opportunity to learn first-hand story of the evolution of the concept of Emacs. But, most importantly, I got the opportunity to correspond with this truly remarkable person.

I also contacted @larsbrinkhoff, who is the editor of the Emacs section of Computer History Museum's Software Preservation Group, and an edited version of my impromptu interview with Bernard Greenberg is now available for everyone to read:

https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Bernard-Greenberg-interview.org

I also got this picture: