Alternative method for defining statically typed variables

I've been thinking about the feasibility of a type system that incorporated the type of variable into its name using symbols.

E.g.:
var @4-VariableName;

The system could use symbols like @, #, $ and % for signed, unsigned, character and object and the number would be the size of the variable in bytes (objects wouldn't have this) and the hyphen to separate the name from the type. The symbols would be used every time the variable is used (for the programmer's advantage of readability).

So what are people's views on this idea?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Something like this?

Something like Hungarian notation (but as more than just a convention)?

Yes, as in the symbols would

Yes, as in the symbols would tell the compiler as well as the programmer the type of variable.

Would this system of static typing be useful or outdated compared to systems such as the system in C?

Sigils

As John W Cowan and Ray Dillinger mention, this convention is well-known from early BASICs and from scripting languages; the symbols which are adjoined to the variable name are called sigils.

A related convention used in FORTRAN was to assign implicit types to any variables starting with certan letters. By default, all variables starting with I, J, K, L, M or N were considered integers.

These conventions have nowadays been abandoned in statically-typed languages, since most of them require explicit declarations anyway. IDEs can parse these declarations and show variable types in a tooltip, so the readability advantage is also negligible.

In some special cases, it may be worthwhile to adopt the convention from mathematics of assigning different formats to different identifier types, since formats tend to be more readable than sigils or Hungarian-like prefixes. But such conventions would require special support and have to be chosen on a case-by-case basis.

Hence the joke:

"God is real ... unless explicitly declared integer."

That looks painful...

A simple refactoring task might need to touch every variable.

Generic programming would be similarly difficult.

The same anew, the same anew

10 INPUT LINE FOO$
20 BAR$ = FOO$ + FOO$
30 PRINT FOO$
40 END

Yup.

Those very early BASICs did exactly this. $ was used to prefix variable names containing strings, # for numbers, etc.

Folk didn't like it, apparently; it was one of the first things that BASIC dialects dropped from their design, along with nontarget line numbers.

Back to BASICs

Just what I thought when I read this proposal, too :-)

Perl

I'm surprised that anyone could read this question and not think immediately of Perl. Indeed, vrijz's link suggests that the CS usage of the term ‘sigil’ was introduced in precisely that context.

For what it's worth, I find the decorators very handy, and often miss them when I read languages with typing systems stronger than Perl's but weaker than Haskell's (which is just about all of them, I guess); but they seem widely reviled outside of Perlist circles.

problems with this approach

There are two obvious issues with this approach; both
have to some extent been addressed in modern Basic dialects.

  1. It doesn't scale to arbitrary user-defined types: if $ indicates
    a string, what should we use for a rank-4 array of priority queues
    of some user-defined type?
  2. As already noticed, the system makes generic programming difficult:
    what is the sigil for a type variable?

Modern Basics typically allow the sigil system to be used for
a few fundamental types (string, int , float) and use explicit
declarations for everything else.

One unsuspected language which has something similar to this
is Standard ML, but then at the level of types.
In SML, a type variable can either be of the form 'a, 'b, 'c,
which means it is fully unconstrained, or it can be ''a, ''b, ''c,
which means it is an equality type.