[ANSI-Smalltalk] RE: ANSI-Smalltalk Digest, Vol 2, Issue 31 - Downloads of ANSI framework

[Martin McClure]

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 
have the
 > whole document text encoded. Of course, the same concern arises for 
encoding
 > 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 
parse the
 > text of the current document, meaning that we can switch over from 
working
 > 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:

   returnValues: {
     ReturnValue
       protocol: AnsiByteArray; new,
     ReturnValue
       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.

Regards,

-Martin