[erlang-questions] New draft of frames proposal (was Re: Frames proposal)

[Richard O'Keefe]

There is a new version of
http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf

- a couple of diagrams
- some new material, including a description of what
  is wrong with using X.y to access a field
- a new section 2 apologising for the rewrite this
  needs and hasn't had yet
- a new section 15 (starting on page 41)
  which describes in some detail how it works
  with new BEAM(-ish) instructions
	put_frame	allocate a frame
	is_frame	give true/false result
	test_frame	used in clause heads
	check_frame	used in expressions
	load_slot	load a slot (with inline cache)
	copy_frame	copy a frame for updating
	store_slot	store a slot (with inline cache)



On 2/05/2012, at 5:19 AM, Björn-Egil Dahlberg wrote:

> Syntax is more than just finding which characters our parser can identify, like in the frames proposals where ~ is our separator. When I read <{ k ~ value | Is }>  it says cons "k is like a value" to Is. *brr*

In fact the semantics very closely related to the semantics of
`((k ,@REDACTED) ,@REDACTED) considered as an association list in Scheme,
which really does involve a cons.  Let's face it, Is#{k=value}
says that k *equals* value, which it doesn't.  There is a uniquely
right character for the job, and that's ↦ .

> What guarantees should we leave?

Any data structure associated with Phil Bagwell is likely to repay study.
I do hope there is no patent on "Cache-Aware Lock-Free Concurrent Hash Tries"
by Aleksandar Prokopec, Phil Bagwell, and Martin Odersky, because that's
_exactly_ what I want for storing frame descriptors.  However, the
frame implementation described in the frames proposal is meant as a
replacement for records, and however good HAMTs are at other things,
frames should leave them in the dust *when used as record replacements*.