[swift-evolution] Epic: Typesafe calculations

[Thorsten Seitz]

> Am 13.01.2016 um 20:37 schrieb davesweeris at mac.com:
> 
> Matt, funny you should use that example… We might be trying to work on the same sorts of problem :-)
> 
> Thorsten, I don’t see why it wouldn’t work for any immutable matrix (literal or otherwise), or even mutable matrices if assignment operations were allowed to fail*, or Swift supported class clusters (such as NSNumber, appropriately enough) it could just change its “private” type behind the scenes if needs be (at least I think I remember reading that NSNumber does that).

Ah, ok, I see what you mean. The question is when should determinant() be calculated? If Matrix is immutable it can be done just after initialization and be memoized. Or lazy at the first time the dynamic type is needed (and then memoized). This would add a lot of complication, though.

A very nice research language called Cecil (by Craig Chambers from the University of Washington, later replaced by the similar language Diesel) once had a feature like that. They called it "Predicate Objects“ (see http://www.cs.washington.edu/research/projects/cecil/www/research.html#cecil). 
Cecil had many very nice features like multimethods with multiple dispatch implemented in a quite nice way.

-Thorsten
	
> 
> [At this point I remembered that Matt was thinking the “where determinant() != 0” part was specifically going to be a compile-time check, and pretty much everything I’d written was coming from the run-time point of view…] Ok, so… what if “where” clauses in the “inheritance" section forced all the initializers to be failable, and there was an implicit “if !(where clause) { return nil }” inserted at the end of every initializer? It’d cut down on boilerplate code, and it’d tell whomever was looking at the public interface two things: 1) That all the initializers had “universal precondition”, and 2) exactly what that universal precondition is. I mean if you were using a matrix library and only had what they exposed to go on, which would be more useful to you, having an API note that says, “blah blah square matrix blah nonzero determinant blah blah”, or being able to examine the actual bit of code that will determine if your data can pass the “universal” validation check?
> 
> *Yes, I know you can use will/didSet to roll back the changes if the new value fails some validation check. I can’t figure out a way to get those to throw errors, though, nor is there currently a way to have subscript() throw an error (somebody’s already filed a radar about that). Since there’s no way to alert the programmer that the assignment they just performed might not stick, this seems like a colossally bad idea (for general code, anyway… obviously if it works in your specific situation, then go for it).
> 
> - Dave Sweeris
> 
> (At what point does something need to get split off into its own thread? Because after typing this all up, I’m not sure it’s particularly related to what we’ve been talking about here.)
> 
>> On Jan 13, 2016, at 09:56, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> Am 12.01.2016 um 23:49 schrieb Matt Whiteside via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> struct InvertibleMatrix: SquareMatrix where determinant() != 0 
>>> //                       ^~~ 'restriction’ clause, i.e., not inheritance;
>>> //                       determinant() is executed at compile time,
>>> //                       since `entries` is a constexpr
>> 
>> Wouldn't that only work for literal matrices?
>> 
>> -Thorsten 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/7ecea7b1/attachment.html>