The Artima Developer Community
Sponsored Link

Weblogs Forum
What if Constant Values were also valid Types?

41 replies on 3 pages. Most recent reply: Jan 20, 2006 10:43 AM by Gregor Zeitlinger

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 41 replies on 3 pages [ 1 2 3 | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

What if Constant Values were also valid Types? (View in Weblogs)
Posted: Jan 18, 2006 10:06 AM
Reply to this message Reply
Summary
I don't know any language which is so perverse as to do such a thing, but I want to throw it out there as an idea to torment people.
Advertisement
I want you to think about the implications of making the following change to C++ or Java: allowing any constant literal to be used as a type.

This would mean that you can declare instances of them:

  42 x;
You can inherit from them:
  class FourtyTwo : 42 { };
You can alias them:
  typedef 42 fourty_two;
You can overload functions using compile time constants:
  
  int fubar(true x, int n) { return n + 1; }
  int fubar(false x, int n) { return n - 1; } 
I know this is a perversion of nature, but it does simplify a language from a designer's standpoint. I bring this up because it looks like I am going this route for the time being as an undocumented feature in the next Heron release, and I thought it might blow a few people's minds.


Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What if Constant Values were also valid Types? Posted: Jan 18, 2006 3:16 PM
Reply to this message Reply
I think this is a good idea. It is used in functional languages like Haskel and Scala to great effect. The classic example is factorial.

Functional languages go even further and allow conditions to be put on the arguments, the case of a constant is just the condition that it matches the argument exactly. IE:
int factorial( int x ; x < 1 ) { throw new IllegalArgumentException( "Factorial is undefined for negative numbers" ); }
int factorial( 1 x ) { return 1; }
int factorial( 2 x ) { return 2; } // optimization
int factorial( int x ) { return x * factorial( x - 1 ); }

(I made up the above syntax!)

However some people dislike the idea because all the different definitions of factorial can be distributed. People who dislike overloading based on a value prefer:
int factorial( int x ) {
  if ( x < 1 ) throw new IllegalArgumentException( "Factorial is undefined for negative numbers" );
  if ( x == 1 ) return 1;
  if ( x == 2 ) return 2; // optimization
  return x * factorial( x - 1 );
}

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What if Constant Values were also valid Types? Posted: Jan 18, 2006 3:55 PM
Reply to this message Reply
Just a further thought on your idea. You are actually going further than finctional languages by making a value a type. I think that is a good idea as it gives nice flexibility. However I think you need to look at the implications of the decision and whether you can impliment it. Functional languages generally shy away from doing this (although it is discussed in the literature), because the implication is:
abstract class Byte {
  abstract Byte instance(); // this function is automatically generated by the compiler and returns the singleton of the class
  abstract Byte increment();
  abstract Byte decrement();
}
 
class -128b extends Byte {
  Byte increment() { return -127b.instance(); }
  Byte decrement() { throw new IllegalStateException( "-128b is the smallest Byte and therefore can't be decremented" ); }
}
 
class -127b extends -128b {
  Byte increment() { return -126b.instance(); }
  final Byte decrement() { return super; }
}
 
class -126b extends -127b {
  Byte increment() { return -125b.instance(); }
}
 
...
 
class 127b extends 126b {
  final Byte increment() { throw new IllegalStateException( "127b is the largest Byte and therefore can't be incremented" ); 
}

Note how class -127b extends class -128b which in turn extends Byte. The compiler also ensures that there is only one instance of each of these classes and it is refered to by the constant name appended with .instance().

This construct of integers as a heirachy of types goes back to Church's Lamda Calculus and is used to prove the properties of integers. In Lamda Calculus the class heirarchy is treated as a list. But note that the heirarchy is very long!

You may just have had in mind that the constants just extend the base class, Byte, and not each other. This latter approach may be easier to implement. The 'functional people' would like the full Lamda Calculus approach given above, but don't do it for efficiency reasons.

Kannan Goundan

Posts: 18
Nickname: cakoose
Registered: Nov, 2005

Re: What if Constant Values were also valid Types? Posted: Jan 18, 2006 7:16 PM
Reply to this message Reply
The Merd programming language is chock full of unconventional ideas. The type system allows using literals as types (or as members of compound types):

http://merd.sourceforge.net/types.html

Another neat idea is "horizontal layout" (denote order of operations with whitespace):

(x*x + x) vs. (x * x+x)

The grouping is done exactly the way it looks like it should be done.

http://merd.sourceforge.net/choices_syntax.html#horizontal_layout

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 4:20 AM
Reply to this message Reply
To Christopher: What can you do with instances of these "types", and how are the instances different from the "types"?

Types usually denote the possible operations you can do on its instances. I have a little difficulty mapping that to this.

> I think this is a good idea. It is used in functional
> languages like Haskel and Scala to great effect. The
> classic example is factorial.
>
> Functional languages go even further and allow conditions
> to be put on the arguments, the case of a constant is just
> the condition that it matches the argument exactly. IE:
>
> int factorial( int x ; x < 1 ) { throw new
> IllegalArgumentException( "Factorial is undefined for
> negative numbers" ); }
> int factorial( 1 x ) { return 1; }
> int factorial( 2 x ) { return 2; } // optimization
> int factorial( int x ) { return x * factorial( x - 1 ); }
> 

> (I made up the above syntax!)

Hm, but can you call this "types"? Sure, functional programming languages have such pattern matching, but it's my impression that they match on values, not types. Consider an analogue example using C++ (ref my mentioning of templates being similar to FP pattern matching):

template<unsigned int N>
struct factorial
{
static const int value=N * factorial<N-1>::value;
};

template<>
struct factorial<0>
{
static const int value=1;
};

std::cout << factorial<4>::value; // Prints "24"

What we match on, here, is most definiely values, not types. We have a template with an argument of type int, which is specialised for various values of it.

As you say, the FP way may be considered "overloading on value", but that still doesn't make the values types...

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 6:08 AM
Reply to this message Reply
A type defines a fixed domain that subsumes variable values. Allowing only one value is just the limit case. So there is no intrinsic invalidity to the idea. But the 'power' of the abstraction is somehow reduced to (almost) nothing...

Relations between types are defined with inheritance. This requires derived types to be supersets of their bases, in terms of operations. A 'constant-type' can fit this structure. All operations must be read-only/constant, but that is quite normal.

Therefore the concept is logically sound for the Object-Oriented universe.

That assessment affirms that types and values are still separate. Calling a type '42' implies some different kind of character, but that would carry a whole set of new relations which have not be described...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 7:28 AM
Reply to this message Reply
> To Christopher: What can you do with instances of these
> "types", and how are the instances different from the
> "types"?

The differences is the same as the differences between values and types in C++. An instance of the type would be:

42 fourty_two;

but you can't write:

fourty_two y;

because fourty_two is a variable (i.e. an instance of the type 42).

Now I haven't decided what functionality these types will have, so for the time being it is purely an academic exercise.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 7:43 AM
Reply to this message Reply
> A type defines a fixed domain that subsumes variable
> values. Allowing only one value is just the limit case. So
> there is no intrinsic invalidity to the idea. But the
> 'power' of the abstraction is somehow reduced to (almost)
> nothing...

Ok, so what you're saying is that you may define "42" as a type, whose only value is, well, 42? That doesn't seem terribly useful, no... :)

> That assessment affirms that types and values are still
> separate. Calling a type '42' implies some different kind
> of character, but that would carry a whole set of new
> relations which have not be described...

Yes. It's a bit like this blog: We have the answer, but not the question (what it's for). ;)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 8:57 AM
Reply to this message Reply
The only way I can see this being useful is if Heron supports double-dispatch on method calls. I am not sure if that's a feature you are including.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 9:06 AM
Reply to this message Reply
Of course, that's assuming that the runtime value of 42 is an 'instance' of the 42 type. I'm not sure about that either.

Kresimir Cosic

Posts: 34
Nickname: kreso1
Registered: Jan, 2006

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 9:22 AM
Reply to this message Reply
It's ok to me. I look on it this way: the constant is a type that has it range reduced to single value. Thats ok.

Type conversions will fit nicely, and interface of constants will satisfy interface of their full types (but!).

I would also like to point out one peculiar thing (using C++ syntax): If there are two types 'sometype' and 'const sometype', then 'const sometype' shouldn't have same subtype relations as 'sometype' (and C++ doesn't allow you to express this).

So be carefull. 42 is subtype of const int, but not of int.

But the real question is: is this usefull at all? Who knows...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 10:15 AM
Reply to this message Reply
> Yes. It's a bit like this blog: We have the answer, but
> not the question (what it's for). ;)

I am throwing the idea out mostly as a tease and to see where other people go with it.

Personally, I find the idea useful in the context template metaprogramming.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 10:33 AM
Reply to this message Reply
> So be carefull. 42 is subtype of const int, but not of
> int.

'const int' is a type? That seems pretty undesireable and unintuitive.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: What if Constant Values were also valid Types? Posted: Jan 19, 2006 11:01 AM
Reply to this message Reply
> I would also like to point out one peculiar thing (using
> C++ syntax): If there are two types 'sometype' and 'const
> sometype', then 'const sometype' shouldn't have same
> subtype relations as 'sometype'

I'm not sure if I understand what you mean. Could you provide some example code showing what it is C++ doesn't let you express?

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Well, I like the idea Posted: Jan 19, 2006 11:03 AM
Reply to this message Reply
I'm assuming that "constant" value includes more than ints, or even floats, but also includes (say) arrays or structs:

struct base_type { 10, 23.5, 19 };
struct Derived : base_type { ... };

Flat View: This topic has 41 replies on 3 pages [ 1  2  3 | » ]
Topic: M Clock 2.0 Previous Topic   Next Topic Topic: Static Behavioral Subtyping and Heron Traits

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use