> > As Gabe mentioned (and you've explained about) the term "type" > > is really confusing here. As you know, the R internals are all > > about SEXPs, TYPEOF(), etc, and that's what the R level > > typeof(.) also returns. As you want to use something slightly > > different, it should be different naming, ideally something not > > existing yet in the R / S world, maybe 'kind' ? > > Agreed - I've been using type in the sense of "type system" > (particularly as it related to algebraic data types), but that's not > obvious from the current presentation, and as you note, is confusing > with existing notions of type in R. I like your suggestion of kind, > but I think it might be possible to just talk about classes, and > instead emphasise that while the components of the system are classes > (and indeed it's implemented using S3), the coercion/casting > relationship do not strictly follow the subclass/superclass > relationships.I've taken another pass through (the first part of) the readme (https://github.com/r-lib/vctrs#vctrs), and I'm now confident that I can avoid using "type" by itself, and instead always use it in a compound phrase (like type system) to avoid confusion. That leaves the `.type` argument to many vctrs functions. I'm considering change it to .prototype, because what you actually give it is a zero-length vector of the class you want, i.e. a prototype of the desired output. What do you think of prototype as a name? Do you have any thoughts on good names for distinction vectors without a class (i.e. logical, integer, double, ...) from vectors with a class (e.g. factors, dates, etc). I've been thinking bare vector and S3 vector (leaving room to later think about S4 vectors). Do those sound reasonable to you? Hadley -- http://hadley.nz
> I'm now confident that I > can avoid using "type" by itself, and instead always use it in a > compound phrase (like type system) to avoid confusion. That leaves the > `.type` argument to many vctrs functions. I'm considering change it to > .prototype, because what you actually give it is a zero-length vector > of the class you want, i.e. a prototype of the desired output. What do > you think of prototype as a name?The term ?type system? in computer science is used in very different ways. What the note describes is not a type system, but rather a set of coercions used by a small number of functions in one package. Typically it refers to a set of rules (either statically enforced by the compiler or dynamically enforced by the runtime) that ensure that some particular category of errors can be caught by the language. There is none of that here. My suggestion would be to avoid ?type system?. "The short-term goal of vctrs is to develop a type system for vectors which will help reason about functions that combine different types of input (e.g. c(), ifelse(), rbind()). The vctrs type system encompasses base vectors (e.g. logical, numeric, character, list), S3 vectors (e.g. factor, ordered, Date, POSIXct), and data frames; and can be extended to deal with S3 vectors defined in other packages, as described in vignette("extending-vctrs?).? ==> The short-term goal of vctrs is to specify the behavior of functions that combine different types of vectors (e.g. c(), ifelse(), rbind()). The specification encompasses base vectors (e.g. logical, numeric, character, list), S3 vectors (e.g. factor, ordered, Date, POSIXct), and data frames; and can be extended to deal with S3 vectors defined in other packages, as described in vignette("extending-vctrs?). and so on. -j
On Thu, Aug 9, 2018 at 4:26 PM jan Vitek <vitekj at icloud.com> wrote:> > > I'm now confident that I > > can avoid using "type" by itself, and instead always use it in a > > compound phrase (like type system) to avoid confusion. That leaves the > > `.type` argument to many vctrs functions. I'm considering change it to > > .prototype, because what you actually give it is a zero-length vector > > of the class you want, i.e. a prototype of the desired output. What do > > you think of prototype as a name? > > > The term ?type system? in computer science is used in very different ways. > What the note describes is not a type system, but rather a set of > coercions used by a small number of functions in one package. > > Typically it refers to a set of rules (either statically enforced > by the compiler or dynamically enforced by the runtime) that ensure > that some particular category of errors can be caught by the > language. > > There is none of that here.I think there's a bit of that flavour here: vec_c(factor("a"), Sys.Date()) #> Error: No common type for factor and date This isn't a type system imposed by the language, but I don't think that's a reason not to call it a type system. That said, I agree that calling it a type system is currently overselling it, and I have made your proposed change to the README (and added a very-long term goal of making a type system that could be applied using (e.g.) annotations).> "The short-term goal of vctrs is to develop a type system for vectors which will help reason about functions that combine different types of input (e.g. c(), ifelse(), rbind()). The vctrs type system encompasses base vectors (e.g. logical, numeric, character, list), S3 vectors (e.g. factor, ordered, Date, POSIXct), and data frames; and can be extended to deal with S3 vectors defined in other packages, as described in vignette("extending-vctrs?).? > > ==> > > The short-term goal of vctrs is to specify the behavior of functions that combine different types of vectors (e.g. c(), ifelse(), rbind()). The specification encompasses base vectors (e.g. logical, numeric, character, list), S3 vectors (e.g. factor, ordered, Date, POSIXct), and data frames; and can be extended to deal with S3 vectors defined in other packages, as described in vignette("extending-vctrs?).Thanks for the nice wording! Hadley -- http://hadley.nz