Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

defining booleans #3

Open
esotericist opened this issue Nov 12, 2021 · 0 comments
Open

defining booleans #3

esotericist opened this issue Nov 12, 2021 · 0 comments

Comments

@esotericist
Copy link
Owner

esotericist commented Nov 12, 2021

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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To do
Development

No branches or pull requests

1 participant