... a touch of romance, from 11th May 2023

a silken hand, a velvet glove,
come teach me all you know of love,
touch, with slowness, grasp me never,
I may make you stay forever

#MastoPrompt #Grasp #MicroFiction #SmallStories

Of course the terminal version of #GRASP is going to use colors for this, but I feel that Unicode alone is a fairly expressive medium

I never showed it to anyone, but my 'unit test' for drawing lines in the textual client of #GRASP looks like this:

I've designed a notation for quotations in #GRASP (and now all that's left to do is to implement it :D)

Yeey I will be showing a demo of #GRASP during this year's European Lisp Symposium!

I have been continuing the march towards a usable version of #GRASP, but a usable application is still beyond my reach.

As always when working with schedules, I feel that my work is behind the schedule.

I managed to provide some support for line comments and block comments (I have uploaded some screenshots earlier), and I'm still working on expression comments.

At some point I even began to stress out a bit, because I was hoping to have a usable version of GRASP ready for the European Lisp Symposium.

But I haven't heard any response from them, neither negative nor positive (even though it's already 3 days past their deadline).

I also notice that deadlines don't necessarily work well for me. Also, my current day job is fully remote, so I've been mostly working from home, which creates an abnormal condition for the development of GRASP, because so far, I've mostly been developing on my train to and from work. (On the positive side, I started going to the gym regularly 3 times a week.)

In either case, in addition to those comments, I also did something unexpected: I have implemented gesture drawing, which is like in the previous prototype, but which also works in the terminal client -- which I feel is a bit crazy (see the video below).

Anyway, I feel that letting the stress into the development of GRASP was a bad move. It is a fruit of my passion, and I enjoy developing it. I sometimes think about "the grand scheme", and I really can't wait to see it. Yet, there's still so much to do before the vision becomes clear.

On the other hand, as I look back, I am really happy with the progress that I made so far. Sure, there's still so much to be done, but a lot is done already...

@lispegistus I hope that one day #GRASP will become a viable alternative to mobile apps.

When I started developing it, I also tried using Android Studio. It quickly turned out that I had to buy additional RAM, because 2GB wasn't enough even to start up.

And even with 4GB it was terribly slow.

Then I discovered a project called buildAPKs, which allowed me to build apps directly on my phone (in Termux), and I developed two iterations of GRASP entirely on my phone.

Currently I cross-develop GRASP on a laptop and on the phone (I can run it on the phone, in a windowing environment and in terminal), and I think that within a few months I should be able to develop GRASP in GRASP itself.

The terminal version of #GRASP looks progressively more and more like some sort of ASCII art (or rather Unicode art? is that even a thing?)

I hold a strong belief that the future software archeologists are generally going to praise #GRASP for its rather indiscriminate choice of fonts

As February is getting to an end, I decided to summarize another month of work on #GRASP

The main task was polishing the keyboard editing experience. This is a task that I first attempted at the beginning of May 2022.

I remember how hard it was back then, and that the resulting code was incredibly tangled up.

However, it turned out that intermediating all document modifications through reified undoable operations helped to untangle that mess.

While there are still some bugs to be nailed down, and some small things to be improved, I at least reached the point where fixing those bugs seems fairly simple, so I'm not too worried about them.

I also managed to submit my demo paper to European Lisp Symposium, and now I can only wait for a whole month to receive a notification.

But of course I have plenty of other things to do.

My current goal is to bring GRASP to a usable form as soon as possible, which means that I need to
1. provide support for comments (i.e. line comments, block comments and expression comments)

2. provide support for quote, quasiquote, unquote and unquote-splicing

3. fix vertical keyboard arrow movement

4. support file opening and handling

5. support screen scrolling

6. support screen splitting

Overall, I'd like to be able to edit the GRASP source code in GRASP; ideally - before European Lisp Symposium.

Two other hallmarks of GRASP that I want to have, i.e. extension mechanism and gesture recognition - will probably have to wait.

However, I am thinking about implementing quotations and friends using the extension mechanism, so there's a chance that I'll be able to push it a little bit.

Also, gesture recognition is something that I've already done in the previous prototype of GRASP, so I'm not too worried about it.

There's 7 weeks left until the Symposium, and I'm curious how far I'll manage to get. (I think that the points 4, 5 and 6 should be fairly straightforward - because I also managed to implement them in the previous prototype. Point 3 will require at least a week, point 1 - two weeks or so. I am a bit concerned about point 2, but even if it takes more than 3 weeks, I think that the deadline might still be realistic. In either case, being accepted to ELS would certainly boost my motivation.)

#TypesVsTests

@pureevil I don't feel like that's an adequate narrative.

I wrote the earlier versions of #GRASP in #Java with absolutely no tests, which initially gave me velocity to explore things.

But those Java prototypes were ultimately throw-away -- mostly because they were written in Java, but also because there were no tests.

Now that I'm working on "the final version", I use Kawa Scheme. And a part of my "test suite" looks like this:

https://github.com/panicz/grasp/blob/main/src/test-editor-operations.scm#L46

These tests help in two ways. They help me develop my code systematically (and of course give some sense of security when I refactor my code), but they also provide "evidence" for particular operations, so that the person reading the code can imagine how these operations work without studying their definitions (which would be much harder).

Studying the tests is a good place to start when you're new to the code base.

Now, #Scheme theoretically is a dynamically typed language, but Kawa extends it with a roughly Java-like type system.

And I'm really grateful for that.

Without type annotations, everything is considered to be of java.lang.Object type. Type annotations allow me to convey more information. They are also typechecked, which sometimes helps, even though it's not 100% reliable.

But I can make type signatures even more expressive by writing macros that expand to java.lang.Object: I can include useful information in type signatures, even though the compiler (or rather macro expander) throws most of that information away. This may not be perfect (I dream that one day @edwinb will come and implement a more expressive and more reliable type system for Kawa), but it's still useful.

Lastly, I piggybacked on Kawa's type system and Scheme macros to define the first decent record system for Scheme in the history of human kind.

I have used it, among other things, to implement the undo mechanism in GRASP. I honestly think it's beautiful: I define a set of operations, and each operation has its inverse:

https://github.com/panicz/grasp/blob/main/src/history.scm#L31

Contrast this with the way undo is implemented in #Emacs (where both Emacs #Lisp is untyped, and Emacs buffers are unstructured):

https://github.com/emacs-mirror/emacs/blob/master/lisp/simple.el#L3608

Look how all the type information is encoded in the comments, which is both more verbose and more error prone.

In either case, I feel that both types and tests are valuable tools, but they serve different purposes.

This is the closest thing to crazy I have ever seen...

#GRASP #Lisp #Terminal #Drag&Drop

Wow I just realized that the input system that I implemented for #GRASP also happens to be a #Lisp parser!

I just ran into the dissertation of Michael Eisenberg, describing "Bochser, An Integrated Scheme Programming System", and I initially thought that it will turn out to be very similar to #GRASP (or actually the other way around) - but that didn't turn out to be the case.

https://boxer-project.github.io/boxer-literature/theses/Bochser,%20An%20Integrated%20Scheme%20Programming%20System%20(Eisenberg,%20MIT%20MSc,%201985).pdf

@juliana

my temporary answer is

(defun kill-whitespace-or-sexp ()
(interactive "*")
(save-excursion
(save-restriction
(save-match-data
(if (string-match "[ \t\r\n]" (string (char-after)))
(progn
(re-search-forward "[ \t\r\n]+" nil t)
(replace-match "" nil nil))
(kill-sexp))))))

(global-set-key (kbd "M-<delete>") 'kill-whitespace-or-sexp)

my target answer is #GRASP (which is not Emacs, even though its name doesn't make any reference to it not being Emacs)

Dear Fediverse,

I have a software design problem.

As some of you may know, I'm working on a structural (non-textual) editor for #Scheme called #GRASP

GRASP is implemented in Kawa Scheme, so in addition to "just being a Lisp program", it uses Java's object model, which Kawa exposes to programmers.

The representation of documents in GRASP is a bit elaborate: they are implemented as (sort of special) cons cells that can contain other cons cells, Atoms (which can resolve to things like symbols, numbers, etc.) and Text (which resolves to string).

However, I also needed to store some information about whitespace and comments contained in the document.

I chose to use weak key hash tables indexed with the cons cells to store that information, and so I have five tables:

pre-head-space
post-head-space
pre-tail-space
post-tail-space
dotted?

The first four of them return a special Space object, which is a compact representation of spaces (and possibly comments, but that's not relevant right now)

Now, I'm currently working on keyboard editing. The rules of keyboard editing are meant to resemble normal editing text, and it feels quite natural so far - but they are fairly difficult to describe, so it takes time.

Yesterday I made a refactor: I made Atoms and Text implement the same interface, that I have called "Textual". It includes operations like insert-char! or delete-char!.

Now, I am considering whether to make Space also implement that interface. However, the caveat is that the only characters that would be acceptable for Space are #\space and #\newline.

So the question is whether:
- I should make Space implement the Textual interface but make assertions inside the insert-char! that the character belongs to the desired class?
- or should I just have a separate path for editing Space?

This question is more about programmers' expectations regarding interfaces, than it is about finding the "right" technical solution, so I made a poll.

Please help me making it reach other programmers.

Since the January of 2023 is getting to an end, I wanted to summarize this month's work on #GRASP

Not much happened -- certainly less that I would want to.

I did manage to create a unifying layer of keyboard binding support on all three clients (i.e. Android, desktop and terminal). There's also a common initialization file executed by all the clients.

I also managed to implement a prelininary version of keyboard editing. The code is a bit ugly and still requires a lot of work (e.g. to integrate it with the "undo" mechanism - which roughly works for the drag&drop mechanism), but if you don't go astray or run into an irritating bug, it feels fairly smooth.

Here's what it looks like in the Android client:

https://youtube.com/shorts/vjHyoyiPcOA?feature=share

and here's the terminal client:

https://youtube.com/shorts/VzJB1wHymM8?feature=share

The desktop client looks roughly like the Android one, so I spared a recording.

I hope that within the upcomming two weeks, I will manage to polish the code to behave flawlessly.

My most immediate goal is to develop GRASP to the point where I'd be able to use it to develop itself. There's still a lot of work to be done:
- I need to support comments, quasiquote syntax and some Kawa's extensions to Scheme syntax
- I need to improve handling of vertical arrows, because now it's an ugly hack
- I need to implement things like view scrolling, or loading and saving files

My second goal - specifically for the February - is to write a submission about GRASP to the European Lisp Symposium (because of the deadline, which is February 26).

Since it's going to take place in April, I feel that there's a chance that by that time the thing might be usable.

The things that I fear can be missing are:
- the extension mechanism (which is crucial to the concept of GRASP)
- the gesture interface (like the one from the prototype shown on 2020 ICFP's Scheme Workshop - but extensible from within the editor itself)
- particular extensions (I have a few ideas, but I feel that it's too early to be focusing on them)

𝗔𝗽𝗽𝘀 𝘃𝗮𝗻 𝗱𝗲 𝘄𝗲𝗲𝗸: 𝗡𝗲𝘁𝗳𝗹𝗶𝘅 𝗸𝗿𝗶𝗷𝗴𝘁 𝗲𝗲𝗻 𝗺𝗮𝗸𝗲-𝗼𝘃𝗲𝗿

De Netflix-app krijgt een make-over en de eerste functies van Grip komen naar de ABN AMRO-app. Dit zijn de apps van de week.

https://www.nu.nl/tech/6247616/apps-van-de-week-netflix-krijgt-een-make-over.html #nieuws #NUnl #netflix #grasp #abnamro

@cyrilpedia Interesting, and strange that the manuscript on inducing synapse formation with foreign adhesion molecules [1] doesn't mention GRASP (GFP reconstitution across synaptic partners) [2] which essentially does the same thing–strong bounds across membranes of two cells and which is suspected (or known?) to induce synapse formation or prevent their pruning.

[1] Hale et al. 2022 https://www.pnas.org/doi/10.1073/pnas.2215905120
[2] Feinberg et al. 2008 https://www.sciencedirect.com/science/article/pii/S0896627307010203
#neuroscience #GRASP

@sanchayan I kinda liked this article, because it (unwillingly) seemed to explain some fundamental assumptions behind #GRASP.

I wouldn't dare to write anything like this myself - at least not before the release of GRASP, but also because there are aspects of Emacs that I deeply respect.

(That being said, once GRASP is released, I do plan to submit a talk to FOSDEM, titled "sudo killall -9 emacs")