Abstractions
in [Lisp]
|
From: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 4 Aug 2010 03:53 George Neuner <gneuner2(a)comcast.net> writes: > On Tue, 03 Aug 2010 16:42:59 +0200, bjorn(a)runa.se (Bj�rn Lindberg) > wrote: > >>Secondly, the kind of abstraction we are discussing here, namely one to >>allow changing the implementation of some data type in a later version >>of the program, _has_ no dynamic properties. In version X of the >>program, a particular call site (ref ...) will mean ASSOC, in version Y >>GETHASH. No dynamicity involved. In contrast, your straw man the >>arithmetic operators are very likely to accept different number types at >>run-time. > > Interface abstraction frequently hides dynamic changes. It's not at > all uncommon, for example, for collections to change data structures > depending on the number of elements involved. Of course. I explicitly limited my discussion to the case at hand, which was about being able to change implementations in later versions of the code, and the potential refactoring resulting thereof. In my mind this and the dynamic change you are speaking of are two different topics, albeit with overlapping solution spaces. Bj�rn Lindberg
From: RG on 4 Aug 2010 11:26 In article <9mplj8mkewt.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) wrote: > RG <rNOSPAMon(a)flownet.com> writes: > > > In article <9mpwrs7kipq.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) > > wrote: > > > >> > It all boils down to some common sense. Just like we use + rather than > >> > fixnum+, bignum+, float+, double+, it's often convenient to use ELT > >> > rather than AREF or NTH. > >> > >> No, these are two completely different topics. We do not use generic > >> arithmetic operators to delay an implementation choice of which number > >> type to use. > > > > Huh?!? This seems to me to be the *only* reason to use generic > > arithmetic. What else is it good for? > > To write code that can accept differing types of numbers at run-time. And how is that not "delaying an implementation choice" (to run-time) on which number type to use? > As > you know, + takes a variable number of arguments, which among themselves > can have different types. Alessio would need an awfully high number of > operators with his approach (admittedly a straw man). Actually having a different operator for each numeric type is not a straw man. Some languages (like OCAML) actually do math this way. rg
From: Alessio Stalla on 4 Aug 2010 11:35 On Aug 4, 5:26 pm, RG <rNOSPA...(a)flownet.com> wrote: > In article <9mplj8mkewt....(a)runa.se>, bj...(a)runa.se (Björn Lindberg) > > As > > you know, + takes a variable number of arguments, which among themselves > > can have different types. Alessio would need an awfully high number of > > operators with his approach (admittedly a straw man). > > Actually having a different operator for each numeric type is not a > straw man. Some languages (like OCAML) actually do math this way. Ugh! I did intend it as a straw man :) I didn't suspect someone would actually do it! Cheers, Alessio
From: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 4 Aug 2010 12:23 RG <rNOSPAMon(a)flownet.com> writes: > In article <9mplj8mkewt.fsf(a)runa.se>, bjorn(a)runa.se (Bj�rn Lindberg) > wrote: > >> RG <rNOSPAMon(a)flownet.com> writes: >> >> > In article <9mpwrs7kipq.fsf(a)runa.se>, bjorn(a)runa.se (Bj�rn Lindberg) >> > wrote: >> > >> >> > It all boils down to some common sense. Just like we use + rather than >> >> > fixnum+, bignum+, float+, double+, it's often convenient to use ELT >> >> > rather than AREF or NTH. >> >> >> >> No, these are two completely different topics. We do not use generic >> >> arithmetic operators to delay an implementation choice of which number >> >> type to use. >> > >> > Huh?!? This seems to me to be the *only* reason to use generic >> > arithmetic. What else is it good for? >> >> To write code that can accept differing types of numbers at run-time. > > And how is that not "delaying an implementation choice" (to run-time) on > which number type to use? Let us be careful not to have this discussion stray from the topic, and consider the context in which that comment was made. If you think that Alessio's 'typed arithmetics' are similar in nature to what I was outlining in the post he replied to, can you please explain that further? >> As >> you know, + takes a variable number of arguments, which among themselves >> can have different types. Alessio would need an awfully high number of >> operators with his approach (admittedly a straw man). > > Actually having a different operator for each numeric type is not a > straw man. Some languages (like OCAML) actually do math this way. A straw man argument is based on misrepresenting an opponent's position. That someone, somewhere, might hold the opinion of the straw man argument is irrelevant. Bj�rn Lindberg
From: RG on 4 Aug 2010 13:20
In article <9mpzkx2ibyb.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) wrote: > RG <rNOSPAMon(a)flownet.com> writes: > > > In article <9mplj8mkewt.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) > > wrote: > > > >> RG <rNOSPAMon(a)flownet.com> writes: > >> > >> > In article <9mpwrs7kipq.fsf(a)runa.se>, bjorn(a)runa.se (Björn Lindberg) > >> > wrote: > >> > > >> >> > It all boils down to some common sense. Just like we use + rather than > >> >> > fixnum+, bignum+, float+, double+, it's often convenient to use ELT > >> >> > rather than AREF or NTH. > >> >> > >> >> No, these are two completely different topics. We do not use generic > >> >> arithmetic operators to delay an implementation choice of which number > >> >> type to use. > >> > > >> > Huh?!? This seems to me to be the *only* reason to use generic > >> > arithmetic. What else is it good for? > >> > >> To write code that can accept differing types of numbers at run-time. > > > > And how is that not "delaying an implementation choice" (to run-time) on > > which number type to use? > > Let us be careful not to have this discussion stray from the topic, and > consider the context in which that comment was made. If you think that > Alessio's 'typed arithmetics' are similar in nature to what I was > outlining in the post he replied to, can you please explain that > further? The original context was snipped out. I presume you're referring to this: > If I may interject, I do see value in abstraction, but it will usually > take a different form than what you propose. > > Let's say that we in our program have objects of the kind foo, indexed > by bar, stored in collections bork. You do not want to prematurely > select the implementation of bork to be either hash tables, alists or > something else. You now write accessors like ADD-FOO, FIND-FOO, and the > like, essentially creating an ADT specific to the program. This ADT > encapsulates whatever implementation is chosen for bork, making change > later easy. The advantages of this approach are plenty: The accessors > can be written to fit the semantics of foo, bar and bork, rather than > shoe-horning the behaviour of those into some generic collections > framework. It makes the code much more descriptive of what it is doing > than if it is sprinkled with "generic" REF calls, which from a > documentation perspective is even worse than having it filled with calls > to GETHASH. Alessio's typed arithmetic operators seem to me to be exactly analogous to your typed collections operators. ADD-FOO (presumably) only adds objects of type FOO. In fact, just change FOO to FIXNUM and you've got Alessio's example nearly verbatim. > >> As > >> you know, + takes a variable number of arguments, which among themselves > >> can have different types. Alessio would need an awfully high number of > >> operators with his approach (admittedly a straw man). > > > > Actually having a different operator for each numeric type is not a > > straw man. Some languages (like OCAML) actually do math this way. > > A straw man argument is based on misrepresenting an opponent's > position. That someone, somewhere, might hold the opinion of the straw > man argument is irrelevant. That's true, but Alessio's example doesn't look like a straw man to me from that perspective either. It seems to me to be a perfectly valid critique of your approach. If you think it's a straw man then you haven't communicated your point very well, at least not to me or Alessio. rg |