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 cue 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.

I will be interesting to see how this combined number data type plays with the Zig/CPP/C interop feature: https://github.com/buzz-language/buzz#call-czig-code

Thanks, yeah that makes a lot of sense. I do tend to conflate the two concepts.

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)

They are not ducks, they are two different animals, even if you disregard binary representation.

It may be strong typing, and there are just no ints. This is how JavaScript works: all numbers are f64.

Then what is: 1 << 33

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.

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.

Exposing how? If you mean documentation, Buzz as not yet its reference manual but it'll definitely be there.

> Exposing how? If you mean documentation

No I mean as an actual type, instead of `num` juggling representation internally.

Lua has the same strategy as Buzz around numbers see https://www.lua.org/manual/5.4/manual.html#2.1

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.

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.

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.

> Numbers are either internally i64 or f64 and are coerced from one to the other as needed

I agree, not quite my preference in scripting languages. I prefer to be able to deal with numeric representation.

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.

https://hackage.haskell.org/package/base-4.17.0.0/docs/GHC-N...

I too would really prefer int & float!