5 ms·

The @pn(...) construct is very interesting, compelling, worth chewing on. I too have a pet DSL project for graphs. Think JSON, QML, etc. A central design prob

The @pn(...) construct is very interesting, compelling, worth chewing on. I too have a pet DSL project for graphs. Think JSON, QML, etc. A central design problem is divining a single syntax for both "groves" (nested objects decorated with key/value pairs) and tabular data. Asked another way: How would you inline CSV snippets within JSON? Parenthesis are used for function parameters. Curly brackets are used for composition: parent { child { key value, key value } } Square brackets are used for arrays: parent { array [1 2 3] }} How to simply encode tables (matrices)? Nested arrays? Like: table [ [1 2 3] [4 5 6] ] Is there another character or lexeme to use? Maybe delimit rows with pipe char? Like [ 1 2 3 | 4 5 6 ]

samatman 4y ago
I'd suggest not painting yourself into a corner where your map has to be either key/value or an array. Lua got this right, most other languages didn't. It's an anti-feature, especially from a data modeling perspective. Treating indices as implicit is good, pretending integer indices are special, and must be separated from all other sorts of mapping, is not. Consider that Lua can express XML without making up a fake key for children: {tag = xml, attr = {...}, child1, child2, child3}
- specialist 4y ago
  Totally agree. In my hobby DSL, those inlined childX are syntactic sugar for parent{ children=[child1, child2, child3]}. More generally, I remain uncomfortably undecided about named params (pairs) and indexed params. Esp wrt constructors. IIRC, I spotted a (hobby?) language that permitted both indexed params (matched in order per method signature) and named params, plus default values. So given "method( int a=10, int b=20)" you could invoke as "method( 1, 2 )", out of order like "method( b: 2, a: 1)" or partially like "method( b: 2 )". Riffing a bit, this could then allow passing a map of params to a method. Code construction wise, that looks like passing around a context object. I'll look at Lua again. (It's been a minute.) Thanks.

samatman 4y ago

I'd suggest not painting yourself into a corner where your map has to be either key/value or an array. Lua got this right, most other languages didn't. It's an anti-feature, especially from a data modeling perspective. Treating indices as implicit is good, pretending integer indices are special, and must be separated from all other sorts of mapping, is not. Consider that Lua can express XML without making up a fake key for children: {tag = xml, attr = {...}, child1, child2, child3}

specialist 4y ago
Totally agree. In my hobby DSL, those inlined childX are syntactic sugar for parent{ children=[child1, child2, child3]}. More generally, I remain uncomfortably undecided about named params (pairs) and indexed params. Esp wrt constructors. IIRC, I spotted a (hobby?) language that permitted both indexed params (matched in order per method signature) and named params, plus default values. So given "method( int a=10, int b=20)" you could invoke as "method( 1, 2 )", out of order like "method( b: 2, a: 1)" or partially like "method( b: 2 )". Riffing a bit, this could then allow passing a map of params to a method. Code construction wise, that looks like passing around a context object. I'll look at Lua again. (It's been a minute.) Thanks.