Yuval Kogman skribis 2005-10-18 20:38 (+0200): > the function encode has the type Unsafe -> Safe
I read the article before. What occurred to me then did so again now. What exactly do Unsafe and Safe mean? Safe for *what*? Something that is safe to put in HTML may be unsafe to put in an rfc822 header, and what may be safe there is likely to be unsafe in a shell command line. Instead of Safe and Unsafe, I suggest using safe::html, safe::rfc822, safe::bash, etcetera instead of Safe, and nothing instead of Unsafe. If it's not safe::($usage), then it's unsafe. Just like how something that isn't defined() is undef, without there being any need for an undefined() test. One problem still is that once something is encoded, quoted or escaped it can't always be easily re-encoded. Encoding functions should therefor check if a variable does safe::(none()) and warn or fail if so. I used lc class names, because they're empty roles, used only for decoration and does-testing, and has no methods. I've thought about suggesting such a convention, and this, I guess, is as good a time as any. Another possibility is to use Str types, and coercion for encoding. In that case I suggest the "lit" operator that provides Str::Literal context&coercion, which coerces to any other string type without encoding. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
