Hacker News new | ask | show | jobs
by jorams 3445 days ago
I think most CL programmers would agree with several of your points. Using lists of symbols instead of strings is not useful. Though there are infinite ways to model the calendar, a slightly better way would be something like the following. Note that it's incredibly similar to your Clojure example, though it uses property lists instead of maps:

    ((:start @2014-01-02T09:15:00Z :end @2014-01-02T09:15:00Z :description "See Anderson")
     (:start @2014-01-02T10:45:00Z :end @2014-01-02T11:00:00Z :description "See Lundstrom")
     (:start @2014-01-02T13:15:00Z :end @2014-01-02T16:00:00Z :description "Attend Y Committee Meeting")
     ...)
Do note that this uses the local-time[1] library's timestamp syntax. If you don't want dependencies you could put numerical universal-time[2] timestamps there.

Of course, depending on the programmer, this would change a lot. For example you could use a simple list or vector of 3 items instead of a property list, or maybe an association list. But if this isn't a one-off thing, most would probably define a class or a struct to store the data in, with proper accessors to get the data out. This wouldn't be so easily PRINTable as the above, but in code it would look something like the following:

    (list (make-appointment :start @2014-01-02T09:15:00Z
                            :end @2014-01-02T09:15:00Z
                            :description "See Anderson")
          (make-appointment :start @2014-01-02T10:45:00Z
                            :end @2014-01-02T11:00:00Z
                            :description "See Lundstrom")
          (make-appointment :start @2014-01-02T13:15:00Z
                            :end @2014-01-02T16:00:00Z
                            :description "Attend Y Committee Meeting"))
Now you have data with actual types, with accessors like appointment-start, appointment-end, and appointment-description.

[1]: https://common-lisp.net/project/local-time/manual.html#Reade... [2]: http://www.lispworks.com/documentation/HyperSpec/Body/25_adb...