4 ms·

Why not use simpler names? (bar (foo object)) I mean, I understand that "a.foo" (class A) does not represent the same name as "b.foo" (class B) due to sco

by junke 10y ago

Why not use simpler names? (bar (foo object)) I mean, I understand that "a.foo" (class A) does not represent the same name as "b.foo" (class B) due to scoping rules, and so logically you would have to use (a-foo a) and (b-foo b) if you wanted to replicate the same in CLOS. But on the other hand, FOO can be generic and applied to different types of objects. You might even have a mixin providing the FOO slot, which classes A and B inherit from. I find the notation fine, it looks like regular function application (some people prefer threading macros, I personally don't care). Note also that CLOS allows you to add code "between the dots" by specializing accessors on qualifiers (:before, :after, :around), which can be useful to add orthogonal things like logging, persistency, ...

cronjobber 10y ago
That could work within a single, well coordinated project. Beyond that, the Common Lisp package system doesn't cooperate the way you'd like it to, so you're back at (libraryA:bar (libraryB:foo object)) Since the package system is not hierarchical and doesn't allow local aliases, if you're unlucky you get fully qualified Java-convention package names and end up writing: (com.myfavoritecorp.dept1a.project7.subprojectX:bar (com.biggercorp.dept32.project2.subprojectE:foo object)
- junke 10y ago
  > Beyond that, [it] doesn't cooperate the way you'd like it to I know what I would like it to do. There are some additional features that people would like to use (https://github.com/fare/package-renaming https://github.com/fare/package-renaming), but even though the package system could be improved, I don't think it is so bad right know. It can be frustrating to try to use it in a way it wasn't designed. I seldom use qualified symbols, so it is generally "(bar (foo x))" anyway. The case when fully qualifiable symbols might be the best solution is when you need symbols with the same name from different packages at the same time (without shadowing), which is quite rare IMO. Also, defining short packages as a facade for other packages is possible. When you develop an application, not a library, you can also choose to mess things up by renaming packages and adding nicknames. By using unqualified packages, I can change the meaning of the code by editing only the package definitions (and recompiling): you code says `(foo x)` and originally meant `(a:foo x)`, but then you change a package and now it means `(b:foo x)`. For example `b:foo` could be a wrapper around `a:foo`. Packages prefix help a little when trying to understand where a symbol comes from. For example, "json:decode" is a little easier to read than "decode". However, with the right editor (or just the REPL) you point to the symbol and have the information.
- zeveb 10y ago
  > Beyond that, the Common Lisp package system doesn't cooperate the way you'd like it to I'm pretty sure that it is, and that generally in my package I would import bar from libraryA & foo from libraryB and not have to qualify the names. It's only in the case that both packages export a symbol with the same name that one is forced to disambiguate. I'd say that Lisp's package system is very close to perfect — it really does work well.
- kazinator 10y ago
  The CL package system allows local aliases. How do you think you can be in the default cl-user package yet refer to cl:cons as just cons? Firstly, the exported symbols in one package can be made visible in another package through package use. Secondly, a symbol from package A can actually be made present in package B via import: http://clhs.lisp.se/Body/f_import.htm http://clhs.lisp.se/Body/f_import.htm
  - junke 10y ago
    Regarding packages, sometimes I wonder whether package names could have been symbols: that would allow for gensymed packages, as well as hierarchical packages.
    - kazinator 10y ago
      I implemented a package system influenced by CL's. I thought of the idea of package names themselves being symbols (themselves interned in some root package that has no name, or perhaps has one of those symbols as its name). I couldn't come up with a good set of requirements that would make things better, so I didn't bother with it. It just seemed like self-refererence for the sake of self-reference, like some new appendix to D. Hofstadter's GEB. :)
      - aidenn0 10y ago
        I prototyped a reader-macro for CL that does this, specifically because it gives you package-local nicknames: https://github.com/jasom/spm-reader https://github.com/jasom/spm-reader
        kazinator 10y ago
        I once made a kind of "package Swiss Army Knife" reader macro for Common Lisp which lets you do cool things. It's reasonably well documented in a header comment. It might be up your alley, since you're working on a package-related reader macro: http://www.kylheku.com/cgit/lisp-snippets/tree/pkg.lisp http://www.kylheku.com/cgit/lisp-snippets/tree/pkg.lisp
aidenn0 10y ago
Simpler names is certainly less idiomatic (sibling comments have already mentioned why), so it's a fair complaint. Note that the lisp equivalent of foo.bar(x).baz(y) would be something like: (send (send foo :bar x) :baz y)) which can be made even more terse with a macro, doing something like (@ foo (:bar x) (:baz y)). This was how most pre-CLOS object systems in lisp worked, and CLOS supplanted this. Implementing SEND in CLOS is trivial. There are many people who experienced SEND style object systems and CLOS but I haven't found any of them to be detractors of CLOS, which is what prompted my original question; lisp had something much closer to smalltalk before switching to CLOS and if there is a group of lispers who want to go back to that, they are in a small minority.

by junke 10y ago

cronjobber 10y ago

That could work within a single, well coordinated project. Beyond that, the Common Lisp package system doesn't cooperate the way you'd like it to, so you're back at (libraryA:bar (libraryB:foo object)) Since the package system is not hierarchical and doesn't allow local aliases, if you're unlucky you get fully qualified Java-convention package names and end up writing: (com.myfavoritecorp.dept1a.project7.subprojectX:bar (com.biggercorp.dept32.project2.subprojectE:foo object)

junke 10y ago
> Beyond that, [it] doesn't cooperate the way you'd like it to I know what I would like it to do. There are some additional features that people would like to use (https://github.com/fare/package-renaming https://github.com/fare/package-renaming), but even though the package system could be improved, I don't think it is so bad right know. It can be frustrating to try to use it in a way it wasn't designed. I seldom use qualified symbols, so it is generally "(bar (foo x))" anyway. The case when fully qualifiable symbols might be the best solution is when you need symbols with the same name from different packages at the same time (without shadowing), which is quite rare IMO. Also, defining short packages as a facade for other packages is possible. When you develop an application, not a library, you can also choose to mess things up by renaming packages and adding nicknames. By using unqualified packages, I can change the meaning of the code by editing only the package definitions (and recompiling): you code says `(foo x)` and originally meant `(a:foo x)`, but then you change a package and now it means `(b:foo x)`. For example `b:foo` could be a wrapper around `a:foo`. Packages prefix help a little when trying to understand where a symbol comes from. For example, "json:decode" is a little easier to read than "decode". However, with the right editor (or just the REPL) you point to the symbol and have the information.
zeveb 10y ago
> Beyond that, the Common Lisp package system doesn't cooperate the way you'd like it to I'm pretty sure that it is, and that generally in my package I would import bar from libraryA & foo from libraryB and not have to qualify the names. It's only in the case that both packages export a symbol with the same name that one is forced to disambiguate. I'd say that Lisp's package system is very close to perfect — it really does work well.
kazinator 10y ago
The CL package system allows local aliases. How do you think you can be in the default cl-user package yet refer to cl:cons as just cons? Firstly, the exported symbols in one package can be made visible in another package through package use. Secondly, a symbol from package A can actually be made present in package B via import: http://clhs.lisp.se/Body/f_import.htm http://clhs.lisp.se/Body/f_import.htm
- junke 10y ago
  Regarding packages, sometimes I wonder whether package names could have been symbols: that would allow for gensymed packages, as well as hierarchical packages.
  - kazinator 10y ago
    I implemented a package system influenced by CL's. I thought of the idea of package names themselves being symbols (themselves interned in some root package that has no name, or perhaps has one of those symbols as its name). I couldn't come up with a good set of requirements that would make things better, so I didn't bother with it. It just seemed like self-refererence for the sake of self-reference, like some new appendix to D. Hofstadter's GEB. :)
    - aidenn0 10y ago
      I prototyped a reader-macro for CL that does this, specifically because it gives you package-local nicknames: https://github.com/jasom/spm-reader https://github.com/jasom/spm-reader
      - kazinator 10y ago
        I once made a kind of "package Swiss Army Knife" reader macro for Common Lisp which lets you do cool things. It's reasonably well documented in a header comment. It might be up your alley, since you're working on a package-related reader macro: http://www.kylheku.com/cgit/lisp-snippets/tree/pkg.lisp http://www.kylheku.com/cgit/lisp-snippets/tree/pkg.lisp

aidenn0 10y ago

Simpler names is certainly less idiomatic (sibling comments have already mentioned why), so it's a fair complaint. Note that the lisp equivalent of foo.bar(x).baz(y) would be something like: (send (send foo :bar x) :baz y)) which can be made even more terse with a macro, doing something like (@ foo (:bar x) (:baz y)). This was how most pre-CLOS object systems in lisp worked, and CLOS supplanted this. Implementing SEND in CLOS is trivial. There are many people who experienced SEND style object systems and CLOS but I haven't found any of them to be detractors of CLOS, which is what prompted my original question; lisp had something much closer to smalltalk before switching to CLOS and if there is a group of lispers who want to go back to that, they are in a small minority.