On Feb 21, 2008, at 11:40 PM, Michael O'Brien wrote:
The reason is we could remove a few road blocks with some design
notes.
These won't be as complete as the spec but could from the basis of
writing some of the spec prose.
Ok.
Also, the spec can reference the RI (not just SML but, for
What about the actual content sections?
We want the same look and feel over the text -- what perspectives do you
need covered in describing a feature. Do you have a sample?
Michael
Graydon Hoare wrote:
Brendan Eich wrote:
I'll start the ball rolling with writing up some notes on Program
On Feb 19, 2008, at 6:39 PM, Graydon Hoare wrote:
Finally there is a category I left off the above elaboration, mostly
because it is under-developed in the RI: control mechanisms. There are
dependencies between tail calls, generators and stack inspection,
and I
can't say I fully understand
Seems to me we may have some emerging agreement on the following items.
Please be kind if I'm overstating the consensus, but I believe the
following items start us in the right direction without being too
onerous.
Triage the existing proposals into those that are current and
correct and
Comments below:
This sounds good, but if we've accepted proposals and need detailed
specs, why not write specs? This is not just a matter of wiki
namespace (proposal: vs. spec:). Proposals have emphasized precedents,
use-cases, and anti-use-cases, and considered alternatives. Discussion
Comments below:
Going further, I have mentally considered the language as providing 3
big categories of enhancement: fixtures, types, and namespaces. I
think that within -- and possibly between -- these groups there are
dependencies. For example, we can consider these levels of
