Strong Typing?

[bcholmes]

Geek question:

What is the feature of a language that you consider "strong typing"? How does strong typing manifest itself (or not) in your favourite language or two?

Comments

[hellsop.livejournal.com]

Weak typing will cause the following code to return "b":

foo="a"
foo=foo+1
print foo

Or possibly "a1", depending. That's what makes weak typing so interesting!

[cigfrain.livejournal.com]

in even a weakly typed language, wouldn't that be a result of foo=foo+"1" ? conventions being what they are 'n all...

[king-tirian.livejournal.com]

In Java,

String foo = "a";
System.out.println(foo+1);

generates a1.

In Perl, the output from polyfrog's script is 1.

[cigfrain.livejournal.com]

so does java consider all constants in a mixed string to automatically be of the same type as the declared variable? is there a precedence? or does the println function cast everything to strings?

or...
um.

[king-tirian.livejournal.com]

IANAJP (yet), but I think it's um. Java is even a strongly typed language but they decided to not do operator overloading and then made a sole exception for String concatenation, so println is a bit of a kludge of doing the math if they can figure it out and casting any other objects to Strings if not. That's probably not even a total understanding because 1 isn't an object, so I don't know if they're sticking a new Integer on the heap just so they can cast it to a String or if they have some other way of turning stack numbers into Strings, but it's a muddle either way.

[hellsop.livejournal.com]

Similar, in javascript (to be expected) and php, respectively. NSBasic spits out "a1", and I'd expect most BASICs to do something similar, as the "a1" depends on the "+" operator to be overloaded to "concatenate".

[cigfrain.livejournal.com]

just tested it in javascript.

well, don't that just beat all...

[erik]

That seems broken to me.

It should either fail or do what I said (increment the character value by one). Doing what you're saying, it has to be implicitly casting my 1 into "1" and then concatenating. Which in turn implies that there's some typing happening in the background.

On the other hand, your example and mine are not the same: You are displaying the result of foo+1. I am incrementing foo and then displaying. At the end of yours, foo is still "a", at the end of mine its...well in any weakly-typed language I've used, its "b".

[hellsop.livejournal.com]

It's programming languages... "should" hardly enters in. The distinction between adding 1 and incrementing isn't express in the sample. perl can do that as well, and gets the result you're expecting:

$ cat test.pl
$foo="a";
$foo=++$foo;
print $foo;
print "\n";
$ perl test.pl
b

But, that reveals a parallel ambiguity in expressing "incremement" versus "add 1" in most languages. Perl (and other languages borrowing heavily from C) distinguish between them; other languages don't, and some use a partial typing to "do what I mean". Javascript doesn't like incrementing a string at all,

javascript: var foo = "a"; document.write(++foo);
NaN

which kind of indicates that it's doing some DWIM with regard to the "+" operator.

At the opposite end of things, we've got bourne shell scripting where EVERYTHING is a string operation, unless specified otherwise:

$ foo=1+1
$ echo $foo
1+1
$

If you specify the operation to be a numerical calculation,

$ foo=$((1+1))
$ echo $foo
2
$ foo=$((a+1))
$ echo $foo
1
$ echo $a

$ a=a
$ echo $a
a
$ foo=$((a+1))
/bin/ksh: a: expression recurses on parameter `a'
$

[hellsop.livejournal.com]

also

$ foo=$(($a+1))
/bin/ksh: a: expression recurses on parameter `a'
$

[erik]

(and in fact the last time I was using BASIC (which admittedly was Cro Magnon BASIC on I believe a Commodore PET), it would do what I think. I did it all the time, that's where I came up with the example. (if foo<128, foo=foo+128, endif. Ta da! Force caps!))

[erik]

(sorry, make that -64, not +128. Been too long.)

[king-tirian.livejournal.com]

Huh, every flavor of BASIC I ever used (including but not limited to QBASIC, QuickBASIC, and Visual Basic for DOS) was different and very strongly typed. "a"+1 would generate a syntax error. If you wanted to turn "a" into "b", you'd need to do CHR$(ASC(foo$)+1)), and if you wanted to turn "a" into "a1", you'd need to do foo$ + STR$(1).

[erik]

interesting.
Either I'm misremembering the multiple layers of casting as in your example (it was 25 years ago, after all) or maybe I was doing peek-poke things to get around it...or Commodore BASIC was different.
All are equally likely.

I know that TUTOR (the language I worked in professionally in the 80s) and original K&R C both do it my way. C especially I remember transitioning from K&R to ANSI C and running up against the typing restrictions.

[http://users.livejournal.com/merle_/]

You're probably just channelling old C memories, not BASIC.

char a = 'a';
a = a + 1;
/* a == 'b' now */

If your character is represented as a char/byte, then yes, incrementing it shifts the letter up. But if it's a string then it depends on how "+" is interpreted: either it will concatenate a "1", or, horrors, it will increment your pointer and...

Some BASICs let you work with character codes. Commodore BASIC had tons of poke/peek/call things that were basically invoking magic machine code, so you would probably have been passing char/byte values around.