[Swift-devel] Re: passing types and variables in swift

[Mihael Hategan]

I have a different idea. Let's not do this.

On Fri, 2007-10-05 at 00:40 -0500, Michael Wilde wrote:
> I'm ready to start the seconds round of months of arm waving on mappers, 
> by the way. I hope we can cut it down to weeks.
> 
> Lets get the data model cleaned up before the user and code base grows 
> bigger, and we'll piss people off when we have to finally fix it.
> 
> I'm uncomfortable with aspects of:
> - what the language's set of values is (what Ben calls file-space)
> - when mappers run
> - what their role is (input vs output name determination)
> - what they return
> - syntax and semantics of initialization
> - how values are persisted (especially across restarts)
> - how values are returned from app calls
> - why "@filename" is special and what else is
> - why we should *not* be able to map output datasets until they have 
> been created
> - what creating (and closing) an output dataset means
> - how single-assignment and the functional model impacts this
> - issues of value-assignment dependence in blocks of assignment statements
> - how any of these issues might affect a provenance model
> 
> Not all of these are of equal importance.
> 
> I'm open to *how* this deliberation should take place if people have 
> suggestions.
> 
> Barring other suggestions, I propose to couch it as proposed revisions 
> to the tutorial examples or users guide, before implementing it.
> 
> Then implementation could start on the things we agree on, if we agree 
> that the things we dont agree on wont change the things we do. ;)
> 
> - Mike
> 
> 
> On 10/4/07 11:41 AM, Ben Clifford wrote:
> > yes.
> > 
> > that's why I'd rather they be hacks that look more like what they should 
> > end up like.
> > 
> > in order to get people doing things with this, there are going to need to 
> > be hacks (or prototype implementations, if you prefer) - months of 
> > abstract arm waving about how mappers work without concrete use has not 
> > resulting in a mapper API that does what some people want it to do; and 
> > months more of it won't, either.
> > 
> > On Thu, 4 Oct 2007, Mihael Hategan wrote:
> > 
> >> These hacks will bite us in the future.
> >>
> >> On Thu, 2007-10-04 at 15:46 +0000, Ben Clifford wrote:
> >>> i'd be inclined to grab the csv reading code from the csv mapper and see 
> >>> about making a @extractcsv function. It keeps code using it a little bit 
> >>> more like it would if mappers could support it, which is probably the way 
> >>> things will end up one day.
> >>>
> >>> On Thu, 4 Oct 2007, Michael Wilde wrote:
> >>>
> >>>> a hacky way to do this is first a loop to read the csv file into an array,
> >>>> then do a foreach over the array.
> >>>>
> >>>> i suspect we have the constructs (with @extractint) to do this; not sure if we
> >>>> can read the CSV into an array-of-structs that we can then foreach() over. But
> >>>> even if not, this will work using parallel arrays, and probably not be too
> >>>> unpleasing.
> >>>>
> >>>> lets try it.
> >>>>
> >>>> On 10/4/07 10:15 AM, Ben Clifford wrote:
> >>>>> you're the second person today to talk about reading in values from csv
> >>>>> files. maybe we should implement this.
> >>>>
> >>> _______________________________________________
> >>> Swift-devel mailing list
> >>> Swift-devel at ci.uchicago.edu
> >>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
> >>>
> >>
> > 
> > 
>