Re: [Unicon-ldif] Can we implement table constants?

[Wade B. <sta...@yc...>]

Clint Jeffery writes: 

> 
>>   I was wondering how feasible it would be in Unicon to extend the list 
>>   constant format a little to product table constants (to probably something 
>>   like PHP's array format). 
> 
>>   Would people be interested in this? 
> 
> Yes, very.  You might define a bit of new syntax in unigram.y and translate
> it into conventional / older-style table calls, but I have also thought
> about extending the table() function to support initializations, which might
> make it easier to translate the extended syntax into efficient code. 
> 
> Having said that, we do have to be careful that the new syntax "fits"
> the language and doesn't introduce any parsing ambiguities.  What did
> you have in mind?

In PHP, arrays, lists and tables are all the one type. In Icon, this is not 
so, so PHP's approach of mixing keyed and keyless list elements was going to 
be difficult. The idea of introducing a tuple datatype was tempting, but 
far-reaching and that still leaves the problem of how to convert into a 
table a list constant that is only partly tuples. So, what if a table 
constant would *require* all elements to have matching keys? I judged that 
would probably be an acceptable limitation and it could be easily enforced 
in the parser. 

After thinking about valid character sequences, I came up with the 
following: 

newtable := [< "key1": "value1", "key2": "value2", "key3": "value3" >] 

Then I went looking for grammar tables. 

After rummaging in the files like src/common/tokens.txt, src/h/grammar.h and 
src/icont/tree.h, I figured out how to make icont parse this into some new 
node types and emit a new primitive that iconx would be able to put together 
into a table in much the same way it currently constructs list from list 
constants, but I haven't finished it yet so I don't have a patch for you. 

Where I was tinkering has the characteristic that the new literal type is 
down in the Icon code, not the Unicon code. I never, in fact, thought to 
look in the Unicon layer. Would it need to know? unigram.y looks like it 
would need to (why?). 

Wade.