On Thu, Aug 3, 2017 at 12:42 AM, Xiaodi Wu <[email protected]> wrote:
> > 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. > > Thinking again about it, I guess this requirement is less often required than I originally had in mind. Things like subselections (slicing) and concatenation operations might need an adequate syntax: [A B; C D; ...] would build a new matrix in Julia and also in Matlab based on the scalar or matrix elements A B C D... and will often be combined several times in the same command (here ... is a continuation symbol) A =[ -0.2122 -0.1220 -0.3183 1.1845 -1.3455 1.9629; ... zeros(1,3) -0.3183 2.4862 2.6483; ... 0.1311 -0.1229 -0.2264 -0.3743 2.0005 0.0996]; B =[ [-0.2122 -0.1220 -0.3183; zeros(1,3) ; 0.1311 -0.1229 -0.2264] [1.1845 -1.3455 1.9629; -0.3183 2.4862 2.6483; -0.3743 2.0005 0.0996] ]; or write something like this to replace some elements of B, with ones + some of the elements of A ( here 1:2 is a bit like 1...2 in Swift, expect that you can write 1:end-1 to get all but the last one or making the union of the several ranges as you concatenate vectors. B(1:2,2:3) = ones(2,2) + A(2:3,1:2)' ; >> >> 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]> w >>>>> rote: >>>>> >>>>>> >>>>>> >>>>>> 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
