Conversation

Notices

1. Embed this notice
   LisPi (lispi314@udongein.xyz)'s status on Saturday, 02-Nov-2024 07:07:02 JST LisPi

   • screwlisp
   • Paul SomeoneElse
   @pkw @screwtape Alternatively, if one is presenting a stable API of some sort (or supporting a versioned protocol), it could make sense to keep the old ones around.
   • Embed this notice
     Paul SomeoneElse (pkw@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:34:54 JST Paul SomeoneElse

     #techpost

     I use the word(s) pattern a lot when describing code where 'word' is some specific name so I don't want the plural 's' to confuse that. Writing thing(s) lets me talk about a group of thing instances using the plural w/o making the name confusing to myself.

     I also obsess over whether to name something with the plural outright. This comes up a lot in table names. I tend to want to use the singular unless there's a reason not to.

   • Embed this notice
     Paul SomeoneElse (pkw@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:50:11 JST Paul SomeoneElse

     in reply to

     I am a serenity prayer programmer 😋

     screwlisp repeated this.
   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:50:11 JST screwlisp

     in reply to

     • Paul SomeoneElse

     @pkw did you have opinions viz this whole conversation https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf ?
     While reading through the beginning of SICP, I noticed I have a reactionary feeling against the Good Advice shared between a lot of the introductory lisp books. Imagine I have something like
     (defun x-value (3-list) (car 3-list)) <=> (setf (symbol-function 'x-value) #'car)
     I don't see the poetry of the euphemism x-value for car. So I think lisp objects should all be directly amenable to function-lambda-expression

   • Embed this notice
     Paul SomeoneElse (pkw@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:50:12 JST Paul SomeoneElse

     in reply to

     But one of my opinions is that idiom is more important than my opinion.

     So when I am in a code base that uses plural table names for example, I am totally not bothered.

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:51:53 JST screwlisp

     in reply to

     • Paul SomeoneElse

     @pkw and as a corollary, new function definitions should feel similar to coining new words with all the weight that entails.

   • Embed this notice
     Paul SomeoneElse (pkw@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 05:53:04 JST Paul SomeoneElse

     in reply to

     ALSO common lisp and this fit together VERY WELL.

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 06:18:16 JST screwlisp

     • Paul SomeoneElse

     @pkw here we run into the whole Let Over Lambda paradigm of having your function-lambda-expression -s (which can be closures) include their own machinery for their use and implication changing over time.
     I guess in this case interactive renaming could be like
     (setf (symbol-function 'new-name) (symbol-function 'old-name))
     (fmakunbound 'old-name) (unintern 'old-name)

     (though the lambda could also just sit in the symbol-value to be funcalled or applyed as well)

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 06:29:15 JST screwlisp

     • Paul SomeoneElse

     @pkw well it's just the lisp2 thing right. Whereas in practice we normally use defun, or have a compiled lambda in the value cell, to be lisp2 means
     CL-USER> (apropos 'symbol- 'cl)
     DEFINE-SYMBOL-MACRO (fbound)
     SYMBOL-FUNCTION (fbound)
     SYMBOL-MACROLET (fbound)
     SYMBOL-NAME (fbound)
     SYMBOL-PACKAGE (fbound)
     SYMBOL-PLIST (fbound)
     SYMBOL-VALUE (fbound)

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 06:45:33 JST screwlisp

     • Paul SomeoneElse

     @pkw well the joke is that what makes something a lisp2 is that it has 6 namespaces
     symbol-function symbol-value symbol-name symbol-package symbol-plist
     and sixthly, the KEYWORD package is its own namespace in a similar way.
     I became more cognizant of this when I started using plists, ie storing stuff in
     (setf (get 'my-symbol :my-property) 'stored-value)
     ; this way I'm not tempted to try and use symbol-value basically as a plist.

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 07:00:27 JST screwlisp

     • Paul SomeoneElse

     @pkw
     It does come up in people other than mine's code as well.
     Imagine if you are concerned with lighting fixtures in rooms and you have a room stored in
     (intern "KITCHEN" "ROOMS")
     but since we are also specially concerned with roomses lighting we could symbolically imagine to check for or otherwise also use
     (intern (format nil "~@{~a~^-~}" 'kitchen lights) "ROOMS")
     which would implicitly (explicitly?) house room lighting value, functionality and metainformation (plist).

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 07:07:00 JST screwlisp

     in reply to

     • Paul SomeoneElse

     @lispi314
     maybe with a compatibility layer to the new function in its 'symbol-function and a :status "DEPRECATED" or something in its plist
     @pkw

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 07:51:02 JST screwlisp

     in reply to

     • Paul SomeoneElse

     @lispi314
     It's interesting that lisp retains basically maclisp compatibility, but also has CLOS. I think that what you have said about CLOS is relevant when implementing and exposing your package's previously agreed upon protocol implementation to users (in this case, application programmers).
     There is however the different scenario: Making original programs, in which case by definition we don't know what will turn out to be the right move right now, and we can anticipate needs changing.
     @pkw

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Saturday, 02-Nov-2024 07:51:03 JST LisPi

     in reply to

     • screwlisp
     • Paul SomeoneElse
     @screwtape @pkw It'd be nice for Common Lisp to have something like Emacs Lisp's make-obsolete that is actually considered by the rest of the system.
     
     Compatibility layer is only good (mostly) if the signature doesn't change, otherwise it's creating an avoidable maintenance nightmare (especially if multiple versions are kept) while also worsening the usability with all sorts of docstring-only info (or worse, a bunch of undocumented behavior).
     
     The pattern I've observed that is most sensible for this is encoding the difference in the classes, such that one can then simply recursively upgrade the instances (now-obsolete and unused methods can possibly be safely removed at this point depending on program flow), handling all that is necessary for compatibility differences there, and otherwise preserve everything unchanged from an external user point of view.
   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Saturday, 02-Nov-2024 11:02:27 JST screwlisp

     in reply to

     • Paul SomeoneElse

     @pkw
     Clojure a lisp-1? That's quite different indeed to lisp []. @aartaka
     @lispi314