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

[Mihael Hategan]

On Fri, 2007-10-05 at 09:05 -0500, Michael Wilde wrote:
> please clarify - briefly is fine but your meaning is unclear.
> are you saying:
> a) these parts of the language are fine as-is?
> b) these issues should be addressed but are low priority?
> c) you have an idea of how to address these issues technically?
> d) you dont but have an idea of how to get there socially?
> e) none - please specify

f) none of the above.

These questions were already answered in previous discussions. Some
repeatedly. So I'm not sure what you're looking for here. The answers
won't change.

> 
> - Mike
> 
> On 10/5/07 8:52 AM, Mihael Hategan wrote:
> > 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
> >>>>>
> >>>
> > 
> > 
>