thanks, there is alot for me to digest here. inlC2 looked promising but I can't seem to chain with it:
NB. OK 2 add inlC2 t _ 2 3 4 5 6 7 8 9 10 11 NB. not OK 3 add 2 add inlC2 t _ |value error: add | 3 add 2 add inlC2 t _ Some additional comments below: On Sun, Nov 8, 2015 at 1:09 PM, 'Pascal Jasmin' via Programming <[email protected]> wrote: >>It would be best, I think, if you paired up "to" on the right of the > > sentence with a word on the left of the sentence which terminates the > dsl expression. My verbal imagination fails me at the moment, so I'm > going to use "from" > > The style of taking locales as the y parameter and returning a locale is > pretty useful. It also applies to pointers in my BN(openssl) and Arrayfire > addons. It simplifies composition > > 2 (3 add add) tbl > > A "hard" global current locale switch has problems with errors in that if a > dsl is meant to be used interactively, an error can leave you in an > unexpected locale. > Agreed > verbs that take and return pointers or locales have the performance advantage > that even though you normally want to see the side-effected "pretty printed > data value" inside the pointer or object, when you > just want to chain operations, you're not slowed down by the value extraction > process. That is exactly what I'd like to do. I've been using my MicroJ quite a bit because of its native table type. It recently occurred to me that it could be possible to create a table object in J that wraps the raw data and provides convenient methods to work on it and then returns a pretty-printed result after the chain of operations is complete. I realize there is some overlap between what jd and jdb do. I could follow a similar path of using quoted strings to send the expressions to evaluate and then chopping them apart. This is how plot does it as well. Perhaps that's the most appropriate way since others have solved the dsl problem with it. The downsides to the quoted string are: nested quotes and the work to parse it out. The nested quotes problem could be easily solved by using a different quote identifier (e.g. double quote ") and parsing wouldn't be that bad. For parsing, an expression won't always take a single word, so I will probably need to implement some logic to pair nouns with their verb based on whether the verb exists in a whitelist (I think this is along the lines of how plot does it) Example: 'select ("name";"age") from tbl' vs 'select "name" from tbl' Putting aside the nuisance of quoting column names, which can be automatically quoted based upon some other rules: The parser would work from right to left and find the next word that it's the verb whitelist. It would take all values from the right and use that as the operands to the verb and then pop that in the stack for the next verb. This description sounded much like J's parser so it made me question whether I should to reimplement it or try to just let J do it directly ;: 'select ("name";"age") from tbl' rplc '"';'''' +------+-+------+-+-----+-+----+---+ |select|(|'name'|;|'age'|)|from|tbl| +------+-+------+-+-----+-+----+---+ verb whitelist: 1. from, select 2. go from right to left: a. tbl not on whitelist, add to stack b. from on whitelist b1. invoke with stack (tbl) b2. replace stack with result of from tbl c. ) not on whitelist, add to stack d. 'age' not on whitelist, add to stack e. ; not on whitelist, add to stack f. 'name' not on whitelist, add to stack g. ( not on whitelist, add to stack h. select on whitelist h1. invoke select with ('name';'age') and result of from i. nothing left on queue, return stack ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
