Type System Through Comments

Those that use a language without a proper type system are (or can accidentally be) liars, and should implement types into the source comments if held at gun point and forced to work with an improper language. See also WeakTypesLie and LooseTypesSuck.

Put the type system (or hopefully some of it) into the source comments. Or at least, one should.. because all languages need truth. 

  $var = 'hello';   // type: string
  $iMain = 5;       // anything starting with "i" will be an integer in this program


  // this function ONLY DEALS WITH INTEGERS (oh shit, it's a function? or procedure? I forgot)
  function foo($i)
  {
      $i[0] = 'h';
      $i[1] = 'i';      // oops, I like to lie
                        // hehehe I'm a liar pants on fire
      print $i;
  }




  // this function DOES NOT RETURN ANYTHING, IT IS NOT A FUNCTION (IT'S A PROCEDURE)
  function bar($i)
  {
      return 'hi';    // I like to lie
                      // hehehe I'm a liar pants on fire
  }

Many low level languages do this. For example, AssemblyLanguage and ForthLanguage primarily use machine words (cells), so typing is by convention. In Forth, this is expressed via "stack comments" which take the form ( stack before -- stack after ). It is up to the programmer to obey and enforce the comments, via careful programming and thorough testing. e

This page was started because an opinion is (a strong one.. maybe even a right one) that type systems keep code readable, sterile, sane, and integral. They allow humans, not just compilers, to check over and keep code sane. As Dijkstra put it - once upon a time doctors (professional surgeons) did not believe in sterility because real doctors and real men performed surgery without cleaning/boiling their utensils.

If one had to keep his utensils sterile then he obviously wasn't very competent nor was he skilled because real surgeons could perform surgery with any utensil. Similarly, arrogant programmers have an attitude that code does not have to be kept sterile because real programmers can code correctly using assembly language or PHP with no sound type system.

Empirical studies showed that hand-washing helps. There's no equivalent for a "scriptish" style, at least not across all domains. Thus, your analogy is weak at best. And I find your "arrogant" comment, well, arrogant. And, you keep stating it over and over, making this slothful-versus-anal fight last forever. Until there is empirical evidence, the arrogant one is the one who claims objective net advantage before the proof arrives. (Incidentally, I don't really like PHP's type system either. I'd prefer no types to half-assed types: TypelessVsDynamic) --top

[You'd prefer no types? Really? You mean in PHP you'd rather there were only undifferentiated bit strings of arbitrary size (i.e., a blob), and would prefer to identify what a particular blob means purely by choice of operator? To add two integers you'd have to do something like '4 +I 3', and to add two floats might be '4.2 +F 3.5', and so on. Of course, it would mean something like '4.2 +I 3.5' would return an unpredictable result -- which would depend what the internal representation of a float becomes when interpreted as an integer. Are you sure you don't mean you'd prefer a different form of DynamicTyping?]

It would take a while to describe the comparison operator system I'd personally prefer. However, I will point out that one usually does not have to distinguish between integer and floating arithmetic. If two integers (nums with no decimal places) are added, the result should always be an integer. (Whether existing engines do that or not is another matter.) And something besides "+" should be used for string concatenation. Further, 4.2 +I 3.5 is poor form. It should be rewritten as something like round(a) + round(b).

[I'm sure 4.2 +I 3.5 is bad form. It was an illustration, not a suggested syntax. I wrote that you'd have to do something like it, not that you'd have to do it. So... You'd like something closer to the metal than C, but not as gnarly as AssemblyLanguage or as, uh, Forth-ish as Forth? Interesting. I'd never have taken you for that much of a low-level, down-and-dirty kind of programmer. Do you secretly harbour a desire to be an EmbeddedSystems coder? Is writing reports and business apps just the day job, and you long for the romance and swashbuckling adventure of washing-machine controllers and engine management units?]

{Eh? He said "nums with no decimal places", so obviously his 'typeless' approach has enough of a type to distinguish decimal-place bit-patterns from other bit-patterns. Perhaps he's aiming for EverythingIsa string. That's not quite so close to the metal as you describe here.}

[I know what he meant. My tongue was firmly embedded in cheek when I wrote the above.]

That is "characteristics of numbers". Numbers can have a lot of characteristics: decimal place quantity, positive, odd, by-tens, etc. etc. etc. Such can be represented as types if one wants to shoehorn their world view into types (EverythingIsa), but that is not the same as *being* types and only being types. I find a set-theory-based "feature" view more flexible and scalable. Stuff has features, and a list (set) of all possible features usually does not fit well into type systems because type systems get unbearably messy and difficult to maintain if they drift too far from trees. Why should "integerness" be treated significantly different than "positiveness" or "even-ness"? Why have one be inside the formal type system and the other be out? It is a design DiscontinuitySpike. Byte the bullet and go attribute sets all the way for consistency. (Perhaps take this to SetsVersusTypes.) --top

{Nothing about TypeTheory requires types in a TypeSystem be exclusive; they can overlap as much as sets - even more so, given possibility for dualities that sets alone lack (type can relate to intersection or union or subset or superset depending on context and semantics). I've worked with languages where 'prime integer' or 'even positive integer' can easily be declared as a type for a variable. I'll agree that most production-language type implementations aren't quite as flexible as is desirable; they tend to aim for easier implementation or guaranteed termination at some loss of generality (and in some ways are 'simplistic' for it - when they force someone to work around the type system rather than with the type system), though they often guarantee the goal of TypeSafety.}

A sufficiently-powerful "type system" that can handle lots of variations of features well will more or less trigger GreencoddsTenthRuleOfProgramming.

{In any case, 'by-tens' and 'decimal place quantity' aren't characteristics of numbers, but rather of the representation of numbers.}

Since anything we model in the computer is merely a representation, such should go without saying.

{Incorrect. Everything we model must be represented, but we don't model only representations.}

Compare with ProofAnnotationsForBubbleSort !

MayZeroEight

CategoryLanguageTyping, CategoryTypingDebate

EditText of this page (last edited August 6, 2014) or FindPage with title or text search