> * 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?
Speaking for myself, I would imagine filing this away as a possible future idea, should people find the unified form confusing over time. I'd at least mention it in the commit message for this change; possibly filing a feature request future for it (one that makes it clear in the body that it's an optional concept and not necessary). > * _isPrimitiveType: I will retire and replace with use-specific queries. After sending my last mail, I've been working on a side exploration of what the constraints on the uses of _isPrimitiveType() in casts have been about. It seems that for many core casts, we implement them in the compiler; but that for a few (complexes and imaginaries, primarily), we implement them in module code, for better or worse. I've got a patch that I'll send you as food for thought in a separate mail. > 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. I remain confused then. By your definition of the three (presumably disjoint?) categories, I would expect isValue() to return: * 'false' for x declared 'var x: real' * 'true' for '1.2' * and possibly 'true' for y declared 'param y: real = 1.2;' * and I'm not sure what for z declared 'const z: real = 1.2;' (which also matches my intuition from the name). But you seem to be saying that it would return true for all four. To me what you're describing sounds more like 'hasValue()' (i.e., it either is a value or it stores a value). Personally, given my confusion and lack of scenarios for when I would want isValue(), I'd drag my feet, stick to isType(), isParam(), (and perhaps isConst()) and wait for the demand for something else to come along (and perhaps we should wait for that demand for isConst() as well...). > * My plans for the following are: > > _isSimpleScalarType() -- leave alone. other suggestions? If I'm not missing anything and this is used in only one place in IO.chpl then I think the call should be eliminated and that its definition should be inlined into its one use. > _isSimpleIoType() -- leave alone, I don't know what it means > _isIoPrimitiveType() -- ditto As long as we're taking a pass over this stuff, I think that anything that's "left alone" should get a chpl_ prefix added to use the more current way of marking something as reserved for developers. > * 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. OK, thanks. ------------------------------------------------------------------------------ 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
