20240804

Helping HEΛP Again! ... and Again!

In the heat of the summer (the coolest summer of the next ones), it is never a good thing to get an email from Xach telling you that "something does not compile on SBCL". In this case the issue was the usual, fascist STYLE-WARNING, that prevented a clean build on Quicklisp.

The fix was relatively easy, but it lead to a number of extra changes to properly test the fix itself.

Bottom line, a new version of HEΛP is available at helambdap.sf.net. Soon in Quicklisp as well.

Stay cool, hydrated and enjoy.


(cheers)

20240627

Helping HEΛP Again!

In a flurry of ... free time, I also went back to HEΛP and fixed a few bugs that were exposed by some of the things I did with CLAST. Recording the documentation strings from the pesky

  (setf (documentation 'foo 'function) "Foo Fun!")
  

are now all working as expected, at least at top-level and within PROGN-like constructs, e.g., EVAL-WHEN.

Meanwhile, I also updated the documentation and the web page adding a few caveats about how to run the DOCUMENT function, and how to work around issues I have seen in my (not so) extensive tests.

Of course, I put my money where my mouth is: the HEΛP documentation web pages are built with HEΛP.


(cheers)

20240626

CLAST reworked

Prompted by a post on one of the various Common Lisp fora, I finally got my act together and went back to CLAST, i.e., the Common Lisp Abstract Syntax Tree library that I had in the works for ... some time.

The library has an interesting origin, which I will recount in a different post. Suffice to say that eventually I needed a code walker which did a few complicated things. NIH sydrome immediately kicked in.

The main think I needed were functions inspecting code, as in the example below.

cl-prompt> (clast:find-free-variables '(let ((x 42)) (+ x y)))
(Y)

To achieve this (apparently) simple goal, a (mostly) portable environment library had to be developed and a full set of AST node structures had to be provided.

The result is now finally ready for prime time. In Lispworks you can also see how things actually get parsed. As an example, the picture below shows the result of the following command.

cl-prompt> (clast:parse '(loop for i in '(1 2 3)
                               count (oddp (+ qd i)) into odds))
#<LOOP-FORM  24ECE77F>
NIL

Please try it, report bugs, blast my design choices and suggest improvements.

Thank you


(cheers)

20240508

ELS 2024 in Vienna

I just got back from the 2024 European Lisp Symposium in Vienna. After many years it was good to meet again in person with so many talented and interesting people (all interested in parentheses).

Many, many thanks to Beppe Attardi, Philipp Marek, Georgiy Tugai, Yukari Hafner, and, especially, Didier Verna, for pulling this together.

20240303

A Rant about R and Python (and anything with a-lists, tuples and "dictionaries").

R and Python come from Lisp (R for sure, Python will deny it). Early Lisp. Even before the first edition of "AI Programming" by Charniak, Riesbek and McDermott.

At that time, there were a-lists and p-lists. Then Charniak, Riesbeck and McDermott taught us (not only them of course) to create records in Lisp. You know... those things like:

    DECLARE
      1 STUDENT,
        2 NAME     CHAR (30),
        2 SURNAME  CHAR (50),
        2 ID FIXED DECIMAL (8),
        2 ADDRESS,
          3 STREET  CHAR (80),
          3 NUMBER  FIXED DECIMAL (5),
          3 CITY    CHAR (80),
          3 PRST    CHAR (20),
          3 ZIP     CHAR (10),
          3 COUNTRY CHAR (80);

Using a-lists the above may become:

    (defvar student '((name . "John")
                      (surname . "Blutarski")
                      (id . 42)
                      (address . ((street . "United State Senate")
                                  (number . 0)
                                  (city . "Washington")
                                  (prst . "DC")
                                  (zip . "20510")
                                  (country . "U.S.A.")))
                      ))

In Python you can do the following.

    student = {}    # a 'Dict'; i.e., a hash table.
    student['name'] = "John"
    student['surname'] = "Blutarski"
    student['id'] = 42
    student['address'] = {}
    student['address']['street'] = "United State Senate"
    student['address']['number'] = 0
    student['address']['city'] = "Washington"
    student['address']['prst'] = "DC"
    student['address']['zip'] = "20510"
    student['address']['country'] = "U.S.A."

Not that you must, but surely you can; and this, as in the case of R below, is the root of my rant.

In R you use lists; a misnomer for something that is essentially a dictionary like in Python, patterned, ça va sans dire, after a-lists.

    student = list()
    student$name = "John"
    student$surname = "Blutarsky"
    student$id = 42
    student$address = list()
    student$address$street = "United State Senate"
    student$address$number = 0
    student$address$city = "Washington"
    student$address$prst = "DC"
    student$address$zip = "20150"
    student$address$country = "U.S.A."

This of course gives you a lot of flexibility; e.g., if - in the middle of your code - you need to deal with the student's nickname, you just write the following.

In (Common) Lisp:

    (defun tracking-student ()
        ...
        ...
        (setf student (acons 'nickname "Bluto" student))
        ...
        )

In Python:

    def tracking_student():
        ...
        ...
        student['nickname'] = "Bluto"
        ...

In R:

    tracking_student <- function() {
        ...
        ...
        student$nickname = "Bluto"
        student <<- student     # Yes, R scoping rules are ... interesting.
        ...
    }

The example is relatively simple and innocuous, but it has some consequences when you have to actually read some code.

The problem I have (it may be just me) is that this programming style does not give me an overview of what a data structure (a record) actually is. The flexibility that this style allows for is usually not accompanied by the necessary documentation effort telling the reader what is going into an "object". The reader is therefore left wondering, while taking copious notes about what is what and where.

Bottom line: don't do that. Use defstruct and defclass in CL, classes in Python, struct in Julia, etc. etc. etc. In R, please document your stuff.

You may feel that your code is less malleable, but, in the end it becomes easier to read. At least for me. Sorry.


(cheers)

20240104

A Parenthetical Year and New Open Parentheses

It has been a few years that I have spent the New Year Holiday to update my Common Lisp libraries and to think about all the open parentheses that are left unclosed. This year is no different, only I have had even less time to work on CL. Therefore, my updates to my libraries on common-lisp.net and Sourceforge all have had some minor repairs and copyright updates. As usual, I direct you to HEΛP and CLAST; most of my other libraries are support for these two.

One effort, I would like to finalize in the coming year (that is; closing this parenthesis) is the CL-LIA layer/library. Help is wanted for this! Drop me a line if you want to chip in. The main issues are API designs around the floating point environment condition handling.

Apart from that, I have been looking more and more to the future, that is, Julia (I should have listened more to some people in the CL community years ago), and... in the past.

Julia and Cancer Research

I have advised a student to work on Julia and the result is this nice (very rough) simulator for solid tumors with input from images and tracking of cells lineages: SOPHYSM. SOPHYSM builds on J-Space which is the simulator core; you can find the publication at BMC Bioinformatics.

I am currently pushing Julia to my research group, especially for new AI and ML applications to Data Analisys in Cancer Research (cfr., Data and Computational Biology Laboratory at Università degli Studi di Milano-Bicocca). This is because new Julia ML and AI frameworks have become much more solid in recent months; in particular Flux and SciML.ai.

Programming Archeology

If you have followed my older posts, you know I fell into a rabbit hole (with several side tunnels). I have been dabbling with very old technology, which turned out to be ... fun (don't tell my Department Head!).

I will just say that now I can understand the vagaries of PL/I (where do you think that loop and generic functions come from?) and that I can write decent Fortran IV (66) (downgrading from Fortran 77). And yes! I can compile my program on Hercules (of course using Emacs to submit jobs to MVS TK5; some work required).

Happy Hacking and Science Year!

That's it. These are my report for 2023, and my wishes for you all in 2024.

Just one more thing: you reader know that I am becoming and old geezer. I somehow rationalize my dabbling with parentheses and even older stuff as "taking care" of things that should not be lost; even if now we have Julia.

Let's all try to take care of each other and the world, of the old things and of the new ones that will inherit it.


'(peace)