On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris <daveswee...@mac.com> wrote:
> > On Jul 23, 2017, at 12:18, Taylor Swift <kelvin1...@gmail.com> wrote: > > On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <daveswee...@mac.com> > wrote: > >> >> On Jul 23, 2017, at 09:08, Taylor Swift <kelvin1...@gmail.com> wrote: >> >> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ??? >> >> >> Correct. If you wanted a multidimensional array, that'd be written "let >> nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let >> nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option. >> IMHO all those read better than this proposal's syntax. >> >> >> > No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size > array of length two and with the elements 5 and 3, or a flexible sized > array with two elements 10 and 3? This is v confusing and difficult to > read, especially when you have actual multiplications going on such as > > let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ??? > > > That's... huh? To me, "[2 * 3 * 5, 3]" should obviously evaluate to "[30, > 3]". How are you getting that "[2*5*3, 3]" could be a 2-element FSA > containing 15 and 3? Are you suggesting that instead of "[value * value * > value, value]", it could be parsed as "[modifier value * value, value]" > (with `modifier` being "2 *")? To me, that syntax would *strongly* > suggest that the modifier only applies to the first element of the array, > which would mean the only other option for parsing it would be equivalent > to "[[3, 5], 3]", which is neither a match for fsa's type, nor a > semantically valid array (the elements have to be the same type), nor a > syntactically valid array (the nested array in the first element is missing > its "[]"). > > Well, that *is* the syntax you’re proposing right? What comes on the left of the asterisk is the FSA dimensions, and what comes to the right is the FSA elements. So `2` is the FSA length, and `3 * 5` and `3` are the two elements in the FSA. Unless of course, the right-most asterisk is defined to be the separator, in which case our FSA has *six* elements, the first two of which are `5` and `3` (what if there was a `default:` argument?). This seems v confusing to me, since we now have asterisk-as-separator and asterisk-as-multiplication mixed together within the same brackets. > Using the *multiplication operator* as a *separator* character seems like >> an extraordinarily bad idea. >> >> >> Well, much to the dismay of my occasionally-inner Unicode fanboy, we >> decided that we didn't want to make everyone have to figure out how to type >> "×" to use a stdlib type (to the further dismay of my O-IUF, this is >> actually a really good argument, especially since a likely use for FSA is >> in embedded or systems programming, where you might need to use an editor >> that doesn't support Unicode). >> >> > The text encoding of the source code shouldn’t have any effect on the > compiled target? And while the ◊ or × suggestions are semi-rhetorical, > given a choice between difficult-to-read syntax and unicode, I’ll choose > unicode every time. Swift is nowhere near the first language to use > unconventional symbols. Inserting special characters these days is barely > harder than typing a capital letter. They should be used sparingly but not > ruled out completely, and it doesn’t seem like there are many alternatives. > > > I would choose the unicode route for my projects as well, but locking > stdlib types or functionality behind unicode has been a no-go ever since > Swift was open-sourced (and presumably before then as well, since nothing > in the stdlib uses them). We couldn't even get the unicode operators for > set notation: "∩", "∪", "⊂", "⊃", "⊆", "⊇", "∈", "∋", and "∖" (maybe not > "∖"... it's been a while), accepted as *alternate* spellings for: > "setA.intersection(setB)", "setA.union(setB)", etc, back in the "Set > Algebra" proposal. I really doubt a proposal for FSAs with syntax involving > unicode will be accepted. Feel free to try, though. Maybe there's been a > change of heart since the topic last came up. > > Unicode operators for set notation was a bad idea because there was a clear, readable non-unicode alternative available — the plain spelled-out methods. Here we are far more restricted in our options, so we may as well consider Unicode as a possible alternative.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution