What would you like to see in uLisp in 2023?

#22

For these reasons I think gensyms would be necessary too.

#23

Very true!
Here is a good example the first post by Rainer Joswig covers it well.

I don’t think Lisp stores all past gensym’d symbols. They’re free to be garbage collected but it does increment a gensym forming counter when making them which uses that global counter to make the next gensym.

Now if the gensym C counter is very small for uLisp (byte?), perhaps it attempts to fill old holes before incrementing. I think technically they’re not to be reused but uLisp has small footprint needs. Also, the default gensym would probably work. The optional prefix is for the programmer but I’d imagine it creates yet another lookup table.

Didn’t mean to open a can of worms!
Up to you of course. :)

#24

On the other hand, perhaps I already have (gensym) :)
This will not conflict with interned symbols if a user defines “g4”.
At that point it should see it and hop over, generating “g5”.
Even when you delete the old symbol from memory the counter holds until it wraps around (very unlikely).
At that (extreme) point, I believe it’d start filling gaps.

(defvar *gensym-counter* 0)

(defun gensym (&rest prefix)
  "Generates new symbol, increments *gensym-counter* until empty is found."
  (loop
    (let ((new-sym (read-from-string
                    (concatenate 'string
                                 (or (car prefix) "G")
                                 (string (incf *gensym-counter*))))))
      (when (not (boundp new-sym))
        (return new-sym)))))

(symbolp (gensym "foo")) ; She's a symbol
(eq (gensym) (gensym)) ; They're unique
#25

Maybe, based on summary of all completed projects, it would be possible to design a framework for a basic nano-satellite?

#26

Your wish has come true! See uLisp Release 4.4.

#27

2 posts were split to a new topic: What would you like to see in uLisp in 2024?