Sent from my iPad
> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fez...@gmail.com> 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.
- Dave Sweeris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
