Saturday, February 25, 2012

A decision point on Lazy J

I have a conflict between human convenience and strict computer rules regarding Lazy J. Human convenience should prevail. Consider keywords typed in the human. He has already decoded tem, they are immediates, not symbols. {Key1,Key2} means find key1 or Key2 the exact text, as opposed to $Key1 or $Key2. It fouls me up when the default typing is keyword instead of symbol, too many dollar signs. But I can live with it, as a developer, if it lets the client type bare keywords with comfort. I still like the idea that a quote signifies a bags of keyword, that would be a great compromise.

This is all looming on the horizon, now that we have a complete system with an incomplete search and construct language. Right now the nest thing on my todo list is he Ugly Handler, what is the grammar when two Qsons are run through the execution machine, as opposed to just moving around. I have to work the language anyway to get access to my System calls. But that means I have to dollar up all ny system call syntax. We could say that the symbol table reports back that this must be immediate by having no entry, but the machine cannot rely on that when it runs autonomously. This si where the NoSql crowd can jeer, because I cannto do anything in defaul grammar that is not natural to sqlite3. When the client give the machine G1{Myname,mycar,myaddres}, then Sqlite can run a match, even nested graph matching right off of that in table Qson form, but it cannot do look ups. I could write a call back, but really, let the client type in bare key words as default. Since we know when a symbol is created or redefined, the : tells us, we are better to silently flag the symbols, and leave the unflagged as default bare key word.

Pushing this thing into territory I am still learning about.

No comments: