deprecating struct permissions?

[Andy Wingo <wingo@pobox.com>]

Hi,

I would like to deprecate struct permissions.

Struct permissions are an aspect of structs that lets the vtable specify
which of a struct's fields are mutable.  It's expressed in the layout
symbol, which can be like "pwpwpw" for three mutable fields, or "prprpr"
for three read-only fields.

Struct permissions are bad in three ways.

First of all, immutability is a concept best added at a higher level.
For example, SRFI-9 records allow you to create immutable records,
simply by not exposing setters.  Structs are a low-level concept, and
the mutability checks in structs actually duplicate concepts that are
better expressed at a high level.  Structs are capabilities to build
abstractions, not abstractions in and of themselves.

Second, "pr" slots aren't really immutable memory -- they are
initialized when the struct is created.  I would like to be able to
compile simple make-struct invocations into separate allocate-struct and
struct-set! operations, and "pr" slots are getting in the way -- I don't
want to have to add a separate
struct-set!-no-really-it's-ok-this-struct-set!-is-initialization
instruction.

Finally, struct permissions rely on the struct layout symbol mechanism,
which is an abomination of an interface.  Ideally I'd like to remove
tail arrays, self fields, opaque fields, read-only fields, and the
layout symbol in the future, instead replaced by a simple field count
and bitfield of "raw" values (the "u" fields).  So for 2.2 we could have
all of these features map to "pw" fields, and in 2.4 we could remove
them entirely.  Or we could deprecate them in 2.0 already; dunno.
Perhaps that is best.

I'm not entirely happy with this proposal -- I would like to prevent
people from mutating nfields in a vtable, for example.  (Class
redefinition is still possible of course.)  But however we do things, we
need a low-level abstraction that underpins records, and making a new
lower-level interface below structs seems like a lose to me.

Thoughts?

Andy
-- 
http://wingolog.org/