Hi Vass: 1. I think the type query functions are fairly comprehensive and well-named. I take it you had no specific proposal to add or subtract from this set.
2. I think it's a good idea to keep the names of type query functions to be applied to type expressions versus those to be applied to run-time variables. Blurring the distinction between types and values would seem to be encouraging mindless programming. A counterargument would be that enforcing unnecessary distinctions will negatively impact productivity. But while I believe that the distinction between a param (compile-time value) and a var (run-time value) is unimportant, I still think the programmer should know (and be forced to be aware of) the difference between a value and a type. 3. I think a better name for _isPrimitiveType() would be isFundamentalType(). It is intended to capture types that are defined internally by the language, and to distinguish these from types that are provided by library modules and user code. chpl_isCertainSimpleType() does not say which simple types are in the set and which are not. If the name cannot be more precise than "certain" or "selected", the predicate ought to be removed entirely. The user can select for himself the types he wishes to capture (with all due precision). THH ________________________________________ From: Vassily Litvinov [[email protected]] Sent: Monday, July 07, 2014 4:04 PM To: chapel-developers Subject: [Chapel-developers] RFC regularize is...Type() functions Hello developers, I would like to regularize the various is...Type() functions currently defined in a few Chapel standard modules and promote them for general availability. PART 1: I'd like feedback on the following set of functions - whether they are OK in terms of naming, functionality, etc. They all are param functions, returning true if the property holds, false otherwise. // The following functions correspond to the list of types in the spec. isVoidType isBoolType isIntType // int(*) isUintType // uint(*) isRealType isImagType isComplexType isStringType isEnumType isTupleType isClassType isRecordType isUnionType isRangeType isDomainType isArrayType isSyncType isSingleType isAtomicType // The following functions combine several of the above. isPrimitiveType // primitive types, as defined by the spec, namely: // void, bool, int, uint, real, imag, complex, string isIntegralType // int, uint isNumericType // int, uint, real, imag, complex isFloatType // real, imag -- is this a good name for such a query? // While there, add these meta-queries. isType // any type isValue // any value, including param values isParam // a param value Most of the above queries are already implemented. My proposal is about their names and making them part of the standard library. PART 2: A related question is: do we want to have "Type" in those functions' names? For example: Option 1: // is 'arg' a range type? an error if invoked on a value proc isRangeType(type arg) ... // is 'arg' a range value? an error if invoked on a type proc isRange(arg) ... Option 2: // is 'arg' a range type or a range value? returns false if neither // ok to invoke on a value or on a type proc isRange(type arg) ... proc isRange(arg) ... Considerations/votes in favor of one or the other? Assume that this principle will be applied to all is...Type functions above. PART 3: I will also rename proc _isPrimitiveType -> proc chpl_isCertainSimpleType, unless there are objections. This is to avoid ambiguity - technically it is not checking whether the argument is a primitive type, in the Chapel sense of "primitive". Vass ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
