[r6rs-discuss] [Formal] Version reference syntax is overly complex.

From: Shiro Kawai <shiro>
Date: Sun, 17 Jun 2007 02:03:58 -1000 (HST)

From: Jens_Axel_S?gaard <jensaxel at soegaard.net>
Subject: Re: [r6rs-discuss] [Formal] Version reference syntax is overly complex.
Date: Sun, 17 Jun 2007 12:57:13 +0200

> Shiro Kawai wrote:
>
> > Suggested alternative #2
> > ------------------------
> >
> > Drop the whole library versioning idea from r6rs.
>
> In the case where you distribute your program including
> all used libraries, versions aren't terrible important.
>
> However, if a library outside your control is updated,
> then it is better to get a library version error than
> some random runtime error.

Right. However, although having version-reference in the
import clause helps, I don't think it alone solves large
part of the problem.

- At least from my experience, the versioning is more
  important in a way that you can switch your code depending
  on the version to accomodate API change. For example,
  we may want to have srfi-0 cond-expand extended to version
  checking, like this:

  (cond-expand
    ((library-version<= foo (2 3))
     (foo-api x y z))
    (else
     (foo-api x y z #f)))

  Just rejecting loading some versions hardly increases
  usability of your code. (You may make different packages
  for each of different third-party library versions, but the
  combination would easily explode once your code depends
  on more than a few third-party libraries.)

  Besides, if we have this kind of extention, we can check
  required versions in our code as well; version reference in
  the import clause doesn't add a new feature, except a
  little bit of convenience.

- One may argue that having explicit version reference in
  import clause may help writing meta tool, like packaging
  tool that checks dependencies. However, an application
  these days can depend on quite a few number of other
  components, most likely including non-Scheme components
  that uses versioning outside of r6rs, which may not follow
  r6rs versioning scheme (e.g. 4d2, 20070617a, 1.3.2-rc2, etc.)
  So, such meta tool can't live within the r6rs versioning world
  anyway.

- If one need to rely on a convention like "API changes
  imply major version change", then one can also rely on that
  "most library provides a specific macro that allow the
  library user to check the library version". In other words,
  even if r6rs doesn't include versioning, we can roll our own.
  And we don't know (at least, I don't know) the versioning of
  r5.94rs is the best, so I'd feel rather safe not to include
  it in the spec. SRFI seems the best fit to me.

--shiro
Received on Sun Jun 17 2007 - 08:03:58 UTC