Re: provided for compatibility

[Shiro Kawai <shiro@xxxxxxxx>]

I second for Neil.

If my Scheme has the same operation as the SRFI's with a different
name, it is trivial for me to support the SRFI by adding one line
of definition.  I expect supporting any SRFI requires some amount
of work anyway (at least I need to add a documentation to mention
the SRFI support), so I don't see a compatibility problem in such a case.

In this particular SRFI, I'm for -ref, -set! and -delete! for
consistency of R5RS and SRFI-1/13 operations.

The real compatibility problem arises when the same name is used for
different API or semantics.  In this particular srfi, I see a couple
of such conflics.

- The 'default' argument handling of hash-table-get conflicts with 
  PLT's hash-table-get, which requires a thunk.  On the other hand,
  the current proposed API is consistent with STklos, Gauche, and Chicken
  at least.

- make-hash-table has wider variations among implementations.  
  Most implemtations seem to be able to support the current proposed API
  by dispatching with the type of the first argument, but ironically,
  the STklos's make-hash-table, which has the most similar API to
  the proposed API, conflicts, since STklos's hash function doesn't
  take optional 'bound' argument.

It may not be easy to design a hash table API that avoids any conflicts
with the existing implementations; should we invent a new name other
than hash-table-* ?

--shiro



From: "Neil W. Van Dyke" <neil@xxxxxxxxxxxxxxx>
Subject: provided for compatibility
Date: Mon, 25 Apr 2005 18:10:13 -0400

> Regarding the "provided for compatibility" aliases...
> 
>     hash-table-ref     === hash-table-get
>     hash-table-set!    === hash-table-put!
>     hash-table-delete! === hash-table-remove!
> 
> I think aliases like this are more appropriate in a library than in a
> SRFI.
> 
> Currently, the SRFI draft would require all complying Scheme
> implementations to support multiple names for the same operation, which
> seems a little odd ("call/cc" notwithstanding).
> 
> I'd lean towards having the SRFI specify only one name per operation,
> and having the Scheme implementations and user code comply with that.
> 
> -- 
>                                              http://www.neilvandyke.org/
>