BCFJ's fundamental type is equivalent to BASIC's number, or C's "int". It's enough to get a few things done but won't go far...

Scalar types :

Defining the size explicitly is important, otherwise many problems appear.

Integer numbers are either signed or unsigned so the following types should be supported (if the processor can handle it) :

S8, S16, S32, S64 : Signed integer of 8/16/32/64 bits
U8, U16, U32, U64 : Unsigned integer of 8/16/32/64 bits
F16, F32, F64 : Floating point of 16/32/64 bits

(I didn't add support for logarithmic, unlike in the early F-CPU, which was a dead-end...)

Characters... Are another thing. ASCII is only a relic now and UTF8 is the norm, which can have a crazy dynamic range. The norm limits the size to 21 bits (assembled from 4 bytes) so there is no actual "character" type as in C because the representation can vary wildly. However, intermediary types are possible for various representations (UNICODE point or byte serialised).

Strings too can have multiple representations (point or byte) and can't be handled directly in the core language. Yet this is very important and useful so a careful and simple design is required early on. Without proper string handling, no parser is possible... Usually, strings are very easy to process in plain ASCII but I don't want to make an ASCII mode at first because UTF8 will never get implemented later. Is the development of UTF-8 library holding everything back ?