skip to main |
skip to sidebar
Since so many key parts of the system require both representation and querying, I've been working on building out the language specs for building them, and specifying local indexing structures to hold the items and handle the queries. This will flow nicely from one activity to the next: if I have a representation language, I can build out the parsers and also start building out content. If I have parsers, I can start build out parse-tree representations and make sure they are robust against errors (which will be critical for the graphical query construction), and this leads on to query evaluation and navagation vis and graphical query construction, etc. In other words, it's a good inroad for the entire project, and allows me to skirt around the p2p platform question productively, for a demo.
As a result of working on the parser, I've actually had a chance to go back to the query language and improve it in two key ways:
- Make more components of various query constructs optional, making the query language more expressive with no extra work. :)
- Removing unusable keywords and ambiguous parses through "the literal idiom".
The literal idiom comes from the representation language work. It means: either you already know the ID for it, or you want to specify it in-place, parenthetically.
For example: suppose that you want to tag an existing hip hop chat room as being about hip hop (logical enough). Then, supposing the chat room is already created you type
(connection hip-hop-chat-about-hip-hop
hip-hop-chat
(tag hip-hop-tag hip hop))
creating the tag on the fly. Also note that the parenthesis is used to group multiple lines together.
So, you don't have to worry about tag being a keyword. The fact that it starts a literal is good enough. The same holds true for both representation and querying.
0 comments:
Post a Comment