Previous Entry Share Next Entry
Release 0.6.5
querki
jducoeur wrote in querki_project
Today's release has a few new goodies:


Sensible _or and _and functions: there has been an _or function for a long time, but it was actually the C-style short-circuiting "or" operator -- it produced the first parameter that was non-empty. This is useful, but only occasionally, and isn't what most folks expect "or" to do.

So that function has been renamed "_firstNonEmpty" (wordy, but correct and clear), and I've added new _or and _and functions that work in the more usual way: they expect their parameters to all be true/false values, and they return true iff any/all of those parameters are true, respectively. This should make it easier to do interesting things with _if().


Beginnings of Type Coercion: mindways hit an interesting problem: he tried to say approximately:
[[_if(_equals(My Thing -> Name, ""Expected""), ... do some stuff...)]]
That's nice straightforward code, and seems like it should work, but it didn't. The problem is that Name is its own special snowflake of a Type, because of how it is used and the restrictions on its values. (It is, in fact, the "bootstrap type", created before anything else in the system, because everything else relies on it.) So _equals threw an error because of the Type mismatch.

(Worse, this error would get swallowed, and it would always return false. This was because _if() wasn't propagating errors from its predicate. That's now fixed, and I've put in a general fix so that functions should *usually* propagate errors in parameters correctly, but please tell me if you come across exceptions.)

Anyway, to make this code work as expected, I've introduced a limited but useful notion of automatic type coercion. Basically, there is now a mechanism whereby a Type can declare that it can be faithfully and implicitly cast to another Type. So far, the only usage of this is that Name Type knows how to be coerced to Text Type, and _equals() knows to use Type coercion between its parameters, but I expect us to find many other places where this makes sense. Feel free to request that a coercion be added to a Type or function, if you think it is clearly right.

Note, however, that I'm not going to go hog-wild with this. I've recently been reading this magnificent rant about how horrible a language PHP is, and one of the valid points that it makes is that PHP's ad hockery about type conversion makes it very hard to predict what's going to happen in many situations. So I'm probably only going to do implicit coercion in cases like this, where it is *clearly* correct to do so, and you can make the conversion without losing information. I'm open to introducing explicit casting operators for less-straightforward cases, but probably won't do them automatically, so point out when you think they are needed.


Disabled "XML blocks": a minor detail, but I removed the Actuarius notion of an XML block. Basically, the parser would interpret an XML opening tag at the beginning of a line to be the start of a block, and would do no Markdown parsing until it hit a line starting with an XML end tag. This may be common in Markdown (I'm not sure), but it isn't at all intuitive for QText, so I've disabled it.
Tags:

  • 1
It might be worth creating a pseudo-keyword for the short-cutting logical operators. _andCStyle or _andShort or similar. _firstNotEmpty is obvious as to what it does, but not why I would want to use it.

Possible -- we'll see whether folks care enough. In practice, I don't believe I've seen it used since my original wedding Space, a year ago, so it doesn't seem to be core functionality...

  • 1
?

Log in

No account? Create an account