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

For R^5RS or not for R^5RS. *This* is a question?




I'd like to bring something up which I am not really sure belongs in
an appendix to R^5RS.  Unlike "lambda*" and "procedures with
operations" (both of which I support), the following proposals do not
affect the Scheme language--only the runtime system.

What I want is the ability to do portable low-level systems
programming in Scheme.  This requires the ability to do low-level
(storage) representation mapping.  A desired feature is to be able to
free storage allocated by a static heap allocator such as C's malloc,
close unused ports, etc. when associated values are no longer live.
Higher-level facilities such as foreign structure/record support and
window systems can be built upon these services.

The reason I am bringing this up is that proposals below are
reasonably easy to add to implementations, but impossible to do in
standard Scheme. 

So I really have 2 questions:
  [A] Is R^NRS the place to bring this type or proposal up (if not,
  where)? 
  [B] What do you think of the specific proposals?

Thanks in advance,
-Ken					kend@data.rain.com

===============================================================
PROPOSAL [1]: `object finalization'
===============================================================

The interface I propose for object finalization is:

  (REGISTER-FOR-FINALIZATION <object> <thunk>)  -> unspecified

Notes:

  When <object> is collected, <thunk> is executed.  

  Executing <thunk> should never allocate (cons) storage.


===============================================================
PROPOSAL [2]: `abstract stores'
===============================================================

PRIMARY REASON DE ETRA:  Random & Binary i/o.

BASIC IDEA: A (binary) store with size and permissions.


DISCUSSION:

The Store abstraction allows one to deal with low-level file,
unscanned-vector, and computer memory `objects', allowing device
drivers, file systems, compilers, linkers, and other system programs
to be written directly in Scheme.  An implementation may supply
predefined stores which map to computer memory or memory mapped
devices.  Memory which remains fixed, e.g. C structs and Pascal
records, can be mapped as stores and dereferenced.  Memory can be
copied to memory, file to file, file to memory, etc. 


SYNOPSIS:

; predicate
(STORE? obj) -> #t or #f

; creation
(MAKE-STORE num-bytes . fill-integer) -> store
(MAKE-STORE num-bytes fill-integer . permissions) -> store
(MAP-STORE  start end . permissions) -> store
(MAKE-STATIC-STORE num-bytes . fill-integer) -> store
(MAKE-STATIC-STORE num-bytes fill-integer . permissions) -> store
(FILE->STORE path) -> store

; access
(PERMISSIONS store) -> 'read-only 'read+write or 'write-only
(ENDIAN store) -> 'big-endian or 'little-endian
(STORE-LENGTH store) -> num-bytes
(STORE-REF-BYTE store address) -> integer
(STORE-REF-WORD store address) -> integer
(STORE-REF-LONG store address) -> integer
(STORE-REF-CHAR store address) -> character
(STORE-SLICE->STRING store start end) -> string
(STORE->FILE store path) -> path
(WRITE-STORE-SLICE store start end . port) -> unspecified

; mutation
(STORE-SET-PERMISSIONS! store permissions) -> permissions	{?unspecified?}
(STORE-SET-BYTE! store address integer) -> integer		{?unspecified?}
(STORE-SET-WORD! store address integer) -> integer		{?unspecified?}
(STORE-SET-LONG! store address integer) -> integer		{?unspecified?}
(STORE-SET-CHAR! store address character)     -> character	{?unspecified?}
(STRING->STORE-SLICE-SET! string store start) -> unspecified
(STORE-SLICE->STORE-SLICE-SET! store1 start1 end1 store2 start2) -> unspecified


optional:
  (STORE-REF-IEEE-SINGLE->REAL   store address) -> real
  (STORE-REF-IEEE-DOUBLE->REAL   store address) -> real
  (STORE-REF-IEEE-EXTENDED->REAL store address) -> real
  (STORE-SET-IEEE-SINGLE!   store address real) -> unspecified
  (STORE-SET-IEEE-DOUBLE!   store address real) -> unspecified
  (STORE-SET-IEEE-EXTENDED! store address real) -> unspecified
  ...


NOTES:

Permissions are used to allow EPROM memory and read-only files to
signal an error upon assignment.  Default permissions are 'read+write. 

An error is also signaled if an integer of greater size than the unit
is assigned [byte = 8 bits; word = 2 bytes; long = 4 bytes, ...].

Stores are zero based.  There is no requirement for storage alignment
above the byte level {e.g. (store-ref-long <store> 3) is ok}.

Store finalization is provided.  I.e. when a store representing
statically alloc'ed memory is collected, the memory is free'ed; when a
store representing a port is collected, the port is closed.

A Scheme character is of implementation-dependent size (e.g. Japanese
or Chinese characters may be multi-byte quantities).

Returned integers are always non-negative.

Endian ordering matters only in the store-set-*! and store-ref-*
operations.  The *-slice-* operations do the proper endian transforms
as required. 

NOTA BENE:  This data type has no print representation.


ISSUES:

No file extension is provided for {one can use write-store-slice}.

There is no support for specifying and mapping between multiple
address spaces. [ (map-virtual-store ...) ? ]

I really don't like returning unspecified values.  Can we agree to
return the *old* values on mutations marked as {?unspecified?}, above?



;;			--- E O F ---