Hi!
Ralph Johnson wrote:
On Thu, Mar 12, 2009 at 5:28 AM, Göran Krampe goran@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