[Swift-devel] multiple arguments

[Mihael Hategan]

I'd say it's somewhat simpler.
Since data in Swift is recursive, non-leaf paths make sense by
themselves. What may not make sense is translating them to arguments to
an application. For example, passing a complex type as an argument to an
application is not well defined.

This can be restricted to, say, passing single values or arrays. In the
case of arrays, a space separated list is the implicit conversion
scheme, and functions could be provided to pass them as comma or
something-else-separated-lists. Passing the whole fringe as a list is a
possibility, too

When it comes to files, the scheme was a little simpler. @filename would
pass the file names of the fringe of a particular data tree. And
@filenames would do the same, but each leaf is a single argument.

On Fri, 2007-05-04 at 11:15 +0000, Ben Clifford wrote:
> 
> On Wed, 2 May 2007, Ben Clifford wrote:
> 
> > The semantics of these 'multiple valued' language constructs ([*] and how 
> > that passes through @filenames, for example) seems (still) quite poorly 
> > defined...
> 
> So I thought about this for a while.
> 
> I believe that the problem is there is a tension between C/Java like 
> structure/array access constructs (which is the syntax, but not 
> necessarily the semantics, that SwiftScript uses) and XPath-like XML 
> selection constructs (which is the semantics that let you write [*]).
> 
> That tension for the most part has not been a problem in the way that 
> we've written code so far, except in the presence of [*].
> 
> In the C/Java like model, an expression like
> 
>   v
> 
> or 
> 
>   v.image
> 
> identifies exactly one entity - in the first case to a variable v, in the 
> second case (assuming that v is a structure) to the unique element of the 
> structure in variable v that is called image.
> 
> In the XML/XPath model, we can make similar looking expressions, such as:
> 
>   v/image.
> 
> However, XPath expressions do not identify exactly one entity. XPath 
> expressions select nodes in an xml document; the identified entities are 
> XML nodes. But they are not constrained to selecting exactly one node. 
> They can select none, or they can select one, or they can select many.
> 
> Consider the XPath query:  v/image   when applied to the XML document:
> 
>  <v>
>   <image>theimage</image>
>   <header>theheader</header>
>  </v>
> 
> The above query will select the node <image>theimage</image>
> 
> However, consider the same query with the document:
> 
>   <v>
>    <image>theimage</image>
>    <header>theheader</header>
>    <image>more</image>
>    <foo>bar</foo>
>   </v>
> 
> The query will select two nodes. One of the nodes selected will be 
> <image>theimage</image> and the other will be <image>more</image>.
> 
> We have not uniquely identified an entity. We have selected several.
> 
> Similar things happen if we use what Swift refers to as arrays. Consider 
> an XML document like this:
> 
>  <lifeforms>
>    <foo>tree</foo>
>    <foo>plant</foo>
>    <foo>fish</foo>
>    <foo>dog</foo>
>  </lifeforms>
> 
> We can say lifeforms[1] and have the element <foo>plant</foo> uniquely 
> identified.
> 
> or we can say lifeforms[*] and have all four foo elements selected.
> 
> But what is the 'value' and 'type' of lifeforms[*], for the purposes of 
> feeding into other swift expressions?
> 
> When we say lifeforms[1] we can say the 'value' is the uniquely selected 
> node <foo>plant</foo>, and that lifeforms[1] evaluates to 
> <foo>plant</foo>.
> 
> But there is no definition of 'value' at the moment in SwiftScript for 
> expressions like this that select multiple expressions. And without a 
> definition of what the value of such an expression is, then we can't use 
> such an expression as a value to pass into some other bigger expression, 
> for example @filenames(lifeforms[*]).
> 
> One solution is to define a data type that can hold (as a single value) 
> the complete set of results (for example an unbounded sequence of XML 
> <any>, or in something more like SwiftScript syntax  any[]  ).
> 
> This would allows expressions such as lifeforms[*] to return a single 
> value (an instance of the above type, containing all of the selected 
> nodes) and would give a stronger formalisation of what expressions like 
> @filenames(lifeforms[*]) actually mean.
> 
> There may be other ways, which I'd be interested to hear about.
>