Abstractions
in [Lisp]
|
From: George Neuner on 12 Aug 2010 00:24 On Wed, 11 Aug 2010 18:19:37 -0700, RG <rNOSPAMon(a)flownet.com> 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? > >> So in >> general, if you really want your work to be accessible to anyone, the >> best option is to use a liberal open source license (such as MIT or >> BSD). > >OK, fine. I'll get right on that. > >rg === I am not a lawyer === In countries operating under WIPO (184 now) technically you never can surrender or transfer an *implicit* copyright - that's the one granted by fact of authorship. In theory, implicit copyright is passed to the estate and can persist as long as descendants claim it - but implicit copyrights are worthless in practice. Explicit copyrights (marked with a copyright notice) and registered copyrights (explicit AND filed with the government copyright office) can be transferred in whole or individual rights transferred or conferred via contract. This is how the various open-source licenses operate: the author retains "authorship" but confers some derivative and distributions rights via the licence agreement. However, by deliberately placing an explicit or registered work in public domain, the copyright holder explicitly confers to the public derivation and distributions rights to the work. Enforcement varies quite a bit - particularly with respect to open source software. AFAIK, most WIPO countries do recognize public domain but not all of them routinely recognize other OSS ... and some of them get downright nasty if they catch people with unsanctioned non-PD software. === I am not a lawyer === George
From: Scott L. Burson on 12 Aug 2010 02:45 Alessio Stalla wrote: > What I'm dubious about is how often someone thinks "I > really need FSet to solve this problem!". I suspect that doesn't > happen often and that it would happen more often if FSet was part of > some "batteries included" library for CL and if it integrated well > with sequences. It's in LibCL! :) :) Alas, it's not clear LibCL itself is seeing much use. That's too bad -- Daniel has done a lot of work on it and I think he's done a good job. If there's another "batteries included" library you think FSet should be in, let me know. (It's also ASDF-Installable, or should be -- I haven't tested that in some time.) >> The other philosophical divergence between the CL approach and the FSet >> approach is that the FSet collections are semantics-heavy: a collection >> knows what kind of thing it is, what operations are applicable to it, >> and what equivalence relation it should use for its elements. By >> contrast, a CL list can be used in many different ways -- as a set, a >> sequence, a bag, an alist, a plist, etc.; the semantics are not supplied >> by the data structure, but rather by the operations that are used on it >> and the arguments (such as :TEST) that are supplied to those operations. >> >> I suppose this second divergence is less difficult to overcome; one >> simply says that if you're calling UNION on two FSet sets, it's an error >> to supply a :TEST argument. Indeed, FSet signals an error in that case. > > Why must it be an error? I'd prefer to have it work with an > arbitrary :test, albeit more slowly, presumably - or isn't it > possible? It doesn't make any sense. Each set which is passed to UNION already has its own idea of what equivalence relation it uses. If you now try to treat it as a set with a coarser equivalence relation, in general it will now contain duplicate elements, which means it's not really a set anymore. I suppose one could define this to mean, convert both sets to use the new equivalence relation (possibly thus making them smaller), and then union them. But once you get used to the way FSet is designed, I think you will agree this is pointless, because it would be vanishingly rare to need it, and therefore it would be too obscure a behavior to have built in. If you actually ever come across a case where you want to do this, it would be better, I think, to write the conversions explicitly so the reader of the code knows what you really mean. > I don't quite get the point for semantics-heavy collections in > general, as a design principle. I understand that some collections > have to be semantics-heavy - for example hash-based data structures > inherently depend on a given hashing function and a given equality > relation - but in general, what's the benefit of encoding in the > collection how it's going to be used and prematurely forbidding other > uses? I designed FSet to have semantics-heavy (maybe I should say "high-level") collections because I know, from using other languages, how convenient they are to use and how clear the resulting code is. When I tell you that you can't supply :TEST to UNION of two FSet sets, your reaction, naturally, is to think that something is being lost. What you don't yet know is what you get in return. Having the equivalence relation be implicit, rather than explicit in every operation, is actually a great convenience. In my experience, the vast majority of types have a single natural equivalence relation that is part of the definition of the type. If one finds oneself thinking in terms of two different equivalence relations for the same type, I would argue those are really two different types. FSet is a little odd at the moment because it doesn't even give you a way to specify a non-default ordering/equivalence relation when you create a collection. (When you create a type, you can specify the ordering for that type, which is then used for all collections containing the type.) I concede that collection-specific orderings would be a desirable feature, but I haven't bothered to implement it yet because I don't think it's very important. If you really want to enumerate the elements of a set in some specific order that's different from the default order, it's just not that hard to convert the set to a list and sort it. If you want to continuously maintain the set in some non-default order, you'll have to create a new type (at the very least, a one-member struct that wraps each element of the set) and tell FSet to use your desired ordering for that type. This would be a bit onerous, but I've never had to do it. >> (While you're at it, better integration of CL hash tables wouldn't be a >> bad thing. Granted, hash tables can't meaningfully be concatenated or >> even unioned(*), but at least ELT and (SETF ELT) could work on them. >> (*) Come to think of it, maybe there is a possible meaning for the union >> of two hash tables, if they're assumed to represent sets, i.e. only the >> keys are significant.) > > For hashes, and dictionaries in general, one would need another API. > ELT & friends are specified to work on objects of type SEQUENCE. In > any case, I wouldn't use ELT for accessing dictionaries. Why not??? A sequence is just a map whose domain is a subrange of the integers. A hash table is a different kind of map. There are languages where these two are accessed with identical syntax. (They're not all obscure languages, either; JavaScript is one.) FSet uses LOOKUP (or @) for both. Ron proposes using REF for both (see elsewhere in this thread). And the problem with GETHASH is that it uses the "wrong" argument order (at least, it's inconsistent with AREF and ELT, though consistent with ASSOC; my own preference is that the collection come before the index/key, and FSet uses this order consistently). >> As for what is the largest barrier to adoption of FSet, I don't really >> know but I would be surprised if it's an ease-of-use problem. It is a >> bit unfamiliar, I know, but I put a lot of effort into the design to >> make it as easy to use as I could, and wrote a tutorial besides. >> >> I think that the largest barrier is simply that people don't see the >> need for it; they're happy with what they have. There are lots of >> different kinds of programs and of programming in this world, and I >> freely admit FSet is not appropriate for all of them. I think it would >> be of some value for most kinds of programs, but perhaps it really >> becomes massively useful only for the kind of work I do: static analysis >> and automated reasoning. > > That may be true. However, a significant part of the hype around > Clojure is precisely about its functional collections. Ah yes, right -- when I wrote that I wasn't thinking about concurrency. I think concurrency is the key motivator for functional data structures (including collections) in Clojure. I think somebody started a CL-STM project, but I don't know whether it went anywhere. I haven't done much with concurrency myself. -- Scott
From: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 12 Aug 2010 05:39 RG <rNOSPAMon(a)flownet.com> writes: > In article <9mpaaouhhj4.fsf(a)runa.se>, bjorn(a)runa.se (Bj�rn Lindberg) > wrote: >> In the abstract(!) this is a good idea. The potential problem >> specifically with collections is the enforced least common denominator >> interface that will make a lot of important aspects of them unavailable >> through the generic interface. Especially those aspects that cause you >> to prefer one collection over another. > > You keep mentioning this LCD interface. Can you give an example of the > sort of functionality that you fear you would lose? I have given several examples already. >> As far as code reuse go, it is certainly interesting to be able to reuse >> implementations of algorithms and data structures. Reusing code just to >> get to have to conform to some particular interface, which may or may >> not be well suited to the application at hand, is less appealing. A >> generic collection library that actually implemented collections and >> operations upon them could be interesting for that reason. A library >> whose only purpose were to serve as an abstraction layer for the built >> in collections much less so. Such a layer is comparatively cheap to >> construct in the application itself, with the benefit that it can be >> adapted to the task at hand. >> >> > (I note in passing that it was in the dim and distant past not uncommon >> > to hear the same form of argument used to oppose high level languages in >> > general: developing and maintaining a HLL is expensive. The design of >> > the HLL must cater to some sort of least common denominator. Etc.) >> >> I disagree that these are the same. I would rather note that one common >> fallacy in computer science is the one of "false generalization", of >> considering things to be the same which are not. > > Like for example? This one. Or the idea that generic collection abstractions are "the same" as generic arithmetic. Bj�rn Lindberg
From: Alessio Stalla on 12 Aug 2010 06:21 On 12 Ago, 03:19, RG <rNOSPA...(a)flownet.com> wrote: > In article > <f1786719-65bc-44c4-bc2f-ba2105e89...(a)f6g2000yqa.googlegroups.com>, > Alessio Stalla <alessiosta...(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. Ok, probably I'm mistaken about that. However, I'm quite confident about the proposition below. > > In some countries, you cannot give up your copyright on your work. > > Which countries are those exactly? What country do you live in? I live in Italy. I'm not a lawyer; doing some research it's clear that public domain is automatically granted after copyright expires, but I found no source that claims that you can voluntarily place your work under the public domain. And since in Italy (but I guess in the whole Europe, more or less) any work is copyrighted by default, it's very unclear to me whether the fact that it's public domain in the US, say, has any relevance. > > So in > > general, if you really want your work to be accessible to anyone, the > > best option is to use a liberal open source license (such as MIT or > > BSD). > > OK, fine. I'll get right on that. > > rg
From: Zach Beane on 12 Aug 2010 06:59
"Scott L. Burson" <Scott(a)ergy.com> writes: > Alessio Stalla wrote: >> What I'm dubious about is how often someone thinks "I >> really need FSet to solve this problem!". I suspect that doesn't >> happen often and that it would happen more often if FSet was part of >> some "batteries included" library for CL and if it integrated well >> with sequences. > > It's in LibCL! :) :) > > Alas, it's not clear LibCL itself is seeing much use. That's too bad -- > Daniel has done a lot of work on it and I think he's done a good > job. If there's another "batteries included" library you think FSet > should be in, let me know. (It's also ASDF-Installable, or should be > -- I haven't tested that in some time.) It's in Quicklisp, too! Zach |