custom type tests

custom type tests

[Drew Adams]

Does anyone know of code that deals with custom types in such a way that you
could test whether the type of a user option is compatible with a given
type?

For instance, if a variable `foo' is of type `regexp' and `bar' is of type
`color', I would want a test for compatibility with type `string' to return
non-nil for each, since a regexp and a color are strings.

As another example, if `foo' is of type `string', I would want a test for
compatibility with type (choice (const nil) string) to return non-nil, since
a string is in the union of all strings and {nil}.

Any existing code that deals with subtypes this way? Any code that deals
with custom type tests, other than just `custom-variable-type' and (get __
'custom-type)?

I'm looking for code that would allow flexible type tests - subtyping, if
possible (see above), but also not differentiating between types such as
(choice (const :tag "toto" nil) string) and (choice (const nil) string) or
between (choice (choice (const nil) string) and (choice string (const nil)).

Any pointers to pertinent code or doc are appreciated. Think of it this way:
Given a custom type, how can I find all user options that have that type (or
a compatible type, such as a subtype)?

Re: custom type tests

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Does anyone know of code that deals with custom types in such a way that you
> could test whether the type of a user option is compatible with a given
> type?
> 
> For instance, if a variable `foo' is of type `regexp' and `bar' is of type
> `color', I would want a test for compatibility with type `string' to return
> non-nil for each, since a regexp and a color are strings.
> 
> As another example, if `foo' is of type `string', I would want a test for
> compatibility with type (choice (const nil) string) to return non-nil, since
> a string is in the union of all strings and {nil}.
> 
> Any existing code that deals with subtypes this way? Any code that deals
> with custom type tests, other than just `custom-variable-type' and (get __
> 'custom-type)?
> 
> I'm looking for code that would allow flexible type tests - subtyping, if
> possible (see above), but also not differentiating between types such as
> (choice (const :tag "toto" nil) string) and (choice (const nil) string) or
> between (choice (choice (const nil) string) and (choice string (const nil)).
> 
> Any pointers to pertinent code or doc are appreciated. Think of it this way:
> Given a custom type, how can I find all user options that have that type (or
> a compatible type, such as a subtype)?


I do not know exactly, but the :match property of a widget has the 
function you need. Look in cus-edit.el and wid-edit.el how this function 
is built. It does not look very easy to find out however.

Re: custom type tests

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Drew Adams wrote:
>> Does anyone know of code that deals with custom types in such a way 
>> that you
>> could test whether the type of a user option is compatible with a given
>> type?
>>
>> For instance, if a variable `foo' is of type `regexp' and `bar' is of 
>> type
>> `color', I would want a test for compatibility with type `string' to 
>> return
>> non-nil for each, since a regexp and a color are strings.
>>
>> As another example, if `foo' is of type `string', I would want a test for
>> compatibility with type (choice (const nil) string) to return non-nil, 
>> since
>> a string is in the union of all strings and {nil}.
>>
>> Any existing code that deals with subtypes this way? Any code that deals
>> with custom type tests, other than just `custom-variable-type' and 
>> (get __
>> 'custom-type)?
>>
>> I'm looking for code that would allow flexible type tests - subtyping, if
>> possible (see above), but also not differentiating between types such as
>> (choice (const :tag "toto" nil) string) and (choice (const nil) 
>> string) or
>> between (choice (choice (const nil) string) and (choice string (const 
>> nil)).
>>
>> Any pointers to pertinent code or doc are appreciated. Think of it 
>> this way:
>> Given a custom type, how can I find all user options that have that 
>> type (or
>> a compatible type, such as a subtype)?
> 
> 
> I do not know exactly, but the :match property of a widget has the 
> function you need. Look in cus-edit.el and wid-edit.el how this function 
> is built. It does not look very easy to find out however.


Thinking about it again, the code is in set-variable. Look for :match 
there.

RE: custom type tests

[Drew Adams]

> >> Does anyone know of code that deals with custom types
> >> in such a way that you could test whether the type of
> >> a user option is compatible with a given type?
> >>
> >> For instance, if a variable `foo' is of type `regexp'
> >> and `bar' is of type `color', I would want a test for
> >> compatibility with type `string' to return non-nil for
> >> each, since a regexp and a color are strings.
> >>
> >> As another example, if `foo' is of type `string', I
> >> would want a test for compatibility with type (choice
> >> (const nil) string) to return non-nil, since a string
> >> is in the union of all strings and {nil}.
> >>
> >> Any existing code that deals with subtypes this way?
> >> Any code that deals with custom type tests, other than
> >> just `custom-variable-type' and (get __ 'custom-type)?
> >>
> >> I'm looking for code that would allow flexible type
> >> tests - subtyping, if possible (see above), but also
> >> not differentiating between types such as (choice
> >> (const :tag "toto" nil) string) and (choice
> >> (const nil) string) or between (choice (choice (const
> >> nil) string) and (choice string (const nil)).
> >>
> >> Any pointers to pertinent code or doc are appreciated.
> >> Think of it this way: Given a custom type, how can I
> >> find all user options that have that type (or a
> >> compatible type, such as a subtype)?
> >
> > I do not know exactly, but the :match property of a
> > widget has the function you need. Look in cus-edit.el
> > and wid-edit.el how this function is built. It does
> > not look very easy to find out however.
>
> Thinking about it again, the code is in set-variable.
> Look for :match there.

Thanks for checking and replying.

No, I don't see that, however. That code is about checking that a given
value is of the right type.

I want to compare two types themselves, to see if they are compatible (one
is <= the other). I don't want to check the type of a value.

I want to know if the custom types defined for two variables are compatible:
whether the type defined for var1 is compatible with the type defined for
var2. If the type of var1 is `regexp' and the type of var2 is `string', for
example, then the types are compatible (var1's type <= var2's type) -
regardless of the current values. Testing current values is not sufficient.

It's really what I said before:

> >> Given a custom type, how can I find all user options that
> >> have that type (or a compatible type, such as a subtype)?

By "have that type", I meant "are defined with that type", not "have values
of that type".

Re: custom type tests

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> Thinking about it again, the code is in set-variable.
>> Look for :match there.
> 
> Thanks for checking and replying.
> 
> No, I don't see that, however. That code is about checking that a given
> value is of the right type.
> 
> I want to compare two types themselves, to see if they are compatible (one
> is <= the other). I don't want to check the type of a value.
> 
> I want to know if the custom types defined for two variables are compatible:
> whether the type defined for var1 is compatible with the type defined for
> var2. If the type of var1 is `regexp' and the type of var2 is `string', for
> example, then the types are compatible (var1's type <= var2's type) -
> regardless of the current values. Testing current values is not sufficient.
> 
> It's really what I said before:
> 
>>>> Given a custom type, how can I find all user options that
>>>> have that type (or a compatible type, such as a subtype)?
> 
> By "have that type", I meant "are defined with that type", not "have values
> of that type".


Ah, sorry, I see. I think that would require some work, especially since 
the same type may be expressed in several ways in custom.

Re: custom type tests

[Stephen J. Turnbull]

Lennart Borgman (gmail) writes:
 > Drew Adams wrote:

 > > It's really what I said before:
 > > 
 > >>>> Given a custom type, how can I find all user options that
 > >>>> have that type (or a compatible type, such as a subtype)?
 > > 
 > > By "have that type", I meant "are defined with that type", not "have values
 > > of that type".
 > 
 > 
 > Ah, sorry, I see. I think that would require some work, especially since 
 > the same type may be expressed in several ways in custom.

This seems to be an instance of the unification problem, which is a
well-known NP-complete (ie, very expensive to compute even with an
optimal algorithm) problem.  It's very probable that Emacs
customizations (at least in practice) satisfy restrictions that make
efficient (enough) computation possible, though.  Algorithms are
available, eg Aho Sethi Ullman "Compilers" (aka the Dragon Book) gives
some elementary ones.

The main problem would be figuring out all the rules for constructing
subtype implementations, since some of them would never be used by a
human writing a defcustom and are sparsely documented.