> On Aug 31, 2017, at 3:17 PM, Dave DeLong <[email protected]> wrote:
>
>>
>> On Aug 31, 2017, at 3:58 PM, David Sweeris <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Just a side observation…
>>>
>>> One of the downsides I would put forward to notation like this is it
>>> massively increases the barrier to entry for anyone else. I look at that
>>> “Reduction.agda” file and wonder if I need to go back to school for a
>>> degree in Math just to understand what’s going on.
>>>
>>> On the other hand, while using inefficient matrix notation may be more
>>> verbose, it is consistent with the other notation used in programming,
>>> which means it is more easily understandable for new-comers to the code.
>>
>> New-comers from where? I've met more than one mathematician or physicist who
>> claims they can't code because the syntax isn't what they're used to. People
>> with different backgrounds can and do have vastly different ideas about what
>> constitutes an intuitive syntax for any given semantic (which why I disagree
>> with the notion that having more than one spelling for stuff is inherently
>> bad).
>
> That’s a fair point, which IMO reinforces the notion that changes like this
> should be an editor-level feature, and not a code-level feature.
>
> An editor can reformat code (using a font with bazillions of ligatures or
> whatever) in was that you wouldn’t want to necessarily “hard code”.
To clarify, you're suggesting we do something like this?
@prettyprint(prefix operator "Σ", /*probably some CSS or something for telling
the editor where to position the arguments relative to the operator, whether
they're rendered with subscript vs superscript vs normal, etc */)
func sum <T: Numeric, S: Sequence> (indicies: S, term: (S.Element) -> T) -> T {
return indicies.reduce(0) { $0 + term($1) }
}
Technically speaking, yeah, sure, such a system could be made to work. I don't
see it getting much support outside of Xcode, though, unless you can convince
other languages to adopt the same convention. We'd want people's choice of
display style to be driven by personal preference, not whether they can
integrate Xcode into their workflow. Speaking of workflows, how far from "plain
text" do you think we can get before people start thinking that you need a mac
running Xcode to program in Swift?
- Dave Sweeris_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
