Yann Guidon / YGDESWhat's best ? Pascal's strong typing or JS' weak typing ?
Both have excellent arguments but also significant drawbacks.
It's hard to reconcile both.
Since BCFJ starts as an interpreted language, typing can be weak and in fact, the first type is "a number" (think "int" in C).
Later, when objects ("blobs") are introduced (à la JS) a stronger typing mechanism can be introduced. The trick is to have/check the "type" attribute, which points to a collection of handlers that then resolve the types, convert or compute values...
So BCFJ does not enforce a typing mechanism or precise resolution behaviours from the beginning (this removes a LOT of red tape from the language). Later, conventions can be added to prevent inconsistencies or adopt the preferred behaviours.
So BCFJ starts "naked", like in FORTH, with an "integer" type, which is then completed... See the next logs.
Oh my...
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
You can please some of the people all of the time, or all of the people some of the time.
It appears to be universal :-D
Are you sure? yes | no
I know. This is why I stick to the goal : to develop a software framework to help bootstrap the ecosystem of my CPUs. That's why a non-perfect but flexible and functioning language is required, starting with a small scripted kernel (that doubles as a command-line interface) that evolves enough to write an assembler or a compiler (for itself or other languages). So BCFJ is a mean, not an end :-)
Are you sure? yes | no
I thought you'd like NaN lol. I didnt encounter it until I began throwing geometry around and made some funny values. ;-p
Are you sure? yes | no
One thing at a time, please ;-D
Are you sure? yes | no
How about Python's Dont Care attitude, and treat all things as equal unless they arent?
I like how Python converts inline so you dont have to declare types, but has a very formal way of going about the conversion.
I also like NaN, which resolves to zero with a warning. Please :-D
Are you sure? yes | no
The problem is that conventions, you know... everyone has their own.
And I care about coherence. I know it can quickly stab you in the back so I'm careful...
So by default, don't play with things that are not of the same type :-)
And NaN is another can of worms... Too many JS memories :-P
Are you sure? yes | no
Funny thing : JS provides the "==" and "===" comparison operators. The "===" checks if both operands have the same type and this is the behaviour that I prefer...
Are you sure? yes | no
Just so long as you make it complain about
if a = 0
and
a == 0
because Python does and C doesnt always. Its my favourite trick forgetting an equals, and the only thing I loved about BASIC which I learned first. ;-)
Are you sure? yes | no
Oh, comparison/assignation is yet another subject :-D
In ADA/VHDL there are the := and <= assignation operators (one is immediate and the other is delayed).
Then if == is comparison, we can finally get rid of the ambiguous "=" operator....
Are you sure? yes | no
And since "<=" can be confused with "less than or equal", there only remains "==" for strict equality and ":=" for assignation. "=" will throw an error.
Are you sure? yes | no
"=" can throw an error until you add a computer algebra system to the pre-processor
Are you sure? yes | no
Ted: yep, something like that.
My strategy is to have a configurable parser, a bit like lex & yacc as standard modules, so parsing/analysis can be tweaked at will and the baseline language has a "default configuration".
Are you sure? yes | no
Actually the default equality function for objects in Python (used when you don't define your own) is to compare the object's id, so an object is only equal to itself, and not equal to anything else.
Are you sure? yes | no
Yeah that makes sense, otherwise you'd be able to make the statement
a==0 , resulting in 'a' containing True if 'a' already contained 0, and False if not.
Which results in another bind I have with languages, some use -1 for True and some use 1, and some use a bool type. Python does avoid that neatly by using types for everything and figuring out if it has a numeric value when it needs it.
Are you sure? yes | no
Python's bool type is a subclass of the int type, and True is equal to 1:
>>> issubclass(bool, int)
True
>>> isinstance(True, int)
True
>>> 1 == True
True
>>> 1 is True
False
Same for False and 0. You can actually do this:
>>> 2 + True
3
Are you sure? yes | no