[ANSI-Smalltalk] RE: ANSI-Smalltalk Digest, Vol 2, Issue 31 -
Downloads of ANSI framework
martin.mcclure at gemstone.com
Wed Nov 28 20:05:21 GMT 2007
Richard Sargent wrote:
> However, we have the concern of inserting something like this into the
> critical path, delaying any progress on the standard until we can
> whole document text encoded. Of course, the same concern arises for
> the document into any format other than the one already used to
submit it to
> the standards body for approval.
> This suggests the following parallel efforts:
> 1) "cherry picking" of easy issues with the current standard, such as
> correcting errata and enhancing it with relatively small items.
> 2) development of a tool for encoding the document into some manipulable
> form, such as what Martin has come up with. Ideally, this tool can
> text of the current document, meaning that we can switch over from
> with the document in its current form at any point.
I certainly hope no one with specific proposals for content changes is
waiting for better tools support -- I agree that it's better to start
working on these now.
For most things other than simple errata we have a ways to go before we
reach a point where tool support would help much. Since I don't have any
specific content proposals right now, I'm working on tools. My hope is
to have a tool that meets at least our minimum requirements by the time
we reach a point in our discussions where some kind of tool would help.
> I think what Martin is proposing is an excellent tool. It will allow
> "reasoning" about the standard itself, using Smalltalk to manipulate the
> specification. I don't know what reasoning I would want to do, but the fact
> that we could is crucial. I would suggest taking it one step further so that
> Strings are only used for semantically free information like narrative and
> names. Objects of various kinds should be used for things like the return
> value specifications, parameter specifications, and so on. Objects should be
> used for the meta-concepts like "<sequencedCollection>" and so on.
Thanks for the comments. I tend to agree. I considered using something
other than plain Strings for the more structured parts. The chief reason
I ended up with Strings was that this initial version was timeboxed into
a holiday weekend, and this was the simplest initial option.
Also, giving things a richer object structure while preserving editing
usability requires a bit of thought. For instance, right now
AnsiFileStream>>contents contains this code:
returnValues: #('<ByteArray> new' '<String> new' )
This is fairly readable in source code, and is easily editable. The most
straightforward translation of this to objects might replace this code
with something roughly like this:
protocol: AnsiByteArray; new,
protocol: AnsiString; new }
This isn't *too* bad, but is a bit harder to read, and a bit harder to
write. Worse, it uses an array constructor, which makes it non-portable.
I'm resigned to the framework requiring some work to port between
dialects, but I really want the protocol code itself to be totally portable.
In an attempt to get the best of both, I'm currently leaning toward
using the plain string code, but parsing it into objects when executed
by the framework.
More information about the ANSI-Smalltalk