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

[Chris Lattner via swift-evolution]

I tried to send a response to this earlier today but it apparently didn’t get 
out.  If it did, then I apologize in advance for the dupe:

> On Oct 30, 2017, at 10:47 PM, Douglas Gregor  wrote:
 // not magic, things like Int, String and many other conform to this. 
 protocol Pythonable {
  init?(_ : PythonObject)
  func toPython() -> PythonObject
 }
>>> 
>>> It’s not magic unless you expect the compiler or runtime to help with 
>>> conversion between Int/String/etc. and PythonObject, as with 
>>> _ObjectiveCBridgeable.
>> 
>> Right, as I said above “not magic”.  The conformances would be manually 
>> implemented in the Python overlay.  This provides a free implicit conversion 
>> from "T -> Pythonable” for the T’s we care about, and a failable init from 
>> Python back to Swift types.
> 
> Note that, under this scheme,
> 
>   let p: Pythonable = 17
>   let i: Int = p as! i
> 
> will work if Int is Pythonable, but not when p comes back from Python. 

Right.  I don't expect users to traffic in the Pythonable type, it would be 
something that is used internally by the Python overlay.  The only time I'd 
expect them to see it is when they want to make one of their types Pythonable 
(which would be rare, but needs to be possible).

>> I can think of two things that could tip the scale of the discussion:
>> 
>> a) The big question is whether we *want* the ability to write custom 
>> rule-of-5 style behavior for structs, or if we want it to only be used in 
>> extreme cases (like bridging interop in this proposal).  If we *want* to 
>> support it someday, then adding proper “safe” support is best (if possible). 
>>  If we don’t *want* people to use it, then making it Unsafe and ugly is a 
>> reasonable way to go.
>> 
>> b) The ownership proposal is likely to add deinit's to structs.  If it also 
>> adds explicit move initializers, then it is probably the right thing to add 
>> copy initializers also (and thus go with approach #2).  That said,  I’m not 
>> sure how the move initializers will be spelled or if that is the likely 
>> direction.  If it won’t add these, then it is probably better to go with 
>> approach #1.  John, what do you think?
>> 
>>> Presumably, binding to Python is going to require some compiler 
>>> effort—defining how it is that Python objects are 
>>> initialized/copied/moved/destroyed seems like a reasonable part of that 
>>> effort.
>> 
>> Actually no.  If we add these three proposals, there is no other python (or 
>> perl, etc…) specific support needed.  It is all implementable in the overlay.
> 
> Support for working with Python objects would be implementable in the 
> overlay, but the result isn’t necessarily ergonomic (e.g., my “as!” case from 
> a Python-generated integer object to Int, shown above). That might be fine! 
> More comments on this below.

Yeah, I don't think that matters.  The preferred way to do this is to use:

  Int(somePythonValue)

which would be a failable conversion.  somePythonValue would be a PythonObject 
(the struct) not "Pythonable"

 // Magic, allows anyobject-like member lookup on a type when lookup 
 otherwise fails.
 protocol DynamicMemberLookupable {
   associatedtype MemberLookupResultType
   func dynamicMemberLookup(_ : String) -> MemberLookupResultType
 }
>>> 
>>> AnyObject lookup looks for an actual declaration on any type anywhere. One 
>>> could extend that mechanism to, say, return all Python methods and assume 
>>> that you can call any Python method with any PythonObject instance. 
>>> AnyObject lookup is fairly unprincipled as a language feature, because 
>>> there’s no natural scope in which to perform name lookup, and involves 
>>> hacks at many levels that don’t always work (e.g., AnyObject lookup… 
>>> sometimes… fails across multiple source files for hard-to-explain reasons). 
>>> You’re taking on that brokenness if you expand AnyObject lookup to another 
>>> ecosystem.
>> 
>> Yeah, sorry, that’s not what I meant:
> 
> (Good)

Also, for sake of discussion, we’d have to figure out what the type of 
MemberLookupResultType would be for Python.  I can see several choices:

1) Make it return a  "PythonObject!”
2) Make it strict, returning a PythonObject or trapping.
3) Make PythonObject itself nullable internally and return a null PythonObject.

#1 matches Python semantics directly, because it allows clients who care to 
check, but those who don't can ignore it.  The only problem I anticipate is 
that it will break things like:

let x = foo.bar
let y = x.thing   // fails, because x implicitly promoted to PythonObject?
 
#3 is gross and cuts against lots of things in Swift (recall when UnsafePointer 
itself was implicitly nullable, lets not go back to those bad old days).  I 
think that #2 is the least bad tradeoff.

>> Right, something like this could definitely work, but keep in mind that the 
>> Swift compiler knows nothing about Python declarations.  
>> 
>> Perhaps the 

Re: [swift-evolution] “Integer” protocol?

[Xiaodi Wu via swift-evolution]

Right, these issues were discussed when the proposal was introduced and
reviewed three times. In brief, what was once proposed as `Integer` was
renamed `BinaryInteger` to avoid confusion in name between `Integer` and
`Int`. It was also found to better reflect the semantics of the protocol,
as certain functions treated the value not merely as an integer but
operated specifically on its binary representation (for instance, the
bitwise operators).

Do not confuse integers from their representation. Integers have no
intrinsic radix and all integers have a binary representation. This is
distinct from floating-point protocols, because many real values
representable exactly as a decimal floating-point value cannot be
represented exactly as a binary floating-point value.

To your specific question about bitwise operators: their semantics are with
respect to the two's-complement binary representation of the integer
regardless of the actual internal representation. `~` returns the one's
complement of the two's-complement binary representation of the integer.
FWIW, this is exactly what `mpn_com()` does in GNU MP for
arbitrary-precision integers.


On Tue, Oct 31, 2017 at 7:23 PM, Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> Just for the reference. There was a lengthy discussion here in the mailing
> list back when the proposal was introduced:
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170109/thread.html#30191
>
> Max
>
> On Oct 31, 2017, at 5:15 PM, Daryle Walker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an
> “Integer” protocol between Numeric and BinaryInteger? Without that, there’s
> no solution for Integer types that are either a non-binary radix or a
> non-radix system (besides being over-broad with Numeric).
>
> What would move there are: isSigned, quotientAndRemainder, signum, %, %=,
> /, and /=.
>
> Also, how is ~ supposed to work in a BinaryInteger that is not a
> FixedWidthInteger? Extend the high bits to infinity? Maybe that operator
> should move to the derived protocol.
>
> Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger
> should be renamed “FixedWidthBinaryInteger,” which derives from
> BinaryInteger and a new version of FixedWidthInteger. The new version peels
> off: max, min, addingReportingOverflow, dividedReportingOverflow,
> dividingFullWidth, multipliedFullWidth, multipliedReportingOverflow,
> remainderReportingOverflow, and subtractingReportingOverflow. There’s also
> a “digitWidth” type property, analogous to “bitWidth”.
>
> Sent from my iPad
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] “Integer” protocol?

[Max Moiseev via swift-evolution]

Just for the reference. There was a lengthy discussion here in the mailing list 
back when the proposal was introduced:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/thread.html#30191
 


Max

> On Oct 31, 2017, at 5:15 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an 
> “Integer” protocol between Numeric and BinaryInteger? Without that, there’s 
> no solution for Integer types that are either a non-binary radix or a 
> non-radix system (besides being over-broad with Numeric).
> 
> What would move there are: isSigned, quotientAndRemainder, signum, %, %=, /, 
> and /=.
> 
> Also, how is ~ supposed to work in a BinaryInteger that is not a 
> FixedWidthInteger? Extend the high bits to infinity? Maybe that operator 
> should move to the derived protocol.
> 
> Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger 
> should be renamed “FixedWidthBinaryInteger,” which derives from BinaryInteger 
> and a new version of FixedWidthInteger. The new version peels off: max, min, 
> addingReportingOverflow, dividedReportingOverflow, dividingFullWidth, 
> multipliedFullWidth, multipliedReportingOverflow, remainderReportingOverflow, 
> and subtractingReportingOverflow. There’s also a “digitWidth” type property, 
> analogous to “bitWidth”.
> 
> Sent from my iPad
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] “Integer” protocol?

[Daryle Walker via swift-evolution]

Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an 
“Integer” protocol between Numeric and BinaryInteger? Without that, there’s no 
solution for Integer types that are either a non-binary radix or a non-radix 
system (besides being over-broad with Numeric).

What would move there are: isSigned, quotientAndRemainder, signum, %, %=, /, 
and /=.

Also, how is ~ supposed to work in a BinaryInteger that is not a 
FixedWidthInteger? Extend the high bits to infinity? Maybe that operator should 
move to the derived protocol.

Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger 
should be renamed “FixedWidthBinaryInteger,” which derives from BinaryInteger 
and a new version of FixedWidthInteger. The new version peels off: max, min, 
addingReportingOverflow, dividedReportingOverflow, dividingFullWidth, 
multipliedFullWidth, multipliedReportingOverflow, remainderReportingOverflow, 
and subtractingReportingOverflow. There’s also a “digitWidth” type property, 
analogous to “bitWidth”.

Sent from my iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Wallacy via swift-evolution]

Like Adam said, this make much more sense than
"classprivate./typeprivate"...

+1 for me.

You just create another 'bucket'! ;)

Em ter, 31 de out de 2017 às 08:19, Mike Kluev via swift-evolution <
swift-evolution@swift.org> escreveu:

> On 31 October 2017 at 06:57, Goffredo Marocchi  wrote:
>
>> I like the IB use case :).
>>
>>
> my favourite one would probably be continuations used for protocol
> adoption - no longer the trip to the main class needed to add a variable:
>
> continuation DataSource of MyViewController: UITableViewDataSource {
>
> private var variable: Bool // ***
>
> override func tableView(_ tableView: UITableView, cellForRowAt
> indexPath: IndexPath) -> UITableViewCell {
> ...
> }
> }
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

On Mon, Oct 30, 2017 at 10:55 PM, John McCall  wrote:

>
> I can think of two things that could tip the scale of the discussion:
>
> a) The big question is whether we *want* the ability to write custom
> rule-of-5 style behavior for structs, or if we want it to only be used in
> extreme cases (like bridging interop in this proposal).  If we *want* to
> support it someday, then adding proper “safe” support is best (if
> possible).  If we don’t *want* people to use it, then making it Unsafe and
> ugly is a reasonable way to go.
>
> b) The ownership proposal is likely to add deinit's to structs.  If it
> also adds explicit move initializers, then it is probably the right thing
> to add copy initializers also (and thus go with approach #2).  That said,
>  I’m not sure how the move initializers will be spelled or if that is the
> likely direction.  If it won’t add these, then it is probably better to go
> with approach #1.  John, what do you think?
>
>
> I was hoping not to have to add explicit move/copy initializers, perhaps
> ever.
>

Can you elaborate more on why?  I'm even more interested in your the
rationale more than the outcome :-)


I would suggest one of two things:
>   - We could add a Builtin type for these types in Swift.  Because of our
> architecture, this is mostly an IRGen task.
>

Yes, this could definitely work.


>   - We could start working on C++ import.  C++ import is a huge task, but
> we don't really need most of it for this.
>

This could work, but it would be unfortunate to push people to having to
write (unsafe) C++ and import it into Swift to achieve simple things like
this.  I'd prefer going the direction of suggestion #1 above and allowing a
"pure swift and explicitly unsafe" solution.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 31 October 2017 at 02:29, Adam Kemp  wrote:

>
> No, grep would be sufficient as well. The issue is still which files to
> grep in the first place. Everything else comes after that. If you manually
> read files looking for usages of an API you’re changing then I feel sorry
> for you. You’re doing things the hard way.
>
>
so you've used grep to search for "foo" in all files of the module (in case
of "internal func foo") and grep returned 50 files.

in case of "classprivate func foo" that would be, say, 10 files. or even 50
files - doesn't matter.

what matters is the actual number of hits of "foo" to review, in the former
case it would be, say "50 files * 10 hits in each" in the latter - "50
files with one hit in each". and in reality even "10 files with one hit in
each". thus the search set to review is much much smaller.

I’m not going to go back and forth on this any longer. We’re going in
> circles. We just don’t agree, and this doesn’t appear to be going anywhere.
>

i agree to disagree.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 31 October 2017 at 06:57, Goffredo Marocchi  wrote:

> I like the IB use case :).
>
>
my favourite one would probably be continuations used for protocol adoption
- no longer the trip to the main class needed to add a variable:

continuation DataSource of MyViewController: UITableViewDataSource {

private var variable: Bool // ***

override func tableView(_ tableView: UITableView, cellForRowAt
indexPath: IndexPath) -> UITableViewCell {
...
}
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SPM] Roadmap?

[Jean-Christophe Pastant via swift-evolution]

Ok so seems to me like there are 2 big needs that came up often on this
thread: better integration for iOS and for C/C++.

For iOS, Build settings would definitely be a huge plus as it would allow
to generate a full configured xcodeproj file (and thus
build/sign/distribute the app). Not perfect but that would pave the way for
next steps.

For C/C++ however I have no idea of what is missing in SPM ecosystem. I
guess build settings would be good interesting, but would it be enough?

Jean-Christophe Pastant

« Mobile Applications Done Right »
156, boulevard Haussmann, 75008 Paris
jcpast...@xebia.fr 
[image: Xebia Mobile] 

2017-10-29 22:47 GMT+01:00 Georgios Moschovitis <
george.moschovi...@icloud.com>:

> I would like to see:
>
> - Xcode integration
>   I guess that entails:
>   - Support for iOS
>   - Support for Assets
> - Better error reporting (SPM’s error messages are often cryptic)
> - Improve the testing story on Linux (as mentioned elsewhere)
>
> -g.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Goffredo Marocchi via swift-evolution]

I like the IB use case :).

Sent from my iPhone

> On 31 Oct 2017, at 03:22, Adam Kemp via swift-evolution 
>  wrote:
> 
> This I actually support. In C# the same concept exists in the form of partial 
> classes. A class must be declared as partial everywhere in order to support 
> it. It only works within a single assembly (similar to a module).
> 
> There are a few important use cases for this in C#:
> 
> 1. Code generation. For instance, Interface Builder could modify a separate 
> file for things like outlets and actions, and it could freely wipe and 
> regenerate that file from scratch without touching any of your own code. Some 
> people also generate parts of classes from templates while filling in the 
> rest in another file. 
> 
> 2. Cross platform code. A common strategy in C# is to have a class split into 
> parts, where one part is compiled on all platforms, and the other files are 
> each specific to one platform or another. For instance, you may have 
> Foo.swift, Foo.macOS.swift, and Foo.iOS.swift. Foo.swift would be compiled on 
> both platforms, but then the iOS build would only include Foo.iOS.swift. This 
> is a preferred alternative to using #ifs.
> 
> 3. The use case Mike described. Sometimes we fail at making classes small, or 
> maybe someone else failed and we’re stuck with it. Splitting a single class 
> into pieces can be useful to organize cohesive chunks. That’s not something I 
> tend to encourage as a design pattern, but it still happens anyway. 
> 
> A related feature in C# is partial methods, which are just void-returning 
> methods that have been declared as partial without an implementation. If an 
> implementation is provided by another file (in another part of the partial 
> class) then it is used. If no file provides an implementation then calls to 
> that method are just stripped out by the compiler. This is also commonly used 
> for cross-platform code. Maybe one platform needs to do something at a 
> particular time but another doesn’t. Rather than using #ifs or having empty 
> stubs in other platforms you can declare it partial and provide an 
> implementation on just the one platform that needs it.
> 
>> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> a general feeling that there are two very different use cases of extensions 
>> -- one to extend own classes and another to extend other people classes; a 
>> lengthy discussion in a nearby thread; a disparity of features of class and 
>> it's extensions and different access right treatment depending upon whether 
>> the extension is in the same with the main class or a different file lead me 
>> to the following idea. hopefully you will find this idea useful and we may 
>> even see it one day in swift.
>> 
>> introducing class / struct / enum continuations.
>> 
>> in a few words the are:
>> 
>> 1) "extensions on steroids". in fact very similar to Objective-C "class 
>> extensions" but can be more than one and in more than one file.
>> 
>> 2) as good as the classes they continue (or other continuations they 
>> continue)
>> 
>> 3) can declare variables
>> 
>> 4) have full access to "private" members of the class or other continuations
>> regardless whether they are in the same or in a different files. no need for 
>> "public/internal/module" fallbacks to pass though files boundaries. 
>> similarly the class itself can use private members of its continuations.
>> 
>> 5) "by invitation only" system. can only be written if declared by the class 
>> or some continuation of it.
>> 
>> 6) A particular continuation only defined once (of course). There can be an 
>> arbitrary number of different continuations to a class similar to extensions.
>> 
>> 7) alternative name considered: "extending" (as a noun). shall definitely be 
>> a different name than say, "extension" with some bracket-syntax variation - 
>> the two use cases are very different and shall be named differently.
>> 
>> 8) the particular syntax is preliminary of course. 
>> 
>> example:
>> 
>> = Some.swift ==
>> 
>> class Some {
>> 
>>private func private_method_of_class() {
>> 
>>// *** can use private methods of continuations even if they are in a 
>> different file
>>private_method_defined_in_a_continuation()
>>}
>> 
>>// *** "by invitation" system
>> 
>>continuation Feature// *** declaring a continuation
>>continuation SomethingElse// *** Capitalized names, like classes
>> }
>> 
>> = Some-Feature.swift ==
>> 
>> // *** similar naming convetion to "Some+Feature.swift"
>> // used for extensions, just with "-" instead
>> 
>> // *** this is merely a naming convention, no need to
>> necessarily follow it, can put more than one thing into
>> a file, the continuation can reside in the same file as
>> the main class fie, etc.
>> 
>> continuation Feature of Some {
>> 
>> // *** as