Hi Vass: My suggestion that isRangeType and isRangeValue etc. be separate was uncharacteristically cautious, so I rescind that criticism.
If the implementation if isRange() [etc.] is naturally implemented as the composition of isRangeType() || isRangeValue(), then we may as well expose the component functions to the user as well. (This would seem to be sensible way to decompose the definition of the type/value-ambivalent functions.) I don't like the word "Simple" in "isSimpleScalarType", because it can mean many things. In this case what it actually means is "not Complex" in the particular sense of "not a complex number". The only place it is used in the modules is in the definition of isSimpleIoType() where it is ORed with isComplexType. That is, the specific exclusion of complex numbers is immediately undone. Therefore, for that particular case, I recommend providing isScalarType() (plus possibly isScalar() and isScalarValue()) -- defining it to include isComplexType() -- and then updating the implementation of isSimpleIoType() so that its semantics remain unchanged. I'm OK with the other names you have proposed. THH ________________________________________ From: Vasily Litvinov [[email protected]] Sent: Tuesday, July 08, 2014 7:17 PM To: Brad Chamberlain Cc: chapel-developers Subject: Re: [Chapel-developers] RFC regularize is...Type() functions To summarize the thread w.r.t. action items: * isRange vs. isRangeType etc.: I feel we have enough votes for isRange, so I'll go with that. I can also provide the more specific isRangeType() and isRangeValue(), in addition to isRange(), and analogously for the other queries. Do people feel this would be potentially useful, or on the contrary excessive? * _isPrimitiveType: I will retire and replace with use-specific queries. * chpl_taskID_t - I will resolve off-list. Answering Brad's questions: * Q: What is a "value"? A typical language definition deals with these key categories: types, values, and variables. A variable is storage; a value is what is stored in a variable (semantically speaking), and a type is a property of a value or a variable or an expression. Therefore, isValue(x) is the same as !isType(x). Is it valuable, then? These two are pretty much equivalent in my view, it would be odd to have one and not the other. * isConst() is a legitimate query on an l-value - think 'ref' vs. 'const ref'. If I can implement this easily, I will. * My plans for the following are: _isSimpleScalarType() -- leave alone. other suggestions? _isSignedType() --> isInt() _isUnsignedType() --> isUint() _isSimpleIoType() -- leave alone, I don't know what it means _isIoPrimitiveType() -- ditto * Q: What should the behavior be for user type aliases whose underlying definitions satisfy one of these predicates? For a type alias that is intended to be interchangeable with the aliasee, each predicate should return the same on both. For a type alias that is intended to be something entirely different, the predicates we discuss should all return false (except for the general isType); we should introduce a new predicate isAliasType() to return true. Right now I think Chapel supports only the former. I do not plan to do anything special w.r.t. type aliases at the moment. 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
