- pro - mailman3.common-lisp.net

[pro] User defined format functions
by Didier Verna 25 Jan '11

25 Jan '11

Hello, there are situations in which I find myself frequently using the same format "pattern", which I'd like to abstract away. A concrete example is from my Declt package[1] which prints a lot in Texinfo format. Since Texinfo has a couple of special characters (e.g. @), I have an ESCAPE function which takes a string and returns another one with all special characters escaped. In the Declt code, I hence have very frequent calls which look like this: (format stream "... ~A ..." #|...|# (escape str) #|...|#) This is frustrating because I would like to abstract away the relation "~A <-> #'escape". Of course there are solutions (I could provide my own wrapper around FORMAT in some way) but none of them seem satisfactory. I'm aware of the ~// construct, which I find extremely cumbersome. Does anybody actually use it? It seems to me that the package handling part, specifically, makes it totally unusable. Just imagine that I would need to do something like that if I were to use it: (format stream "... ~/com.dvlsoft.declt:escape/ ..." #|...|# str #|...|#) and you get the idea! :-) No, in fact, the problem is that FORMAT control sequences are not extensible. This reminds me of something that we have in the Gnus mail/newsreader. It's called "user format functions". Gnus Group and Summary buffer lines, for example, are define by a format string with a set of predefined %<char> constructs. One of them, %u<char> lets you define and use your own function, called gnus-user-format-function-<char>. So what I would like to do is more or less define a function FORMAT-FUNCTION-E, just like a standard formatter, and then be able to write something like that: (format stream "... ~\e\ ..." #|...|# str #|...|#) Of course, there are package issues. Maybe we would need a centralized mapping between function names (what goes in ~\\) and actual symbols denoting the actual function? Possibly with the possibility to override the mapping by providing a package prefix in the ~\\ construct? In fact, the more I think about it, the more it sounds like having a format-table facility, much like what a readtable is, with a similar API. You could do (in-format-table :my-table-name) at the beginning of a file and have a totally customized set of format control sequences, possibly inheriting the standard ones. WDYT? Does something like that already exists[2]? Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt [2] I've heard of something called fmt for scheme, but don't know much about it. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 3

[pro] A little success story...
by Pascal Costanza 24 Jan '11

24 Jan '11

Hi, I just wanted to report on a little success story. In the recent few months, I have been working on a new project that concerns itself with parallel programming. For that purpose, I experimented with variations of a home-grown work-stealing scheduler. (See http://en.wikipedia.org/wiki/Cilk#Work-stealing for a description of what work stealing is.) The development platform is LispWorks 6.0, which comes with an excellent library for SMP. (I would say it's the best of any dynamic language I am currently aware of, not just those of Lisp dialects.) Performance matters in parallel programming. The benchmark application was a structured grid computation, like is for example used for computing heat equations, for running game of life, or for similar applications. This is easy to parallelize, because each processor can perform part of the computation on a sub-grid independently of all the other processors. The hardware that I ran the experiments on is a 4x 6-core Intel Xeon "Dunnington" 2.67 GHz running Ubuntu. For 200 iterations on a 4096x4096 matrix of single float values, I got the following runtimes: - with 8 cores ca. 19-20 secs. - with 16 cores ca. 9-10 secs. - with 24 cores ca. 8 secs. The same experiment was also implemented by others in our group in the following languages: Unified Parallel C, Cilk++, C with MPI, OpenMP, and C++ with Threading Building Blocks. They all have slight variations in runtime, but all roughly in the same ballpark. The runtimes were: - with 8 cores ca. 10-11 secs. - with 16 cores ca. 8-10 secs. - with 24 cores ca. 8-10 secs. The advantage of using Common Lisp is that I could still use higher-order constructs (closures) and have a pretty decent separation of concerns in the software architecture, while still getting very good efficiency. Of course, this required some pretty low-level tricks with type and optimization declarations in several places, but the nice thing about Common Lisp is that you don't have to be low-level right from the start, and only at the places that you identify as bottlenecks. Unfortunately, I cannot present a lot more details at this stage, because most of this is covered by an NDA. I hope, though, that I can make the work-stealing scheduler available as an open source library at some later stage. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

3 5

Re: [pro] Learning Lisp the Bump Free Way
by raito＠raito.com 21 Jan '11

21 Jan '11

Quoting Vladimir Sedach <vsedach(a)gmail.com>: > 2. There are no libraries to do <X>/I can't find any libraries. It may sound shocking, but there's non-programmers out there who complain if there isn't a free-as-in-beer application to do what they want. This argument is the programmer corollary. It always appears to me as though the real argument is "No one else has already done my work for me." But then, when I first learned C, we got stdio and stdlib, and nothing else, really, so my view may be skewed. I do find discussions that pit the syntaxes of Lisp vs. other languages very amusing, and not for the reason most Lisp users might. Yes, many new languages have long drawn out discussions about how their syntax should change, while Lisp has had the same syntax for a very long time. But here's where libraries come in... It seems like an awful lot of Lisp libraries exist to wank about with the language than libraries in other languages, rather than to actually do the sort of tasks that programmers look to do. This may make it look like Lisp is defective. After all, if you need a bunch of libraries to 'correct' the language, it can't be any good, right? And because there seems to be several libraries to 'correct' the same problem in different ways, it's pretty obvious that the 'community' can't even agree on how to do it. In some people's minds, this is a problem. (And yes, I know that it's a rather superficial view, but from someone casually considering Lisp, a superficial view is all you're going to get). Neil Gilmore raito(a)raito.com

10 13

[pro] Learning Lisp the Bump Free Way
by Daniel Weinreb 21 Jan '11

21 Jan '11

This is a very nice essay to help people get over their initial problems with Lisp: http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way I also just came across an online book called "Successful Lisp", by David B. Lamkins (maybe many of you already know about this): http://psg.com/~dlamkins/sl/ It's also available from Amazon, in trade paperback (300 pages). http://www.amazon.com/Successful-Lisp-How-Understand-Common/dp/3937526005/r… I'm not sure whether we need any more Lisp textbooks now that we have Practical Common Lisp, but it's somehow just nice to know that there are more books about Lisp that managed to get published; at least in the sense that Amazon has it (the web site of the publisher seems to have expired). -- Dan

16 22

[pro] simple-style-warning
by Vladimir Sedach 21 Jan '11

21 Jan '11

Is there a portable way to create a simple-style-warning condition that when signaled with WARN won't cause SLIME to claim that file compilation failed, that works for all/most CL implementations? I'm trying to use this: (define-condition simple-style-warning (style-warning simple-warning) ()) (found in one of KMP's usenet posts: http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c55278c8…) but it works inconsistently in SBCL and CCL. Thank you, Vladimir

3 2

Re: [pro] Learning Lisp the Bump Free Way
by Vladimir Sedach 21 Jan '11

21 Jan '11

I really didn't appreciate this whole discussion, but I think I can contribute a few points about how to think about the problem so that things like this will stop happening. There are two assertions being made here: * "Lisp is falling behind" * "To stop Lisp falling behind, we need to do <X>" No one has provided any quantitative evidence for either. How is Lisp "falling behind?" Compared to what? And what effect does that have? What effect does that have on you personally? Why do you think doing <X> will be good? Did anyone ask for <X>? Is it actually preventing people from doing things? How can you tell <X> will work when you can't even quantify the "falling behind" thing <X> is supposed to change? What is the basic pattern behind this argument? Alexander, I will use your original post as an example, please don't take it personally: "Lisp is dying: some JavaScript implementation is slower than Clozure; let's work on the Clozure IDE!" Where is the logic here? Most of these arguments use "Lisp is dying" handwaving to promote a personal project, and in most of these cases no one outside the current Lisp community cares about the issue. What does it mean to say "Lisp is falling behind?" There aren't enough people using it? Have you tried listening to people who have tried and failed to use Lisp? Do you understand the difference between a reason and a rationalization? There are people who rationalize not using Lisp by saying it has parentheses, and there are people who have a reason for not using Lisp because they can't find the libraries they need. Listening to the former is a waste of time, listening to the latter will give you a way to actionably decrease the "Lisp falling behind" and measure it. Here are some things I notice people actually saying: 1. The #1 problem is that people (and this includes even people who have been using Lisp for decades and post to this list, not going to name names :)) have misconceptions about what current Lisp implementations, libraries and tools can do. And this is just the people that know about the existence of Lisp. Simply letting people know about Lisp and how great it is is the most direct way you can get more people to use it. 2. There are no libraries to do <X>/I can't find any libraries. Improve and promote the existing libraries. Write new ones for some service/software/function that isn't possible from Lisp yet. Put a description of your library on CLiki, ask Zach to add it to Quicklisp. Help improve the existing library listings in CLiki. Help with Quicklisp, add metadata and search stuff to Quicklisp projects (https://github.com/quicklisp/quicklisp-projects) Give Zach money. Basically anything that makes Quicklisp better is good. 3. How do I deploy applications? Web apps (the story here is incredibly bad - http://stackoverflow.com/questions/2458805/nohup-sbcl-ubuntu-couldnt-read-f… Work on cl-launch, lispx-proxy, cl-daemonize This is today's list, it will change tomorrow. The important thing is to understand what's really going on, and the psychology behind it. Which is why the last thing I'm going to say is that saying "Lisp is dying" is destructive. If Lisp experts are saying our community is a loser, why would anyone want anything to do with Lisp? Stop doing it. ------ Now I'm going to reply to Dan. I think ITA's attitude of "I wish we didn't write qpx in Lisp but it's the only thing good enough" is bizarre. That no one was assigned even part time to be a "Lisp evangelist" was a *strategic* mistake. It would have saved ITA hundreds of thousands in recruitment costs, and improved productivity through an improved Free Software Lisp ecosystem. Another thing is the "I won't be allowed to use Common Lisp" attitude. This is the perfect opportunity to force Common Lisp into Google, and you're walking in expecting to fail. Vladimir

1 0

Re: [pro] Learning Lisp the Bump Free Way
by Alexander Repenning 20 Jan '11

20 Jan '11

Hi Drew, perhaps the point of a mailing list for professional lisp developers is to act, well ... professional? Remember one of the points made in original article about the Lisp community: "The community isn’t nearly as blood thirsty as some people might portrait it." Seems to me you just confirmed what many people appear to worry about. Well done. Alex On Jan 20, 2011, at 10:57 AM, Drew Crampsie wrote: > On 20 January 2011 08:04, Alexander Repenning <ralex(a)cs.colorado.edu> wrote: > >> Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. > > I participated in the creation of this mailing list in part to get > away from trolling like this on the other lisp forums. Is there no > place on the interwebs safe from such bullshit? > >> The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). > > And i'm not convinced a mailing list for professional lisp developers > needs more diatribes explaining how _we_ should 'fix' Common Lisp to > make it 'cool' again. > > Can we leave this sort of drivel on comp.lang.lisp where i have > plonk-ability, and keep this mailing list for "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"? > > Cheers, > > drewc > > > > > > On 20 January 2011 08:04, Alexander Repenning <ralex(a)cs.colorado.edu> wrote: >> One point made: >> >>> It’s probably faster than most dynamic languages. >> >> is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary. >> >> Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum. >> >> The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again" >> >> best, Alex >> >> >> >> >> On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote: >> >>> This is a very nice essay to help people get over their >>> initial problems with Lisp: >>> >>> http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> >> >> _______________________________________________ >> pro mailing list >> pro(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/pro >> Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

7 9

[pro] Style issue about predicates
by Daniel Weinreb 16 Jan '11

16 Jan '11

If you have a function that is a predicate, in the sense that the function's contract says that its value should be interpreted as being either false or true, do you think it's better to code it so that it always returns "t" for the true case? Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t. Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know. All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like: (defun ... ... (when (fn1 arg2 arg2) t)) It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate. Is this good, bad, don't care, depends on the circumstance? -- Dan

9 8

Re: [pro] Style issue about predicates
by Bob Kerns 15 Jan '11

15 Jan '11

Agreed. As I indicated later, throwing away useful information wasn't my intent -- having a tight, well-defined contract was. T serves that purpose, but other values may also serve it and add utility at the same time. The WORST case, in my mind, is to return something useful, but leave the contract as "non-null". This encourages programmers, who may or may not have observed the contract wording, to experimentally observe the actual behavior, and depend on it. It's probably even more likely in Lisp than in most languages, because it's so easy to type a test case into a read-eval-print loop. I am not generally dogmatic that all aspects of all behavior need to be tightly specified. For example, there can be substantial performance benefits to leaving traversal/iteration orders unspecified, or there can be substantial benefit from implementation freedom, or it can be completely impractical to write a full specification. But return values, especially boolean return values, are well worth consistently specifying tightly. And I think there's little danger of a religion arising based on it -- and it'd be a relatively harmless one even so. ----------- Date: Sat, 15 Jan 2011 15:23:48 +0100 From: "Svante Carl v. Erichsen" <Svante.v.Erichsen(a)web.de> Subject: Re: [pro] Style issue about predicates Hi! I would not like such a rule in a style guide, for fear of religious followers. My view is: yes, tighten the contract, but no, it needs not (but may) specify exactly t. If something useful can be returned, why throw it away?

1 0

Re: [pro] Style issue about predicates
by Bob Kerns 15 Jan '11

15 Jan '11

Just to clarify my earlier stance: I agree -- if there's something well-defined and more useful than T to return, return that. It's the 'null/non-null' contracts that are problematic. The extra wiggle-room here offers no utility at all. It does allow for one branch of an implementation to avoid a constant load, or in some cases a test/branch and load. In this day and age, I do not find small constant bits of CPU compelling, in contrast to matters that affect reliability of large-scale software, when coded by real-world teams of programmers. ---------------- Date: Fri, 14 Jan 2011 17:59:52 +0100 From: Edi Weitz <edi(a)weitz.de> Subject: Re: [pro] Style issue about predicates There are lots of functions in the standard which are predicates in that they return generalized booleans but on the other hand return something "useful" if the result is not NIL, e.g. MEMBER or STRING<. I think this is good practice, i.e. return something other than T in case this might make more sense. Of course, this should then be documented in the predicate's contract and thus should be OK to use by the caller.

1 0