Strange thoughts:
what if
#false == nil == the empty set
#true == the infinite set
(shut up Bertrand Russell I am here assuming some kind of set membership condition can be defined such that an actual infinite set exists)
then
not x == invert the members of x
(a . #true) == literally a asserts EVERYTHING assertable
Can we then model all X as (X . #true) or is that still inconsistent?
I keep wanting, you see, to represent all kinds of structured data as functions. (Because we already have functions, that's why. It's not an especially good reason, no. But it's a reason.)
That means I want to represent BOTH 'binary relation' AND 'set' - any intermingling of them - losslessly, as a single function.
This may be impossible. But is it?
A function can represent a relation if we restrict it to always returning a set-or-function. (Or a list/array, if you want to be ad-hoc. That's the usual solution. I'm not pursuing it because I don't like it).
If the key/argument is not in the relation, you get #nil. #nil could then be thought of as a function that always returns #nil
If the key/argument has multiple values, you get one function where the arg is the value and the value is..... what?
We need a consistent sentinel value. #true?
The standard way of representing sets as functions DOES use #true (not necessarily defined as 'a very large set or relation')
But the standard way does not assume that you ALSO might have key-value pairs in your set as well as just members.
I want that very awkward and stupid thing because, well, I'm dumb.
The problem is a Goedel-like conundrum, that for any given sentinel value you might choose to return to show 'just set membership', you might ALSO want to represent that value as a legitimate value in a key-value pair.
Is that the end of the matter? Or could we get by with a very small restriction that 'you just can't ever use #sentinel as the CDR of a pair'? And would #true be a sensible sentinel? Or not.
(Sure you could put your code into a database as raw strings, but the whole POINT of Lisp is you DON'T do that, you put your code in as parse trees and you execute it as parse trees. And if your parse trees include both a Forbidden Symbol AND dotted pairs - as, eg, Scheme variable assignments do - then you're in for a world of hurt).
@natecull zero terminated strings were a big mistake, same for lists, maybe?
@saper Maybe! They have ups and downs. This is where there's a big war between the Lisp way of lists-as-nil-terminated, and the Maths way of lists-as-sequences-of-CONS-operations, which means the last one in the sequence is a raw value and there's no nil, and it's really a tuple not a list.
The Lisp way is nice in many respects because a list always recursively decomposes into 'head, and then tail' and 'zero-length list' is a perfectly sensible tail. It's not really a sentinel like C strings.
@natecull @saper Fascinating digression for me because my teaching/experimental Assembly language Mu[1] has length-prefixed rather than null-terminated arrays/strings. But it ALSO has s-expressions to represent types. And I started out[2] with the s-expressions not being nil-terminated, before switching to nil-terminated lists[3]. So I have the scar tissue showing those two are not the same issue at all.
[1] https://github.com/akkartik/mu
[2] https://github.com/akkartik/mu/commit/af023b323b
[3] https://github.com/akkartik/mu/commit/93d4cc937e
@saper Good question. That happens in `create-array`, which yields fixed-size arrays (like `int[3]` in C). Idiomatically, I tend to use addresses to arrays, which are like `int[]`. Either way, arrays record their length in their value at runtime. But you can know the length of a fixed-size array ahead of time. That's what you're seeing.
/cc @natecull
Dave Childs claimed he'd solved this and made it consistent by using #nil as the sentinel. Which, I just don't understand how that can be consistent. All I can assume is that he's never tried to directly represent Lisp nil-terminated lists in his Extended Sets formalism. Because they just don't work. nil-as-membership-sentinel clashes with nil-as-CDR and it all falls apart.
it's 'good enough for databases', but NOT 'good enough for code'.
A database you can't put source code in is a bit naff.