limited(<integer>, min: x, max: y), x > y 
Author Message
 limited(<integer>, min: x, max: y), x > y

Hi folks,

As Ashley Yakeley pointed out previously on comp.lang.dylan, the
description of subtype? in the DRM has some problems.

Specifically limited(<integer>, min: x, max: y) is problematic when x > y (The
minimum is greater than the maximum).

The DRM states:
"The following is an informal description of type relationships: The function
subtype? defines a partial ordering of all types.  Type t1 is a subtype of
type t2 (i.e., subtype?(t1, t2) is true) if it is impossible to encounter an
object that is an instance of t1 but not an instance of t2."

From the description in the DRM, an example like this:
  subtype(limited(<integer>, min: 1, max: -1), <duck>);
should return #t because it is impossible to encounter an instance of
limited(<integer>, min: 1, max: -1) that is not an instance of a <duck>.  (It
is impossible to encounter any instances of limited(<integer>, min: 1, max:
-1)).

One question to resolve is what kind of type
limited(<integer>, min: x, max: y) should return when x > y.  

I see a number of possibilities:
  Signal an error if min > max
  Return a new instance of a limited integer type, doing nothing special
  Return a special type, the empty-type, which is an instance of <type>
(or an instance of some subclass of <type>)

I favor signalling an error.  Allowing types to be created that have no
possible instances doesn't seem like a useful concept to me, and if I were
writing code that did that, I would prefer to see an error generated.  It
is reasonable for a
method to signal an error for certain ranges of input values (Example methods
of this type would be element or \/).  In general it seems such a thing should
be caught immediately, instead of being allowed to "propagate".

Specializing methods on an empty-type would not be very meaningful or
fruitful.

This is not a very important question because the problem will not
normally be encounter, but the type system is part of the foundation of
Dylan so maybe it would be good to resolve the issue.




Mon, 11 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

>Hi folks,

>As Ashley Yakeley pointed out previously on comp.lang.dylan, the
>description of subtype? in the DRM has some problems.

>Specifically limited(<integer>, min: x, max: y) is problematic when x > y (The
>minimum is greater than the maximum).

>The DRM states:
>"The following is an informal description of type relationships: The function
>subtype? defines a partial ordering of all types.  Type t1 is a subtype of
>type t2 (i.e., subtype?(t1, t2) is true) if it is impossible to encounter an
>object that is an instance of t1 but not an instance of t2."

>From the description in the DRM, an example like this:
>  subtype(limited(<integer>, min: 1, max: -1), <duck>);
>should return #t because it is impossible to encounter an instance of
>limited(<integer>, min: 1, max: -1) that is not an instance of a <duck>.  (It
>is impossible to encounter any instances of limited(<integer>, min: 1, max:
>-1)).

Notice that the quote from the DRM is explicitly an *informal* description.
The section "Limited Integer Type Protocol" describes the specific rules
that subtype? must obey for limited integer types, which only covers the
cases where both types are limited integer types.

Common Lisp's SUPTYPEP function description explicitly mentions that it's
not always possible for an implementation to determine true subtype
relationships (the most obvious case of this is when either type makes use
of the SATISFIES type specifier, which defines a type in terms of an
arbitrary predicate).  The function actually has two return values; when
the first value is false, the second value indicates whether it knows for a
fact that t1 is not a subtype of t2 or it simply couldn't determine the
relationship.  I would expect (subtypep '(integer 1 -1) 'duck) to return
NIL NIL.

I'm not sure how much this is used in practice.  Certainly the Dylan
designers knew of this CL feature, so I expect they decided that most
applications that deal with types don't need to distinguish between
"definitely isn't a subtype" and "might not be a subtype", and they didn't
bother including it.

Quote:
>One question to resolve is what kind of type
>limited(<integer>, min: x, max: y) should return when x > y.  

>I see a number of possibilities:
>  Signal an error if min > max
>  Return a new instance of a limited integer type, doing nothing special
>  Return a special type, the empty-type, which is an instance of <type>
>(or an instance of some subclass of <type>)

>I favor signalling an error.  Allowing types to be created that have no
>possible instances doesn't seem like a useful concept to me, and if I were
>writing code that did that, I would prefer to see an error generated.  It

You may be right that this type constructor should signal an error, but
don't equate that with the claim that types with no possible instances are
not useful.  Common Lisp has the type NIL, which is defined to be the empty
type (not to be confused with the type NULL, whose only member is the
object NIL).  An empty type is useful to avoid boundary problems; it's
analogous to zero-length arrays, which may not be able to hold anything but
may be necessary to pass to functions that need an array to iterate over.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.



Mon, 11 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

> Common Lisp's SUPTYPEP function description explicitly mentions that it's
> not always possible for an implementation to determine true subtype
> relationships (the most obvious case of this is when either type makes use
> of the SATISFIES type specifier, which defines a type in terms of an
> arbitrary predicate).  

From the Dylan "October 194 Design Notes"

"This change [to the type system] was based on the following principles:

* All Dylan types may be used as method parameter specializers.

* All operations on types are well-defined (for example, there is
no Common Lisp-like freedom for subclass? to return 3don't know2
instead of an answer)."

If limited(<integer>, min: x, max: y) where x > y.  
returns different types under different Dylan implementations, then the
type system is not well-defined and that would go against a design goal of
Dylan.

Quote:
> You may be right that this type constructor should signal an error, but
> don't equate that with the claim that types with no possible instances are
> not useful.
> An empty type is useful to avoid boundary problems;

Can anyone think of uses of an empty-type in the context of Dylan?

regards,



Mon, 11 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


Quote:
>>From the description in the DRM, an example like this:
>  subtype(limited(<integer>, min: 1, max: -1), <duck>);
>should return #t because it is impossible to encounter an instance of
>limited(<integer>, min: 1, max: -1) that is not an instance of a <duck>.  (It
>is impossible to encounter any instances of limited(<integer>, min: 1, max:
>-1)).

Thanks for raising this again. Perhaps the author of the DRM would care
to comment?

Quote:
>One question to resolve is what kind of type
>limited(<integer>, min: x, max: y) should return when x > y.  

>I see a number of possibilities:
>  Signal an error if min > max
>  Return a new instance of a limited integer type, doing nothing special
>  Return a special type, the empty-type, which is an instance of <type>
>(or an instance of some subclass of <type>)

>I favor signalling an error.  Allowing types to be created that have no
>possible instances doesn't seem like a useful concept to me, and if I were
>writing code that did that, I would prefer to see an error generated.

I prefer returning an empty type that followed Dylan's 'informal' type
protocol. I believe errors and exceptions should only be signalled when
there's no meaningful way to continue.

Bear in mind that the 'min' and 'max' values may be calculated rather
than fixed. I think it would be useful if

  instance?(p,limited(<integer>, min: x, max: y))

were guaranteed to be the same as

  (p >= x) && (p <= y)

without having to worry about x>y as a special case.

--
Wassail! (good health)
Ashley Yakeley, Seattle WA



Tue, 12 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


Quote:
>Notice that the quote from the DRM is explicitly an *informal* description.

It shouldn't be. But that's another issue...

Quote:
>The section "Limited Integer Type Protocol" describes the specific rules
>that subtype? must obey for limited integer types, which only covers the
>cases where both types are limited integer types.

The lack of mention of the possibility of empty limited types, given that
as specified they are at least anomalous, leads me to believe that the
issue was simply overlooked.

Quote:
>Common Lisp's SUPTYPEP function description explicitly mentions that it's
>not always possible for an implementation to determine true subtype
>relationships (the most obvious case of this is when either type makes use
>of the SATISFIES type specifier, which defines a type in terms of an
>arbitrary predicate).  

Obviously if you have 'SATISFIES' types, you can't in general determine
true subtype relationships: but Dylan allows only certain kinds of
'limited' types, etc., and it certainly _can_ determine true subtype
relationships. In fact, it has to so it can order methods for dispatch.

...

Quote:
>>I favor signalling an error.  Allowing types to be created that have no
>>possible instances doesn't seem like a useful concept to me, and if I were
>>writing code that did that, I would prefer to see an error generated.  It

>You may be right that this type constructor should signal an error, but
>don't equate that with the claim that types with no possible instances are
>not useful.  Common Lisp has the type NIL, which is defined to be the empty
>type (not to be confused with the type NULL, whose only member is the
>object NIL).  An empty type is useful to avoid boundary problems; it's
>analogous to zero-length arrays, which may not be able to hold anything but
>may be necessary to pass to functions that need an array to iterate over.

I agree.

--
Wassail! (good health)
Ashley Yakeley, Seattle WA



Tue, 12 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


Quote:

>>Notice that the quote from the DRM is explicitly an *informal* description.

>It shouldn't be. But that's another issue...

Ashley Yoakley has proposed that the informal relationship between subtype?
and set inclusion described on DRM p.50 be made the formal definition of
subtype?.  A similar proposal has been made regarding type disjointness.
Specifically, Ashley proposed that

  subtype?(T1, T2) <=> { for all x: ~instance?(x, T2) => ~instance?(x, T1) }

As Ashley (and others) has noted, a consequence of such a definition is that,
for example,

  subtype?(limited(<integer>, min: 3, max: 2), T)

is true for any type T.  That is, any type which can be shown to have no
instances is a subtype of any other type (the empty set is a subset of all
other sets).  (Note that an important point is that the phrase "which can
be shown to have no instances" requires a precise definition.)

The actual specification of subtype? used by Dylan explicitly defines the
relationships between all types according to certain rules (1).

A possible reason for taking this approach rather than formalizing the set
inclusion relationship is that the above relationship for empty types appears
to be a rock under which a number of worms lurk.  The difficulty has to do
with there being quite a few ways to create a type which either has or can
have no instances, some more difficult to prove than others, and many
depending on the precise definition of that phrase about having no instances.
Specifying that the type constructed by some of these mechanisms to be an
"empty" type and so a subtype of all other types would seem quite counter to
typical expectations.

A good example of a type which can have no instances but for which it would
be somewhat strange to treat as "empty" is a sealed abstract class with no
explicitly known subclasses in the library which defines it.  Should such
a class be a subtype of all other types?  It will be quite difficult to
convince at least me that it should.

Given that there are at least some types which can have no instances and for
which it is undesirable to treat them as "empty", is there a compelling
rationale for splitting the set of types which can be shown to have no
instances into those which are treated as "empty" and those which are not?
And if such a split is shown to be desirable, is there a compelling rule for
choosing which of those two sets a given type should in.  My opinion is that
the answer to the first question is "no", both for aesthetic reasons and
because answering "yes" would require a positive answer to the second
question, and I haven't been able to think of any compelling rule to use in
making that distinction.  (Note that I don't consider ease of implementation,
performance, and similar criteria compelling in this context.)

1. Somebody (probably Ashley) previously pointed out that there seems to be
no rule specifying the behavior of subtype? when the first argument is a
limited integer type and the second is a singleton type.  I believe this is
simply a bug in the DRM, and that the following rule should be added to the
section "Limited Integer Type Protocol" on p.74-75 of the DRM:

 - subtype?(limited(<integer>, min: w, max: x), singleton(y)) will be true
   if and only if (w = x) and (w = y).

Note that although this would result in limited(<integer>, min: n, max: n)
being type equivalent to singleton(n), they are still not the "same", in
that singleton(n) has greater precedence in method selection, while the
limited integer type would remain unordered with respect to any other
relevant limited integer specializer.



Fri, 15 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


Quote:
>I think it would be useful if

>  instance?(p,limited(<integer>, min: x, max: y))

>were guaranteed to be the same as

>  (p >= x) && (p <= y)

>without having to worry about x>y as a special case.

Yes, this is an excellent reason for not signalling an error.


Fri, 15 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


...

Quote:
>The actual specification of subtype? used by Dylan explicitly defines the
>relationships between all types according to certain rules (1).

>A possible reason for taking this approach rather than formalizing the set
>inclusion relationship is that the above relationship for empty types appears
>to be a rock under which a number of worms lurk.  The difficulty has to do
>with there being quite a few ways to create a type which either has or can
>have no instances, some more difficult to prove than others, and many
>depending on the precise definition of that phrase about having no instances.
>Specifying that the type constructed by some of these mechanisms to be an
>"empty" type and so a subtype of all other types would seem quite counter to
>typical expectations.
>A good example of a type which can have no instances but for which it would
>be somewhat strange to treat as "empty" is a sealed abstract class with no
>explicitly known subclasses in the library which defines it.  

This isn't actually empty, is it? The library in which the class is
defined could define subclasses, which could then have instances.

...

Quote:
>Given that there are at least some types which can have no instances and for
>which it is undesirable to treat them as "empty", is there a compelling
>rationale for splitting the set of types which can be shown to have no
>instances into those which are treated as "empty" and those which are not?

Rather depends on what you mean by "shown to have no instances". As far
as I'm concerned, the Dylan type protocol alone nowhere forbids any class
from having concrete subclasses, provided the subclass is defined in the
correct library, so every class is 'generally' (as opposed to 'directly')
instantiable. So no class is empty as a type.

Now, specifiable types in Dylan are either

1. classes,
2. unions,
3. singletons, or
4. limited types.

Any reasonable rule for empty types is going to find singletons non-empty
and unions empty iff their components are both empty. So that leaves
limited types.

The main advantage of formalisation is that once you've defined a
particular formalisation, these questions are trivial, and I think it's
easier to pick the most attractive or intuitive of a set of possible
consistent formalisations than pick rules entirely ad hoc. But of course
the type rules of Dylan _aren't_ being picked ad hoc, they're being
picked with reference to the designers' own internal ideas of the object
system.

These ideas are mentioned in the DRM, but not with anything like the
rigor needed to check the rules. The most basic concepts are left
suggested, but undefined.

Now discussions about possible rule changes are also made with reference
to ideas of the object system, and disagreements on rule changes are
really disagreements on possible interpretations or variations on these
internal ideas. If these 'guiding' ideas were given more authority, we
could discuss them directly and a lot of confusion could be eliminated.
And it would also be a lot easier to extend Dylan (e.g. subtype limited
types) without worrying about possible inconsistencies and anomalies.

In this case it's all about 'possible instances'. Should a type T be
considered empty for the purposes of 'subtype?' if:

1. there happen to be no instances of T right now?

2. no instances of T can be created outside library L, and Dylan knows L
well enough that it can personally guarantee that L will never create any
instances?

3. no instances of T can be created by any library due to a limited-type
protocol?

My formalisation efforts so far give a definite 'no' on the first two.
Possible formalisations that give 'yes' seem to me more attractive than
those that say 'no' because they properly account for the limited-type
protocol. Limited-type protocols involve subtype relations, so they have
to be in the formalisation of type, whereas libraries do not. And I don't
see any reason to 'privilege' any particular library (such as the 'Dylan'
library) for type-formalisation.

Quote:
>1. Somebody (probably Ashley) previously pointed out that there seems to be
>no rule specifying the behavior of subtype? when the first argument is a
>limited integer type and the second is a singleton type.  I believe this is
>simply a bug in the DRM, and that the following rule should be added to the
>section "Limited Integer Type Protocol" on p.74-75 of the DRM:

> - subtype?(limited(<integer>, min: w, max: x), singleton(y)) will be true
>   if and only if (w = x) and (w = y).

I suggested this, but it turns out to be more complicated on closer
inspection. Bear in mind that it's only true because <integer> is a
sealed class. For all I know, there could be a hidden subclass of
<integer> defined in the 'Dylan' library.

From a formal point of view, it's not enough that <integer> is sealed in
some library. Either there would need to be a guarantee that <integer>
has no subclasses as an axiom of the type system (which I'm not really
comfortable with), or the definition of limited(<integer>, ...) would
have to imply that instances of subclasses of <integer> are not instances
of any limited(<integer>, ...) type.

This second option is certainly acceptable, so on balance I favour this
rule addition.

Quote:
>Note that although this would result in limited(<integer>, min: n, max: n)
>being type equivalent to singleton(n), they are still not the "same", in
>that singleton(n) has greater precedence in method selection, while the
>limited integer type would remain unordered with respect to any other
>relevant limited integer specializer.

That's not consistent with the DRM rules for method specialisation. From
<http://www.harlequin.com/products/ads/dylan/doc/drm/drm_50.htm#HEADIN...

Quote:
>:

     If the specializers are type equivalent, then A and B are unordered
     at the current argument position.

and from
<http://www.harlequin.com/products/ads/dylan/doc/drm/drm_40.htm#HEADIN...

Quote:
>:

     Two types t1 and t2 are said to be equivalent types if subtype?(t1,
t2)
     and subtype?(t2, t1) are both true.

...and in any case, it's a _horrible_ idea. I believe that as a general
"rule of thumb" (in the absence of formalisation) if two types are
type-equivalent, they should be treated the same with regard to these
type-operations.

--
Ashley Yakeley, Seattle WA



Fri, 15 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

> I prefer returning an empty type that followed Dylan's 'informal' type
> protocol. I believe errors and exceptions should only be signalled when
> there's no meaningful way to continue.

There is almost always a meaningful way to continue:  Just ignore the
"error" and keep going.   That doesn't mean it is a good way to handle the
situation.

Quote:
> Bear in mind that the 'min' and 'max' values may be calculated rather
> than fixed. I think it would be useful if

>   instance?(p,limited(<integer>, min: x, max: y))

> were guaranteed to be the same as

>   (p >= x) && (p <= y)

> without having to worry about x>y as a special case.

It looks like you favor returning some sort of empty-limited-type.  (A
plain empty-type is not going to have slots for min and max, and a plain
limited integer is not immediately discernible as an empty-type.)

I think the best solution may be to just add the word "generally" to the
description of the DRM to stress that the description is just an informal
description:

"GENERALLY, Type t1 is a subtype of type t2 (i.e., subtype?(t1, t2) is
true) if it is impossible to encounter an object that is an instance of t1
but not an instance of t2."



Fri, 15 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:



> > I prefer returning an empty type that followed Dylan's 'informal' type
> > protocol. I believe errors and exceptions should only be signalled when
> > there's no meaningful way to continue.

> There is almost always a meaningful way to continue:  Just ignore the
> "error" and keep going.  

That's not in general meaningful. For instance, what's 1/0? If your divide
function return type restriction allows it, returning an 'infinity' value
is a meaningful way to continue. But if you're restricted to finite
numbers, you should throw an exception. Returning, say, zero is not
meaningful, because in no sense is 1/0 = 0.

--
Ashley Yakeley, Seattle WA



Sat, 16 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y


Quote:


>>Hi folks,

>>As Ashley Yakeley pointed out previously on comp.lang.dylan, the
>>description of subtype? in the DRM has some problems.

>>Specifically limited(<integer>, min: x, max: y) is problematic when x > y (The
>>minimum is greater than the maximum).

[...]
>>One question to resolve is what kind of type
>>limited(<integer>, min: x, max: y) should return when x > y.  

>>I see a number of possibilities:
>>  Signal an error if min > max
>>  Return a new instance of a limited integer type, doing nothing special
>>  Return a special type, the empty-type, which is an instance of <type>
>>(or an instance of some subclass of <type>)

>>I favor signalling an error.  Allowing types to be created that have no
>>possible instances doesn't seem like a useful concept to me, and if I were
>>writing code that did that, I would prefer to see an error generated.  It

>You may be right that this type constructor should signal an error, but
>don't equate that with the claim that types with no possible instances are
>not useful.  Common Lisp has the type NIL, which is defined to be the empty
>type (not to be confused with the type NULL, whose only member is the
>object NIL).  An empty type is useful to avoid boundary problems; it's
>analogous to zero-length arrays, which may not be able to hold anything but
>may be necessary to pass to functions that need an array to iterate over.

>--

>GTE Internetworking, Powered by BBN, Burlington, MA
>*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
>Don't bother cc'ing followups to me.

The existence of a type to which no object belongs (and one to which every
object belongs) can be most easily justified by thinnking of types in
terms of sets of classes. These are then simply the least (and largest)
members of the type lattice. Mathematically, at least, it is cleaner to
deal with bounded lattices.

In Maple, there are types `nothing' and `anything' with the properties
that "type( e, 'nothing' )" returns false for all objects e, while
"type( e, 'anything')" always returns true. These are useful when a
type (or structured type) is being computed dynamically in a program.
(Mostly, type `anything' is used as documentation that a procedure can
accept any expression for its argument.) The `nothing' type helps to
work around a problem/feature in Maple that procedures are naturally
polyaritic. If I write

Quote:
> f := proc(a::string) print(a); end;

                         f := proc(a::string) print(a) end

then procedure `f' will accept any positive number of arguments, ignoring
all but the first:

Quote:
> f("foo");

                                       "foo"

Quote:
> f("foo",2);

                                       "foo"

If I want to restrict to one argument only, I can use type `nothing':

Quote:
> g := proc(a::string, b::nothing) print(a); end proc;

                   g := proc(a::string, b::nothing) print(a) end

Quote:
> g("foo");

                                       "foo"

Quote:
> g("foo",2);

Error, g expects its 2nd argument, b, to be of type nothing, but received 2

Could one do something similar in Dylan? Also, is it possible to manipulate
types in Dylan as expressions? For example, in Maple, I can do

Quote:
> t1 := { 'integer', 'string' };

                              t1 := {integer, string}

Quote:
> e := sin( 2 + exp( x ) );

                               e := sin(2 + exp(x))

Quote:
> type( e, t1 ); # not an integer or a string

                                       false

Quote:
> t := t1 union { 'algebraic' };

                         t := {integer, string, algebraic}

Quote:
> type( e, t ); # but *is* of type `algebraic'

                                       true

Can something similar be done in Dylan, where I build a type dynamically,
which I can then use to test objects against? (Sorry if these are
simple questions, but I am just getting started with Dylan, having mostly
programmed in Maple, C and Scheme in the past. Neither of
my Dylan books has given me any clue about this. If it matters,
I am using Gwydion Dylan on Solaris.)

Thanks,

James
--
James McCarron
cat(``,op(zip(cat,[seq(_,_="Js nte al akr")],[seq(_,_="utAohrMpeHce ")])));



Mon, 18 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

> The existence of a type to which no object belongs (and one to which every
> object belongs) can be most easily justified by thinnking of types in
> terms of sets of classes.

Ashley Y. has recently been trying to formalize the Dylan type system in
terms of sets.

Quote:

> In Maple, there are types `nothing' and `anything' with the properties
> that "type( e, 'nothing' )" returns false for all objects e, while
> "type( e, 'anything')" always returns true. These are useful when a
> type (or structured type) is being computed dynamically in a program.
> (Mostly, type `anything' is used as documentation that a procedure can
> accept any expression for its argument.) The `nothing' type helps to
> work around a problem/feature in Maple that procedures are naturally
> polyaritic. If I write

> If I want to restrict to one argument only, I can use type `nothing':

> > g := proc(a::string, b::nothing) print(a); end proc;
>                    g := proc(a::string, b::nothing) print(a) end

> > g("foo");
>                                        "foo"

> > g("foo",2);
> Error, g expects its 2nd argument, b, to be of type nothing, but received 2

> Could one do something similar in Dylan?

That seems to confuse the arity of the parameter list with the type of the
parameters.  In Dylan, all methods belonging to the same generic function
are forced to have the same number of required parameters.  Methods may
also support keyword arguments (through the #key construct) and variable
numbers of arguments (through the #rest construct).

In Dylan, types are mainly used to constrain definitions (such as
variables) and for calculating which method is most applicable during the
process of method dispatch.

Personally, I don't see a use for empty types in Dylan.  It would not be
useful for specializing definitions, nor specializing method parameters:

define variable foo :: <empty-type> := ???;

define method print (foo :: <empty-type>)
  // this method body sure won't be executed very often!
end method;

- Show quoted text -

Quote:
> Also, is it possible to manipulate
> types in Dylan as expressions? For example, in Maple, I can do

> > t1 := { 'integer', 'string' };
>                               t1 := {integer, string}

> > e := sin( 2 + exp( x ) );
>                                e := sin(2 + exp(x))

> > type( e, t1 ); # not an integer or a string
>                                        false

> > t := t1 union { 'algebraic' };
>                          t := {integer, string, algebraic}

> > type( e, t ); # but *is* of type `algebraic'
>                                        true

> Can something similar be done in Dylan, where I build a type dynamically,
> which I can then use to test objects against?

Yes, you can create unions of types dynamically in Dylan with the
type-union() method.  limited() and singleton() also can create types
dynamically.  Try it, you'll like it! :-)

Quote:
> If it matters,
> I am using Gwydion Dylan on Solaris.)

Keep up the good work! :-)   If you want to look at how the type system is
implemented, take a peek in the Gwydion source.  I think the file the
relevant file is
  gd/src/d2c/runtime/dylan/type.dylan


Mon, 18 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

> That's not in general meaningful. For instance, what's 1/0? If your divide
> function return type restriction allows it, returning an 'infinity' value
> is a meaningful way to continue. But if you're restricted to finite
> numbers, you should throw an exception. Returning, say, zero is not
> meaningful, because in no sense is 1/0 = 0.

Likewise, if you are restricted to non-empty types, returning an empty
type is not meaningful.  It is not useful for specializing definitions or
method parameters. :-)


Mon, 18 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:

>Personally, I don't see a use for empty types in Dylan.  It would not be
>useful for specializing definitions, nor specializing method parameters:

Since Ashley has apparently been trying to define an algebra for Dylan's
type system, I think it could be useful when used there.  The empty type is
the identity value for a type-union() function.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.



Mon, 18 Jun 2001 03:00:00 GMT  
 limited(<integer>, min: x, max: y), x > y

Quote:



> > That's not in general meaningful. For instance, what's 1/0? If your divide
> > function return type restriction allows it, returning an 'infinity' value
> > is a meaningful way to continue. But if you're restricted to finite
> > numbers, you should throw an exception. Returning, say, zero is not
> > meaningful, because in no sense is 1/0 = 0.

> Likewise, if you are restricted to non-empty types, returning an empty
> type is not meaningful.

Right, that's an argument for not being restricted to non-empty types.

Quote:
> It is not useful for specializing definitions or method parameters. :-)

One might as well argue that zero isn't useful because it doesn't count
anything.

--
Ashley Yakeley, Seattle WA



Mon, 18 Jun 2001 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. ><><><><>Heeeeeeeeeeeeeeelp on INT 14!><><><><><>

2. <<<<<YOU MUST CHECK THIS OUT >>>>>>>>>> 2103

3. limited(<integer>, min: x, max: y), x > y

4. <union-type>, <limited-type>

5. <><><> FLOODFILL <><><>

6. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

7. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

8. >>>HELP, DECOMPILER<<<

9. <<<XXX Password>>>

10. <<<XXX Password>>>

11. <<<XXX Password>>>

 

 
Powered by phpBB® Forum Software