Hacker News new | ask | show | jobs
by armchairhacker 1783 days ago
When I write programming languages, I usually define primitives as "any value without children". Strings, numbers, booleans, are primitives. Collections and records are not.

Some edge cases: literal ranges would be primitives, because their ast is represented (in Haskell) as "Range Int Int". Ranges which take values wouldn't be primitives, because their ast is represented as "Range expr expr"

2 comments

BQN uses the term "atom" for such values[0]. They include numbers, characters, and functions, as well as namespaces—really "atom" just means "non-array". These are the values that can't be split apart by array operations, but they might still be made up of multiple things, for example a function train[1].

In contrast, primitives are the starting point for programming, particularly tacit programming ("point-free" in Haskell). While the two names have a similar meaning, I think it fits a little better to call values that are indivisible from a particular perspective "atoms" and the ones that are meant to really be fundamental "primitives".

[0] https://mlochbaum.github.io/BQN/doc/types.html

[1] https://mlochbaum.github.io/BQN/doc/train.html

Are you saying that you consider strings in Haskell to be a primitive?
No, Haskell is weird since a string is [Char]. If it was it’s own value, yes.

The languages i’ve written are pretty basic. e.g. the data types might be

- Number - String - True, false, null - Array of values - Record of fields (key + value) - Variant of options (key + value)

So the distinction is clearer.

> No, Haskell is weird since a string is [Char].

I can think of various langages where string is not a built-in, but i can’t think of a langage where string is not some sort of sequence, not just in its implementation but in its interface.

The definition also breaks down quickly e.g. is a complex a primitive? If not because they have real and imaginary parts, why are floats which have a mantissa and an exponent? And what about functions? What even is a child? Are value-less sum types primitives but valued ones not?

More importantly, how does it matter? What does the distinction you draw provide that is useful?