Abstractions
in [Lisp]
|
From: RG on 12 Aug 2010 13:33 In article <8ci3lqFo28U1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 12/08/2010 03:19, RG wrote: > > In article > > <f1786719-65bc-44c4-bc2f-ba2105e89df8(a)f6g2000yqa.googlegroups.com>, > > Alessio Stalla<alessiostalla(a)gmail.com> wrote: > > > >> On 11 Ago, 23:05, RG<rNOSPA...(a)flownet.com> wrote: > >>> In article<877hjwandt....(a)kuiper.lan.informatimago.com>, > >>> p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > >>> > >>>> RG<rNOSPA...(a)flownet.com> writes: > >>> > >>>>>> I would be interested in > >>>>>> trying it, especially if it comes under a reasonably liberal license > >>>>>> like BSD or LLGPL. > >>> > >>>>> I released it to the public domain last year. > >>> > >>>> Which means that you remains the only one entitled with the right to > >>>> make a copy of it, and your heirs until 70 years after your death. > >>> > >>> I don't know where you got that idea, but you are absolutely wrong. > >>> Releasing the work to the public domain means I have forfeited all my > >>> intellectual property rights and anyone can do anything they want with > >>> it, including use it in commercial software without any constraints > >>> whatsoever. > >>> > >>> http://en.wikipedia.org/wiki/Public_domain > >>> > >>>> Could you please try the GPL? > >>> > >>> Actually, I can't. The GPL requires that the work be copyrighted. Once > >>> a work enters the public domain then by definition it is no longer (and > >>> can no longer be) copyrighted. > >> > >> AFAIK, not all legislations have the concept of public domain. > > > > I am quite certain you are quite mistaken. > > > >> In some countries, you cannot give up your copyright on your work. > > > > Which countries are those exactly? What country do you live in? > > In Germany, you cannot give up your copyright. So if I have a copyrighted work I can't sell the copyright to someone else? Thank God I don't live in Germany. > (It actually makes a > finer distinction between creator's rights and copyright, and you cannot > give up creator's rights - simply because you _are_ the creator of your > work, giving that fact up would be like denying reality... ;) Well, now, you've just contradicted yourself. Is it my copyright I can't give up, or merely my "creator's rights" (whatever those might be)? What are "creator's rights" anyway? I've never heard of such a concept before. Under what circumstances do they apply? I am a U.S. citizen living in the U.S. Do I have "creator's rights" under German law? Will the German government prosecute you on my behalf for violating my creator's rights by making a copy of rg-utils.lisp despite the fact that I have expressly given you (along with everyone else on the planet) permission to do so? Feel free to treat all those as rhetorical questions. rg
From: RG on 12 Aug 2010 14:09 In article <87r5i4jacm.fsf(a)ma-patru.mathematik.uni-karlsruhe.de>, Nicolas Neuss <lastname(a)kit.edu> wrote: > RG <rNOSPAMon(a)flownet.com> writes: > > > The real heart of the system is the ITERATOR generic function, which > > returns a closure that yields successive values of the iteration on > > each call, and terminates by returning the privileged value +iterend+. > > (It is not clear that this is really the Right Thing. The Right Thing > > is probably to call THROW or raise a condition. The current > > implementation should be considered more of a proof-of-concept than a > > final design.) > > OK, I've looked at your code now. At some time I have thought myself > about basing my interface on iterators, but somehow I did not come up > with anything good. Probably it is time to reevaluate this again more > carefully. > > IIUC, the iterator approach is more basic than the generic "FOR-EACH", Not sure what you mean by "the generic FOR-EACH". Can you be more specific? > especially with the advantage that one can easily expand into a > LOOP-like construct (and a FOR-EACH can be easily constructed). The > question is if one loses something using iterators instead of a generic > FOR-EACH. I can think of two points here. > > 1. The interface is somewhat more complicated. For example, you need to > access +ITEREND+ for defining ITERATOR for some collection, see below. Yes, +ITEREND+ is a Horrible Hack. At the very least the API should be changed to (iterend) instead of +ITEREND+ to make it easier to change the actual underlying implementation. > 2. In theory, performance should be more or less the same, because both > call one closure for each iteration step. In practice, however, the > iterator approach might be slower because of the passing of > multiple-values. The quality metric I used for my design was primarily to reduce the cognitive load on the user (i.e. the user of the FOR construct, not so much the writer of iterators), both for initial coding and also for maintenance. Efficiency was a secondary consideration. Being CPU-bound is pretty rare nowadays. rg
From: RG on 12 Aug 2010 14:16 In article <9mp4of0ezey.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) wrote: > Nicolas Neuss <lastname(a)kit.edu> writes: > > > The > > question is if one loses something using iterators instead of a generic > > FOR-EACH. I can think of two points here. > > > > 1. The interface is somewhat more complicated. For example, you need to > > access +ITEREND+ for defining ITERATOR for some collection, see below. > > > > 2. In theory, performance should be more or less the same, because both > > call one closure for each iteration step. In practice, however, the > > iterator approach might be slower because of the passing of > > multiple-values. > > I think this paper has some valid points: > > http://www.pipeline.com/~hbaker1/Iterator.html It should be noted that many (though not all) of the criticisms Baker levels are specific to C++ iterators, and do not apply to rg-iterators. Furthermore, because rg-iterators are really just a thin layer on top of LOOP, any of Baker's criticisms which do apply to rg-iterators will also apply to LOOP. Finally, if you constrain yourself to certain LOOP constructs (like COLLECT) then iterators become purely functional, which obviates nearly all of Baker's objections to them. Besides, Baker is a functional programming weenie. What does he know? ;-) rg
From: Nicolas Neuss on 12 Aug 2010 15:19 bjorn(a)runa.se (Bj�rn Lindberg) writes: > Nicolas Neuss <lastname(a)kit.edu> writes: > > I think this paper has some valid points: > > http://www.pipeline.com/~hbaker1/Iterator.html Yes, thank you. The most practically relevant objection against iterators might be that it is not clear how to parallelize code with the iterator concept (while it is really easy with constructs like FOR-EACH or MAP/REDUCE). What I find impressive, but rather gross, is Baker's proposed generator alternative to iterators. For my above example, it translates into something like --8<---------------cut here---------------start------------->8--- (defun eof (c) (funcall c nil t nil)) (defmethod gen ((vec vector) consumer genrest) (labels ((myloop (i consumer) (if (= i (length vec)) (funcall genrest consumer) (funcall consumer (aref vec i) nil #'(lambda (consumer) (myloop (1+ i) consumer)))))) (myloop 0 consumer))) (let* ((n 10000000) (test-vec (make-array n :element-type 'double-float :initial-element 1.0d0))) (time (let ((sum 0.0d0)) (labels ((myloop (xg) (funcall xg #'(lambda (x eofx xg) (unless eofx (incf sum x) (myloop xg)))))) (myloop #'(lambda (c) (gen test-vec c #'eof)))) sum))) --8<---------------cut here---------------end--------------->8--- As Baker says one probably can get used to such code, but I'm not sure if that would be any good for my mental health. And the performance seems to be even worse than for the other two approaches. Nicolas
From: Nicolas Neuss on 12 Aug 2010 15:23
RG <rNOSPAMon(a)flownet.com> writes: > In article <87r5i4jacm.fsf(a)ma-patru.mathematik.uni-karlsruhe.de>, > Nicolas Neuss <lastname(a)kit.edu> wrote: > >> RG <rNOSPAMon(a)flownet.com> writes: >> >> > The real heart of the system is the ITERATOR generic function, which >> > returns a closure that yields successive values of the iteration on >> > each call, and terminates by returning the privileged value +iterend+. >> > (It is not clear that this is really the Right Thing. The Right Thing >> > is probably to call THROW or raise a condition. The current >> > implementation should be considered more of a proof-of-concept than a >> > final design.) >> >> OK, I've looked at your code now. At some time I have thought myself >> about basing my interface on iterators, but somehow I did not come up >> with anything good. Probably it is time to reevaluate this again more >> carefully. >> >> IIUC, the iterator approach is more basic than the generic "FOR-EACH", > > Not sure what you mean by "the generic FOR-EACH". Can you be more > specific? (defmethod for-each (func (vec vector)) (dotimes (i (length vec)) (funcall func (aref vec i) i))) You can easily define this for other collections and base other functionality on it like MAP, REDUCE, etc. Also a parallel version splitting the work to several threads is straightforward. Nicolas |