While playing around with the idea of allowing users to explicitly specify the type for a const statement, I realized that it might be equally as interesting to play around with the idea of not requiring a type in a Dim statement so long as there's an assignment present. It would look very similar to the way Const works today:
Dim foo = 12
Now, don't start thinking that REALbasic is going to become VBScript and lose type safety, because that's not going to happen! The right-hand side of the declaration has a concrete type -- Integer. So we can infer foo's type as being Integer as well. So essentially, the above statement is simply shorthand for:
Dim foo as Integer = 12
They amount to the same thing, it's just that the former is more succinct. The downside is when you write code like this:
dim i as Integer, s as String, d as Double
// Stuff happens
// ...
// ...
Dim foo = i
Dim bar = s
It's now more difficult for you to read the foo and bar declarations and know their types as you're reading the code. So the trade off for succinct code is readability -- but that's a well known phenomenon. However, it hardly seems compelling to implement a feature that does nothing more than make your code harder to read.
Where it gets more compelling is when you think about delegates. Since the AddressOf operator returns a strongly-typed delegate reference, you could now write code like this:
Sub Test( i as Integer )
MsgBox Str( i )
End Sub
Dim foo = AddressOf Test
foo.Invoke( 12 )
You no longer need to manually create a delegate type, since the type can be inferred from the AddressOf operator. Of course, if you want to pass that delegate to a function, you'd still have to have an explicit type for it, since parameters are not Dim statements.
Keep in mind, just because I'm thinking about something doesn't mean it's going to happen. ;-) But this is an interesting little language idea that's not exactly new. C# has the "var" keyword (which it basically stole from VB), and it's used in conjunction with anonymous classes. Since I'd love to see some more LINQ-esque features in REALbasic, this would be a good first step towards that goal. What sort of thoughts do you have on the idea of type inference (with the requirement that it still retain type safety)?
The Short Answer: Ugh!
The Long Answer: Ugh! Applescript does this...
set theValue to 12
But then later, I can change the variable to anything else just as easily...
set theValue to True
So, I can only imagine the confusion that's caused in a loosely-typed language like Applescript would only be magnified in a strongly-typed language like RB. I think we already have this neatly encapsulated in the Variant data type with all the warnings that go along with it (don't use it if at all possible). One of REALbasic's core strengths is readability. If all the other programming languages jumped off a cliff, would RB? Let's not muck it up now...
Ugh.
@Philip -- but we already have some inferred types in REALbasic, do you feel they're a problem as well? For instance, constant types are inferred. So are exception types (you can use Exception err at the end of a method and the infers that you really mean Exception err as RuntimeException).
One of the places I was thinking this could be introduced is with the for each syntax. The compiler already knows the type of the loop variable -- it can be gotten from the as type clause. So, for instance:
for each foo in someStringArray
next foo
instead of
for each foo as string in someStringArray
next foo
Would this be a reasonable syntax? Or confusing?
I think you mean:
For Each Dim foo In SomeStringArray
Which would be great IMO.
@Adam -- no, I really did mean to leave the Dim off. It's not needed, the compiler already knows if there's a Dim needed or not, so it's implied.
Gotta agree with Philip. I'd like to see strong-typing taken even further with warnings for automatic-conversions and old-style untyped constants (once typed constants are a feature of course).
@Aaron -- Yes, that can be an issue, especially if there are a lot of constants composed of a lot of data types, but I can't think of a better way to handle them. As for the for...each syntax, there is something to be said about not having to go back to the as type clause to sort out what the data type is.
This all just reminds me of my initial hurdles trying to wrap my head around Applescript and Objective-C, so I have an immediate negative reaction to it. I think one of the greatest "freedoms" about REAbasic is the straightforward syntax and strong typing. It forces users to program into the language rather than worry about the nuances of syntax. At the same time, there's nothing to say I would have to use any of this in my own code.
Well, just to be clear, I'm not tied to the idea myself. It's just one of those "hmmm" sort of things I think about. I like REALbasic's strong typing very much, and don't suggest that ever change. Also, there's something to be said about the explicitness of any BASIC-like language. It's very easy on the eyes, and this change would certainly reduce that.
That's why I wonder if there are ways to selectively make use of it, such as with the for each clause. But then you have these weird idiosyncrasies in the language where you have to declare a type here, but not there, etc. That always drives me nuts and I try to avoid them whenever possible.
My two cents is that if there's any hint of confusion or adds more idiosyncrasies to the language then don't do it.
"It's just one of those "hmmm" sort of things I think about."
So, are these "hmmm" things the result of your new-found powers from being in charge of the compiler? ;-) Remember, with great power comes great responsibility. [Insert other superhero reference jokes at your leisure.]
@Philip -- I've always had these "hmm" sort of thoughts. But since I am the lead compiler dev, my "hmm" thoughts now carry a bit more weight than previously. ;-)
I have these sorts of "hmm" thoughts as well. Unfortunately, I don't work on the Rb compiler, so my thoughts carry no weight at all. Generics and anonymous methods make me go "hmmm".
@Charles -- I've had those same two "hmmm" thoughts as you. The difference is "hmmm, type inference?" would be about a day. "hmmm, generics?" would be about three months. :-P I've got plenty of ideas on those topics though, so don't worry.
I should have kept my mouth shut about asking for explicit types for consts.
It makes the compiler guy go "hmmmmmmm......." and now you see where that leads :P
The upside is that no type safety _seems_ to be lost BUT readability definitely could be.
I'd think there's a certain bigger negative to it if the readability is lost than what is gained in some cases. I like the idea of not having to create a delegate :)
I can't see how type inferring can compromise the static type system of REALbasic. Besides, if implemented, it's going to be optional, so nobody is forced to use it.
As for readability, in cases like the one below the IDE can show hints for variable types as it does in Visual Studio, so you don't have to hunt around looking for the type of i or s when you see the declarations of foo and bar.
dim i as Integer, s as String, d as Double
// Stuff happens
// ...
// ...
Dim foo = i
Dim bar = s
So, I'd say 'Go for it!'.
First integrate RBUnit into the IDE and batch build features, then...
Bring on the ducks!
http://en.wikipedia.org/wiki/Duck_typing
We're all consenting adults here, right? :-)
I don't like the idea of type inference. In fact I'd like to see more, and stronger typing required. eg Const just feels unnatural and ugly since it doesn't allow me to specify a type, same thing for the constant dialog. Inferring the numeric type from whether the numeric literal happens to contain a period is not a good approach.
I'd even like to see strict numeric type checking. And Integer should not be automatically converted to a double etc. These automatic conversions can easily silently loose data and lead to hard to find bugs.
@Joe - I couldn't disagree more strongly about the silent conversion of integer to double being a cause of bugs, I've lost count of the number of times in C or Java why I've sat scratching my head wondering why an expression like this evaluates to zero...
double value = 4 / 5;
...before remembering that the dopey C/Java compiler was designed to preserve performance at all costs, including the cost of mathematical precision, readability and common sense. (In case you were wondering, you have to write it like this to get the expected result: double value = 4.0 / 5.0)
REALbasic takes the high ground here - the conversion to double may cost a few extra cycles but 99.9 times out of 100 it means you get the result you wanted. I don't know what you're talking about with respect to loss of precision - RB always promotes values to an *equal or higher* precision during calculations, so there is no loss - the only exception might be if you're multiplying a lot of 64 bit integers or something, and if that's still converting them to doubles then it's a bug not a design flaw.
Some related thoughts:
1. What about a "scripting" mode, where we don't have to declare variables, and any unrecognized identifier is taken to be a Variant?
2. I *hate* AddressOf. It's super ugly. I know you borrowed it from MS, but can we have something more concise? Maybe a unary operator?
3. Instead of or as well as 2, let us drop the AddressOf in any place where a Delegate is expected (if the user intends to invoke the method/function rather than name it, they can put parentheses after it).
Delegates are powerful and liberating, but writing AddressOf all over the place is painful and cluttering.