From: Clark C . E. <cc...@cl...> - 2001-11-02 20:22:51
|
On Fri, Nov 02, 2001 at 07:28:05PM +0200, Oren Ben-Kiki wrote: | Clark C . Evans Wrote: | > I was thinking about an explicit indicator for the | > "flow scalar" (;) and the expansion of scope for the | > implicit representation to cover multiple lines. | | ... from which flows a ^ proposal. I'm unclear about why | it is necessary, exactly. Regardless of the "^" proposal; I'm really trying to clarify the differnce between a "class" and "syntax". | The syntax seems redundant Actually, I think it becomes "cleaner" beacuse flow, block, etc. all become syntax modules and not part of the core productions. | for example this: | | > node: ^flow | > - this is a flow node and not a list | | Seem to mean exactly what this: | | node:: | - this is a flow node and not a list. oh yes. I forgot about the : indicator. This isn't my point. This proposal moves the indicators out of the core productions and into the "implicit" syntax auto-discovery mechanism, which can be cleanly separated. In this way, all that remain in the core productions are map, list, scalar and the descriptors & (anchor), ! (class) and ^ (syntax). Then, for a given "parse node", if the syntax module is given; parsing is delegated to that module. Otherwise, parsing moves into the auto-discovery system where the appropriate syntax module is determined. In this way "| <CR> *" (aka block syntax) is at the same priority as "[*]" (aka base64). In my humble opinion, removing the indicators in this manner _greatly_ reduces the complexity. | Every node has a serialized, text based representation which | conforms to one of three "kinds". map, list or scalar -- right? | Independently, every node has an in-memory, native-language | representation which belongs to some "type". There are three | "types" which happen to have a "direct" mapping to the three | "kinds", so this mapping is used *by default*. However in | general the mapping between the node "type" and its "kind" | is up to the application, and can be specified using | implicit/explicit types. Ok. This is the issue. I no longer think of it as implicity *type*, but as an implicit *kind*. | Where's the need for an additional syntax/concept/construct? As I said... this *simplifies* things by merging all of our advanced kinds (block,flow,quote) into other kinds (base64,numeric). In short, I see this distinction currently between "implicit types" and "indicators" to be not so good of an abstraction (and certainly not that easy to explain and/or implement). If you would like... I'll spend some time this weekend rewriting the productions to make it more clear what I'm proposing. That being said... the ^ doesn't have to be added; but it provides for a nice explicit way for user-defined syntax parsers. Note that parser <> type. As I can have a base64 image -- base64 is the syntax module and org.yaml.imgage.jpeg is the class. | About the MIME issue... Ok. We drop the notion of Mime compatibility. Clark |