[Swift-devel] Problem with @extractint?

[Mihael Hategan]

On Tue, 2007-10-09 at 20:09 -0500, Yong Zhao wrote:
> We had discussions about mapping functions vs mappers too. Essentially
> readdata is doing what a mapper (an advanced CSV mapper) should do. I am
> not sure whether this is the right direction though, as 'readdata' might
> just have been implemented as a specialized karajan function, instead of
> being a swift level mapper or mapping function.

It is a specialized karajan function, not a mapping function. Thing is,
I don't really like the special treatment that mapping functions get. I
don't think there's a need for such special treatment, because it isn't
needed. Unless I'm missing something.

> 
> So for mapping, there are two choices:
> either the type info is passed in to the mapping, which will try to
> interprete the values according to the types/member-types passed in.
> 
> or the mapping is type agnostic, and extractint, extractstring,
> extractdata, whatever is applied to a generic value to get the actual
> typed data back. I can see cases where this may not work well.
> 
> Yong.
> 
> On Tue, 9 Oct 2007, Mihael Hategan wrote:
> 
> > On Tue, 2007-10-09 at 13:22 +0000, Ben Clifford wrote:
> > > The bit of kml that does the assignment is run in a sequential bit that
> > > sets up variables, before any of the parallel stuff happens (that usually
> > > consists of procedure calls, and is the part that ends up being evaluated
> > > in data dependency order rather than source text order).
> > >
> > > It makes sense to allow what you want to do, I think.
> >
> > There was some discussion about removing the @ sign in front of built-in
> > functions. There is no need for the distinction, and, apparently, it
> > does cause problems.
> >
> > >
> >
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
> >
>