- pro - mailman3.common-lisp.net

[pro] Compiler APIs in Common Lisp
by Matthew Swank 13 Apr '11

13 Apr '11

I am current reading an interesting paper on Racket's macro system (referenced here: http://lambda-the-ultimate.org/node/4196 ), and some of the objects they expose quack like CLTL-2 Environments: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html. I have read that having write access to environments makes it hard for the compiler to optimize code. However, even portable read only access would be helpful. Does anyone besides me and Cyrus Harmon (http://cyrusharmon.org/blog/display?id=113) miss Environments? Matt

6 6

[pro] code organization and name conflicts
by Ryan Davis 13 Apr '11

13 Apr '11

When working on a larger lisp code base, one with 10+ files in one package, I begin to get nervous about accidental name conflicts, and was wondering how other people deal with this. Here's the scenario I'm worried about: * dsl.lisp, written by a coworker two years ago, has a number of small functions that are helpers for the main #'WRITE-DSL-REPORT function; one of these helpers is #'GET-WAN-IPS * nagios-config.lisp, written by me today, has a number of small functions that are helpers for the main #'WRITE-NAGIOS-CONFIG function; one of these helpers is #'GET-WAN-IPS * I miss the compiler warning about redefining #'GET-WAN-IPS * I test my code, it works in my REPL so I commit and call it a day * Code eventually gets pushed to production and #'WRITE-DSL-REPORT is broken It doesn't happen very often (and testing procedures usually catch stuff before it goes to production), but it seems like there should be a nicer way to deal with helper functions that you want to develop/test from the REPL, but don't need to be used outside the current file. I had a few ideas to solve it, none of which I really like. I could add a top-level FLET for the file, but the extra indentation will be annoying and it'll be harder to test/maintain those helper functions. I could define a helper package, per-file, and put my helper functions in that package (e.g. (defun nagios-config-helpers::get-wan-ips ...)), but that feels funny and awkward, which usually means it's a bad idea. I could break up my code into many smaller packages, each exporting and importing the functions needed elsewhere in the system, but that seems like recipe for dependency headaches and a lot of unneeded paperwork. Do other people have this anxiety? Are there elegant ways to deal with it? (besides medication and more unit testing) Thanks, -- Ryan Davis Acceleration.net Director of Programming Services 2831 NW 41st street, suite B Gainesville, FL 32606 Office: 352-335-6500 x 124 Fax: 352-335-6506

4 3

[pro] PDM Review
by aashish atl 13 Apr '11

13 Apr '11

Hi, I am developer of aspiwork-pdm project that I moved to cl.net in Feb'11. Motivation for this project can be found on its devel mailing list. At present, application is a crude expression of what I intended to do. I spoke to some prospects in my locality. Most of the office owners agree that integration of their resources would be a great idea. Yet I am not sure if their hesitation purely relates to technical issues... I am not getting a satisfactory feedback. With this much, I have virtually not touched the code for weeks. I welcome your perspectives on this project. While comments on its actual code may suit project's own mailing list; here I seek some enlightenment on project's concept/design, utility in day to day scenario, acceptance of common lisp for such application... any other comment from your point of view. I see document management and process flow modules in a few 'cloud' services and upscale ERP installation. I am wondering if these are practical at smaller level with common lisp as a tool. I guess few of you must have implemented similar systems. Thanks. Regards -Aashish

1 0

[pro] Order of package declarations
by Daniel Weinreb 06 Apr '11

06 Apr '11

In large Lisp systems, it's easy to run into problems with the order in which files are loaded and compiled. One often-vexing issue is where to put package declarations. If a file names an exported symbol such as foo:bar, the package foo with its export list must have been loaded earlier. In general, it seems to me that in a big complicated system with lots of packages, it would be great if you could just first load all the files with defpackage forms, and get all those packages created and all the external variables externalized, and then load everything else. However, in a situation I'm working on now, that doesn't work, because package X has (:import-from :y :a1 :a2), and the symbols :a1 and :a2 are not exported from :y. That is, X is exporting internal symbols of Y. This fails, because the symbols :a1 and :a2 do not exist, because they get created only when the files that define them get loaded. So doing all the package declarations first does not work. Possible approaches: (1) Too bad; you really do have to load the Lisp files that created those internal symbols after defining package X and before defining package Y. (2) For Y to export symbols of X that X does not export, while being valid Common Lisp, is a bad practice. It's a little hard to explain why we're doing this at all. I think it is historical. Originally there was only package X. Then it was considered a good idea to classify some of the functions in package X under a new package name, Y, to make the rest of the code clearer. Unfortunately, the symbols and functions and macros of package X may be too entangled to separate them out the way we would have done had the partition between X and Y been done from the beginning. By "too hard" I mean that it's not worth the trouble to attain the goal, which was to remove a single ugly use of "::". But I'm interested in the topic anyway. -- Dan

4 3

Re: [pro] definitional home
by Bob Kerns 30 Mar '11

30 Mar '11

I don't mean to discourage innovative thinking here, but for reference, consider that the editor and/or separate source indexer can locate defXXX forms, and record the location of (define-widget cool-widget ...) as (:definition (:name cool-widget :type define-widget) :location (:file "file.lisp" :line 28)), and make it available to meta-dot. While I can see advantages to having a form record where it came from, as you guys are describing, there's also a huge disadvantage -- the need to actually expand (and possibly evaluate) that macro, before being able to use meta-dot. You'd *like* to be able to edit code which is only conditionally loaded, or intended for some other platform or environment, or not yet working. Let's say, you just modified (and broke) the define-widget macro,and now you want to look at its usage -- but you can't, because you can't load it, because the file define-widget itself is in is broken and won't load. You'd even like to be able to index forms which are read by neither the compiler nor the interpreter. You may have definitional data which you want to constrain to certain definitional types, and NOT allow arbitrary evaluation (for example, it may be from an untrusted source). That said, it's typical for compilers and interpreters, in many languages, to record source locations. This has advantages when no source is available -- for example, reporting stack traces. Sometimes you can even detect version-mismatches between source and binary as a result. But I don't think it's ever the optimal solution for a development environment. Eclipse sort of does both for Java -- if you have a jar file with binaries, you can associate it with a directory or jar with sources; otherwise, it indexes the sources as it parses them, collects cross-reference data, etc. (It also constructs cross-reference data for the .jar files, so you can find usages within methods within classes in compiled jar files). So I'd say, what you really want here is, not a run-time or read-time action, but rather a declarative hint to both compiler and editor, that a particular form is definitional. The simplest, and traditional way to do that, is to simply declare that forms beginning with 'def' are definitional. It's arbitrary -- but it's simple.

2 1

[pro] DEFVARs combined service
by Kazimir Majorinc 28 Mar '11

28 Mar '11

"DEFVAR and DEFPARAMETER do the combined service of - in some implementations, recording the "definitional home" of the variable - declaring the indicated variable special in compiler and runtime - assigning the variable (either conditionally, as in DEFVAR, which assigns only in the case that the variable is unbound, or unconditionally, as in DEFPARAMETER). " K. Pitman, comp.lang.lisp, 26. April 2001. What "recording the definitional home" means? Why "in some implementations?"

9 12

[pro] Common Lisp replacement for noweb
by William Halliburton 28 Mar '11

28 Mar '11

---------- Forwarded message ---------- From: daly <daly(a)axiom-developer.org> Date: Mon, Mar 28, 2011 at 12:18 PM Subject: Common Lisp replacement for noweb To: thomas.m.hermann(a)odonata-research.com, pro(a)common-lisp.net I have moved from using noweb to a pure Common Lisp version of literate programming. (The source is also at: http://literatesoftware.com/tangle.lisp ) The noweb program uses two functions, weave -- takes a file and extracts latex tangle - takes a file and extracts running code The noweb syntax is: <<thechunk>>= your source code @ where your code is defined in the block delimited by the <<...>>= and the @ symbol. To use the delimited chunk somewhere you write the name of the chunk as: <<thechunk>> It would be better to use a valid latex environment. That would mean that there is no need for a "weave" function since the original file is valid latex. \begin{chunk}{thechunk} your code here \end{chunk} \getchunk{thechunk} All that would be left is to make Common Lisp understand the latex environment syntax which is trivial to do. So I wrote a tangle.lisp program. It accepts and processes both the old noweb syntax and the new latex syntax. The idea is simple. Read the file, hash the chunks, and expand them when a getchunk is found. The code is attached. Send questions to daly(a)literatesoftware.com Tim Daly daly(a)axiom-developer.org daly(a)literatesoftware.com

1 0

[pro] Matrix operations...
by Pascal Costanza 28 Mar '11

28 Mar '11

Hi, I am looking for a Common Lisp library that provides some essential mathematical matrix/vector operations. There seem to be a couple of offerings, but it seems hard to determine in what kind of state they are (without essentially trying them all one by one). If anybody could share his/her experience, I would be very grateful. Some (soft) requirements: - It should be implemented in "pure" Common Lisp. Preferably no wrappers for libraries implemented in other languages. - Preferably sequential, but parallel implementations may also be fine. - Focus on performance (incl. low-level type declarations, for example). - Preferred platform is LispWorks, but other Common Lisp implementations are also fine. Portability is not a high priority. Thanks a lot in advance, Pascal -- Pascal Costanza, ExaScience Lab, Intel Belgium

3 5

[pro] Bottom-up, top-down or both ?
by Didier Verna 11 Mar '11

11 Mar '11

It is well known that a functional approach to programming helps thinking in a top-down fashion. Idioms made available by first-class functions (e.g. mapping and folding) help you write down the general ideas first, and worry about the details later. Paul Graham has nice examples of that in On Lisp IIRC. In fact, it seems that being able to think in a top-down fashion is not specifically tied to functional programming, but perhaps more generally to the level of expressiveness that your language provides. For example, I find that the very existence of a REPL helps a lot: you can test a function on manually-provided data, that would normally be constructed by a lower-level, yet-to-be-written function. You can pre-define stuff to do nothing but print "I'm here", just to check if the bigger thing works. In Lisp, with half-defined generic functions, you can even have your program half-working, some details remaining to be sorted out later. So obviously, Lisp being as expressive as it is, is of great help in thinking top-down. Even in Lisp, however, some things need to be defined before they can be used. So I recently discovered, to my greatest astonishment, that even if my thought process is top-down 99% of the time, my /code/ is *always* written down in a bottom-up fashion. Occasionally, I might have one of those quasi-hysterical crisis in which I would spend hours re-organizing my code until the I get the overall expression of the program as close as possible to the ultimate upside-down pyramid of dependencies. And then, we I need to immerse myself again into something I wrote a long time ago, I usually read my files backwards... or not! So I was wondering, how's your code organized? How's your thought process organized? Top-down? Bottom-up? Both? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 2

[pro] slime help
by Alexandre Rademaker 11 Mar '11

11 Mar '11

Hello, Sorry if this list is not the best place to ask this question... Maybe we should create a newbie lisp list! What is the easy way to copy/paste a form from a source code buffer to slime prompt? Is there any keyboard shortcut emacs/slime-mode to copy the whole body of a form from anywhere within it?? Cheers, Alexandre Rademaker http://web.me.com/arademaker/

3 2