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