- pro - mailman3.common-lisp.net

[pro] substitution macro lisp extension?
by Mark H. David 22 Sep '10

22 Sep '10

Is there any well-known implementation of a macro similar to old Lisp Machine's defsubst, but not as fancy, one that simply emits a macro after doing a reasonable, if less than perfect, attempt to do substitutions and guarantee first-to-last arg once-and-once-only evaluation? I realize that most people just use declare inline for this kind of thing. Or define a macro like defsubst just to emit a defun with a declare-inline declaration. I would like something that's different: something that always emits a macro def given a function-like semantics for args and body. It's a pretty simple thing, but I was wondering if it's sitting around in a library somewhere. What's out there? Thanks, Mark

7 8

Re: [pro] The Best Examples of "Code is Data"
by Daniel Weinreb 09 Sep '10

09 Sep '10

Scott L. Burson wrote: > On Thu, Sep 9, 2010 at 8:26 AM, Daniel Weinreb <dlw(a)itasoftware.com> wrote: > >> One of the very first things you want when >> you start writing macros is for auto-indentation >> to do the right thing. The IDE can't just >> know this for a macro. >> > > Huh. I always thought Zmacs did an adequate job of this. Just know > what &BODY means and give me COM-INDENT-DIFFERENTLY for special cases, > and I'm pretty happy. > Yes, Zmacs knew about &rest, as does our stuff at ITA. That automatically notes that the symbol name is of the form (a b c ... . rest), usually just (a .rest). > (Dan will of course know what I'm referring to, but for everyone else, > the Zmacs command COM-INDENT-DIFFERENTLY -- bound to C-Tab, if memory > serves -- could be used to manually cycle through a series of > alternate indentation points for the current line. Oh, I forgot about that one! I probably didn't write it. There are a few gems in the Symbolics code that would be nice to extract. > I'm not aware of > an equivalent command having been implemented for GNU Emacs.) > > -- Scott >

1 0

[pro] [LibCL-devel] A brave new world
by Daniel Herring 07 Sep '10

07 Sep '10

[Most discussion should take place on the libcl-devel list.] Hi all, It has been several months since LibCL saw significant progress. This was a period of small experiments, reflection, and numerous "real-world" distractions. This past week, I had a bit of free time; and recent rumors of quicklisp focused the need to sieze the moment and put thoughts into action. [Thanks Zach. Honestly, with everything in my head, I couldn't have handled volunteers anyway.] Here's the result: a revised plan for LibCL, and a skeleton code base ready for contributors. http://libcl.com/ [main website, as yet unchanged] http://gitorious.org/libcl/world [new git repo] * User experience The user experience will see relatively few changes; just more stuff will be available. ASDF 1 to ASDF 2 is the biggest configuration change. * Developer experience This is much improved. No more tediously maintaining two git repos for each package. No more harrowing forced conversions of upstream sources into git. No more massive packages.lisp with a metadata defstruct. Now, each package is defined by a simple package.lisp file. This contains a single plist of information. Many of the keys are inherited from the old packages.lisp file; others are defined in the new metadata.txt. Key new metadata types are :maintainers, :tags, :todo, and :source. Now a single file describes everything needed to obtain and describe a (nearly) arbitrary upstream package. Helper scripts standardize the process. A simple framework structures the steps needed for building a release. It also applies local patches until they can be merged upstream. Names aren't finalized, but see workflow.txt. The html index will have a mark denoting local patches, except for patches following a naming convention indicating "trivial" operations like renaming directories and building documentation. * Expanded vision History: LibCL began after yet-another-computer/OS-upgrade cycle left me spending months reconstructing my libraries. The current systems just didn't work for me. I started with a bunch of things; but realized that many packages needed to be dropped because they were hard to support (most notably, anything using FFI). Then I moved towards the idea of creating a "core standard library", with a team of developers, etc. That never gelled. People were asking for more; I even found myself needing one-off, non-portable documentation tools to build the docs for LibCL... LibCL now aims to be a 1-stop shop. If a library isn't in LibCL, please send a metadata file to this mailing list, with a subject line like "[metadata] awesome-package.lisp". Or use a merge request on the gitorious repository. Same thing goes for applications. If/when the downloads start bloating, we can offer variants as needed. How are non-portable tools handled? Through tags. Only portable, pure CL libraries may be tagged with :pure. Only :pure libraries seeing widespread use may be tagged with :core. The default invocation of compile-libcl will only compile :core libraries. Calling compile-libcl with other tags allow people to compile things specific to their interests. Selecting a package by name will compile it and all its dependencies. Selecting T will compile everything. * Upcoming feature PJB and others had a great idea. After "(compile-libcl t)", walk the packages and generate a master index of all available symbols. Link this index to docstrings, and eventually add links to the full documentation. Good for searching. This will be included in the next LibCL release. ------------- Call for help The current libcl-world is a rough skeleton; but key pieces are already in place. Any help would be appreciated; please coordinate on the libcl-devel list; here are some suggested places to start. Easy tasks: - add metadata for new packages - create/add tags to packages - add maintainer information to packages Harder tasks: - coordinate metadata and/or the tarball cache with quicklisp? - fix package :todos, and add more as needed - update configure-libcl for ASDF 2 - website stuff - create a cache system for package tarballs and log files - create a comment/voting system for packages - sort through the old upstream/local repos for patches which never made it upstream - design a "fetch on demand" layer a la quicklisp or MiKTeX - hook "fetch on demand" into ASDF - design a system for caching .so and .dll files for FFI bindings Most changes may be handled through git merge requests. Metadata changes may be sent to libcl-devel with a subject like "[metadata] package.lisp". Contact me directly if you need a shell account for web changes (the current website should be available on gitorious). Thanks for reading this far. This will be a busy week personally, and I should be offline during September 12-14; but feel free to make progress without me. Let's see where this thing goes. Later, Daniel

2 1

[pro] Introducing the list
by Hans Hübner 03 Sep '10

03 Sep '10

Hi folks, this list has been created in response to an email by Dan Weinreb, addressed to a bunch of Common Lisp programmers that he knows, who wondered where to turn to for some advice on the existence of certain Common Lisp libraries. comp.lang.lisp was deemed not to be the right place, because it is full of spam and requires sophisticated special-purpose software and regular care taking to be readable. Thus, we came up with the idea of a mailing list targeted at people who already know and use Common Lisp and who don't want to discuss the merits of it or how other languages are worse or better. This is an implementation-agnostic list. Discussing any Common Lisp implementation is on-topic, although implementation specific questions are probably better discussed on the respective mailing lists. We generally also know why we chose one implementation over another, so "my implementation/your implementation"-type discussions should not be started unless they are technical (as opposed to license-oriented). Be inclusive and friendly, accept commercial and non-commercial developers. Let's not use the word "free" here, unless it is about beer. :) -Hans

1 0

[pro] Greetings
by Peter Seibel 03 Sep '10

03 Sep '10

Greetings fellow Lisp pros. Heh, this list should have been called "pros" and then when someone starts a list for beginners (i.e. one to help grow the list of Lisp programmers) it could have been called "cons". ;-) -Peter -- Peter Seibel http://www.codequarterly.com/

2 1

Re: [pro] How to get useful Lisp info?
by Hans Hübner 03 Sep '10

03 Sep '10

Daniel, On Fri, Sep 3, 2010 at 16:18, <dherring(a)tentpost.com> wrote: > If pro(a)cl.net will be an implementation-agnostic place for serious CL > users, it needs an accompanying place for new user questions. Is that > place lispforum.com? a new mailing list? I'm a bit sceptical regarding a new mailing list for CL beginners. For one, it would further support fragmentation. For another, starting the two lists at the same time will likely lead to confusion (where do I post this?). I think we should start get pro@ going and then maybe consider adding a new list for beginners. -Hans

2 1

Re: [pro] How to get useful Lisp info?
by Hans Hübner 03 Sep '10

03 Sep '10

On Fri, Sep 3, 2010 at 11:11, Juan Jose Garcia-Ripoll <juanjose.garciaripoll(a)googlemail.com> wrote: > One thing which is very useful for those who love fori or searching the web > would be to ensure the list archives are public and perhaps subscribe gmane. > At the ECL mailing list we have a gmane subscription > (http://news.gmane.org/gmane.lisp.ecl.general) which works fine for those > who do not want to subscribe but still are interested in the topics which > are discussed -- and I believe the pro@ mailing list would be way more > interesting than ECL's :-) Thanks for the suggestion. I have sent a subscription request for the list as gmane.lisp.pro to the Gmane administrators. -Hans

1 0