Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

With untyped languages, essentially everything is a (shitty) sum type because of runtime tagging. Tags <-> sum type.


You can do dynamic tagged values in Go, too. It's called interface{} and everyone hates it. So this does not respond to the parent's point.


I'm not arguing untyped is good: it's most certainly not. Everything nullable is also bad, and also introduces a limited some type (Maybe).

What I am saying is if you have static types (good) but don't do anything else, you loose sums (bad). You then need to add (back) sums.


Please don't spread this flamewar-provoking way of speaking about type-systems.

Firstly, dynamic languages are typed. The word "untyped" has a very specific meaning in a narrow branch of computer science, as in "untyped calculus", which refers to a situation in which the types of the syntax tree nodes of the program are not being taken into consideration. (Which doesn't mean they don't exist, by the way!)

In sofware engineering, an untyped language is something utterly unsafe, like assembly language or BCPL, where every value is just a machine word, and the meaning/type of a machine word is just that of whatever operation is being applied to it at a given spot in the program.

Dynamic languages are typed, and even to the extent that some of them do assign type to the nodes of program (type inference).

Secondly, a "tag" is an implementation concept. A tag typically does not give all of the type information about an object, or not about every object kind. There may be more than one kind of tag used. For instance, a value might have a two-bit tag indicating a crude classification of a value into four categories. For an unboxed fixnum integer, that indicates the exact type (fixnum), but most heap objects might be lumped into the same category accordint to that tag, distinguished by a more comprehensive type tag that might take on, say, one of twenty values. That tag is also not complete information for all objects. For instance for an OOP object, the tag might indicate "this is an OOP object", without regard for its class: all OOP objects might share the same tag. Yet, at the language level, their type is their class. Another example is functions. All functions might have a tag indicating "this is a function". There might be a separate tag for things like compiled function, interpreted function, foreign function or whatever. But the type of a function takes into account not just that it's a function, but other properties like number of arguments. In many dynamic languages, you cannot call a two arguments function with three arguments. That check doesn't come from the tag, which doesn't have that information.

The type of an object in a dynamic setting goes beyond the tag. For some objects, the word tag tells everything, and the heap tag does for others; but not for all object kinds.

When the dynamic language implements a type inference system, the truths which that inference system works with cannot simply be reasoning about tags. The representation of type has to include concepts like the class of an object, or the number of arguments and types of a function and its return type.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: