How Console Displays Things With No Literal Representation

It's tricky to think of what to do to print out things that don't have representation.

For example, isotopes ("antiforms") don't have representations and cannot be molded. (For a proposal of the exception of MOLD of splices, see MOLD/ONLY vs spread)

So what's traditionally been done is just render it as a quasiform (so the tilde at the beginning hints something its up), and then add a comment at the end of the rendering.

If the renaming of "isotope" to "anti" were taken, this would look like:

>> anti 'null
== ~null~  ; anti

The representational issue is a bit of a thorn in the console, but you have to print something. (Well, unless it's a void, where printing nothing is the design.)

Could it perhaps work to just print anti 'null? (Or unmeta 'null, as the case may be.) After all, they don’t really have a syntactic representation to print out in the first place.

For prior art, Haskell often does this kind of thing:

ghci> import Data.Map.Strict
ghci> fromList [('a',1), ('b',2), ('c',3)]
fromList [('a',1),('b',2),('c',3)]
ghci> singleton 'a' 1
fromList [('a',1)]
ghci> empty
fromList []

Among things that have historically lacked literal forms are objects, so giving back code is what it has done:

>> make object! [a: 10 b: 20]
== make object! [a: 10 b: 20]

The idea that all things need literal forms gave rise to "construction syntax", which was a series of proposals going in this direction:

>> make object! [a: 10 b: 20]
== #[object! [a: 10 b: 20]]

Avoiding that direction and having the console endorsing giving back things that evaluate to the result is another idea:

>> first [a b c]
== 'a

>> any [1 > 2, 3 > 4]
== ~null~

But would be confusing if you didn't do it systemically, e.g. left the quote off of inert things:

>> first [[a b] c d]
== [a b]

>> first ['[a b] c d]
== ''[a b]

So I think the quote would probably need to always be there... and maybe people would get used to it to the point it would be acceptable. Generic quoting opens the door to it being an option.

>> print "Void outputs should still be skipped, probably?"
Void outputs should still be skipped, probably?
== '

>>

This could work if done systematically… but then, you have to consider that you’re no longer looking at the result of your evaluation, but something which evaluates to the result. That feels confusing.

I think there’s a reasonable compromise similar to what is done now: show the literal form of the value if it has one, otherwise give back code which evaluates to that value. That would be unambiguous and consistent, but still easy to read.

2 posts were split to a new topic: Why is TYPE OF 1 an &INTEGER and not INTEGER!