Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal) (guest271314)
guest271314 at gmail.com
Fri Mar 8 17:56:23 UTC 2019
> That proposal wasn't about ranges, even though it might look like it was.
> It's about a special type of numeric array conversion that's really about a
> particular sequence that isn't all that special in the context of
> programming. 1 <https://oeis.org/A217626> It also links to an SO question
> that almost reads like a homework/"gimme teh codez" question. 2
The conversion from number to array and array to number is not "about" the
referenced sequence. Attempting to solve OEIS A217626
https://oeis.org/A217626 directly was the *motivation* for beginning the
work of number to array and array to number conversion.
Do not do "homework" within the sense or scope of western academia. Am not
a student at/of any western academic institutions. And no, the question
does not "almost" read like the little phrase that you used to describe the
question. Do not need your code. Am quite capable of solving own coding
problems. When do decide to ask a question it is for additional
perspective; so as not to exclude other perspectives from being potentially
helpful in solving the problem, as could readily do. Your message reveals a
rather narrow and cynical view. That is ok. Occasionally such a point of
view can be useful. You are simply incorrect in your analysis as to why the
proposal was brought to tc39.
On Thu, Mar 7, 2019 at 11:28 PM Bob Myers <rtm at gol.com> wrote:
> There is already a very well thought out list, although to my knowledge it
> has never been officially blessed, at https://esdiscuss.org/topic/ranges.
> It seems odd that after all these years of discussions and
> meta-discussions about ES feature proposals, some people are still saying
> things like:
> - there really needs to be
> - I'd really like
> - I'd love to have
> often without addressing a single one of the relevant questions:
> 1. *Is it sugar?* Is it "mere" syntactic sugar (which is not
> disqualifying in and of itself), or something that requires (or benefits
> from) being baked into the language?
> 2. *How much sugar?* If it is wholly or partially syntactic sugar,
> what the degree of syntactic optimization?
> 3. *Frequency of benefit?* What is the frequency of the use case?
> 4. *Expected improvement*? If it is something that would benefit from
> being baked into the language, what is the degree of the benefit (eg, in
> terms of performance)?
> 5. *Userland implementable?* Can it be implemented in userland code?
> If so, what's the downside of that?
> 6. *Implementable?* Does it present potentially difficult or
> intractable implementation challenges?
> 7. *Consistent?* Is it consistent with existing syntactic and semantic
> practices in the languages?
> 8. *Holistic?* Does it fill in some obvious logical gap in the current
> language design?
> 9. *Understandable?* Does it place an unsustainable new "cognitive
> burden" on learners and users of the language?
> 10. *Library?* Is is something that would be better provided as part
> of some kind of future standard library?
> 11. *Intrusive?* Does it take over real estate that might be useful
> for future features no one has thought of yet, the obvious example being
> using special characters?
> 12. *Readability?* Is it something that results in a distinct
> improvement in readability or visible semantic correctness of code?
> 13. *Prior art?* Has this or a similar feature already been proposed,
> and if so what was the reaction, and how is your proposal different from
> that, or from a similar features existing in other languages?
> I'm sure there are cases where simply throwing out an informal idea and
> seeing how people react is useful to get a discussions started, but most
> reactions will be that the proposal does not meet one or more of the above
> criteria, so proposers could save themselves and other people lots of time
> in advance by explaining HOW their proposal satisfies these points, not all
> of which are relevant to every proposal, but those which are.
>> It would be useful to have a FAQ somewhere with a version of the above 4
>>> rules that is better worked out and justified, so we could point to that.
>>> (From whatever public-facing forum is selected for the future; this one is
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss