function to check type

[stdweird]

currently we have a bunch of code that does things like

function is_type_x = {
    if(something(ARGV[0]){ 
       return(false)
   }
   true;
}

type type_x = string with is_type_x(SELF);

this is typically used to make new types out of sub-types like

type type_xyz = string with {
    if(is_type_x(SELF)) return(true);
    ....
}

it would make a lot of sense to be able to test the type directly like

type type_xyz = string with {
    if(is_type(type_x, SELF)) return(true);
    ....
}

[stdweird]

@loomis forgot to ask: do you this is feasible?

[loomis]

Yes, it is feasible. Probably fairly straightforward to implement.

[stdweird]

to follow the internal code, and not cause any confustion, we settled on the function name validate to test a variable or value using the type validation code.

(is_type might suggest that you test if a variable (or path) is of a certain non-trivial type. this makes sense for the base types, but those already have dedicated functions like is_string. but not for variables, as you cannot bind variables to a type).

[ned21]

The problem with validate() is discovery -- how does someone know a particular function exists? If the only reason not to use is_type() is because someone might try to apply it to a variable then surely that is best handled in the documentation?

[stdweird]

@ned21 is_type is confusing because it does not check the type. maybe i should rename this issue to function to test value/variable using type validation? (if this makes no sense, then i didn't understand your question 😄 )

[ned21]

Yep, I think I am confused as to what this does. Can you provide a real code example instead of a generic one? Then I might understand it better. :(

[stdweird]

i see 2 main use cases:

• e.g. avoid the mess that is https://github.com/quattor/template-library-core/blob/master/pan/types.pan#L418

type type_ip = string with validate(type_ipv4, SELF) || validate(type_ipv6, SELF);

this would get rid of a bunch of functions that are only used because you currently cannot easily combine types (without refactoring or factroing out the validation code).

• other use case would be to use existing types in control structures
  e.g. assume type exists

type configured_nic = string with exists("/system/network/interfaces/" + SELF);

and then you can do things like

"/software/component/magic/ignore" = {
    foreach(nic;data;value("/harwdare/cards/nic")) {
       if(! validate(configured_nic, nic)) {
           append(nic);
       };
    };
};

and yes, you can define test functions that only return true/false for this and make more type x = string with test_function_x(SELF), but why not define the type and reuse the validation code?

[ned21]

The examples in the docs for the PR help explain this better. I can see why is_type is wrong since you are comparing (, ), to make sure validates as that type.

Validate remains a vague and overly general term which is very close to the existing valid statement. How about valid_type(type, value) ? I suppose that makes it sounds like checking type exists. Or apply_type(type, value) ? If we think of type as a function-like thing, that is effectively what is occurring here.

[stdweird]

@ned21 the pan book has the following wrt bind "If any of the content does not conform to the specified types, then an error will occur during the compilation.". maybe conform as function name? or is_conform, or conforms?
i'm bad with names, not proposing anything more 😄

@iliclaey feel free to make even more suggestions

[ned21]

+1 for accuracy of conform(type, element). It's not very discoverable if someone is grepping the book for type related functions but it ticks all the other boxes.

[jouvin]

What about is_valid(element, type)? At the end, this is to assess if a particular value is valid for a given type, if I followed correctly.

[iliclaey]

I think is_valid most clearly conveys what this function does