Re: [swift-evolution] Swift Reflection

[Robert Widmann via swift-evolution]

If you’re going to build on top of something like Spark it seems you’d have 
better luck wrapping the JNI and using Swift protocols to try to automate away 
as much of the boilerplate of creating JNI classes dynamically.  

~Robert Widmann

> On Oct 18, 2016, at 9:40 AM, Robert Goodman via swift-evolution 
>  wrote:
> 
>  
> I know that there has been some discussion around improving reflection in 
> Swift and I wanted to add to the discussion with some of the work I have been 
> trying to do using the Swift Language. I have been investigating using Swift 
> to create a framework that provides a programming API to process data and 
> execute functions in parallel on a cluster. The framework needs to be able 
> instantiate these functions on the cluster workers and have the data 
> processed by the functions. The plans are to use one of the existing cluster 
> managers, such as Spark or Storm. As of today, I have been looking at using 
> Spark. There would be a predefined set of functions supported such as map, 
> fliter, join, etc. as defined by the cluster manager.
> In my experimenting, I have run into a number of issues which I haven't been 
> able to solve due to the limited support for reflection in Swift. In my 
> description of the issues, I'm going to use APIs based on Spark since that is 
> the cluster manager I have been playing with.
>  
> Parameter and Return types
>  
> The following is an example of a Swift class that maps to the RDD class in 
> Spark.
>  
> public class RDD  {
>public func collect() throws -> [T] {
>
>}
> }
>  
> The value of T could be any basic type to a class. Even if the types are 
> limited to basic types and known Spark types, the list of possibilities is 
> large. From one of the Spark examples, T would be
>  
>   Tuple2>
>  
> The possible combinations of types is too large to be hard coded given Spark 
> supports Tuples with 22 different types. I can get the type of T in a string, 
> but haven't found a way to instantiate the type using the string. Is there 
> some way around this problem?
> 
> User-Defined Functions
>  
> A programmer would define functions that will be executed on a cluster to 
> process data. The programmer doesn't need to do special packaging of 
> functions that run on a cluster. The programmer would code a filter function 
> against the cluster the same way as the filter function for a Swift array. 
> For instance, for a filter method such as the following:
>  
> let result = RDD.filter({ (value) -> Bool in
> return value > 15
> })
>  
> The framework would need to be able to do reflection on the function to get 
> the information needed to instantiate and call the function on the cluster 
> workers. Following is some of the information needed:
>  
>   Module name
>   Class/Struct name
>   Function name
>   Parameter names and type information
> 
> Once on the cluster the framework would need to do the following:
>  
>   1. Instantiate the parameters. Again, a parameter could be a basic type to 
> a class.
>   2. Dynamically load/import the module containing the function.
>   3. Find the function in the module that matches the signature.
>   4. Call the function.
>   5. Handle the return type.
>  
> With the existing Swift support for reflection, I couldn't get all of the 
> information that is needed and what information I could get wasn't in a very 
> convenient form. In some cases, I needed to parse a string to get the 
> different parameter types. Even if I had the information, I didn't see a way 
> to use the information to load the module and execute the function. My plans 
> are to require the programmer to pass the location of modules and 
> dependencies that need to be deployed to the cluster workers on application 
> startup. Given the limitations of reflections in Swift, I don't see how this 
> framework could be implemented. Since this needs to run on Linux, I want to 
> avoid any solution that uses Objective C.
>  
> Thanks
>   Bob
> 
> Robert Goodman
> 
> ___
> 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] [Proposal] Refining Identifier and Operator Symbology

[Colin Barrett via swift-evolution]

> On Oct 22, 2016, at 8:53 PM, Jonathan S. Shapiro 
>  wrote:
> 
> I missed this earlier posting from Joe Groff, who wrote:
> 
> In the discussion about operators, I wonder whether it makes sense to 
> formally separate "identifier" and "operator" characters at all. ...
> 
> The consequence if we do not formally separate the operators (verbs) from the 
> identifiers (nouns) is that white space will be needed around all operators. 
> That's not necessarily a bad thing, but it would be a significant and 
> incompatible departure from today's Swift, both in terms of actual source 
> code breakage and in terms of the "look and feel" that many people feel 
> passionate about.

That’s one way yeah. Or you’d could to make the grammar context sensitive / 
apply a "lexer hack”. Probably other ways to deal w/ context sensitivity as 
well. Joe’s proposed syntax seems pretty explicit, and hopefully it’sdsimple to 
plumb / capture that info in the lexer. (I’m ignorant of the implementation of 
Swift’s front-end unfortunately!)

-Colin

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

I missed this earlier posting from Joe Groff, who wrote:

In the discussion about operators, I wonder whether it makes sense to
> formally separate "identifier" and "operator" characters at all. ...


The consequence if we do not formally separate the operators (verbs) from
the identifiers (nouns) is that white space will be needed around all
operators. That's not necessarily a bad thing, but it would be a
significant and incompatible departure from today's Swift, both in terms of
actual source code breakage and in terms of the "look and feel" that many
people feel passionate about.


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

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Pearce via swift-evolution]

https://docs.docker.com/toolbox/toolbox_install_mac/

On 23 October 2016 at 06:56, T.J. Usiyan via swift-evolution <
swift-evolution@swift.org> wrote:

> Thanks for the heads up! It wasn't just meant for you. Use of a generic
> Result type is one of my motivating cases.
>
> 1. If multiple libraries declare a generic type like that, converting
> between them becomes a pain.
> 2. Specific result types are useful and appropriate in many, if not most,
> cases.
> 3. protocols and retroactive conformance could make this less challenging
>
> On Sat, Oct 22, 2016 at 3:42 PM, David Sweeris 
> wrote:
>
>> Was not sending your reply only to me and not the list intentional? It’s
>> fine either way, I was just about to send this to the list when I realized
>> you’d only sent your reply to me, and I don’t want quote you somewhere if
>> you intentionally didn’t post there.
>>
>> On Oct 22, 2016, at 1:39 PM, T.J. Usiyan  wrote:
>>
>> I would actually hope otherwise. A real benefit of enums is compile time
>> guarantees. I am looking for a generic means to represent and handle a set
>> of possible outcomes. Not in the hopes of making everything fully generic
>> but lessening the redundant parts of dealing with, for example, Result
>> types.
>>
>>
>> I think you can do that now...
>> enum Result {
>> case success(Payload)
>> case failure(Error)
>> }
>>
>> Then in your function…
>> func foo (r: Result) {
>> ...
>> switch r {
>> case .success(let p): ...
>> case .failure(let e): ...
>> }
>> ...
>> }
>>
>> Or am I just not understanding you?
>>
>> - Dave Sweeris
>>
>
>
> ___
> 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] [Proposal] Refining Identifier and Operator Symbology

[Colin Barrett via swift-evolution]

I’m a -1 on the original proposal. I can see the logic in doing things that 
way, but it’s really unclear to me why we need to act *now*. In fact it seems 
like waiting might be a better option, given the things mentioned upthread 
about revisions to the Unicode standard.

Also, I think the message quoted below is a promising direction worth 
exploring. How would something like this work in the front-end? Swift’s grammar 
currently distinguishes between operators and identifiers right?

-Colin

> On Oct 19, 2016, at 12:17 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I think this is a promising direction. Getting us in line with Unicode 
> recommendations is an important first step, and being conservative about the 
> treatment of operator characters and emoji is a good engineering approach, 
> though certainly unfortunate in the short term for users who've adopted 
> custom operators or found interesting uses for emoji identifiers in Swift 3 
> and earlier.
> 
> In the discussion about operators, I wonder whether it makes sense to 
> formally separate "identifier" and "operator" characters at all. My hunch is 
> that there isn't going to be any perfect categorization; there are so many 
> symbols and scripts out there that it's going to be difficult to definitively 
> characterize many symbols as "obviously" an operator or identifier. Not every 
> developer has the mathematical background to even recognize common math 
> operators beyond the elementary arithmetic ones. Something to consider would 
> be to change the way operators work in the language so that they can use 
> *any* symbols (subject to canonicalization, visibility, and confusability 
> constraints), but require their use to always be explicitly declared in a 
> source file that uses an operator outside of the standard library. For 
> example, you would have to say something like:
> 
> import Sets
> import operator Sets.∪
> 
> to make the '∪' symbol available as an operator in the import declaration's 
> scope. This would provide more obvious evidence in the source code of what 
> tokens are being employed as operators, and lessen the need to have formally 
> distinct identifier and operator character sets.
> 
> -Joe
> ___
> 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] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

That, I think, is where we're headed. Take a look at Jonathan Shapiro's
latest draft and see what you think :)
On Sat, Oct 22, 2016 at 17:46 Matt Whiteside via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 
>
> There are a bunch of symbols in unicode which are hard to tell apart, and
> those are bad for recognition, and we should deal with that, but this
> proposal is throwing the baby out with the bathwater, then lighting the
> baby on fire.  Honestly, I would propose we find a way to have Swift see
> certain classes of characters as identical.  Can’t decide which of the
> thousand + symbols should be the one true + symbol?  Have them all map to
> one of them.  That emoji X symbol looks like X, so map it to X.
>
>
>
> Agreed.
>
> I really like the option of using unicode operators in swift.  Removing
> them would be disappointing.  But I do see the problem that there are a lot
> of redundancies and sources of confusion if there are no restrictions.
> Aside from the redundancies, some other cases that I find sub-optimal are:
> 'top-half of integral' ⌠, and  'left parenthesis upper hook’ ⎛ ;  these don’t
> really seem like symbols we want to allow as operators.  Perhaps
> *one* general rule here, is that symbols specifically meant for 2d math
> expressions aren't good candidates for inclusion, at least at the present.
> Another difficult one, I think, are the bracket-like glyphs.  While
> these would be useful in certain math and physics related code, it’s not
> clear at the moment how these could be used in swift, until and unless some
> kind of ‘bracket overloading’ is made possible.
>
> I’m in favor of what Johnathan Hull has suggested above.  I’m also in
> favor of what some others have suggested, i.e., restricting the allowed
> operator symbols to some uncontroversial subset, mainly from the unicode
> ‘math’ category of symbols, and then possibly adding more as needed.
>
> -Matt
> ___
> 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] [Proposal] Refining Identifier and Operator Symbology

[Matt Whiteside via swift-evolution]

> On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution 
>  wrote:

> There are a bunch of symbols in unicode which are hard to tell apart, and 
> those are bad for recognition, and we should deal with that, but this 
> proposal is throwing the baby out with the bathwater, then lighting the baby 
> on fire.  Honestly, I would propose we find a way to have Swift see certain 
> classes of characters as identical.  Can’t decide which of the thousand + 
> symbols should be the one true + symbol?  Have them all map to one of them.  
> That emoji X symbol looks like X, so map it to X.


Agreed.

I really like the option of using unicode operators in swift.  Removing them 
would be disappointing.  But I do see the problem that there are a lot of 
redundancies and sources of confusion if there are no restrictions.  Aside from 
the redundancies, some other cases that I find sub-optimal are: 'top-half of 
integral' ⌠, and  'left parenthesis upper hook’ ⎛ ;  these don’t really seem 
like symbols we want to allow as operators.  Perhaps *one* general rule here, 
is that symbols specifically meant for 2d math expressions aren't good 
candidates for inclusion, at least at the present.  Another difficult one, I 
think, are the bracket-like glyphs.  While these would be useful in certain 
math and physics related code, it’s not clear at the moment how these could be 
used in swift, until and unless some kind of ‘bracket overloading’ is made 
possible.

I’m in favor of what Johnathan Hull has suggested above.  I’m also in favor of 
what some others have suggested, i.e., restricting the allowed operator symbols 
to some uncontroversial subset, mainly from the unicode ‘math’ category of 
symbols, and then possibly adding more as needed.

-Matt

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Daniel Duan via swift-evolution]

It’s worth pointing out that the proposal to add ‘$’ to identifiers is still 
under active review and have generated much controversy. I wouldn’t put much 
weight in “backward compatibility” for that proposal.

> On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro via swift-evolution 
>  wrote:
> 
> Well, it seems that I jumped the gun and sent my document link to 
> swift-evolution by mistake. Since I can't take it back, it might be good to 
> say what it's about. Because of my mistake, this version has not had any 
> review by the rest of the author group, which probably would have improved it 
> a lot. I had intended one more round of edits to deal with a few things that 
> still say "FIX" and a few minor cleanups, but I think the substance of the 
> proposal is sound.
> 
> This revised proposal 
> 
>  tries to take into account most of the feedback we have received here. Lots 
> of nitty-gritty changes, but here's the big picture of the changes:
> Emojis are admitted, subject to reasonable sanity conditions.
> A (significantly) broader, but still conservative set of code points are 
> admitted for symbol identifiers. Hopefully this addresses current need, but I 
> remain open to adopting full-on [:Sm:] and [:So:] if there is a strong push 
> for that.
> Operator definition is orthogonal to identifier specification, which deals 
> with the noun/verb confusion and also addresses the widely-expressed feeling 
> that some symbols aren't operators and their conventional meaning should be 
> usable. The term "operator" no longer has anything to do with identifiers.
> A laundry list of potential parsing gotchas are addressed. The previous 
> proposal would have broken the generics syntax and also the binding syntax. 
> This isn't a substantive conceptual change, but it's important if the 
> proposal is going to, you know, actually work. :-)
> Dollar is admitted in identifiers.
> Explicitly addresses anonymous closure parameters in a way that reflects how 
> the compiler actually needs to deal with such things. Might be I've written a 
> compiler or two in my career. :-)
> Consistent with the current direction of UAX31 on these issues.
> Susan Kare's legacy is preserved. :-) If you don't know who Susan is, look 
> her up and learn why Chris loves the dogcow emoji pair.
> The new proposal remains entirely compatible with Swift 3, except where 
> existing source runs up against the narrower symbol identifier space. It's a 
> specific goal to avoid breaking reasonable current practice where possible, 
> though we're surely going to break something with this one.
> 
> I was trained to write specifications in a school that favored rigorous 
> writing. In order to make sure I didn't lose track of something I rewrote the 
> proposal in a form that I know how to use effectively. Any loss of "fun" in 
> the text is my fault alone.
> 
> Interested to see how this will be received.
> 
> 
> Jonathan
> ___
> 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] [Pitch] deprecating ManagedBufferPointer

[Colin Barrett via swift-evolution]

May be totally wrong about this but I always thought that 
ManagedBuffer(Pointer) would be really useful in conjunction w/ Metal. In 
particular, MTLBuffer gives you a region of memory that is in common 
configurations shared btwn the CPU and GPU. I believe the idea is you write 
your vertex data or textures or whatever into that region, which you then 
associate with a particular command you issue to the GPU.

-Colin

> On Oct 19, 2016, at 6:28 PM, Alexis via swift-evolution 
>  wrote:
> 
> A bit late to this game, because I didn’t fully understand the “point” of 
> ManagedBuffer(Pointer). After a good week of messing around with these in 
> Dictionary/Array/String, I now have Opinions.
> 
> I agree ManagedBufferPointer is largely unnecessary. However it’s seeming a 
> lot like ManagedBuffer (and its equivalents) are suboptimal for the standard 
> library’s purposes too!
> 
> In particular, pretty much every one of these buffers that I see wants to be 
> a subclass of some NS* collection so that it can be toll-free bridged into 
> objective C. This means that all those types are forced to directly drop down 
> to allocWithTailElems, rather than using a nice abstraction that does it for 
> them. Array does this right now, and I’ve got a PR up for review that’s doing 
> the same thing to the HashedCollections. It’s an outstanding bug that String 
> isn’t doing this (forcing its buffer to be wrapped in another class to be 
> bridged).
> 
> I don’t really feel any pain from directly using allocWithTailElems, it’s a 
> great API. It just leaves me at a loss for when I’d reach for ManagedBuffer 
> at all, as it’s very limited.
> 
> 
>> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution 
>> > wrote:
>> 
>> I created a proposal: https://github.com/apple/swift-evolution/pull/545 
>> 
>> 
>>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Tue Oct 11 2016, Károly Lőrentey >> > wrote:
>>> 
 +1
 
 ManagedBuffer has been really useful a couple of times, but I never
 found a use for ManagedBufferPointer. I can’t even say I’m entirely
 sure what need it was originally designed to fulfill.
>>> 
>>> The real need is/was to be able to do the same kind of storage
>>> management in classes not derived from ManagedBuffer.  This can be
>>> important for bridging, where the buffers of various native swift
>>> containers need to be derived from, e.g., NSString or NSArray.  That is,
>>> however, an extremely stdlib-specifc need.
>>> 
>>> 
> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
 > wrote:
> 
> The purpose of ManagedBufferPointer is to create a buffer with a custom 
> class-metadata to be able
 to implement a custom deinit (e.g. to destroy the tail allocated elements).
> It was used in Array (before I replaced it with the new 
> tail-allocated-array-built-ins). But now
 it’s not used anymore in the standard library.
> 
> As a replacement for ManagedBufferPointer one can just derive a class 
> from ManagedBuffer and implement the deinit in the derived class.
> 
> final class MyBuffer : ManagedBuffer {
>  deinit {
>// do whatever needs to be done
>  }
> }
> 
> // creating MyBuffer:
> let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in 
> return MyHeader(...) })
> 
> IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t 
> need this custom
 bufferClass to be passed to the constructor). Also ManagedBufferPointer 
 doesn’t use SIL
 tail-allocated arrays internally. Although this is not something visible 
 to the programmer, it makes
 life easier for the compiler.
> 
> So I suggest that we deprecate ManagedBufferPointer.
> 
> Erik
> ___
> 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 
 
 
>>> 
>>> -- 
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> 

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[David Sweeris via swift-evolution]

> On Oct 20, 2016, at 9:37 AM, Jonathan S. Shapiro 
>  wrote:
> 
> On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris  > wrote:
> Sent from my iPhone
> 
> On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution 
> > wrote:
> 
>> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution 
>> > wrote:
>> 
>> Freeze the set of allowed emoji to whatever the current version of the 
>> Unicode spec defines...
>> 
>> UAX31 won't include emojis in either space, because there is no clear 
>> consensus about where they belong (identifiers or operators). Individual 
>> languages can certainly add them to one space or the other, but should take 
>> care not to cross-contaminate. So if we add them to operators, we need to 
>> exclude any that are already part of normal identifiers and vice versa. That 
>> sanity restriction is technically necessary, but it shouldn't be an 
>> inconvenience in practical terms.
> 
> My understanding (which is admittedly fuzzy) is that the distinction between 
> operators and identifiers is only "technically necessary" because allowing 
> characters to be both causes the parsing algorithm lose its virtual mind, and 
> it takes a century for it to figure out what's going on. What I don't recall 
> being discussed before is whether that's a blanket penalty or if the compile 
> times increases are proportional to the amount overlap between the two 
> character sets.
> 
> The hard requirements are:
> Nothing in identifier start can be in operator start or operator continue. [*]
> Nothing in operator start can be in identifier start or identifier continue. 
> [*]
> Nothing in syntactic punctuation (period, brackets, parens, and so forth) can 
> be in either type of identifier without creating a lot of serious hair. You 
> can see one example of hair in the "double dots" rule.
> If these requirements are not preserved, the consequence is that white space 
> becomes required between identifiers and operators. So, for example, without 
> these rules:
> 
> a+b// gets broken
> a + b  // works
> 
> The presence of dots in operators is actually causing a whole bunch of 
> constraints to get introduced that I'm going to talk about in a moment.


Ah, ok. Your explanation sounds very familiar… Clearly I’ve read it before and 
forgot. I must be going senile in my old age (37).

Would this whitespace rule affect pre/postfix operators, or just the infix 
ones? Personally, I’m fine with requiring whitespace around infix operators, 
but pre/postfix operators would completely lose readability if they needed it, 
too. Have we previously discussed this on the mailing list?

Given my apparent forgetfulness, I have no doubt that we discussed it at length 
two weeks ago, and someone will probably reply to this, quoting some forgotten 
3-page email I sent on the topic :-)

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

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[David Sweeris via swift-evolution]

> On Oct 21, 2016, at 12:23 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Now there's a caveat here worth discussing: would the intention of an 
> "enum-constrained protocol" be to define the *only* cases it can have, or 
> just the minimal set? The former would let you do some interesting generic 
> protocol-constrained exhaustive pattern matching. However, given that no 
> other use of protocols defines an *exact* set (you don't say these are the 
> *only* methods/properties that a conforming type can implement), I think it 
> would be a hard sell to apply a stronger restriction specifically to enums. 
> In any case, it feels to me like an enum restricted to "only these exact 
> cases" calls more for a generic enum rather than a protocol-based solution.

I would say it should define the minimal set, and any switching over the 
generic protocol type needs either a `default` or a `case _` clause to handle 
concrete types which have more cases than the protocol requires.

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Adrian Zubarev via swift-evolution]

First of all, thank you for writing the formal proposal.

To begin with, I’d like to remember you that type nesting is not only done 
through nesting types directly in concrete types. A commonly used pattern to 
reduce clustering is nesting inside extensions:

extension TypeName {
 
class InnerTypeName { … }
}
Next up:

protocol Outer {
 protocol Inner {
 associatedtype Huh // why would you do this?
 }
}
I disagree with this: why would you want to restrict this?

The Outer protocol might be simple by the inner protocol is not. If you’d move 
the associatedtype Huh into Outer protocol you’d automatically break the 
intended simplicity of the Outer protocol.

The following example is kept simple just to show that the outer protocol is in 
our case intended to be simple where the inner is not.

protocol Building {
 
protocol Room {

associatedtype Person
}

var numberOfRooms: Int { get }
}

struct Pupil {}
struct Student {}

struct University : Building {
 
let numberOfRooms: Int = 1000

struct Room : Building.Room {

typealias Person = Student
}
}

struct School : Building {
 
let numberOfRooms: Int = 100

struct Room : Building.Room {

typealias Person = Pupil
}
}

let buildings: [Building] = [University(), School()] // fine because `Building` 
is simple
The inner types in this example are different from each other, but this wasn’t 
the main point anyways.

Unless this restriction would have other technical reasons than “It is hard to 
think of a valid reason why a nested protocol might want to be more generic 
than its parent”, I’m against it.

At the very beginning I said that nesting is also done through extensions. 
Let’s rewrite the above example from your draft that way and see what we good.

protocol Outer {} // Simple

extension Outer {
 
// Complex
protocol Inner {
 associatedtype Huh // why would you do this?
  }
}

// new name spacing `Outer.Inner`
>From this perspective it’s much clearer now that the Outer protocol type in 
>out case is intended to be simple.

About associatedtypes with extensions:

In Swift 3.0 this code compiles:

public class Class {}

public protocol Outer {
associatedtype AAA : Class
}

extension Outer {
public typealias AAA = Int
}
This does mean that the associatedtype is lost in extensions and can be reused 
as an inner type for nesting. This also means that the inner type wouldn’t be 
able to capture the associatedtype from the outer type and might be simple.

protocol Outer {

   associatedtype AAA
}

extension Outer {
protocol Inner {} // Simple because nesting from within extensions seems to 
ignore the associatedtype from the `Outer` type
}
You can compare this to todays workarounds where you only want to create a nice 
name space but want to keep the inner type simple.

// Implementation artifact
protocol _Inner {} // simple

// Complex
protocol Outer {
associatedtype Anything
}

extension Outer {
typealias Inner = _Inner
}

// Free to use `Outer.Inner`


-- 
Adrian Zubarev
Sent with Airmail

Am 22. Oktober 2016 um 04:18:25, Karl (razie...@gmail.com) schrieb:


On 22 Oct 2016, at 04:12, Karl  wrote:


On 22 Oct 2016, at 04:07, Karl  wrote:


On 22 Oct 2016, at 04:02, Braeden Profile  wrote:

But what would that mean?  If I reference `ProtocolName.InnerType`, that 
doesn’t always have meaning.  In fact, if you have two different extensions 
where AssociatedType equals something else, there’s a type ambiguity from other 
code.  I suspect it would only work if that InnerType was mandated to be 
`private`.

You would need a reference to a (ProtocolName where AssociatedType == Int), 
which you can get either from a `self` inside the extension or from a generic 
parameter:

struct MyValue : ProtocolName { typealias AssociatedType = T }

let _ = MyValue().InnerType()

No, wait - sorry, that’s wrong. I got confused for a second. You’re right; it 
would have to be a private type.

Actually I think I take that back (I was just writing, lots of snippets 
floating around my head) - ProtocolName is a generic protocol, so types inside 
of it would become types on the concrete conformers. That’s consistent with the 
Editor.Delegate example in the draft proposal I linked to.

So MyValue.InnerType would exist  ProtocolName.InnerType isn’t really 
very meaningful otherwise.

- Karl




On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution 
 wrote:

That option should not be disallowed. Here is a simple example you might want 
to build at some point:

protocol ProtocolName {
  
associatedtype AssociatedType
}

extension ProtocolName where AssociatedType == Int {
   
struct InnerType {}
}



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
(swift-evolution@swift.org) 

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Will Stanton via swift-evolution]

On $ specifically, I found this Wikipedia article listing native operators from 
other languages: https://en.wikipedia.org/wiki/Operator_(computer_programming).
Haskell was listed with $ as an operator (‘Anything appearing after it will 
take precedence over anything that comes before’ per 
http://stackoverflow.com/questions/940382/haskell-difference-between-dot-and-dollar-sign)

I’m unconvinced a great case for `$` as an operator exists, so opposed to the 
source-breaking change, and supportive of SE-144.


Jonathan,
Thanks for the reply and Jacob, Erica, and Xiaodi as well for drafting a 
broader proposal.
Were you suggesting `$(0)` as a way to initialize a type named `$` or more like 
`$0` as a literal?
As a decimal-number/currency-type literal operator, I remain unconvinced that 
justifies a source-breaking change for reasons discussed on list (which dollar? 
and consistency).
Addressing multiple problems seems like a good direction though (I like the 
list: 
https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/-refining-identifiers-and-operators.md#prior-discussion-threads--proposals).

A thought on the draft:
>   • Identifiers consisting of an initial '$' (U+0024 DOLLAR SIGN) 
> followed by one or more decimal digits ['0'...'9'] are prohibited in defining 
> occurrences. These identifiers are reserved for use by the language as 
> anonymous closure parameter names.  
Would it make sense/is it already the case for closure parameters to be 
let-like constants? (I don’t know how the compiler works it, but the error 
‘Cannot assign to value: %something% is immutable’ makes me think no.) Can 
closure parameters be treated as automatically generated identifiers instead of 
a special restriction in name?

Regards,
Will Stanton

> On Oct 21, 2016, at 10:48 PM, Jonathan S. Shapiro 
>  wrote:
> 
> On Fri, Oct 14, 2016 at 9:29 PM, Will Stanton via swift-evolution 
>  wrote:
> I’m a bit curious about how `$` is/would be used as a prefix operator! 
> Perhaps I’m not creative :-(
> 
> Well for one thing, $(0) can be understood as a value constructor for a 
> currency object having a value zero...

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

On Sat, Oct 22, 2016 at 1:37 AM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> I just read through your new proposal, and I have to say it is extremely
> well-written. There is a vast quantity of information presented quite
> clearly, and it gives me a lot to think about.
>
>
> On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro  gmail.com> wrote:
>
>> On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via
>> swift-evolution  wrote:
>>
>>> I think it is plainly evident that the well-defined criteria you would
>>> like to use *have not yet been defined* by Unicode. That is a large part of
>>> why I recommend that we postpone a major overhaul of our operator
>>> characters.
>>>
>>
>> That's a feasible way to go, but keep in mind that the UAX31 changes are
>> being co-designed with and informed by the current discussion. There are a
>> bunch of things that have come up here that will allow UAX31 to side-step
>> some "might have happened" mistakes, so this discussion has been very
>> useful.
>>
>> The Swift community can and should make its own decision about whether to
>> remain engaged. The risk of disengagement is that messy compatibility
>> issues will probably have to be faced later that we can easily head-off now.
>>
>
> Ah, I had not previously understood that. Well then, in light of the fact
> that the Unicode recommendations may be influenced by our decisions, and
> given that Swift is an opinionated language, it follows that we ought to
> make our best effort at separating out what we have been calling “operator
> characters” (and your revised proposal calls “symbol identifier”
> characters).
>
> In particular, since there does not yet exist a categorization of symbols
> which fits our needs, and since our needs may help shape such a
> categorization as it forms, it behooves us to fully undertake the endeavor
> of defining which symbols we would like to see in which roles for Swift.
>
> Your proposal mentions and links to a set of 650 code points
> 
>  that
> your group identified by hand as operators. It also links to the combined Sm
> and So categories
> .
> However what you actually propose is the far-more-limited Mathematical
> Operators block
> 
> .
>
> I will take it upon myself to go through code-points by hand and see what
> I can find.
>
> It is worth noting that your proposed “symbol identifier” category, by its
> very name, suggests it should have broader membership than just operators.
> I am not sure if that was intentional, however I will restrict my attention
> to symbols that may reasonably function as operators.
>
> After a preliminary glance through the code blocks, I believe there are
> operator-like characters in these blocks
> 
> :
> Basic Latin
> Latin-1 Supplement
> General Punctuation
> Letterlike Symbols
> Arrows
> Mathematical Operators
> 

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Nevin Brackett-Rozinsky via swift-evolution]

I just read through your new proposal, and I have to say it is extremely
well-written. There is a vast quantity of information presented quite
clearly, and it gives me a lot to think about.


On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <
jonathan.s.shap...@gmail.com> wrote:

> On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
>> I think it is plainly evident that the well-defined criteria you would
>> like to use *have not yet been defined* by Unicode. That is a large part of
>> why I recommend that we postpone a major overhaul of our operator
>> characters.
>>
>
> That's a feasible way to go, but keep in mind that the UAX31 changes are
> being co-designed with and informed by the current discussion. There are a
> bunch of things that have come up here that will allow UAX31 to side-step
> some "might have happened" mistakes, so this discussion has been very
> useful.
>
> The Swift community can and should make its own decision about whether to
> remain engaged. The risk of disengagement is that messy compatibility
> issues will probably have to be faced later that we can easily head-off now.
>

Ah, I had not previously understood that. Well then, in light of the fact
that the Unicode recommendations may be influenced by our decisions, and
given that Swift is an opinionated language, it follows that we ought to
make our best effort at separating out what we have been calling “operator
characters” (and your revised proposal calls “symbol identifier”
characters).

In particular, since there does not yet exist a categorization of symbols
which fits our needs, and since our needs may help shape such a
categorization as it forms, it behooves us to fully undertake the endeavor
of defining which symbols we would like to see in which roles for Swift.

Your proposal mentions and links to a set of 650 code points

that
your group identified by hand as operators. It also links to the combined Sm
and So categories
.
However what you actually propose is the far-more-limited Mathematical
Operators block

.

I will take it upon myself to go through code-points by hand and see what I
can find.

It is worth noting that your proposed “symbol identifier” category, by its
very name, suggests it should have broader membership than just operators.
I am not sure if that was intentional, however I will restrict my attention
to symbols that may reasonably function as operators.

After a preliminary glance through the code blocks, I believe there are
operator-like characters in these blocks

:
Basic Latin
Latin-1 Supplement
General Punctuation
Letterlike Symbols
Arrows
Mathematical Operators
Miscellaneous Technical
Miscellaneous Mathematical Symbols-A
Supplemental Arrows-A
Supplemental Arrows-B
Miscellaneous Mathematical Symbols-B
Supplemental Mathematical Operators
Miscellaneous Symbols and Arrows
Supplemental Punctuation

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

All:

Xiaodi has pointed out that the existing Unicode emoji set pulls in a host
of stuff we don't want. My bad for failing to adequately understand what
that file represented.

We can either pull in selected blocks with appropriate sanity filters or
possibly consider adopting the Unicode pictographics. I'll look at cleaning
this up in the morning. If somebody has put forth a clean proposal by then,
so much the better.


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