some help on my programming language

This topic is 4078 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hi, I am making a programming language. I have the , operator which is the tupling operator so that a,b is a tuple of a and b. I also have the boxing operator [ ] so that [a,b] is not a tuple. The [ ] boxes it into a single value. I added this operator to make it so that I can easily make templated containers. For example the list template takes a type as a template parameter for its element type. Using the boxing operator allows you to store boxed tuples in a list. Now I am considering making boxed variable declarations == class literals. So here is some code with tuples: int x , int y; (x,y)=(5,6); Now here is how some boxed code looks: [int,int] m; m = [5,6]; Now what if boxed declarations become class literals? [int x, int y] a; [int w, int z] b; a.x=5; a.y=6; a=[5,6]; //[5,6] is of type [int,int] which is convertable b=[5,6]; //also legal b=a; //illegal since a and b are different types Now I guess in this case the box would make it so that x and y are not independant; you have to prepend a. to get at them, because they are members. Ok now for handling inheritance I have been thinking of doing something like this class A = B += (int x, int y); //B is the superclass class A = B&&C += (int x, int y); //B and C are superclasses class A = B||C += (int x, int y); //the superclass of A is the common root of B and C, which will often be the empty class, which contains all objects. This would also allow you to create classes on the fly: A&&B ab; //ab is both an A and a B Now this would be useless in most languages but because in my language non-member functions are virtual (member functions never are, as there is no "this" pointer) it would be a useful feature, at least sometimes. Ok so now what happens when we bring class literals and set operators together? [int w, int x] && [int y, int z] my_object; my_object has four members: x, y, and z This makes compete sense and so far there are no problems. However boxes aren't limited to class literals. What should the meaning of this operation be: [5,6]&&[7,8] should it then be [5,6,7,8]? It would have to be, so that you can assign it to my_object above. Afterall those boxes do not represent lists or tuples. They do not represent sets. If you have four sets and you do this: (r,s)&&(t,u) the result will be: (r&&t,s&&u) which makes complete sense and is intuitive. Anyway, what about this: [int x, int y] && [int y, int z] or this: [int x, int y] && [int,int] I am inclined to think of [int,int] as a type literal, but not a class literal. Thus it would not have the && operator, but what about the first? Those aren't the same y. Now what if it went like this: class A = [int a]; class B = A + [int b]; class C = A + [int c]; class D = B&&C; now obviously D should have a, b, and c members. Those are the same "a". It comes from B||C. So, your thoughts?

Share on other sites
I'm not sure I entirely follow. What is the purpose of the boxing construct when you already have tuples? In your example...
int x, int y;(x,y)=(5,6)
...presumably the type of (x,y) is something like (int, int) or int * int?

If that is the case, then surely [int, int]m and (int, int)m would declare variables that behave in the same way (modulo the type)? So then why not keep the boxing notation solely for records (which effectively generalize tuples by naming the fields)?

Finally, I believe that [int x, int y] && [int y, int z] should not be a well typed term. You should require that the sets of names of fields in two record types be disjoint when the records are combined in this manner.

Share on other sites
Quote:
 I added this operator to make it so that I can easily make templated containers. For example the list template takes a type as a template parameter for its element type. Using the boxing operator allows you to store boxed tuples in a list.
Ah. Do I take it you don't have typing rules for tuples? Is there any particular reason for this?

EDIT: Oh. I see what you've done. In your example, you seem to be taking (x,y) = (5,6) to be a shorthand for x = 5; y = 6;. Which is neat: multiple assignments are groovy. What they are not, however, is tuples. I believe you are mixing the two. Your problem would therefore be best solved in one of two ways:

1. Keep tuples and find a new syntax for multiple assignments.

2. Keep your current syntax for multiple assignments and discard tuples. Once you've got records, you've effectively got tuples anyway.

As a final note, I think you would have noticed this for yourself had you given tuples a typing rule. And in any case, a language without typing rules for even a single term cannot be type safe, so unless you have typing rules for every construct, you may as well remove the type system altogether.

[Edited by - MumbleFuzz on July 26, 2007 3:48:54 PM]

Share on other sites
This multiple assignment thing is pretty much how Python handles tuple unpacking. Just thought I'd throw that in.

Share on other sites
Quote:
 Original post by MumbleFuzzIn your example, you seem to be taking (x,y) = (5,6) to be a shorthand for x = 5; y = 6;. Which is neat: multiple assignments are groovy. What they are not, however, is tuples.

That doesn't make sense. It's true that a multiple assignment isn't a tuple, but that's because "multiple assignment" and "tuple" describe entirely different things. You may as well complain that a function call isn't a string.
Quote:
 1. Keep tuples and find a new syntax for multiple assignments.2. Keep your current syntax for multiple assignments and discard tuples. Once you've got records, you've effectively got tuples anyway.

3. Permit assignment of tuples of r-values to tuples of l-values.

Share on other sites
Quote:
 Original post by Nathan BaumThat doesn't make sense. It's true that a multiple assignment isn't a tuple, but that's because "multiple assignment" and "tuple" describe entirely different things. You may as well complain that a function call isn't a string.

That was precisely my point.

EDIT: But you're right to include your alternative #3. I was so confused by the boxing construct at first that I forgot what the original tuple assignment was for.

[Edited by - MumbleFuzz on July 27, 2007 9:48:01 AM]

1. 1
2. 2
3. 3
Rutin
16
4. 4
5. 5

• 10
• 11
• 14
• 10
• 25
• Forum Statistics

• Total Topics
632650
• Total Posts
3007645
• Who's Online (See full list)

There are no registered users currently online

×