Yes, but I'm pretty sure it doesn't memoize the checks, and elimates
them, after passing them...
Oh, right. I missed part of your point. Thanks for clarifying.
Simon Danisch, I didn't read too closely what you wrote but what you are
proposing sounds a lot like staged functions. Keno is currently working on
implementing staged functions with proper compiler support. You can look
at that current pull request as well as seach the dev list for a more
# don't neccessarily need to be of the same type, but which type to return if
not the same?
Wouldn't something like promote(typeof(a), typeof(b)) be in the spirit of
Julia?
@Jake Bolewski
Interesting... Staged functions seem to solve exactly this =)
Guess, that puts me on the list of people, waiting for this!
So now, one just needs a nice way, to define groups of similar types.
But probably its enough to just define a function like:
`isvector(x::DataType)`
One might rather choose for example the type of the first parameter,
making + non associative.
Hmm, I'd leave such abominations to the creators of Java, who managed to
forbid operator overloading for simple folks just because they got it
horribly wrong with + for (String, anything), making +
Generally I find that code patterns like this (e.g. using eval) means you
have structured your code poorly and made various brittle / non-composable
assumptions, which will just be lurking out there waiting to bite you (or
more likely your users) later on:
Well it could be, but I was thinking of
