Ralph Johnson <johnson <at> cs.uiuc.edu> writes:
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? If the file is editable in a text editor, then it will be easy to make the bytecodes be incompatible with the source code.
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. 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.
-Ralph Johnson
Agree, double representation seems dangerous to me...
Is it about transporting bytcodes from an image to another? Source might be portable. Bytecodes a little less... Not speaking of Eliot changes, a single addition of an instance variable in an upper class in your image would make importing bytecodes from another image very hard. Or I misunderstood something...
Is it about storing upper level object abstractions in the stream? In this case, I dont' feel comfortable with the static view of an object tree: my experience is that it is a nightmare to maintain upward compatibility when classes have to evolve, and for sure they will. For my major application in VW, 20 years ago, I started with BOSS and this kind of thing. Textual representation of objects (like JSON, XML, whatever...) though readable, would not give me much better results. Guess what, the best syntax I ended up with was: variable := receiver selector arguments. Yes, my objects where fully saved as a script in Smalltalk syntax that could be filed in later. I chose a list of messages (an API) that construct complex object graphs corresponding to my (evolving) model, rather than low level inst var setters. I prefer to store the recipe rather than storing the cake. Much less upward compatibility problem, just had to maintain the API...
Then there is the problem of inter-mixing source code and other abstractions in the same Stream. A well known problem in shell scripts, perl scripts etc... cat >$FILE <<END ... END For my problem, I ended up with a Compiler/Parser subclass for dealing with a small reflective addition: thisFile (like there is a thisContext).
This could give some sentence like: Compiler compile: thisFile nextChunk in: MyClass. myMessage ^myInstVar doSomething!
Of course, you could as well write thisFile nextCodeBetweenBracket.... [myMessage ^myInstVar doSomething]
The reader is as simple as: [thisFile atEnd] whileFalse: [FileParser parseNextSentenceFrom: thisFile]...
This is a very open, reflexive, Smalltalkish way of doing things. For example, I did not impose any ASCII,UTF8,16,32 encoding to my files. Instead I kept the format open because I would just have written in first sentences: thisFile encoding: #ISO8859L1.
Do you think such a format would match your needs?
Nicolas