[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loss of abstraction



On Tue, Aug 23, 2005 at 10:18:12AM +0200, Michael Sperber wrote:
> > The answer in Lisp has been, for 46 years, that syntax objects and lists
> > _are_ the same.  
> Sure.  The answer in Lisp has also been that identifiers and symbols
> are the same.  Turns out it was wrong.

In my view, the power of SRFI 72 is exactly that it is able to preserve
the _important_ abstraction of syntax-as-lists by dispensing with the
less-importan abstraction of identifiers-as-symbols.  You and Marcin:

On Tue, Aug 23, 2005 at 05:54:40PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
> > Syntax as lists (or isomorphic to) represents the highest level of
> > abstraction (on the input) that preserves the meaning of Scheme code.
> I would not call lists a higher level of abstraction than
> distinguished types for syntax.

... seem to be very confident that abstraction over unknown needs (such
as possible, forthcoming syntax representations) is more important than
abstraction over known services (such as the unification of lists and
syntax).  They are very different kinds of abstractions, of course: the
former is design-on-beforehand, the latter is conceptual simplification.

On Tue, Aug 23, 2005 at 10:18:12AM +0200, Michael Sperber wrote:
> Moreover, once that choice is
> made, changing the representation is seriously hindered by the fact
> that the representation wasn't abstract to begin with.

You seem to not acknowledge the fact that however separate you make the
API's of lists and syntax, you still have the risk of choosing the
_wrong_ API for syntax (or lists).  So, you should tackle the problem of
"what syntax really is"; you should show why syntax is _not_ lists.
It's not so clear that a separate API for syntax is "more abstract"; let
alone being better.

-- 
personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@xxxxxxxxxxx, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/