Notices by Panicz Maciej Godek (paniczgodek@functional.cafe)

@oldmankris

Forth is when you try to say 'force' but have a lisp

@amszmidt

@weekend_editor

Good question

I think that Norvig's PAIP code is generally good (although IMO it's nicer when rewritten to Scheme), but I find CLOS-heavy code more difficult to digest.

I find that Common Lisp in general has some 'ancient' vibe, which I don't necessarily like. I much prefer Scheme's recursive functions, named let and map/filter/append-map to CL's loop macro, dolist etc.

(Scheme also has the CL-like "do" syntax that I don't understand, and don't want to understand)

There are some things though that are tragic in Scheme (like records and modules) thar are at least acceptable in Common Lisp.

@amszmidt @jackdaniel

@amszmidt

as a schemer, I tried reading both Maclisp and Interlisp, and my experience is that I find Maclisp fairly understandable (and relatively close in spirit to Scheme), whereas I couldn't understand almost anything from Interlisp, and their spirits felt far apart.

In the incidental interview I made a year ago with Bernard Greenberg (who wrote Multics Emacs in Maclisp, after all), he called Scheme "Sussman and Steele’s much-improved Lisp"

@jackdaniel

@amszmidt right, so the difference is that while in Lisp and Scheme you'd pronounce (* 2 3) as "the product of two and three", in Clojure you'd rather say "projuct"

teraz już orzechy
nie sprawiają tak wielkiej uciechy
jak kiedy byłem młody
i oprócz lepszej urody
i nieco gładszej gęby
miałem jeszcze wszystkie zęby

If you pronounce (+ 2 3) as "the sum of two and three" rather than "plus two three", it makes much more sense.

Follow me for more tips like this.

#Lisp #Scheme #Clojure #programming

Some 8 years ago for my master thesis I wrote a simple macro expander for Scheme, which implemented a pattern language akin to syntax-rules.

At that time, I didn't know about Matthew Flatt's "Let's Build a Hygienic Macroexpander" Strangeloop tutorial, the Clinger-Wand HOPL paper about hygienic macros wasn't yet written, and I didn't know anything about Kohlbecker's work .

So I built a much simpler device - something that operated on s-expressions rather than syntax-objects, and something that doesn't track the scope of identifiers, but instead implements the following rules:
- if a symbol was quoted, it was inserted verbatim into the substitution
- if a symbol appears in both a pattern and a template, the form matched by the pattern is rewritten to the output
- otherwise the expander inserts a gensym'd identifier

I honestly think that this simple set of rules is better than the hygienic expander from syntax-rules: it is both simpler (no scope tracking) and more powerful (makes it easier to break hygiene, and doesn't require the use of generate-temporaries), but if someone wants to prove me wrong, I recently dug it up from my master thesis, and after a number of fixes, it currently works under Guile, and is available here:

https://github.com/panicz/jsssssssss/blob/main/expander.scm

@screwtape
"quit meta" seems to be a universally good advice

@jack

This sounds like perhaps some programming language akin to natural language (e.g. Inform 7 or "Plain English") or maybe a multi-lingual environment could be a better fit for "the concept of Emacs" than Emacs Lisp?

(I mean, Emacs certainly is a complex multi-dimensional beast and there isn't a single concept of it, but maybe that would be an interesting experiment)

@jef

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.

I have been working on the current code base of GRASP since the beginning of 2022 (I think I wrote the parser in the fall of 2021), but I created a separate repository for it at the beginning of 2023.

It's a bit frustrating that - despite all the effort that I've put into the development - it still isn't a well polished app, but on the other hand, the experiences that I've been having while working on the Advent of Code solutions were rather positive - and although I think there's still a few bugs that I need to fix before I start nagging people to try and use it, to me peronally the experience has been rather satisfying, and I already started thinking about uploading it to F-Droid (which, from what I've read, is a process that will probably take some time)

I will try to write a summary of the development for this month and year (and the plans for the next year) tomorrow, because I need to go to sleep now.

Of all the software in the world, #Emacs has been the greatest source of inspiration for #GRASP

I sometimes try to conclude what exactly Emacs is. As a matter of fact, the accidental interview that I made with Bernard Greenberg earlier this year happened exactly because I was trying to make a youtube video about "the concept of Emacs". I haven't finished the video - and I don't know if I ever will, so I decided to write this post.

The two obvious non-answers about the essence of Emacs are are "text editor" and "opearting system", and the closest conceptual relatives are Smalltalk virtual machines.

Emacs didn't begin with Lisp. It began with TECO, and it was MIT students' attempt at creating a working environment that wouldn't take away any power from its users, but that would instead empower them even more.

The Emacs paper by Richard Stallman refers, among others, to Doug Englebart's NLS/Augment system.

In either case, it seems that Emacs was as much a social movement as it was a text editor.

The early offspring of Emacs were Eine (which wasn't Emacs) and Zwei (which was Eine initially) for Lisp Machines and Multics Emacs (which was an Emacs).

Greenberg told me that he was a very close friend with Daniel Weinreb, and that they were inspiring each other's work. (He also told me he didn't know Richard Stallman very well.)

In either case, Multics Emacs was the first Emacs to use Lisp, and Stallman loved that idea.

The only Emacs that I had an opportunity to use was (and constantly is) GNU Emacs, which Stallman took from Gosling and modified. Gosling was a former user of Multics Emacs, and once he was confined to UNIX, he missed it so much that he decided to recreate it.

Of course, UNIX already had its editor (developed by Bill Joy) which was called "ex", as an extension to the "ed" editor developed by Ken Thompson. There was a way of running it in "visual mode" in video terminals (as opposed to teleltypes) by using the command "vi". I don't know whether Gosling didn't like it, or loved Emacs so much, but he created a crippled implementation of a Lisp-like language called "MockLisp", to mimic some of the capabilities of Multics Emacs.

(Guy Steele, who originally started the TECO Emacs project, was later serving on a scientific board for Gosling's PhD at CMU)

This is a very twisted story, and it's hard to get a clear-cut idea of what "the essence of Emacs", so...

so maybe you can tell me?

@dthompson FWIW I wrote a simple macro-expander for Scheme in about 500 lines (with explanations/derivation) in my master thesis:

https://github.com/panicz/master-thesis/blob/master/chapters/C.tex

It operates on s-expressions rather than syntax objects, but it supports a pattern language akin to 'macro-by-example' with some extensions, and it also tracks the derivation, so that the expanded code can be 'impanded' back (this feature isn't implemented in the above code, but I had it running on my laptop, and in my bitbucket repo that atlassian decided to kill)

@ChrisMayLA6 the alternative I see is that they don't take help from their parents, thus pumping up the pockets of landlords and bankers?

On various occasions, I think about C++.
I devoted a few years of my life developing a 3d engine in C++. I learned the language from Stroustrup's book ("The C++ Programming Language"). I also developed a Qt-like widget framework using boost::signals

Also, many examples from "The Game Programming Gems" were using C++, and even some of the chapters in those series were devoted to some specific language features (such as template metaprogramming)

But only after I decided to embed #Guile #Scheme into my engine - which resulted in rewriting the whole thing in pure C - I got enough perspective to criticize the language

I have a strong feeling that the popularity of C++ stems from three factors:
- convincing a lot of people that "C++ is a better C, so if you're using C, you can as well use C++"
- lack of critical thinking among most programmers
- the love of complexity among (usually inexperienced and naively enthusiastic) programmers

I started learning C++ around 2003 (so that was ISO/C++98), but - using macros and a GCC extension - I came up with my own range-based for loop:

#define for_every(ITERATOR, COLLECTION) \
for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
ITERATOR != COLLECTION.end(); \
++ITERATOR)

I don't love the C programming language, but one thing it is fairly good at is modeling what the computer is going to do, and how the system is going to be organized (especially if you work with it at the level of object files)

C++ makes this so much harder, with all of its templates, overloading and name mangling. And its design methodology really is reminescent of a kid in a toy store pointing fingers at different toys and saying, "I want this! and that! oh this is so cool can I have it as well?"

There seems to be very little thought, and design thinking, in C++, on a very fundamental level. (And I liked how the recent drama-blog post pointed out Stroustrup's lack of experience)

But the worst thing, let me tell you, the worst thing, are all those proponents of C++ that you meet on the Internet, who have very little to no experience with anything else, and even their experience with C++ is somewhat miniscule (so that they don't even know about the existence of weird entities such as "r-value references"), and they appear every now and then to tell you how wrong you are in your criticism of C++, because it's the best single language ever invented, but somehow they are never able to refute your arguments

I met dozens of them

@lfa Overflow is something that happens during arithmetic operations. When I set 0x80 to a char variable (assuming it's at least 8-bit wide), that variable contains exactly this value: 0x80 (or bit pattern 0b10000000). There is no overflow.

The problem arises with the operator ==, which performs a widening conversion of the variable to the "int" type, because it treats that variable as a signed value (which is implementation-dependent, which is a problem on its own), and instead of treating it as 0x80, it treats it as 0xFF80 (on 16-bit platforms) or 0xFFFFFF80 (on 32-bit platforms), because this is how widening conversion with 2's complement number representation works.

@lfa I tested here https://www.onlinegdb.com/8ejcl5Le9A (gcc 11.4.0) and on clang 16.0.4, and only clang behaved sanely.

@lfa (but I trust that they both conform to the C language specification)

@lfa but I still don't get what this has to do with int overflow

@lfa what does int overflow have to do with that?