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

[Mihael Hategan]

You're arguing against a different matter. I did not say we shouldn't
solve these problems. We should.

However we should not keep having the same discussion over and over.

On Fri, 2007-10-05 at 09:48 -0500, Michael Wilde wrote:
> Sorry, I'm not going to accept f) as an answer.
> I'm going to argue hard that some things should change.
> 
> We clearly need a better way to integrate tabular data - both from files 
> and external app returns - with datasets as in the code examples we have.
> 
> We clearly have issues in variable/collection closing that cause 
> (unpleasantly) surprising behavior.
> 
> We need ways to make mapping easier. And we certainly need to more 
> clearly explain to users how the mapper model works (although Ben's 
> recent steps are a huge step forward on this)
> 
> I think out of this list, and by analyzing and cleaning up existing code 
> examples, we can identify the problems that are both highest prio and 
> lowest cost to fix, and see where we stand on the rest.
> 
> But there is clearly need for language assessment and discussion.
> I expect some of the current answers to change, sorry.
> 
> - Mike
> 
> 
> On 10/5/07 9:11 AM, Mihael Hategan wrote:
> > 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
> >>>>>>>
> >>>
> > 
> > 
>