I faced a circumstance in the CONSOLE, where I wanted to know if you entered nothing. e.g. if you just hit enter:
>> ; <-- hit enter here
>>
So it just cycled, the prompt, no == output.
If you actually loaded the empty code as [] and evaluated it, then you would get a VOID!.
>> ; <-- hit enter here
== \~,~\ ; antiform (void!)
>>
I found that annoying. However, if you actually did put something in there that evaluated to void, I wanted to see it:
>> comment "for example"
== \~,~\ ; antiform (void!)
>>
So sure, I could write:
let code: transcode ...whatever...
if [] = code [ ; nothing loaded
...cycle prompt, don't evaluate...
]
But I got the feeling that a TRANSCODE of an empty string (or string that is all comments") is probably one of those edge cases that people are probably not expecting... and if it happens you probably need special handling. So making it have better error locality and handling by being NULL seemed like a good idea.
So I changed it to return NULL if nothing was transcoded.
if not code [ ; (or `if null? code`, or `code else [...]` etc.)
...nothing loaded, cycle prompt, don't evaluate...
]
BUT having experienced some of the epicycles beyond the console, I think this was a mistake.
Transcode Has A Lot Of ERROR! Returns
If try transcode ... is going to be useful at all, you probably don't want to conflate the many potential errors it can return with just returning null because it was a valid empty input.
And in the basic case, an empty script is a valid script. It does nothing.
Emptiness is easy enough to test for. So I think that's what should be done here.