You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
one of the key things a useful language needs to have to get work done is some way of evaluating the 'truth' of things. some have explicit true/false values and all else is a type error, some coerce some types into some specific type for evaluating truth (a common one is evaluating things to an integer, and using 0/nonzero)
for my purposes, i'm borrowing from erlang and having the atoms 'true' and 'false' be my canonical boolean values. but there's a great deal of utility in being able to consider the results of many operations to have a truth without having to do some mechanical test when the result should be some kind of inherently obvious.
on the other hand, i don't want to fall down the javascript hole where nearly everything can be considered to be true or false, somehow.
enter the falsifiability concept:
empty objects evaluate to 'false'
non-empty objects capable of being empty evaluate to 'true'
anything else produces a falsifiability error (this is a fatal runtime fault for a given frf process)
falsifiable types:
integers have an empty state of 0
floats, with effort, can be considered to have an empty state of approximately 0.0 (i'll be relying on a 'nearly equal' implementation for testing equality of floats anyway)
strings have an empty state of ""
arrays have an empty state of zero elements
non-falsifiable types (and rationales):
tuples do not have an empty state, because a 0 element tuple is incoherent (because tuples cannot be appended to or otherwise resized after creation, an empty tuple is genuinely a lack of data, and it would universally be better to provide a message of some kind)
variables, function pointers, and descriptors do not have an empty state (because if you somehow have one of those that is not-a-valid-one-of-those it is an error anyway)
atoms do not have have an empty state (all falsifiables evaluate to an atom that is either 'true' or 'false', any other atom is a falsifiability error)
The text was updated successfully, but these errors were encountered:
one of the key things a useful language needs to have to get work done is some way of evaluating the 'truth' of things. some have explicit true/false values and all else is a type error, some coerce some types into some specific type for evaluating truth (a common one is evaluating things to an integer, and using 0/nonzero)
for my purposes, i'm borrowing from erlang and having the atoms
'true'
and'false'
be my canonical boolean values. but there's a great deal of utility in being able to consider the results of many operations to have a truth without having to do some mechanical test when the result should be some kind of inherently obvious.on the other hand, i don't want to fall down the javascript hole where nearly everything can be considered to be true or false, somehow.
enter the falsifiability concept:
falsifiable types:
non-falsifiable types (and rationales):
The text was updated successfully, but these errors were encountered: