freenode/#lisp - IRC Chatlog

2:07:01 thmprover Random question: is there any strong consensus about package-name and directory structure? E.g., in Clojure, each namespace has its name be the file name, and subdirectory as prefix to namespace...does Common Lisp informally do likewise? Or is it all pushed in one giant package?

2:07:38 no-defun-allowed It highly depends.

2:08:00 no-defun-allowed But the alternative, from experience, is "giant files".

2:10:29 no-defun-allowed In my implementation of Netfarm, there are 30 files, each about 50-70 LOC, in one package. There are about 80 exported symbols from memory.

2:11:55 PuercoPop thmprover: There is no strong consensus, but most people use one package per project. There is a one package per file style supported by ASDF and some people do you prefer it. That style is the most similar to the one you'll find in Clojure.

2:13:16 no-defun-allowed Another interesting example is a CLIM implementation; there are many files with (in-package :clim-internals), but they export symbols in some other packages (CLIM, CLIM-EXTENSIONS, etc). And my networking code and Petalisp have several modules, each with a package.

2:14:09 thmprover I've just been sweeping my quasi-CAS into a ./math/ subdirectory of my project, it *feels* natural to include ".math." as part of the package name, but that's a Clojure habit I've acquired

2:14:57 PuercoPop thmprover: You do you boo!

2:16:35 no-defun-allowed The Java teacher at this university told us that you name the files the same name as the classes so that you can always find the implementation of a class without using a search tool. Now, without using a search tool, how do I find the method toUpperCase in java/lang/String.java?

2:16:45 no-defun-allowed But do whatever suits you and your design, really.

2:24:43 thmprover One more question: what conventions are there for docstrings? I infer from the few examples given that UPPERCASE is used for function parameters, and when referring to other functions in my own codebase I defined I should wrap the `function-name' in quotes (like thus).

2:26:53 no-defun-allowed I've always written parameters and function names upcased, or as normal if some noun matches the name of a parameter, eg (defun not-actually-subseq (sequence start end) "Return the contents of a sequence from the start to end positions" ...)

4:07:37 beach Good morning everyone!

4:19:11 beach thmprover: I find it best to have one directory, one package, and one ASDF system definition per *module*. Such a module can have several source files with one and the same initial IN-PACKAGE form.

4:20:10 beach This way, another module can "use" another module by adding its system name to the list of dependencies in its own ASDF system definition.

4:22:47 beach I have yet to see any advantages of a package per file. Every time it is brought up, I learn about contortions that are needed in order to avoid a single huge file for the module or a proliferation of packages that have no semantic meaning.

4:27:00 oni-on-ion back in the day afaiu, more code was per .lisp file

4:28:49 thmprover beach: that is a sound and reasonable design decision. The problem I have is the modules are all really tightly coupled together.

4:29:07 beach Then they aren't "modules".

4:30:06 beach By definition a "module" has a very small interface to the outside world compared to its implementation.

4:31:41 beach Ousterhout (I think it was him) calls them "deep" modules. He uses the image of a rectangle with constant area representing the code size, and the top edge representing the interface.

4:32:02 beach So you want your rectangle to be deep and narrow.

4:32:35 thmprover Yeah, the program is a quasi-CAS with applications to physics (analytical mechanics and field theory), which makes it hard to separate out the code into modules. Ironically, it's for the same reason people called this stuff "beautiful" for a couple centuries...

4:35:32 thmprover I'm sure it's going to be clearer as I continue plugging along, because right now my goals are fuzzy ("do science"). Later, after I have more infrastructure set up, it will become clearer (e.g., "handle celestial mechanics") and, hopefully, even clearer as I progress.

4:36:04 beach How is your system different from Maxima?

4:36:11 oni-on-ion i like this metaphor imagery

4:36:30 beach thmprover: Or is it just that you want to implement this stuff in order to learn?

4:36:42 beach oni-on-ion: Yes, not bad at all.

4:37:39 thmprover beach: isn't Maxima exclusively a CAS? I was hoping to write some GOFAI to do science, in the sense of answering questions and solving problems (not doing any labwork, though).

4:37:47 oni-on-ion lisp+repl is a good platform for having a scratch file, like a pottery floor. then seperate/order stuff out as things solidify

4:40:15 beach thmprover: I am not a domain expert so you may very well be right.

4:41:27 no-defun-allowed You can write list processing and structure processing programs in Maxima, but the evaluation model is a bit wonky.

4:45:19 thmprover I'll look at Maxima as a library, but the main goal is to have a Lispy Leibniz AI do science. Gordon Novak has a simple Lisp program that's a proof-of-concept of simple problems (you can try it online https://www.cs.utexas.edu/users/novak/cgi/physdemod.cgi).

4:50:40 thmprover Egads, it's late, time for bed. Good night, all!

6:00:17 oni-on-ion how come defvar cannot provide both functionality of itself, as well as defparameter ?

6:02:13 beach Because the two have contradictory behavior?

6:02:49 beach You would need a keyword parameter then, like :SET-IF-BOUND.

6:06:38 oni-on-ion ahh; i would have figured that defparam with no second arg could act as defvar

6:06:41 oni-on-ion ACTION naive

6:42:07 loke[m] phoe: Beach suggested a talk about maxima/climaxima. Would that be of interest?

6:58:19 beach I am trying to figure out under which circumstances DEFMETHOD calls ENSURE-GENERIC-FUNCTION, and which what arguments.

7:00:16 beach DEFMETHOD can't blindly call ENSURE-GENERIC-FUNCTION because it would need to supply some :LAMBDA-LIST keyword argument, and if it just supplies its own (with specializers and default arguments removed) then the generic function will be reinitialized without any reason.

7:00:52 imode ** NICK ava

7:00:58 ava ** NICK imode

7:01:06 beach As long as the lambda lists are congruent, DEFMETHOD should at least avoid passing a different lambda list to ENSURE-GENERIC-FUNCTION.

7:02:26 beach But should DEFMETHOD also check the METHOD-CLASS?

7:03:13 beach I guess DEFMETHOD can just call ENSURE-GENERIC-FUNCTION and rely on it to either reinitialize or signal an error.

7:06:51 beach I think I need to re-read the MOP section about initialization of generic-function metaobjects.

7:18:56 beach Nothing special there. Let me check ADD-METHOD.