[swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Richard Wei]

> On Nov 1, 2017, at 21:13, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Nov 1, 2017, at 3:20 AM, Richard Wei <rxrwei at gmail.com <mailto:rxrwei at gmail.com>> wrote:
>>>> 
>>>> Since you bring it up, Python exceptions will be annoying - As with other languages, Python can throw from an arbitrary expression.  Modeling everything as throws in Swift would be super-annoying and unergonomic for the programmer, because we'd require 'try' everywhere.  Thoughts on what to do about that are welcome!
>>> 
>>> Requiring ‘try’ on every statement is annoying, but not having the ability to catch python exceptions is annoying too. We could probably make python exception handling an opt-in feature. For example:
>>> 
>>> try Python.do {
>>>     let a = np.array([1, 2, 3])
>>>     let b = np.array([[2], [4]])
>>>     print(a.dot(b)) // matrix mul with incompatible shapes
>>> }
>>> catch let error as PythonException {
>>>     // Handle PythonError.valueError(“objects are not aligned”)
>>> }
>> 
>> To correct my example:
>> 
>> do {
>>     try Python.do {
>>         let a = np.array([1, 2, 3])
>>         let b = np.array([[2], [4]])
>>         print(a.dot(b)) // matrix mul with incompatible shapes
>>     }
>> }
>> catch let error as PythonException {
>>     // Handle PythonError.valueError(“objects are not aligned”)
>> }
>> 
>> Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.
> 
> That’s a super interesting way to model this.  I’ll need to ponder on it more, but  it is certainly a nice ergonomic solution.
> 
> Question though: how does it work?  Say the first np.array call threw a python exception:
> 
>> try Python.do {
>>         let a = np.array([1, 2, 3])
>>         let b = np.array([[2], [4]])
>>         print(a.dot(b)) // matrix mul with incompatible shapes
>>     }
> 
> 
> We can definitely make the python glue code notice it, catch it and squirrel it away somewhere, but without compiler hacks we couldn’t make it jump out of the closure.  This means that np.array would have to return something, and the calls below it would still execute, or am I missing something?

We make PythonObjects internally nullable (only in the exception-caught state). The second np.array would just return a null PythonObject.

To be specific, we define three states in the python overlay:
- Normal state: PythonObjects are guaranteed to be non-null. Any exception traps.
- Exception-catching state: PythonObjects are still guaranteed to be non-null. Any exception triggers the exception-caught state.
- Exception-caught state: PythonObjects are nullable — all python expressions return a null PythonObject.

The exception-catching state is entered during the execution of Python.do’s body.

-Richard

> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> 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/20171101/ecd7ec98/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171101/ecd7ec98/attachment.sig>