> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu <[email protected]> wrote: > >> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris <[email protected]> wrote: >> >> >> >> Sent from my iPad >> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution >> <[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. >> >> Getting the syntax right could possibly require some compiler changes. >> Maybe. Depends on what "right" means. Declaring a variable, x, to be "the >> set of all real numbers such that x*sin(x) is an integer" using syntax like >> this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on >> my set notation... that might not actually be correct). >> We're actually not that far off from that, compiler-wise, I mean. Aside >> defining the relevant types, operators, and identifiers, that exact syntax >> pretty much just requires the compiler to allow using a certain types of >> variables in their own declaration and either one heck of an >> `ExpressibleByClosureLiteral` protocol, or improvements to the type >> inference engine. > > We must prioritize features that make the biggest impact for the general > community, however. Swift still lacks ABI stability, ownership, concurrency, > etc. In terms of math facilities, we still don't have a model for dealing > with floating point errors. And, yes, there are improvements to be made in > terms of having consistent special functions (sin, cos) in Swift (Glibc and > Darwin don't always give you the same answer). All of these things represent > sorely needed yet large undertakings; none of these require more syntax.
Oh, I know. I wasn't claiming that we need massive compiler changes right now or anything, just providing an example of a syntax that a hypothetical "CoreMath" type of library might want to support which can't currently be made into legal swift code. - Dave Sweeris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
