On Thursday, September 19, 2002, at 02:37 , Jochem van Dieten wrote:
> Whatever (I don't claim to know anything about that). But would adding
> optional "int" and "double" etc. declarations next to "var" really make
> CFML a different language? We use strongly typed stuff all the time
> when working with a database (cfqueyparam), when working with
> overloaded Java classes (javacast()) etc.
But those are localized 'strong types' (and they are both runtime
validation, not compile-time).
Adding types to the language as an aid to the compiler - which is why
we're discussing this - has an impact on the basic semantics of the
language itself and on the code generation. It affects *every* place where
variables are referenced (and where code is generated).
> it would be very nice if I could strongly type it.
Don't get me wrong, I *like* strong type checking - at compile-time - and
prefer it to runtime type validation. I also like the power of
weakly-typed and type-less languages (my language design work in the early
80's was almost entirely in the field of type-less languages).
> But I have not seen any conclusive arguments that support your point
> that adding the option of strongly typed variables would make CFML an
> entirely different language.
Perhaps only people with a background in compiler design and code
generation will believe me?
> But if you say
> that it makes CFML an entirely different language I would like to know
> why you think so.
Because it changes the semantic specification of the language at a
fundamental level. There's no other way to explain this. Let's take a
simple example:
a = x / y;
Right now, as long as x and y are numeric and y is not eq 0, a will end up
as x divided by y, e.g., x = 10; y = 3; a will be
3.33333333333333333333333333.
Now, change x and y to 'int' type variables. Should the expression convert
both to floating point and then perform a floating point division
(yielding 3.33333 again)? Most languages don't behave like that. If x and
y are both 'int' then the division would be an integer division and the
result would be just 3. How should CF behave if both are 'int'? How should
CF behave if only one or the other is 'int'? This needs to be specified.
Now change y to 4. The result would be 2.5 (assuming current numeric
division). What would the result be for both x and y 'int'? Many people
would expect it to be 2 (fractions are dropped in integer division).
Now change a to 'int'. For a numeric division, should a become 2 or 3?
Should assignment truncate or round?
How about this code:
var i = 0;
var j = 0;
for (i = 1; i le 10; i = i + 1.5) {
j = j + 1;
}
This currently works in CF and j ends up as 7. Change i le 10 to i lt 10
and j ends up as 6. (Luckily the tolerances on adding 1.5 several times
remain accurate!)
Now change i to var int i = 0; (or int i = 0; or whatever). What will j be
after the loop? I'd expect it to be 10 (assuming i le 10).
That's what I mean about semantics. As CFML currently stands, it's fairly
simple to explain and most of the code behavior is fairly intuitive.
Adding types could still produce an intuitive language - but introducing
types also introduces widening and narrowing conversions as well as other
implicit type conversions in expressions. The C++ Standards Committee (and
the C committee before them) struggled for years to completely specify
such behavior and there are definitely some non-intuitive aspects to
conversions.
A lot depends on exactly what type 'hints' you add. Even adding a basic
'int' type opens questions: is it 16-bit, 32-bit, 64-bit?
[DevCon]
> I'm afraid I'm just a poor, unemployed student who couldn't hope to
> afford going there :(
Sorry... It would be good to chat over a few beers about this sort of
stuff...
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
______________________________________________________________________
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
