Re: [q-lang-users] Query about Type Tests (Complex and Rational).

[Rob H. <hub...@gm...>]

John Cowan wrote:
> Albert Graef scripsit:
>   
>> I don't think that this is a good idea. The other type checking 
>> predicates isxyz for a type Xyz all follow the scheme that the predicate 
>> is equivalent to the type guard, so iscomplex should follow that 
>> principle, too (that wasn't the case previously, but previously there 
>> was no Complex type and iscomplex was a semantic predicate).
>>     
I'd be happy with that. I was trying to get a handle on what the 
convention was.
> I'm not sure I see the utility of this.  Granted that non-numeric
> types work this way, why should the numeric ones?  I'd favor a scheme
> in which you use the guards for syntactic types and the isX predicates
> for semantic types.  What can you do with iscomplex that you can't do
> with a type guard?
>
>   
This?

func X = func1 Temp
    if iscomplex Temp
    where Temp = func2 X;
> Or if you think this is essential, how about going to a scheme in which
> isX means "is it the representation type" and "is_X_number" means "does
> it actually fit the model for that kind of number"?  So iscomplex would
> be true only of objects of type Complex, but is_complex_number would be
> true of any number (except hypothetical quaternions and octonions to be
> added later).
>   
If you decide to go down this route, then what about "isComplexType" 
versus "isComplexValue"? (But shorter.)
Or e.g. "isComplex" versus "inComplex". (Perhaps these are too similar.)