|
|
Re: Types on the Stack
|
Posted: Aug 17, 2006 11:51 AM
|
|
Hope you don't mind my commenting. My statements usually diverge considerably from the accepted consensus. I want to post because I've actually dealt with something similar.
I'm not sure about how Cat works exactly, so I'll just mention what I've learned in my own development environment about putting types directly in the language. First, your "types" now become values as you've said. So you now need types for your types. The only way I've seen this done is to have primitive types that do not have any sub-attributes. For example, you cannot get its size or anything like that, only its value. The attributes must be assumed. Now, you can get these attributes with built-in functions, mind you. Instead of primitive types being used for ints and floats and things like that, they are now used for defining types. These types in turn define your actual values. But now this creates two separate environments for getting attributes. 1. Members for classes (or other groupings). 2. And built-in functions for primitive types (that in turn define types).
The reason for no attributes is to break the recursion. If you'll note, the recursion is broken in all language (I think). For example, You can't do int.size in C++. You use a built-in function sizeof(). You must now move this system from values over to first "class" types.
Now you must ask yourself why you need runtime types in your language. I use them so that the objects are fully independent and can be sent over the wire. I can also create new values based on other values since these values also contain their types (which is necessary for value creation). However, like I said before, you need a low level implementation of your primitive types for this exchange to take place. This low level stuff cannot be in the language proper, otherwise you get into the recursive definition again. That's where static type languages like C++ and languages that have runtime types values differ. In C++, since RTTI can only be queried (usually by comparing it to existing types), you must manually create any structure or packet information for exchanging this type information (if the software wants to deal with types). The software itself is in control. But if you put types directly in the language, then the language itself must be in control of its definition.
In other words, while it is easy to specify that an int is 32 bit, how do you specify what a type looks like? How is 'int' stored? How is 'bool' stored? These are just a set. You will need to specify how this set is stored if you want manual manipulation of it. You also need a way to create new types. I don't know if you allow subclassing or any of that, but functionality that used to be in the compiler must now be available at runtime. You must ship a good part of the compiler with the software itself unless your language is an interpreter (in that case, it would be available anyhow). The most critical functionality is being able to put other types together to form a new compound type and then create instances of this new type. In my environment, I can create new primitive types as well, but that's way more complicated than anything I could describe in one message. I also see code as an extension of a type (as it defines what [can] happens to the value). So I can also create new code. But this too is another topic.
BTW, I'm guessing you'll soon be looking at grouping types together and how to represent them and how this differs (or is similar) from regular primitive types when it comes to breaking the recursion. Without first "class" types, you can implement groupings any which way you want. Now you must expose this. Remember that groupings have properties. As such, you're going to have to find an alternative in order to break the recursion (perhaps with a built-in function). Your biggest challenge is resolving the dichotomy of types and values.
You're in for a ride. It can be fun, but can be damaging to your sanity. BTW, I've said it before that all of computing community, including yourself, are all going toward the same destination. However, whenever anyone gets close to the goal, they steer clear. Good luck!
Also note that this is stuff I learned on my own. Much of this may already be solved, but since you're posting here, I'm guessing you haven't found any concrete solution, so I thought my comments may be of some value.
|
|
Previous Topic
