Responses interspersed below ... On Tue, 8 Jul 2014, Brad Chamberlain wrote:
>> 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) ... >> >> ... > > I'm torn here, and curious for others' opinions. > > I've seen Tom's, and my counterargument to it (to the part of myself that > leans in that direction) is that I've often wished for a version of > writeln() that accepted types as well as values to avoid being forced to > call typeToString() manually in order to move from the type realm to the > value realm. So that might suggest that I'd like to just apply isRange() > to things without having to distinguish between whether they were types or > values. Similarly, I think C's sizeof() could be cited as an example of a > routine that accepts either (for better or worse). Chapel already brings > down many of the syntactic walls separating types from values -- is this > the logical extension of that? I was initially attracted to Option 1 because I think specificity and redundancy are both good things in code, but the sizeof() precedent does resonate for me, and I think Option 2 gives better readability. >> 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". > > I think it's appropriate to make this into a developer-oriented symbol for > the time being (i.e., add chpl_ as a prefix), but don't think the proposed > name is very helpful (I'm not defending the current name either, in saying > that). > > As currently written, I think its intent is to return true for types that > have a singleton value associated with them (where imaginary is noted as > being future work in the implementation), so a name reflecting that would > be better. E.g., chpl_isSingletonType() potentially or > chpl_typeRepresentsSingleValue() or ...? I like where you're pointed here, but chpl_typeRepresentsSingleValue() doesn't seem a good choice because of the potential for confusion with single vars, the siblings of sync vars. Maybe chpl_isSingleton(), and make it applicable to both types and non-types? Or perhaps instead provide chpl_isStructured(), the opposite? I suppose that depends on what programmers most often write when they use this. Or maybe having both is useful. > Looking at the uses to determine why it has this definition, though, seems > to turn up the following cases: > > ... > > * casts of task IDs (ChapelTaskTable.chpl): I'm having trouble believing > that this really wants/needs to be supported for all primitive types, > but can't think how this code path is exercised offhand... I don't see how it's used, either. I'll try removing it and see what happens. greg > > > The net result of this suggests to me that we should try to try to retire > this query and replace it with more accurate things. > > > > Some questions back at you: > > * what are your plans for the following: > > _isSimpleScalarType() > _isSignedType() > _isUnsignedType() > _isSimpleIoType() > _isIoPrimitiveType() > > * what should the behavior be for user type aliases whose underlying > definitions satisfy one of these predicates? > > > Thanks, > -Brad > > > ------------------------------------------------------------------------------ > 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
