esotericist / frf Goto Github PK

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)

followup to #1
it actually looks like bdw-gc provides an immutable string library remarkably similar to what i implemented after cribbing off of sds to produce sfs.

someday i need to pursue moving from my ultra homebrew kitbashed solution to one made by real programmers.

the design of frf, as with the languages it draws from, assumes most kinds of data are immutable. anything that is changed within a string or container is effectively "copy on write", producing a new object.

sds, the string library i started with, assumes for several functions that strings provided to it are valid scratch space, which invalidates the original string pointer.

this is incompatible with the presumption that a string, once pushed on the stack, no matter how many times, will continue to be that same identical string until it no longer has any references remaining. i keep having to fix bugs related to that incompatibility in worldview, because i expect my data not to get trampled by a thing that's supposed to produce new data.

need to do one of:

• replace sds entirely (unlikely)
• reengineer sds to not abuse inbound strings as scratch space (plausible, but a lot of work)
• aggressively wrap sds so that it never directly receives upstream strings (e.g. lots of sdsdup() invocations)

third solution is most likely. doesn't preclude moving to another solution later.

defines that expand to multiple tokens (e.g. "} array_make") only seem to expand the first token in the definition.