Is there any general guidelines (equivalent to How to Write Go Code ) on how to structure large racket project ?
Your question is about structuring large Racket projects, however your example link How to Write Go Code seems mainly to be about how to create a package. These aren't necessarily the same thing (although you might divide a large Racket program into different source directories, which could be "collections" or "packages"). Anyway, to address both parts:
How to structure a large Racket project: Asumu's answer provides a good link: How to Program Racket. In particular see section 3, "Units of Code", which discusses modules. Also, one technique you will see in the source code of Racket itself, is that a module may exist solely to require functions from others and provide them -- to "re-provide". In other words you can use modules like this to chunk up other modules and selectively expose them as a "layer" in your structure. Furthermore, Racket has a class system if that fits your problem domain, and generics if you have some sort of "interface" or "protocol" strategy. And more. Really, there a many, many techniques available in Racket to structure a large project.
How to make Racket packages: This is an interesting time to ask. Historically Racket has used something called Planet as a package manager. More recently, it has a new package system. Although not yet officially out of beta, many people are already using it for real work. The current documentation for that, although in a different style than the Go doc, is Package Management in Racket Beta).
You asked for general guidelines, which is a bit open-ended. If you have any specific choices you're weighing for how to structure a large project, perhaps you could ask about those one by one to get crisper answers?
There is a Racket style guide called How to Program Racket that will ship in the documentation of a future version of Racket. You can read it at the link I posted or in the bundled docs if you build the git version of Racket.
Related
When I use Eclipse or Visual Studio or Xcode, structure of the project gets created automatically and one can get started immediately.
Now I am trying to create a project on Allegro CL express edition and if I collect all lisp files and run it, it shows package errors which I believe is because of files not getting executed in a specific order as packages must be created in some file that must be executed first.
I am not able to understand how to approach this problem. There is no or little information on creating large projects in lisp and how to incrementally deal with its size and complexity.
I want to port Maxima onto Allegro CL. Can I get some help here and also if one can explain this break up of code in multiple files and packages and basically how to load the whole system.
I know basics of lisp but I don't understand lisp project's structure.
Good news: Maxima already has an Allegro port. You should be able to build it using ./configure --with-acl then type make. I haven't used this recently, but I would expect this to work.
If you want to know more about how stuff is loaded, look at src/maxima.system. It's a bit archaic because it is written for defsystem, which has now been replaced pretty much everywhere else by asdf.
Well, Maxima can be compiled via defsystem or asdf by several Lisps, including Allegro. See INSTALL.lisp for details.
The only limitation that I know of is that the Allegro Express version cannot compile the SLATEC-derived code (the functions translated from Fortran are too big or something like that). So you will have to comment out the SLATEC stuff in maxima.system or maxima.asd.
I have developed some Common Lisp functions in a couple of Lisp source files that I'd like easily available to other functions I write, or make available on github if I think they'd be useful for someone else. For now, I've just been putting them in some pre-defined folder and using (require "/path/to/my/modules/module.lisp").
I'm wanting to understand what is the correct (canonical Lisp) way of defining Lisp library of modules. And the second part of the question is how to use them (whether I've defined them, or whether I've obtained one from someone else).
I've been reading a lot about defpackage and defsystem and asdf. But everything I've read seems to focus on some specific corner of the universe of this task. I'm having a lot of trouble seeing the big picture of custom module creation, deployment, and use. So assuming I have the Lisp environment in front of me (CLISP or SBCL) and one or more .lisp files I'd like to make a package or library out of, is there a document somewhere that explains what steps are required to do that? It's probably something I've already read, but didn't track due to not understanding the context. What I've read about ASDF seems functionally to be what I'm after, but I'm left not understanding whether ASDF is my only option, or whether it just happens to be a de facto standard and what most other people use, or whatever. I played with it a bit in SBCL and wasn't sure I was using it right, and didn't see info on how to set it up in CLISP. So I'm wanting to understand what is the up-the-middle, vanilla approach to this task.
I know this is a big, sloppy set of sub-questions. Again, if there are some good references to look at, I can read. I'm just having some trouble getting a big picture view of how this is supposed to work, and whether there is any "best" approach, or whether, in Lisp, it's a bit of a "Wild West" choose-the-library-manager-you like approach. I did the Google thing and read anything that looked relevant, but my brain is spinning from all of it.
Thanks.
A system is a collection of files and sub-systems. One can compile or load such a system. There are also other operations possible. It keeps track of dependencies and tries to do a minimal amount of work.
If you are using SBCL and CLISP, then ASDF is the tool to choose. See http://www.cliki.net/asdf
ASDF provides, amongst other things, a DEFSYSTEM macro to describe such systems.
Don't use PROVIDE/ REQUIRE- unless you know what you are doing. ASDF is the way to go.
To publish your code and make it easily loadable by others then use QUICKLISP. See: http://www.quicklisp.org/beta/
A package in Common Lisp is not like a package in most other senses. It's not an archive of list files, but more like what most other languages would call a module or namespace that lets you select which symbols (names) from your code you want to show to the outside world of code.
If you just have one file for your little library, you can just distribute that. If you have multiple files, that where a tool like ASDF comes in to make sure, for example, that files defining macros are loaded before the files that use those macros.
Here are some good resources for you to look at, both chapters from Practical Common Lisp:
21. Programming in the Large: Packages and Symbols: This will give you a much better sense of what packages are and how and why to use them.
32. Conclusion: What's Next?: The "Delivering Applications" section has some good resources on this stuff in general, and has some mention of ASDF.
ASDF and Quicklisp are useful tools, that is an established fact. However, I would like to give an alternative point of view on the concept of "library" as it is discussed on previous answers
ASDF is designed to automate the compilation and loading of a set of source files. It is to CL what make is to Unix. It is perfectly valid to write and distribute a program without make just as it is fine to write a program in CL that does not use ASDF.
If your project is simple enough, it is sufficient to provide a file (e.g. load.lisp) that contains the statements to load the dependent files of your project in the right order. Therefore ASDF is not involved in the concept of a library.
In a provocative way, I would say that the canonical way of defining a module in CL is to use the defpackage declaration because it is the language unit that allows a programmer to isolate his/her declarations from those of someone else.
Then is the question of how to make it available to others. If you write portable CL code, then ASDF is the most popular system definition facility and you should use it. If you want to make it easier for others to obtain, then Quicklisp is the tool that changed the face of CL in the last few years.
Finally I would like to add that neither ASDF nor Quicklisp are standards, they are tools (which does not remove to their usefulness). ANSI Common Lisp is a standard and I would love to see a system definition standardized in CL.
Yes, ASDF is a de facto standard, and Quicklisp is another standard.
From Lisp's viewpoint what you want is to define one or several namespaces (packages). This is regulated by the ANSI standard. From your code's viewpoint you want to arrange a bunch of files so that they became a whole and somehow provide that packages. This is where ASDF plugs in. And Quicklisp allows you to manage ASDF systems in the easiest way concievable. You can both download a lot of libraries from Quicklisp's repository and manage your local systems creating symlinks in the quicklisp/local-project folder.
If you have Quicklisp installed, you can type
(ql:quickload :cl-fad)
at the REPL and thus load the CL-FAD library (possibly downloading it); then the packages CL-FAD and PATH become available, you forget about ASDF-systems and stick with the logic of packages.
A good idea would be to take a look at asd-files of several projects downloaded with Quicklisp.
I setup my own libraries, that I use often, using ASDF system definitions and linking them into the local-projects (or similar named) folder of Quicklisp. That allows me to load them using quicklisp like any published package.
If you want to learn how to setup such an ASDF system, I would suggest installing Quicklisp (which for once is really easy, when it comes to installing 'unfinished' software from the internet), quickload a well known package or two and look at its .asd file, consulting the documentation when in doubt.
This way, you have your libraries already setup to be published like most of the well known CommonLisp packages out there.
I need to implement a documentation generation solution for my workplace and have narrowed it down to the three mentioned in the title. I have been able to find very little information in the way of formalized comparisons between these solutions, and I'm hoping that those of you with experience in one or more of the above can weigh in:
Here is what I have been able to glean from my initial pass:
HeaderDoc Pros: Consistent with apple's existing docs, compatibility with making apple docsets
HeaderDoc Cons: Difficult to modify behavior, project is not actively worked on, many have switched away from it (meaning there must be something deficient, though I can't quantify it).
Doxygen Pros:
Active support community b/c of wide use base, very customizable, most output types (like latex etc)
Doxygen Cons:
Takes work to make it look/behave consistent with apples docs, compatibility with apple docsets is not as simple
AppleDoc Pros:
Looks consistent with apple's existing docs, compatibility with making apple docsets,
AppleDoc Cons:
Issue with documentation of typedefs, enums, and functions, actively being developed
Does this sound accurate? Our desired solution will have:
Consistent look and feel with apples objective-c class reference
Ability for option-click to pull up documentation reference from within Xcode, and then link to the doc (just like apple's classes)
Smart handling of categories, extensions, and the like (even custom categories of apple's classes)
Ability to create our own reference pages (like this page: Loading… that can include images, and be linkable from generated class references seamlessly, like how apple's UIViewController class reference links to the linked page.
Easy to run command line commands that can be integrated into build scripts
Graceful handling of very large codebase
Based on all of the information above, are any of the above solutions clearly better than the others? Any suggestions or information to add would be extremely appreciated.
As the creator and lead developer of doxygen, let me also provide my perspective
(obviously biased as well ;-)
If you are looking for a 100% faithful replica of Apple's own documentation style, then AppleDoc is a better choice in that respect. With doxygen you'll have a hard time to get that exact same look, so I would not recommend to try.
With respect to Xcode docsets; Apple provides instructions how to set that up with doxygen (written in the time Xcode 3 was released). For Xcode 4 there is also a nice guide how to integrate doxygen.
As of version 1.8.0, doxygen supports Markdown markup, as well a large number of additional markup commands.
With doxygen you can include documentation on the main page (#mainpage) as well as on subpages (using #subpage or #page). Inside a page you can create sections and subsections. In fact, doxygen's user manual was completely written using doxygen. Besides that, you can group classes or functions together (using #defgroup and #ingroup) and inside a class make custom sections (using #name).
Doxygen uses a configuration file as input. You can generate a template with default values using doxygen -g or use a graphical editor to create and edit one. You can also pipe options through doxygen via a script using doxygen - (see question 17 of the FAQ for an example)
Doxygen is not limited to Objective-C, it supports a large range of languages including C, C++, and Java. Doxygen is also not limited to the Mac platform, e.g. it runs on Windows and Linux too. Doxygen's output also supports more than just HTML; you can generate PDF output (via LaTeX) or RTF and man pages.
Doxygen also goes beyond pure documentation; doxygen can create various graphs and diagrams from the source code (see the dot related options). Doxygen can also create a browsable and syntax highlighted version of your code, and cross-reference that with the documentation (see the source browser related options).
Doxygen is very fast for small to medium sized projects (the diagram generation can be slow though, but nowadays runs on multiple CPU cores in parallel and graphs from one run are reused in the next run).
For very large projects (e.g. millions of lines of code) doxygen allows the projects to be split into multiple parts and can then link the parts together as I explained here.
A nice real-life example of using doxygen for Objective-C can be found here.
The development of doxygen highly depends on user feedback. We have an active mailing list for questions and discussions and a bug tracker for both bugs and feature requests.
Most users of doxygen use it for C and C++ code, so naturally these languages have the most mature support and the output is more tuned towards the features and needs for these languages. That said, also wishes for and issues with other languages are taken seriously.
Note that I do nearly all doxygen development and most testing on a Mac myself.
I'm the author of appledoc, so this answer may be biased :) I tried all mentioned generators though (and more) but got frustrated as none produced results I wanted to have (similar goals as you).
According your points (I only mention appledoc and doxygen, I don't recollect headerdoc that well):
Consistent look: appledoc out of the box, other need to tweak css, but probably doable.
Generation of documentation sets (for Xcode references): appledoc full support for searchable and option-clickable documentation out of the box, doxygen generates xml and makefile which you need to invoke yourself. Additionally appledoc supports published docsets out of the box.
Categories: appledoc allows you to merge categories to known classes or leave them separate, foundation & other apple class categories are listed separately in index file. doxygen: this wasn't working best when I tried it.
Custom reference pages: appledoc supports out of the box using either markdown or custom html, doxygen: you can include custom documentation to main page, don't know if you can include more pages.
Easy command line: depends how you look at it: appledoc can take all arguments through command line switches (but also supports optional global and project settings plist files) so it should be very easy to integrate with build scripts. doxygen requires usage of configuration file to setup all parameters.
Large codebases: all tools should support this, although didn't compare timewise. Also not sure if any tool supports cached values (running over previously collected data in order to save some time) - I am looking into adding this for next major release.
It's some time since I tried using other tools, so above mentioned issues with doxygen/headerdoc may have been addressed! appledoc itself also has disadvantages: like you mention there's no support for enums, structs, functions etc (there was some work done in this direction, check this fork), and it has it's own set of issues that may prevent you using it, depending your requirements.
I am currently working on major update that will cover most glaring issues, including support for enums, structs etc. I'm regularly pushing new stuff to experimental branch as soon as I finish larger chunks and make it stable enough, so you can follow the progress. But it's still very early and progress depends on my time so it may take quite a while until working solution.
Xcode 5 will now parse your comments to search for documentation and display it:
You don't have to use appledoc or doxygen anymore (at least when you don't want to export your docs). More information can be found here
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Examples of excellent Common Lisp code?
I'm currently trying to get proficient in Common Lisp and to learn some of the tricks for writing compact, clear and beautiful code in it.
So, I want to know if you have any sources of good Common Lisp, preferably free and online but books are also OK.
The most admirable modern Common Lisp I've seen is in Edi Weitz's libraries. (Look within the outline area NerdStuff/Common Lisp/Code available on this server.) His CL-PPCRE library is worth studying in depth.
Large codebases can be schizophrenic, because there are often many contributors to the project. I would also say that contributors tend to want to add new features rather than re-write some code because it could be coded in a slightly more elegant way.
Paul Graham is attributed with good coding style. The link points to pages where his coding style in ANSI Common Lisp is commented upon.
Peter Norvig has also written about good Lisp coding style here.
Practical Common Lisp
Complete book (HTML) is free.
http://www.gigamonkeys.com/book/
Most open source Common Lisp (CL) environments ship with a lot of CL source code.
Take a look at CMUCL, CLISP and SBCL.
Cliki (the Common Lisp Wiki) has many open source CL packages.
Google Code Search is another large repository of CL code. Setting the language to "Lisp" will return both CL and non-CL files, like Emacs Lisp (.el) files. To narrow the results, set the Files text box to .lisp$ so only file names that end in .lisp are returned.
Paradigms of AI Programming. The code is online, though the book itself is not to be missed.
On Lisp is also very fine.
Are there any libraries out there that do this? Playing around with Common Lisp it seems like this would be one of the most useful things to lower barrier of entry for newcomers. ASDF seems mostly designed for deployment, not for rapid prototyping and development. Following threads on comp.lang.lisp it seems like people agree that CL's package system is powerful, but lacks the ease of something like Python's dead simple module system. It is FAIL in the sense that it's designed for power not usability.
Glad to know if I'm wrong. If I'm right, I'm stunned that noone has tried to build a Python module-like system on top of ASDF.
Zach Beane wrote how he nowadays starts new Common Lisp projects by using Quicklisp and Quickproject. This might be along the lines you want.
Not sure if it's ready for prime time or whether it fits your requirements at all, but here's a link to XCVB.
I don't know. I mostly use ASDF for my in-development compilation needs. Once you notice that you'd benefiot from more than one source file, open <projectname>.asd, slap in a basic ASDF system definition template and start slapping filenames in. As and when you notice a cross-file dependency, update the dependency list.
But, then, I use the exact same method dealing with Makefiles (yes, I know there are automatic dependency checkers that can do it for you, but since I mostly code on my own, it's easier to just amend the Makefile/ASDF definition as I go).
In SBCL, there's a hook on REQUIRE that checks for ASDF systems, so you end up with something that is about as convenient as Python's import, but somehow I suspect that is not what you meant.
This may not be the answer you want, but clearly you have some idea of what you want in a module system. Have you considered creating one yourself? That is, taking your limited domain, your limited requirements, your environment and simply pounding out whatever abstractions will quickly make your life easier?
That's one of the key benefits of Lisp I'm sure you know, is that these simple abstractions and little tools are typically very easy to craft in Lisp.
I'm not suggesting solving everyone who has a problem with the package system or ASDF, I'm simply suggesting solving your own problem as you understand it, which is likely simpler and smaller than some more powerful larger scope.
There is Mudballs now, too.
If you're looking for a piece of software to add this functionality to then it's a good bet.
If you want a command line tool that just uses bash to generate new common lisp project directory and file layouts, you may find one that I created for myself useful: lispproject. If it doesn't match your needs, go ahead and fork it or the repo it gets it templates from to suit your needs: lisp-project-template. Look at the sh file in lispproject repo to see how the templates are used. Also, please note that you may need to adjust the calls to sed to fit your platform as I am using this on macOS. Alternative sed calls are in the main script but just commented out if you need them.
it's designed for power not usability
that's how most Lisp gurus like it.