Re: Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

2022-09-11 Thread Martin D Kealey
On Wed, 7 Sept 2022 at 18:13, Yair Lenga wrote: > Thanks for providing feedback and expanding with new ideas. > > I believe the summary is: > > ${a.key1.key2} - Static fields > ${a.key1.$key2} - Mixed dynamic/static, simple substitution. > ${a.key1.{complex.$key2}} - For complex keys that may co

Re: Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

2022-09-07 Thread Yair Lenga
Another comment: While it’s important to use “natural” access, I believe it is ok to have a command to set values inside the h-value. It does not have to be supported as part of …=… , which has lot of history, rule, interaction with env var, etc. I think something like: hset var.foo.bar=value

Re: Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

2022-09-07 Thread Yair Lenga
Thanks for providing feedback and expanding with new ideas. I believe the summary is: ${a.key1.key2} - Static fields ${a.key1.$key2} - Mixed dynamic/static, simple substitution. ${a.key1.{complex.$key2}} - For complex keys that may contain anything ${a.key1[expr].key2] - expr is evaluated in num

Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

2022-09-07 Thread Martin D Kealey
Some things do indeed come down to personal preference, where there are no right answers. Then Chet or his successor gets to pick. Keep in mind that most or all of my suggestions are gated on not being in backwards-compatibility mode, and that compat mode itself would be lexically scoped. With tha

Re: bug-bash Digest, Vol 238, Issue 2

2022-09-05 Thread Yair Lenga
Martin brings up several good points, and I think it's worth figuring out the direction of the implementation. Bash currently does not have good syntax for H-values, so a new one is needed. It does not make sense to have a completely new one, as there are few accepted syntax - python, JavaScript, P

Re: bug-bash Digest, Vol 238, Issue 2

2022-09-05 Thread Martin D Kealey
Rather than var[i1.i2.i3] I suggest a C-like var[i1][i2][i3] as that avoids ambiguity for associative arrays whose keys might include ".", and makes it simpler to add floating point arithmetic later. I would like to allow space in the syntax to (eventually) distinguish between an object with a fai

Re: bug-bash Digest, Vol 238, Issue 2

2022-09-04 Thread Yair Lenga
Putting aside the effort to implement, it might be important to think on how the h-data structure will be used by users. For me, the common use case will be to implement a simple, small "record" like structure to make it easier to write readable code. Bash will never be able to compete with Python/