Consider ${a[@]} semantics for List / Dict about oil HOT 5 OPEN

Keeping "external/unaffected" code part breakage low is what allows for gradual migration of code parts.

from oil.

The examples where tested in ysh, but of course it applies even more to using ysh-vars outside of procs in osh.

from oil.

So we now have value.BashArray and value.List which are different types

$ declare a=(1 2 3)

ysh ysh-0.19.0$ = a
<BashArray 0x7f3942b07190>


ysh ysh-0.19.0$ var li = :| 1 2 3 |
ysh ysh-0.19.0$ = li
(List 0x7f3942aee910)   ["1","2","3"]

However you can splice BashArray into a List:

ysh ysh-0.19.0$ var li2 = :| @li @a |
ysh ysh-0.19.0$ = li2
(List 0x7f3942b075a0)   ["1","2","3","1","2","3"]

It might be reasonable to go the other away, but it's not entirely trivial

e.g. "${a[@}"on avalue.List` could work but there's probably a bunch of stuff involved

I think we are going more from OSH data types -> YSH syntax, and not from YSH data types -> OSH syntax

from oil.

Sorry, I couldn't tell how hard or trivial it is.

But sure it would be useful to be able to use ysh vars from the ordinary shell language in osh. Actutally kind of expected you had included that in your thoughts, and that it would work, after reading your blogs about how unix/shell composes, and that ysh and procs are a continuation of that.

Procs can be called with the shell command language, they take shell variables but are not limited to them. So it seemed obvious to me that there would be a way to access the result of the enhanced procs (when using ysh vars) also through some compat shell mechanism for the composability. Very useful to make use of ysh code from osh/shell scripts.

from oil.

we now have value.BashArray and value.List which are different types

Ok, but is that a problem?

You gave a good example, showing procs can process bash variables with their ysh syntax (i.e. when sourced from osh). To afterwards access the results [EDIT: in newly created variables created by] ysh procs from osh, i.e. for interaction, osh code will also need at least the most basic access to ysh datatype variables (using shell compat syntax).

I don't see a reason for requiring to use the same data type internally.

(Well, now that I think about it, for ysh lists and dicts maybe? Could the new hashtable implementation for dicts also bring better search performance to lists? "if ... in list"? )

from oil.