[Swift-devel] Re: [Swift-user] assigning file variables

[Ben Clifford]

On Thu, 26 Feb 2009, Michael Wilde wrote:

> But thats one of the critical things here. I seem to bump into this 
> limitation frequently. Does language consistency require these 
> limitations on setting mappings, or is it an implementation issue that 
> can be lifted? Is it the case that mapping does not affect data flow 
> semantics?

>From a high level perspective, I don't think the language requires much 
about what is mapped where and based on what.

The present implementations of the mappers and the framework surrounding 
those mappers compel stricter requirements.

For example, at present, an entire data structure rooted at some variable 
declaration is regarded as either "not mapped" or "mapped" in its entirety 
- that is either the mapper is not yet initialized, and so any attempts to 
ask it about the data structure it maps must be deferred; or it is 
initialized and therefore can answer authoritatively about any part of 
that data structure.

This is pretty much what is meant by "Swift does not have streaming 
mappers".

What you propose, being able to map some subpiece of a data structure 
programmatically, ties in closely with the 'streaming mapper' concept, I 
think. The 'stream of new things' comes perhaps from some on going 
external process, some deliberate rate limiting or from on-going 
evaluation of other pieces of SwiftScript that come up with new mappings.

> For starters (and feel free to move this to a new thread), do you feel
> comfortable with the current model of var, dsHandle, and by-value-like
> assignment?
> 
> I would like to see a more Java-like model with a var being a typed pointer or
> scalar value holder, and structs and arrays being dynamic objects, and files
> being special vars with mapping and state.

That's very much what SwiftScript has now. Can you describe what you 
percieve to be the salient differences?

> I dont feel that we have yet adequately described the model, neither for a CS
> paper *nor* for the programmer.  I think that a good start is to write a data
> model description (in the user guide, in a detailed "skip this on first
> reading" section, that specifies the data model in
> language-reference-specification fashion).

Yes, I think getting a more rigorous description of what actually happens, 
warts and all, would be useful.

I think targetting such a description as a CS paper is the wrong thing to 
aim for is the wrong way to go - we need to be adding copious warts and 
ugliness to the description making it mind numbingly tedious to read, not 
coughing politely and deleting such paragraphs to make a paper that a 
wider audience is interested in.

--