3 ms·

As the sibling commenter said, that code admits a relatively standard translation. Without understanding the nuance of your code, and assuming you've made your

As the sibling commenter said, that code admits a relatively standard translation. Without understanding the nuance of your code, and assuming you've made your own data structures and didn't use Lisp's standard ones (e.g., Lisp's native lists for the `batch` object), the translation would be this: (defun buffer-batch-array-from-linked-list (arena batch count) (let ((result (make-edit-array :count count :vals (push-array arena edit count)))) (loop :for counter :below count :for node := batch :then (next node) :for vals := (vals result) :until (null node) :do (setf (aref vals counter) (edit node))) result)) This is very typical Lisp code. Could you adorn this code with type declarations? Yes, and you'd get speed and/or safety benefits by doing so. Depends how much this function "matters" in the larger context.

klipt 4y ago
One difference that stands out here is that in the original code, the methods "node->next" and "node->edit" both belong to a "node" namespace, so you could have other objects with the same method name, e.g. perhaps "document->edit(patch)", and there would be no collision since they're in different namespaces. But in your lisp version "next" and "edit" appear to be global methods. That seems like it could lead to a lot of naming collisions. Could you still have a document type that you can call "(edit document patch)" on? A preliminary Google search suggests that CLOS methods can't have definitions with a different number of parameters, so now you're stuck with a global "edit" method that can only ever take one parameter.
- reikonomusha 4y ago
  Common Lisp has generic functions, as you saw. Readers, writers, and/or accessors to classes are generic. So no issue with naming collisions. (defclass a () ((value :reader value) (next :reader next))) (defclass b () ((value :reader value) (next :reader next))) This is totally valid; I can call VALUE and NEXT on instances of both A and B just fine. But, if generic functions aren't your thing, you can skip calling the functions even and just do (slot-value x 'next) if you really want. This is basically x->next Again, works for any object with a field named by the symbol "next". But it's idiomatic to just call the reader function you defined, since getters can be instrumented, debugged, traced, etc. Some people prefer to call the reader A-NEXT or B-NEXT, but it's not necessary. Regardless of all of that, symbols themselves belong to a namespace, called the "package". So your "edit" and my "edit" methods can have a different number of arguments without issue. (If they do have different arguments, they must mean different things.)
- kazinator 4y ago
  In Lisp this is solved with some combination of better names and symbol packages. E.g. you might have some doc-model:edit symbol and file-utils:edit or whatever. The symbols have the same name, but are different objects in different packages. The generic function doc-model:edit is therefore unrelated to file:edit. Packaging at the symbol level means that the package system is relevant to anything whatsoever that is named by a symbol. If you have some logic programming system where you declare some named rules or facts, they can easily go into a package. Symbols which are quoted individually or in a larger literal are in the package system all the same; it's an independent layer.

klipt 4y ago

One difference that stands out here is that in the original code, the methods "node->next" and "node->edit" both belong to a "node" namespace, so you could have other objects with the same method name, e.g. perhaps "document->edit(patch)", and there would be no collision since they're in different namespaces. But in your lisp version "next" and "edit" appear to be global methods. That seems like it could lead to a lot of naming collisions. Could you still have a document type that you can call "(edit document patch)" on? A preliminary Google search suggests that CLOS methods can't have definitions with a different number of parameters, so now you're stuck with a global "edit" method that can only ever take one parameter.

reikonomusha 4y ago
Common Lisp has generic functions, as you saw. Readers, writers, and/or accessors to classes are generic. So no issue with naming collisions. (defclass a () ((value :reader value) (next :reader next))) (defclass b () ((value :reader value) (next :reader next))) This is totally valid; I can call VALUE and NEXT on instances of both A and B just fine. But, if generic functions aren't your thing, you can skip calling the functions even and just do (slot-value x 'next) if you really want. This is basically x->next Again, works for any object with a field named by the symbol "next". But it's idiomatic to just call the reader function you defined, since getters can be instrumented, debugged, traced, etc. Some people prefer to call the reader A-NEXT or B-NEXT, but it's not necessary. Regardless of all of that, symbols themselves belong to a namespace, called the "package". So your "edit" and my "edit" methods can have a different number of arguments without issue. (If they do have different arguments, they must mean different things.)
kazinator 4y ago
In Lisp this is solved with some combination of better names and symbol packages. E.g. you might have some doc-model:edit symbol and file-utils:edit or whatever. The symbols have the same name, but are different objects in different packages. The generic function doc-model:edit is therefore unrelated to file:edit. Packaging at the symbol level means that the package system is relevant to anything whatsoever that is named by a symbol. If you have some logic programming system where you declare some named rules or facts, they can easily go into a package. Symbols which are quoted individually or in a larger literal are in the package system all the same; it's an independent layer.