Monday, July 18, 2005
@beginning
Well, isn't this nice? I have no idea what the good folks at Blogger are getting out of this arrangement, but I sure appreciate having a free blog page.
Manifesto: This is my website for documenting the design of the programming language Flan.
I've been thinking about it and making notes about ideas for about a year and a half now, but hopefully this will be a good way to get it all in one place. And maybe even get some good suggestions from the general public.
First principles -
This is a language designed by me, for me. It would be nice if someone else in the world found it useful... but as long as I do, I'll consider it a success. So ner.
I'm most experienced as a C++ programmer, and it's becoming clear to me (and plenty of others, I'm sure) that the language has some annoying features in it. The Boost libraries go a remarkable way towards fixing them, but they're unreadable and unmaintainable. If I want a little feature that Boost doesn't provide, how do I add it? I wouldn't know where to start.
My wife says I should mention her. So I am. Happy, dear?
I don't have any old C programs that I want to convert, so I'm not worried about backwards compatibility. I'm just going to invent a new language from the ground up, with all the really whizzy new features that I think a language needs.
Let's start with something simple and petty:
In C++, I find declarations a little hard to spot. It would be useful to have an unambiguous, visually large prefix symbol that marks when you declare something. For instance, to declare a variable x, you could write something like "int @x = 4" or "int #x = 4". I'm going to go with @.
(I'll be using # for some other stuff later.)
Convenient results of this -
- Declarations stand out as you read the text.
- You can trivially perform a text search for the place where something is declared. (To help, I'm going to forbid whitespace between the @ and the new identifier.)
- Now that declarations are self-evident even without a type specification, we don't need one if the type is implicitly specified in other ways - i.e. constants.
For example, "const double @pi = 3.14159" is redundant. It can only evaluate to 3.14159, which we know is a double. So we can abbreviate it to "const @pi = 3.14159".
Indeed, since only constants can be abbreviated this way (the same assumption can't be made for variables - they might need to store other data later), the "const" is implicit and we can actually just write: @pi = 3.14159.
- Now that a constant doesn't need an explicit type specification, it makes sense to declare it in a function call. "Out" parameters usually require you to declare a variable to store their results.
vec3d pos;
getPosition(&pos);
I hate doing unnecessary typing, so I'm going to let you declare a constant and infer its type from the function signature, thus simplifying this down to:
getPosition(&@pos);
This saves you some typing and also makes it trivially obvious to the reader that getPosition won't (or at least, shouldn't) use any predefined data stored in pos.
Obviously the compiler will complain if the function is overloaded so that it's ambiguous what type should be used.
That's about it for now.
Next time I'll be taking the & out of getPosition(&@pos)...
Manifesto: This is my website for documenting the design of the programming language Flan.
I've been thinking about it and making notes about ideas for about a year and a half now, but hopefully this will be a good way to get it all in one place. And maybe even get some good suggestions from the general public.
First principles -
This is a language designed by me, for me. It would be nice if someone else in the world found it useful... but as long as I do, I'll consider it a success. So ner.
I'm most experienced as a C++ programmer, and it's becoming clear to me (and plenty of others, I'm sure) that the language has some annoying features in it. The Boost libraries go a remarkable way towards fixing them, but they're unreadable and unmaintainable. If I want a little feature that Boost doesn't provide, how do I add it? I wouldn't know where to start.
My wife says I should mention her. So I am. Happy, dear?
I don't have any old C programs that I want to convert, so I'm not worried about backwards compatibility. I'm just going to invent a new language from the ground up, with all the really whizzy new features that I think a language needs.
Let's start with something simple and petty:
In C++, I find declarations a little hard to spot. It would be useful to have an unambiguous, visually large prefix symbol that marks when you declare something. For instance, to declare a variable x, you could write something like "int @x = 4" or "int #x = 4". I'm going to go with @.
(I'll be using # for some other stuff later.)
Convenient results of this -
- Declarations stand out as you read the text.
- You can trivially perform a text search for the place where something is declared. (To help, I'm going to forbid whitespace between the @ and the new identifier.)
- Now that declarations are self-evident even without a type specification, we don't need one if the type is implicitly specified in other ways - i.e. constants.
For example, "const double @pi = 3.14159" is redundant. It can only evaluate to 3.14159, which we know is a double. So we can abbreviate it to "const @pi = 3.14159".
Indeed, since only constants can be abbreviated this way (the same assumption can't be made for variables - they might need to store other data later), the "const" is implicit and we can actually just write: @pi = 3.14159.
- Now that a constant doesn't need an explicit type specification, it makes sense to declare it in a function call. "Out" parameters usually require you to declare a variable to store their results.
vec3d pos;
getPosition(&pos);
I hate doing unnecessary typing, so I'm going to let you declare a constant and infer its type from the function signature, thus simplifying this down to:
getPosition(&@pos);
This saves you some typing and also makes it trivially obvious to the reader that getPosition won't (or at least, shouldn't) use any predefined data stored in pos.
Obviously the compiler will complain if the function is overloaded so that it's ambiguous what type should be used.
That's about it for now.
Next time I'll be taking the & out of getPosition(&@pos)...
