Hi!

Ralph Johnson wrote:
> On Thu, Mar 12, 2009 at 5:28 AM, Göran Krampe <goran at krampe.se> wrote:
>> - Human readable, just like a cs. We just gzip them and make up some nice
>> extension like .dz or something. :)
>> - Editable in a text editor. This means it can not be too complex.
>> - Easy to extend. This means the base syntax should leave room for new
>> elements and "relaxed parsing" that can ignore unknown elements
>> - Very easy to parse. This means it needs to be simple, simple, simple. I
>> don't want to depend on YAXO or similarly large package for parsing.
>> - Not "compiler driven". I want the format to be safe and fast to load. This
>> means the regular Smalltalk Compiler is out of the picture.
> 
> I don't understand the combination of "human readable" and "not
> compiler driven".  Does this mean that you are going to include
> bytecodes as well as source code?

No. :)

> If the file is editable in a text
> editor, then it will be easy to make the bytecodes be incompatible
> with the source code.

No bytecodes, see below.

> Maybe your definition of "human readable" and "editable in a text
> editor" are different from mine.  Perhaps you only intend human
> readability as a last resort, as a way of debugging the system, for
> example.

No, I would like them to be "fairly readable". And I do want them to be 
quite easily "generated" and fiddled with (although I don't really 
expect them to be generated or edited by many other tools than the DS 
codebase itself).

I think your mentioning of bytecodes comes from a misconception - a 
Delta carries source code, but it is *not* compiled when loaded into an 
image. The compilation is done in the "next step" - when you "apply" the 
Delta to the image (using SystemEditor to do it atomically).

So the file is actually "just a serialization of a DSDelta instance". 
Since a DSDelta instance is basically a sequence of DSChange instances, 
and the most common one is a DSMethodModifiedChange - it kinda will look 
like a changeset, although much more "detailed" in nature.

But from a usage perspective we could even dump them using 
SmartRefStream - since we first load them into the image - but I do 
think a "real" format has its advantages.

Btw, what I meant with "Compiler driven" was how the chunk format works:

http://wiki.squeak.org/squeak/1105

...but I don't think I want an "executable" format like this.

> Netstrings aren't very editable, because you have to keep
> counting characters every time you change a line.  But if editability
> is only for extreme emergencies, this is OK.

Good point, hadn't thought about that weakness of netstrings. Hmmmm.

Perhaps Yaml is worth looking at? Need to figure out its 
advantages/disadvantages.

regards, Göran