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

[Michael Wilde]

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
>>>>>>>
>>>
> 
>