[<<][staapl][>>][..]
Fri Mar 2 19:13:23 GMT 2007

linear languages


http://home.pipeline.com/~hbaker1/Use1Var.html

"A 'use-once' variable must be dynamically referenced exactly once
within its scope. Unreferenced use-once variables must be explicitly
killed, and multiply-referenced use-once variables must be explicitly
copied; this duplication and deletion is subject to the constraint
that some linear datatypes do not support duplication and deletion
methods. Use-once variables are bound only to linear objects, which
may reference other linear or non-linear objects. Non-linear objects
can reference other non-linear objects, but can reference a linear
object only in a way that ensures mutual exclusion."


what he describes a bit further on is an 'unshared' flag. a refcount =
1 flag, but it looks like this is more in the context of a mark/sweep GC.

an attempt to make some patterns automatic? reverse list construction
followed by reverse! is an example of a pattern that might be
optimizable if the list has a 'linear' type: the compiler/interpreter
could know that 'reverse!' is allowed as a replacement of 'reverse'.

so as far as i get it, baker describes a 'linear embedded
language'. linear components are allowed to reference non-linear ones,
but vise versa is not allowed without proper synchronisation. so in a
RT setting, this means the only thing that is allowed to run in the RT
thread is the linear part, while the nonlinear part can maintain it's
game outside this realm.

so, again:
- high priority linear RT core (forth)
- pre-emptable nonlinear metaprogrammer (scheme/cat)

the linear part contains only STACKS + STORE. the nonlinear part can
contain the code for the linear part. the compiler runs in the
nonlinear part. the nonlinear part is not allowed to reference CONS
cells in the linear part.

this can be implemented entirely inside of PLT. on the other hand,
having this structure independent of a PLT image makes it more
flexible: the core linear system should be able to do it's deed
independent of the metasystem's scaffolding.

baker calls my 'packets' nonlinear types: names with management
information (reference counts): a strict distinction is made. this
allows a nonlinear type to be decouple from it's (possibly linear)
representation object.

in PF this means: packets are references to linear buffers. the result
is that underlying representation can change ala smalltalk's 'become'.

conclusion:
- cons cells are linear
- packets are nonlinear wrappers for linear storage elements
- packet access: readers/writers access protocol: mutation is only
  allowed when there are no readers (RC=0). (functional ops)
- 'accumulation ops' use shared state + synchronized transactions.





[Reply][About]
[<<][staapl][>>][..]