> On Aug 31, 2017, at 5:45 PM, David Sweeris <[email protected]> wrote: > >> >> On Aug 31, 2017, at 3:17 PM, Dave DeLong <[email protected] >> <mailto:[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
Perhaps… I’m fully admitting up-front that this is all really hand-wavy and we’re probably veering a bit off-topic, since this is getting more in to “editor-evolution” rather than “swift-evolution”. But yes, if an editor had some sort of intrinsic knowledge about the purpose of a line of code, then it could visually “rewrite” a summation function using a Σ. Or if it knew about matrix types, perhaps it could render the matrix in the 2D format that is standard to matrix notation. Or it could replace UIImage(named: “someConstant”) with the rendered image literal, without actually requiring the explicit underlying image literal syntax. A grossly simplified comparison is that good markdown editors don’t just show the plaintext for the markdown you’re writing, but will also `stylize` *code* _correctly_ **as** *`you write it`*. Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
