We have a few "types" where the naming is not perfectly consistent across the user facing interface:

• The commands specific to the type (e.g. date now)
• The Type name accessible through describe (e.g. 1.0 | describe float)
• The SyntaxShape i.e. the thing you can cue the parser to which is the thing the type annotations in defs are turned into (e.g. def foo [bar: datetime])
• Documentation inside and outside the application when referring to that.

On top of that our internal symbols should follow the same names for better discoverability.

✔️ decimal -> float

Here the direction to move is obvious as float is more true to what the capabilities of the underlying data type is (not money-safe, fast for approximate math)

date vs datetime

This is more contentious: date has a nice brevity for the command names but the capabilities for time are expressed by datetime

• date ... family of commands (effectively the methods/class functions :P)
• format date as the corresponding format command
• into datetime as the cast
• seq date for sequence generation
• Type::Date
• date now | describe returns date (rename date type to datetime #10298)
• SyntaxShape::DateTime
• For command arguments : datetime
• date as the thing to style in the config (see StyleComputer)
• (Dataframes make a distinction between the two types: dfr as-date and dfr as-datetime)
• FlatShape::DateTime
• Expr::DateTime
• Category::Date

✔️ int and integer

bool and boolean

TODO

$nothing/null and nothing

• deprecate $nothing in remove the $nothing variable #10478

See #9973 and #9918

Addendum Path

To the user the distinction between Type and SyntaxShape is probably not strictly obvious. We should also try to get them as close as possible. Here a notable outlier is for example :path is SyntaxShape::Path that enables important completions but doesn't exist inside the Type/Value system