Laurens Holst wrote:
>
> > Indeed, this is even more intuitive than numbering.
> > Let's them make the strings be "MSX", "MSX2",
> > "MSX2+" and "MSX turboR".
>
> What if I write MSX 2+ and MSX turbo R??? No, a number is much more
> clear I think. And if you use my 'system' I proposed in my prev.
> message, you can define a seperate 'option' named 'altered CPU
> speed'.
You got a point, but if all the problem is where the spaces
are located and whether is string is lower case or upper case, then
the solution is just to ignore spaces, case and extra characters.
The parser could understand "MSX turboR" as well as "MSX turbo R",
"msx turbo-r","m S x Turb oR" and so on. Using a parser generator
like lex/yacc, this is easy to implement.
The "option" system you defined is very similar to
the "chunks" system as defined in the MIDI file format standard.
I think it should not used, because we already exposed the problems
of binary data: too difficult to edit, too difficult to update,
have problems in machines with different endianess. Let's just
stick with ascii files, this is what linux does all time.
> (The .msx extension idea for example... apparantly someone else
> got the same idea...:)).
Everyone seems to had the same idea at the same time,
so it must be a very good idea indeed.
Ricardo Bittencourt
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
