4 ms·

I loved playing around with CL but I never could get my mind around that damn packaging system. Maybe I'll give it another try sometime. Has the community got a

by isaiahg 10y ago

I loved playing around with CL but I never could get my mind around that damn packaging system. Maybe I'll give it another try sometime. Has the community got any better or is it still the online equivalent of a private clubhouse for PHDs to smoke their pipes?

aerique 10y ago
The community is very diverse, just ignore the persons you don't like. Was Quicklisp around when you last tried it? If not, you should check it out again. What were your stumbling blocks wrt the packaging system?
TeMPOraL 10y ago
Common Lisp packages are "weird" because they don't express the same concept popular languages do. CL package is not a Java package. I know I tripped over this at the beginning. Some helpful links: http://www.flownet.com/gat/packages.pdf http://www.flownet.com/gat/packages.pdf http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html http://www.gigamonkeys.com/book/programming-in-the-large-pac... As for community, it's fine now. Lots of friendly and helpful people there.
- kazinator 10y ago
  CL supports multiple dispatch in its generic functions. Multiple dispatch leads to ambiguities. If we call (fun derived-obj derived-obj) and the two available methods are (fun base derived) and (fun derived base), which one is called? Now here is the irony: CL will decide this for you, rather than throw an error. However, if you use multiple packages with same-named symbols, you get annoying errors in your face. That's a philosophical inconsistency pointing at too many chefs in the kitchen. It can't be the work of a single designer that reflects properly on what he or she is doing and has a clearly defined attitude about ambiguous situations in programming.
  - jorams 10y ago
    What happens is well specified, see [1] and more specifically [2]. I don't understand where packages even enter the picture though. Symbols/packages and method dispatch are entirely separate concepts that are hardly related. You certainly won't get any weird errors from one in relation to the other. Furthermore, same-named symbols in different packages are just different symbols. The fact that their name is the same is irrelevant. [1]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ff.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ff.... [2]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ffab.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ffa...
    - kazinator 10y ago
      > What happens is well specified Nobody said it wasn't. > Symbols/packages and method dispatch are entirely separate concepts They are examples of different domains which have referential ambiguities. The object system resolves them. For instance, given (defclass base (d1 d2 ..) ...), base is considered slightly more of a d1 than a d2 in situations where this causes an ambiguity. The tie is resolved and life moves on. Multiple package use is also a kind of "inheritance", yet it blows up in your face when there are ambiguities caused by clashes (which "FOO" symbol do you want? The one from package "A" or "B"?) All these behaviors are specified, but according to different philosophy: just resolve things with a documented tie breaker, versus diagnose the situation. If it's OK for base to be considered slighly more of a d1 than a d2, why isn't it OK for, say, a later package use to just shadow an earlier one?
- fourier 10y ago
  They still have a major flow - common lisp packages are not hierarchical (in contrast to java) which makes it hard to have some symbols exported to not all packages but rather subset of them.
  - sabrac 10y ago
    You can import all symbols from a package with "use" or explicitly import specified symbols with "import" on a package by package basis. I am not following your actual use case, can you explain further?
- kazinator 10y ago
  Common Lisp packages are overly complicated in addition to being different. I designed a package system which shares features with the CL one but is considerably simpler. It captures the salient program organization use cases. In addition, I expose the registry of packages with dynamically scoped variable. This allows programs to easily set up sandboxing. Untrusted code cannot use package prefixes to gain access to functions that you don't want it to, because you control what package prefixes refer to. http://www.nongnu.org/txr/txr-manpage.html#N-000CFF61 http://www.nongnu.org/txr/txr-manpage.html#N-000CFF61

by isaiahg 10y ago

aerique 10y ago

The community is very diverse, just ignore the persons you don't like. Was Quicklisp around when you last tried it? If not, you should check it out again. What were your stumbling blocks wrt the packaging system?

TeMPOraL 10y ago

Common Lisp packages are "weird" because they don't express the same concept popular languages do. CL package is not a Java package. I know I tripped over this at the beginning. Some helpful links: http://www.flownet.com/gat/packages.pdf http://www.flownet.com/gat/packages.pdf http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html http://www.gigamonkeys.com/book/programming-in-the-large-pac... As for community, it's fine now. Lots of friendly and helpful people there.

kazinator 10y ago
CL supports multiple dispatch in its generic functions. Multiple dispatch leads to ambiguities. If we call (fun derived-obj derived-obj) and the two available methods are (fun base derived) and (fun derived base), which one is called? Now here is the irony: CL will decide this for you, rather than throw an error. However, if you use multiple packages with same-named symbols, you get annoying errors in your face. That's a philosophical inconsistency pointing at too many chefs in the kitchen. It can't be the work of a single designer that reflects properly on what he or she is doing and has a clearly defined attitude about ambiguous situations in programming.
- jorams 10y ago
  What happens is well specified, see [1] and more specifically [2]. I don't understand where packages even enter the picture though. Symbols/packages and method dispatch are entirely separate concepts that are hardly related. You certainly won't get any weird errors from one in relation to the other. Furthermore, same-named symbols in different packages are just different symbols. The fact that their name is the same is irrelevant. [1]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ff.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ff.... [2]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ffab.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ffa...
  - kazinator 10y ago
    > What happens is well specified Nobody said it wasn't. > Symbols/packages and method dispatch are entirely separate concepts They are examples of different domains which have referential ambiguities. The object system resolves them. For instance, given (defclass base (d1 d2 ..) ...), base is considered slightly more of a d1 than a d2 in situations where this causes an ambiguity. The tie is resolved and life moves on. Multiple package use is also a kind of "inheritance", yet it blows up in your face when there are ambiguities caused by clashes (which "FOO" symbol do you want? The one from package "A" or "B"?) All these behaviors are specified, but according to different philosophy: just resolve things with a documented tie breaker, versus diagnose the situation. If it's OK for base to be considered slighly more of a d1 than a d2, why isn't it OK for, say, a later package use to just shadow an earlier one?
fourier 10y ago
They still have a major flow - common lisp packages are not hierarchical (in contrast to java) which makes it hard to have some symbols exported to not all packages but rather subset of them.
- sabrac 10y ago
  You can import all symbols from a package with "use" or explicitly import specified symbols with "import" on a package by package basis. I am not following your actual use case, can you explain further?
kazinator 10y ago
Common Lisp packages are overly complicated in addition to being different. I designed a package system which shares features with the CL one but is considerably simpler. It captures the salient program organization use cases. In addition, I expose the registry of packages with dynamically scoped variable. This allows programs to easily set up sandboxing. Untrusted code cannot use package prefixes to gain access to functions that you don't want it to, because you control what package prefixes refer to. http://www.nongnu.org/txr/txr-manpage.html#N-000CFF61 http://www.nongnu.org/txr/txr-manpage.html#N-000CFF61