From: Oren Ben-K. <or...@be...> - 2003-03-16 08:46:20
|
Brian Ingerson [mailto:in...@tt...] wrote: > ... Great work on the YOD stuff Oren (and Why). Thanks. Just note that my YOD isn't Why's YOD - unless why has changed his code; if he did, I'd love to run it through yod2pdf to get a printable version. I tried to get a yod2latex going but latex's tables have defeated me; it seems impossible to get the required table functionality out of latex... Also, the source YOD file would look much better (getting rid of all the '- >') once I can switch to the new YAML.pm. As it is today, it needs a hacked version of YAML.pm 0.35. > I'll tell you what. Let's shoot for the end of April for=20 > announcing a Release Candidate. (It seems that) Why, Mike Orr=20 > and I are in the middle of implementing a lot of stuff in=20 > the next 6 weeks. If the spec can survive that period, then=20 > I'm willing to go to a release candidate. Works for me. > BTW Oren (and Clark), you never replied to my email "The=20 > diagram is wrong". I think that it requests some changes in=20 > the model section of the spec. The important part is: ... >=20 > - The flow diagram in the spec is flawed in my opinion. I=20 > am actually to blame, because I wanted it that way. :-) > But a linker and a loader > are just two "flavors" of the same thing. That's what the old diagram said... > And there can=20 > be many > more flavors. I would just drop the concepts of Linker and > Serializer and call them Generic Loader and Generic Dumper. That's > what they are. Hmmm. So you'd rather see the old diagram? -------------- | GRAPH | TEXT -- Parser -> SERIAL -- Loader -> | (generic) | |---- or ----| (syntax) <- Emitter - (tree) <- Dumper <- | NATIVE | | (language) | -------------- /\ || \/ Application=A0 I don't like it much... > ... A native Loader doesn't "employ" a=20 > Linker, as I once suggested. > They may both inherit common=20 > code, but they are conceptually separated. This by itself doesn't bother me at all; it is merely implementation details. It is possible, after all, to implement a YAML loader without going through a serial (tree) model either, directly using some sort of lexical tokenizer. > ie An application=20 > will either want to do a Generic Load, or a Native Load, (or=20 > some other specialized Load). You could also say that an application would either want to see the serial (tree) model or one of the above, but not both. Again that doesn't invalidate the serial model being at a different abstraction level. The main reason I'd like to keep the diagram as it is, regardless of implementation details, is that the graph is an *enhancement* of the native model with formats and a uniform string representation of the scalar values. I think that this justifies viewing the graph model as a valid intermediate step between the native and serial models. Have fun, Oren Ben-Kiki |