> I agree that it would be nice to have some consistency
> in naming extensions across scheme implementations. How should
> we do this? I think the only way would be to survey the
> existing implementations, come up with a proposal that
> is good with the constraint of requiring the least change
> from existing implementations, and then relentlessly promote
> it as an informal standard on comp.lang.scheme.
> Unfortuntately, most of us don't have the energy to do this.
>
> My vote (I used this in the foreign function interface to elk2.0
> in fact):
>
> unix-specific routines are called "unix-something", e.g. unix-fork, unix-wait
>
> other os routines are named "os-something", e.g. "os-filesize".
I've seen this thread in other languages (python, perl) under the
guise of 'module naming'.
To summarize past views (mine), there are 2 approaches. The one above
is the 'standards oriented' and is best expressed by prefixing with a
'standard' descriptor, like 'posix-open' 'posix-exec' & so on. On then
uses 'os-foo' where the implementation of 'os-*' will happen to be
something different on any given os, with some tag for the OS in
'os-name' 'os-version' and the like.
The other approach is the Modula-3 one, and is based on providing
services based on the above groups. This would yield 'process-fork'
'process-exec' 'fs-create-directory' 'pathname-decompose' and the
like, built on top of 'posix-mkdir' and the like.
Personally, I think Scheme is probably a 'lost cause' for this as a
wide spread reform. It is easy enough to redefine or translate any
code for porting to a new Scheme implementation.
--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford_at_lehman.com | 5 cans of Scotchguard.
Received on Thu Feb 16 1995 - 15:29:52 CET