Maybe I'm just old, but first thing I would look for in a strongly typed language is int vs float, but all I see here is num. Is a single numeric type expected for modern languages?
I think it's more to do with it being a scripting language. Scripting languages are designed to be quick and easy to write, so instead of having to deal with int/float etc, the language can do it for you.
Makes sense, and I guess it’s semantics, but if the language/interpreter is handling which numeric types to use for me, should it really be sold as “strongly typed” in the main tagline for the language?
Internally, float and int are completely different types, 2’s compliment vs ieee754. Conglomerating them to a “number” feels like weak typing.
(Disclaimer: I’m a grumpy C++ engineer.)
Edit: it does look like a neat/useable language though!
Typing is technically a distinct concept from binary representation, it just happens to be a very useful concept for interpreting bits. If the set of valid operations is known at compile time with no exceptions, I'd call that strong typing regardless of whether the internal representation changes during execution.
The problem I do see with combining int and float is that it means that you always have to be careful with == on any pair of numbers, where a language that does distinguish between the two gives you a clue about when equality will work and when it won't.
But that's a flaw in the number type, not a weakness in the type system.
Those are representations, not types. I think they are using the "what can I do with this" definition of type, which is just its public API, and nominality (walks like a duck, quacks like a duck, doesn't mean it's a duck)
Hmm... it's 2. It seems that the bitwise operators do indeed convert numbers into 32 bit integers (truncating any decimal parts) before applying their operation.
I'm not excluding the idea to allow the user to choose between the two. But the language must remain simple and relatively high level so I'm wary of going down that road.
The big problem I see with combining the two types is that it means that a user must always consider that the values they're using may have passed through imprecise floating point arithmetic, so the == operator is always potentially problematic. If you divide the two out into separate types, then the user can use == on ints without any concern, and it better reminds people to be careful with floats.
I definitely wouldn't break it out into int, long, float, double, and unsigned variants. That would be too low level for this kind of language.
I think it's fine to not offer all unsigned/signed variations, but in languages like TypeScript I often miss this distinction. Even Python differentiates between int and float where it is relevant, for example when indexing arrays. Sometimes you just don't want to mix the two.
Segmenting the two and performing conversions implicitly as necessary is fairly standard, the only thing that would be required is... exposing the current implicit behaviour.
Python, Ruby, or Lua do that. That's less "nonsense" than doing the same but hiding it from the user.
"num" also gives a false impression: before checking, I expected JS's (or Lua < 5.3) behaviour: everything is a double, and you only get 53 bits of integer precision (which is quite frustrating).
An alternative if you want
> simple and relatively high level
is to use decimals, at the cost of complicating the implementation.
If you want to make a strongly typed language and not repeat the mistakes of Javascript, you should make them distinct. In striving for simplicity it is much easier to accidentally arrive at simplistic.
Not sure what 'num' means in buzz exactly, but it could be something like a Haskell class, choosing the specific instance/implementation automatically, while also allowing explicit specialization if needed.