I'm not crazy about the name (or maybe role) of the following query
because it doesn't seem obvious/self-documenting to me what a "value" is
(to my recollection it's not something we define in the language, and I'm
not sure it's something I want to define):
> isValue // any value, including param values
A literal seems pretty clearly a value. Is a variable? What about a
const? What about a variable whose semantics tend to be more
reference-oriented than value-oriented? What about a 'ref' variable
(upcoming feature). In what cases does isValue() differ from !isType()?
If it doesn't, then is it valuable?
> isParam // a param value
This suggests to me we may want to have 'isConst' as well (?).
> 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.
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?
> 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 ...?
Looking at the uses to determine why it has this definition, though, seems
to turn up the following cases:
* casts between primitive types (ChapelBase.chpl, String.chpl): I think we
intended to support casts between any primitive types, so this seems
like it could/should use the same isPrimitiveType() that a user would
* optimizations of array copies (ChapelArray.chpl): I would guess that
this query should be something more related to whether the type results
in dense, compact, stack-oriented memory. I.e., I would guess that
complexes would be fair game here and that strings would not be (and
that the optimization is simply being overly conservative in the first
case and would be incorrect in the second). Enums also seem like fair
game here, as do typedefs of other types that are fair game.
* 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...
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
