On Sep 27, 2013, at 12:43 PM, "Jonathan S. Shapiro" <[email protected]> wrote:
> This is way off topic, but most of you are language weenies, and you're a
> conveniently captive audience. :-)
>
> Various projects have had me working on "little languages" lately. For
> example, we developed a specialty language for describing registers in chips
> and how various functional units are arranged in a System on Chip CPU for
> Coyotos, and I'm now adapting it for something else.
>
> At the same time, I've been working on a parser generator. Not that the world
> needs another parser generator, but I want the BitC standard library to be
> written in BitC, and I want it to include a package that reads BitC input and
> produces a standardized AST. And of course, if you're going to produce a
> parser, you need to parse the specification file...
>
> In the course of this it occurred to me belatedly that there is an
> under-reported reason to use XML: at the price of making it much harder to
> write the input by hand, and reducing your ability to validate (or in some
> cases improving it), you get a nearly free ride on building a parser. At
> least where specialized "declaration" languages are concerned, most of the
> "little language" tools I can think of really can be done in XML, and an
> awful lot of the tools that read them can be implemented as XSLT scripts.
>
> You also get to leverage all of the other tools that have been done in XML,
> most notably document production tools.
>
> The catch is readability. Speaking for myself, I find:
>
> package IA32;
>
> struct PTE 32 {
> bit V 0; /* present (a.k.a. valid) */
> bit W 1; /* writable */
> bit USER 2; /* user-accessable */
> bit PWT 3; /* page write through */
> bit PCD 4; /* page cache disable */
> bit ACC 5; /* accessed */
> bit DRTY 6; /* dirty */
> bit PGSZ 7; /* large page (PDE only, only if CR4.PSE) */
> bit PAT 7; /* page attribute table */
> bit GLBL 8; /* global page (PDE, PTE, only if CR4.PGE) */
> field SW 9 11; /* software defined */
> bit PAT4M 12; /* page attribute table, 4M pages */
>
> field FRAME 12 31; /* page frame number */
> field FRAME4M 22 31; /* page frame number, 4M page */
> }
>
> To be infinitely more readable than something like:
>
> <package name="IA32"/>
>
> <struct name="PTE" width="32">
> <bit name="V" bit="31"/>
> ...
> <field name=SW" from="9" to="11"/>
> ...
> </reg>
>
> But this really might be one of those kinds of cases where the benefit of
> broad machine readability and interoperability is more important than
> developer convenience.
>
> A relaxed form of JSON (using unquoted identifiers) would almost work, or
> YAML, but the missing piece here is the fact that left brackets do not have
> types. I really have the sense that labeled braces here are a good thing. But
> I also want to be able to embed XML documentation strings, and every other
> labeled bracketing system I've seen turns out to be equally cumbersome.
>
> It really seems like this ought to be a simple problem with a general
> solution, but what I think is going on here is that I'm exploiting type
> inference. For example, I know that a "bit' must have two children: an
> identifier providing a name and a nat providing a position.
>
>
> This feels like it ought to have a good general solution, since it's really
> just another way of describing hierarchies. Just as an alternative notional
> syntax:
>
> PTE : struct 32
> V : bit 0
> W : bit 1
>
> and if you throw in some "smart white space processing" here (in the style of
> haskell), and you have prior schema knowledge about what things come in what
> order with what types, you can kind of see that there is a direct conversion
> to XML here. Or to JSON, or to any number of other formats.
>
> Anybody know of an existing solution? I think it's the type checking (a.k.a.
> validation) that has me playing with this.
I think S-expressions are a better compromise between writability and ease of
parsing than XML.
Geoffrey
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
