On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <[email protected]> wrote:
> I think that the items mentioned earlier in the list (just reminded below) > should not all be treated equally. > > - RNG and cryptography library (CryptoSwift could be a good base for this) > - Generic Math library/Vector library > - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, > graphs, etc) > - Modern DateTime library > - Modern String processing toolkit > - 2D Graphics library (similar to cairo) > - Windowing/UI library > > By that I mean that I see at least one distinction to make between: > > a) the libraries that would make Swift and the programmer experience with > these libraries under Swift significantly better if they are (or at least > feel) deeply integrated in the language (for instance with associated syntax > / syntax sugar) > and > b) those that would not really benefit from such an integration to the > language. > > For me a core math library, clearly belongs to category a) > I am of course not talking about a syntax sugar to call a sin or cos > function, but rather to manipulate other objects such as N-dimensional > matrices, defining maths functions that can take such matrices as argument > e.g. sin(A) with A as matrix produces a matrix of the same size where all > elements are the sinus values of the elements of A (sorry but things like > this calling map() with 'sin' looks quite ugly for scientists). > Such a good math syntax should be compact enough to have complete > equations looking "close enough" to the maths equations you could have > written in a LaTeX or Word documentation of your scientific code. IMO a > well integrated swift core math library should feel a Julia or Matlab code > (while still having the power of Swift in terms of speed and modern > programming paradigms) instead of looking and feeling like 'numpy'. But the > latter is what you get if you just make a math library with no integration > to the language syntax, operators, and basic functions. > I agree that if this would require compiler support, then it needs to be part of the standard library. However, I don't see anything about what you describe that cannot be supported as a third-party library. > > I would personally place a crypto library in category b). > > > For basic data structures, I would say probably something in between: > maybe a few data structures are worth having a nicer syntax that typical > method calls (just as [] are used for arrays and it looks and feels great) > but it would be pointless IMHO to try extending that to too many of these > data structures. > > > > > > On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > >> >> >> On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < >>> [email protected]> wrote: >>> >>>> >>>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >>>> [email protected]> wrote: >>>> >>>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <[email protected]> wrote: >>>>> >>>>>> >>>>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> So, this has been discussed before on the list many times in the >>>>>>>> past. The core team has stated that their preferred process for this >>>>>>>> is to >>>>>>>> have individuals write their own libraries, get real-world adoption, >>>>>>>> then >>>>>>>> (as consensus emerges) propose their inclusion as a core library. >>>>>>>> >>>>>>>> I already opened a new mail to write my answer, but than I thought >>>>>>>> "wait, scroll down, and look if Xiaodi did already post links" ;-) >>>>>>>> [But where have those potential core libraries been mentioned?] >>>>>>>> >>>>>>>> Anyways, my perception hasn't change much: >>>>>>>> I think it would be enough if someone from Apple would say "here's >>>>>>>> an empty github-repo called >>>>>>>> [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; >>>>>>>> feel free to fork and create pull requests" and adding some democratic >>>>>>>> mechanism for acceptance on top of it. >>>>>>>> >>>>>>>> >>>>>>>> What would be your compatibility and stability expectations of such >>>>>>>> APIs? If there are any expectations, then the APIs would need careful >>>>>>>> design and thought. The Swift project faces a lot of design bandwidth >>>>>>>> limitations, so prioritize is always tricky. >>>>>>>> >>>>>>>> >>>>>>> The point of spinning off separate core library working groups would >>>>>>> be so that library feature requests and proposals can stop clogging up >>>>>>> swift-evolution. Then the swift-evolution core team could focus on the >>>>>>> compiler and the standard library and the community would take >>>>>>> stewardship >>>>>>> of the core libraries through separate channels. >>>>>>> >>>>>> >>>>>> My understanding is that the server working group, and all such work >>>>>> groups, will be presenting their proposals here for approval, and that >>>>>> all >>>>>> API changes in the Swift open source project go through this list. >>>>>> >>>>> >>>>> That sounds like it would spam the general list a lot? >>>>> >>>> >>>> On the contrary, core team members have confirmed that working >>>> proposals such as those are the principal intended use for this list; it is >>>> *not* meant to be a general forum for musings about Swift language design. >>>> >>>> >>>> >>>> My rule of thumb was that any post on the mailing list that I make has >>>> to be aimed at providing a solution to a problem, or at the very least, >>>> seeking help in providing a solution to a problem. If the discussion has no >>>> definitive actionable outcome, then I consider it pointless. >>>> >>> >>> At the same time, people should be able to float ideas here to see how >>> well they would be received before investing the energy into writing up a >>> proposal. I certainly wouldn’t spend time drafting up an entire API spec >>> for a math library without first checking that this is something that the >>> community actually wants. >>> >> >> I would mostly agree with that statement, except for the word "here." >> Swift Evolution clearly isn't representative of the community of Swift >> users generally; there are Slack channels, Reddit groups, and other forums >> which are intended to be a place for general discussion, and which would >> probably get you a good sense of what users want. I definitely agree with >> Gor that the "actionable outcome" rule of thumb is a pretty good guideline >> for what's most effective on this mailing list. >> >> The other point I'd make here is that I definitely think the core team is >> right about encouraging any "entire API spec" for a math library to be >> based on implementation experience from actually writing a math library >> that has seen good adoption. Essentially, what they're saying is that any >> proposed design here should have already proved itself in the field. I >> assume that you are well aware of Conway's law, which afaict has good >> evidence to back it up; with that in mind, the end product that emerges >> from a draft spec and an empty open-source repo is unlikely to be >> satisfactory, let alone optimal. >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
