I use Mathematica, which under the covers is very Lisp like, though with names
outside the brackets, comma separators, and square brackets. EG `a + b` is
really:
Add[a, b]
The editor however supports all sorts of input formats including the above two
and renders in full mathematical glory, e.g.:
Integrate[a Sin[:theta:], {:theta:, 0, :pi:}]
The above displays, could be entered with, and can be edited with full integral
sign with limits, Greek, etc. Note how space (between a and Sin) is a shortcut
for * in Mathematica. Also you don’t enter spaces (other than multiply) or
layout text, the editor does those (though you can override) in a word
processor style dynamic layout. Different fonts are extensively used and
comments contain rich text and images and diagrams (like playgrounds).
Food for thought about what might be possible for a Swift editor.
-- Howard.
> On 1 Sep 2017, at 11:27 am, John McCall via swift-evolution
> <[email protected]> wrote:
>
>>> On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution
>>> <[email protected]> wrote:
>>> these versions of the math operators don't quite work the same way as the
>>> standard ones (e.g. `+` can throw), but they still carry math semantics
>>
>>
>> That is exactly what I argue should be avoided. When you see `+` you don’t
>> expect it to throw. What’s more they don’t carry “math” semantics at all
>> because for example
>>
>> Func * (Double, Measurement) -> Measurement is not even associative.
>
> It's not a group operation, but it is consistent with the concept of scalar
> multiplication in a vector space. People sometimes forget that mathematical
> notations are in fact human languages, which is it say that they're heavily
> ambiguous and contextual; there are plenty of texts where you see things like
> S_ij and it's simply understood that i and j are in fact independent indices
> into the family S. You could undoubtedly design a parser that understood
> that sort of rule, but would it ultimately parse a reasonable programming
> language? I don't think so.
>
> I would argue that there is a much broader philosophical truth here.
> Programming is not, and never can be, a pure exercise in mathematics, and the
> concepts necessary for understanding programming are related to but
> ultimately different from the concepts necessary for understanding
> mathematics. That is, Dave Sweeris's mathematicians and physicists are
> almost certainly misunderstanding their confusion: saying that the syntax is
> wrong implies that there could be a syntax that could be right, i.e. a syntax
> that would allow them to simply program in pure mathematics. That is a
> misapprehension just as deep as the belief that there could be a programming
> language that would allow one to simply program in conversational English or
> Korean. Even the ability to extract code from a proof assistant like Coq or
> Agda — and writing a proof in Coq or Agda is pretty far from the daily grind
> of most mathematicians — doesn't belie this, because ultimately the exact
> code extracted matters to a programmer in a way that the exact form of a
> known-valid proof does not matter to a mathematician.
>
> John.
>
>> I agree that operators for this kind of functions should exist and are the
>> right syntactic tool. But I disagree with the current implementation. My
>> proposition for the example of `*` is as follow:
>>
>> This signature happens quite often `(Number, T) -> T`. It would seem quite
>> intuitive to have a dedicated operator for all “Scalar multiplication” which
>> would be visually distinct from `*` (for example **, or Unicode ⊗) and
>> consistent across codebases.
>>
>> For a + operator that throws, I would imagine a “TryAddable” protocol with a
>> `+!` operator which can throw. I agree that it is visual noise, but I argue
>> that it has tremendous value: consistant operator semantics.
>>
>>> (Also, I really doubt changing concatenation to `++` is going to fly. Swift
>>> is not Haskell.)
>> I doubt those remarks are very constructive. The point still stands: I find
>> value in having different operators for different semantics.
>>
>>> On 1 Sep 2017, at 01:54, Brent Royal-Gordon <[email protected]> wrote:
>>>
>>>> On Aug 31, 2017, at 3:40 PM, André Videla via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> Something I could imagine is deprecate operator overloading and constrain
>>>> them to a single Type. For example, the operator `+` could be constrained
>>>> to the protocol `Addable` and has the signature `infix func + (Self, Self)
>>>> -> Self` and is commutative. Similarly, we could have a protocol
>>>> `Concatenable` which has its own operator (e.g.: ++ ) and is not
>>>> commutative.
>>>
>>>
>>> These are basically "bag of syntax protocols" which aren't really usable
>>> generically, so we don't want this design. And if you tied this to the
>>> numeric protocols, then you couldn't use `+` for things that are
>>> numeric-ish but don't quite fit the protocols. For instance, I have a
>>> library that adds `+` and `*` operators to `Foundation.Measurement`; these
>>> versions of the math operators don't quite work the same way as the
>>> standard ones (e.g. `+` can throw), but they still carry math semantics and
>>> so `+` is the right operator for them. If `+` was exclusively tied to a
>>> particular protocol with a particular signature, I wouldn't be able to do
>>> that.
>>>
>>> (Also, I really doubt changing concatenation to `++` is going to fly. Swift
>>> is not Haskell.)
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>> _______________________________________________
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
