Abstractions
in [Lisp]
|
From: Pascal Costanza on 10 Aug 2010 07:12 On 09/08/2010 05:03, Scott L. Burson wrote: > 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. > > And the second largest barrier, I suspect, is simply that people expect > it to perform poorly. A lot of people on this list talk about minimizing > garbage generation in their code -- an art that I think belongs in the > same category as writing in assembler: experts occasionally need to do > it, and it's useful to know how to do it, but most people most of the > time don't need to worry about it. And yet it gets discussed here with > some regularity. I'm not sure people really realize how good modern > generational GCs are. I think another large barrier is, as with any other CL library, that it adds another dependency to your system, which needs to be followed and maintained. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: RG on 10 Aug 2010 16:13 In article <9mpaaouhhj4.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) wrote: > RG <rNOSPAMon(a)flownet.com> writes: > > > In article <9mptyn4ghlo.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) > > wrote: > > >> What I initially took issue with was the idea that one should use > >> generic collections everywhere preventively, so that a later decision to > >> change a data type would not result in massive refactoring. I think this > >> mistaken as general advice, since most data types won't change, yet the > >> costs mentioned above will arise. Instead, I outlined a different > >> approach which solves the refactoring problem in the cases where it > >> appears, yet incurs much smaller costs in general. > > > > But your approach has costs too: the cost of designing, implementing, > > and maintaining the domain-specific abstractions, > > No matter how generic collection abstractions I had access to, I still > would encapsulate important data structures in domain-specific > abstractions as a matter of software engineering. This cost, if it can > be counted as one, would be incurred in either case. > > > to say nothing of the risk of serious problems down the road if you > > have to do a large refactor on a live system. > > I have repeatedly explained how to address this just as well as with a > generic framework. Avoiding large refactorings in this sense is about > encapsulating relevant aspects so as not to proliferate a particular > design choice throughout the code. Deciding on what is relevant may be > difficult, but can be done at least as well in the application itself as > in a generic library that knows nothing about your program. > > > In any particular instance those costs are almost certainly smaller > > than the cost of designing and maintaining a generic abstraction, but > > the cost of building and maintaining domain-specific abstractions is > > an ongoing cost whereas the cost of developing and maintaining a > > generic abstraction is a one-time cost (and at this point in history, > > arguably a sunk cost) which then at least potentially pays dividends > > across a large number of projects. > > 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? > 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? rg
From: Nicolas Neuss on 11 Aug 2010 05:53 RG <rNOSPAMon(a)flownet.com> writes: > In article <i3nngm$dk9$1(a)news.eternal-september.org>, > "Scott L. Burson" <Scott(a)ergy.com> wrote: > >> RG wrote: >> > At the risk of repeating myself, the value of being able >> > to make changes at run time is implicitly acknowledged in nearly every >> > other aspect of CL's design. So I still don't understand why adding >> > that ability to this aspect of the language is resisted so vehemently. >> >> "Resisted so vehemently"? > > "Resisted as vehemently as it is"? > >> Pascal Costanza, 2010-07-30: >> > I find it hard to imagine that this matters beyond simple examples. >> > But that may just be a limitation of my imagination... >> >> Pascal Costanza, 2010-07-30: >> > Don't let me stop you. Everybody should do what they think is right. >> >> Pascal Costanza, 2010-07-31: >> > You could use a collection library, while I could continue to use the >> > low-level substrates... >> >> Pascal Costanza, 2010-07-31: >> > I'm not stopping anybody from creating a good collection framework. >> > If the result convinces me, I'm happy to use it. What I have seen >> > so far doesn't convince me, but who am I to predict there can't >> > be anything better? > > Pascal is not the only one expressing an opinion about this. And this > C.L.L. thread is not the only data I have on this issue. I would be interested in seeing a _single_ person here opposing a generic collection framework which is well integrated in the language, i.e. especially supporting the sequences which CL already has (also typed arrays) and being integrated with LOOP. [And, yes, I also use my own generic "dictionary" interface given mostly by DIC-REF, DIC-FOR-EACH, DIC-REMOVE and DIC-EMPTY-P.] Nicolas
From: Robert Uhl on 11 Aug 2010 11:35 Nicolas Neuss <lastname(a)kit.edu> writes: > > I would be interested in seeing a _single_ person here opposing a > generic collection framework which is well integrated in the language, > i.e. especially supporting the sequences which CL already has (also > typed arrays) and being integrated with LOOP. IMHO the biggest single win would be some standard way to extend LOOP for new datatypes. Ideally, this could be as simple as meaning that '(loop for item in items...)' always Does What I Mean. It's not a bad idea to have type-specific LOOP syntax for built-in type, but it's also a good idea to have generic functionality. And in my ideal world that same syntax would support hash tables and hash-table-like objects. Also, I'd have a pony *grin* -- Robert A. Uhl
From: RG on 11 Aug 2010 12:39
In article <87k4nxlbl4.fsf(a)ma-patru.mathematik.uni-karlsruhe.de>, Nicolas Neuss <lastname(a)kit.edu> wrote: > RG <rNOSPAMon(a)flownet.com> writes: > > > In article <i3nngm$dk9$1(a)news.eternal-september.org>, > > "Scott L. Burson" <Scott(a)ergy.com> wrote: > > > >> RG wrote: > >> > At the risk of repeating myself, the value of being able > >> > to make changes at run time is implicitly acknowledged in nearly every > >> > other aspect of CL's design. So I still don't understand why adding > >> > that ability to this aspect of the language is resisted so vehemently. > >> > >> "Resisted so vehemently"? > > > > "Resisted as vehemently as it is"? > > > >> Pascal Costanza, 2010-07-30: > >> > I find it hard to imagine that this matters beyond simple examples. > >> > But that may just be a limitation of my imagination... > >> > >> Pascal Costanza, 2010-07-30: > >> > Don't let me stop you. Everybody should do what they think is right. > >> > >> Pascal Costanza, 2010-07-31: > >> > You could use a collection library, while I could continue to use the > >> > low-level substrates... > >> > >> Pascal Costanza, 2010-07-31: > >> > I'm not stopping anybody from creating a good collection framework. > >> > If the result convinces me, I'm happy to use it. What I have seen > >> > so far doesn't convince me, but who am I to predict there can't > >> > be anything better? > > > > Pascal is not the only one expressing an opinion about this. And this > > C.L.L. thread is not the only data I have on this issue. > > I would be interested in seeing a _single_ person here opposing a > generic collection framework which is well integrated in the language, > i.e. especially supporting the sequences which CL already has (also > typed arrays) and being integrated with LOOP. That's a tall order, particularly since LOOP is non-extensible. (Also, there is a pretty strong anti-loop faction in the CL community as well.) > [And, yes, I also use my own generic "dictionary" interface given mostly > by DIC-REF, DIC-FOR-EACH, DIC-REMOVE and DIC-EMPTY-P.] That's just my point: everyone who wants a generic collection rolls their own. The discussion does not seem to proceed from the premise that such things are desirable and focus on aspects of the design, instead the discussion hangs up on whether or not such things are even worth doing in the first place. So let me try to change that. *My* generic collection library (yes, I rolled my own as well) is even more generic than yours. It has only a single REF form that can be applied to almost everything dereferencable in CL: ? (ref '(a b c d e f) 3) D ? (ref "abcdef" 3) #\d ? (ref #(a b c d e f) 3) D It supports negative indices which count from the end of a sequence: ? (ref "abcdef" -1) #\f It replaces slot-value: ? (defclass c1 () ((a :initform 'one))) #<STANDARD-CLASS C1> ? (ref (make-instance 'c1) 'a) ONE It supports arrays: ? (ref #2a((a b c) (d e f)) '(1 2)) F And all this is even before we get to dictionaries, which work like this: ? (dict 'a 1 'b 2 'c 3) #<DICTIONARY HASH-TABLE { A 1 C 3 B 2 }> ? (setf d1 *) #<DICTIONARY HASH-TABLE { A 1 C 3 B 2 }> ? (ref d1 'a) 1 T ? (ref d1 'q) NIL ? (ref d1 'q 'default) DEFAULT And of course it lets you change implementations on the fly: ? (change-implementation d1 'plist) #<DICTIONARY PLIST { B 2 C 3 A 1 }> It is not integrated into loop, but it is integrated into my iterator library which expands into LOOP (and thus allows many of LOOP's features to be used): ? (for (k v) in d1 collect (cons k v)) ((B . 2) (C . 3) (A . 1)) FOR...IN is based on an iterator protocol, and it *is* extensible, so using FOR you can loop over anything for which you can define an iterator: ? (for c in "abc" collect c) (#\a #\b #\c) ? (with-input-from-string (s "abc") (for c in s collect c)) (#\a #\b #\c) Iterators are composable so you can do things like this: ? (setf s "line1 line2") "line1 line2" ? (for c in (lines s) collect c) ("line1" "line2") ? (with-input-from-string (s s) (for c in (lines s) collect c)) ("line1" "line2") And just in case Bjorn is reading this (and no doubt recoiling in horror) I also have my own class-defining form that automatically defines appropriate accessors, so I don't *have* to go generic when I know what kind of object I'm dealing with: ? (define-class frob slot1 slot2) #<STANDARD-CLASS FROB> ? (frob-slot1 (make-frob :slot1 'foo)) FOO So, does my design meet your criteria? rg |