4 ms·

Thanks for the explanation. Yeah, that is an interesting feature. Sounds like you'll have to do a lot of reading documentations and testing other packages yours

by t_mann 4y ago

Thanks for the explanation. Yeah, that is an interesting feature. Sounds like you'll have to do a lot of reading documentations and testing other packages yourself then. A typing system that allows defining accepted, rejected and 'other' data types for functions (and a compiler flag for either warning about the latter or not) would be interesting. But the original critique also mentioned several correctness issues in the core language itself, so the issue does seem to go deeper.

gugagore 4y ago
There are several correctness issues lurking about in virtually all software. That part of the critique is uninteresting to me. If I want to pull up a blog post about several correctness issues in any programming language, I bet I could. Also depends what you count as correct, see undefined behavior.
- t_mann 4y ago
  > Also depends what you count as correct I feel that should be the job of the authors to think about what correctness means for their application, and under what circumstances they can give a correct answer. Ideally, also warn the user when the inputs don't fall within that domain or give them options to handle such cases. Let's talk about an example: say you have a neat algorithm for fast multiplication of sparse matrices, approximately correct up to a defined Frobenius error. Say we have some reasonable treatment of dimension mismatch and NaN, inf,... with option flags already. Now if I wanted to know whether your algorithm has the same numerical guarantee for a dense matrix, I'd have to read your paper, run some tests, ask around, and I might never be quite sure. It seems much more sane to put the onus on the authors to be explicit about the behaviour in that case. Your and others' comments seem to put the onus mostly on the user for thinking about the behaviour of others' code. That does not seem like a good practice, especially in the context of complex math and nested composition.
oivey 4y ago
You could do something like this: plus_one(x::Number) = x + 1 function plus_one(x) @warn "untested type usage of plus_one" x + 1 end That's cumbersome, but a macro could make it less annoying.
- gugagore 4y ago
  That is not a full solution to the problem of detecting untested types. What if "plus_one" works for Int, Float32, etc. but not with MyNumber, all of which would dispatch to "plus_one(::Number)".

by t_mann 4y ago

gugagore 4y ago

There are several correctness issues lurking about in virtually all software. That part of the critique is uninteresting to me. If I want to pull up a blog post about several correctness issues in any programming language, I bet I could. Also depends what you count as correct, see undefined behavior.

t_mann 4y ago
> Also depends what you count as correct I feel that should be the job of the authors to think about what correctness means for their application, and under what circumstances they can give a correct answer. Ideally, also warn the user when the inputs don't fall within that domain or give them options to handle such cases. Let's talk about an example: say you have a neat algorithm for fast multiplication of sparse matrices, approximately correct up to a defined Frobenius error. Say we have some reasonable treatment of dimension mismatch and NaN, inf,... with option flags already. Now if I wanted to know whether your algorithm has the same numerical guarantee for a dense matrix, I'd have to read your paper, run some tests, ask around, and I might never be quite sure. It seems much more sane to put the onus on the authors to be explicit about the behaviour in that case. Your and others' comments seem to put the onus mostly on the user for thinking about the behaviour of others' code. That does not seem like a good practice, especially in the context of complex math and nested composition.

oivey 4y ago

You could do something like this: plus_one(x::Number) = x + 1 function plus_one(x) @warn "untested type usage of plus_one" x + 1 end That's cumbersome, but a macro could make it less annoying.

gugagore 4y ago
That is not a full solution to the problem of detecting untested types. What if "plus_one" works for Int, Float32, etc. but not with MyNumber, all of which would dispatch to "plus_one(::Number)".