<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 30.08.2011 19:33, Dean Landolt wrote:
    <blockquote
cite="mid:CAPm8pjohJPw3CiGWkjyvSXW7azR1eHk4JmZGxjiPX1251qQu_Q@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Tue, Aug 30, 2011 at 10:41 AM, Dmitry
        A. Soshnikov <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:dmitry.soshnikov@gmail.com">dmitry.soshnikov@gmail.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="im"> On 30.08.2011 17:41, Rick Waldron wrote:
              <blockquote type="cite">
                <div>
                  <div class="gmail_quote">On Tue, Aug 30, 2011 at 3:39
                    AM, Dmitry A. Soshnikov <span dir="ltr"><<a
                        moz-do-not-send="true"
                        href="mailto:dmitry.soshnikov@gmail.com"
                        target="_blank">dmitry.soshnikov@gmail.com</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      OK, let's up the topic. Seems there are no
                      technical issues in the proposed thing -- we can
                      simply either accept it or not. The question is
                      whether it's needed and sound proposal and the
                      feature to have in ECMAScript.<br>
                      <br>
                      Some summarized features below:<br>
                      <br>
                      + Ability to get help of any built-in and any
                      user-defined function directly in runtime (in
                      later case, authors should provide the
                      documentations though)<br>
                      + Auto-suggest and hints of parameters and their
                      types when typing function name in console.<br>
                      + Ability even to have sort of guards for types
                      with issuing warnings in case if types mismatch
                      (sort of recent contract.coffee projects and
                      actually other langs, e.g. Haskell, Erlang, etc).<br>
                      - Code size will be increased to store the doc
                      string. This can be optional in case of minimized
                      scripts (lint tools can have option "Remove
                      doc-comments")<br>
                      <br>
                      As an example I show a spec description for
                      `parseInt` function:<br>
                      <br>
                      15.1.2.2 parseInt (string , radix)<br>
                      <br>
                      Let [[Documentation]] property of the `parseInt`
                      function be the following string:<br>
                      <br>
                      "The parseInt function produces an integer value
                      dictated by interpretation of the contents of the
                      string argument according to the specified radix.
                      Leading white space in string is ignored. If radix
                      is undefined or 0, it is assumed to be 10 except
                      when the number begins with the character pairs 0x
                      or 0X, in which case a radix of 16 is assumed. If
                      radix is 16, number may also optionally begin with
                      the character pairs 0x or 0X."<br>
                      <br>
                      ...<br>
                      <br>
                      x.x.xx help(F)<br>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>A built-in, global object function property
                      named "help()" will no doubt conflict with
                      userland code</div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              <br>
            </div>
            It's derived question, we may choose any name which fits
            well (though, IMO `help` name isn't used much). </div>
        </blockquote>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>That's tough to say for sure, and even if true still
          probably isn't good enough. Regardless, there's no excuse for
          this kind of global, especially in light of a module system.
          Sure, specifically in a repl you'd probably want to skip the
          require -- for this node offers up dot-prefixed repl keywords.
          So something like .help(F) would be a lot safer and nearly as
          convenience as a help global.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, I guess. Anyway, all this about only "debug-in-console" mode,
    so .help(...) would be just fine.<br>
    <br>
    <blockquote
cite="mid:CAPm8pjohJPw3CiGWkjyvSXW7azR1eHk4JmZGxjiPX1251qQu_Q@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>I think it would be useful for the committee to weigh in on
          the idea of repl plugins. This particular design is pretty
          nice but it conflicts for statements beginning with
          non-zero-prefixed decimals. In practice I don't see this
          causing any real problems, but it'd be great if the grammer
          explicitly forbid this, effectively reserving it for repl
          hooks.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Maybe, though, in contrast with other langs, ES is different since
    because of browser vendors has different implementations. Actually,
    there is no such implementation as "ECMAScript". In contrast,
    languages such as e.g. Python or Erlang have the sample
    implementations (usually that which is placed directly on the
    website of the language), and there of course the attention to a
    good console and downloadable and installable "in one click" REPLs
    is paid much. And that's said, this increases and speeds up the
    learning of the language. I don't know what to propose in case of
    ECMAScript, since repeat, there is no such language as ECMAScript
    "in real life" and therefore, there is no "the sample REPL" for
    which it would be the best to have .help(...) function which shows
    the doc-comment of a function.<br>
    <br>
    And in case of a browser -- I don't think it's needed much. OTOH, of
    course devs. also debug the browser code in tools such as Firebug,
    where they also can use this .help(...).<br>
    <br>
    So I'm still thinking myself, is it worth to move it to the level of
    the ES spec (the [[Doc]] property and similar) or it's not needed
    much and is only for "playing in console". OTOH, this "playing in
    console" is what makes Python the best in this respect.<br>
    <br>
    <blockquote
cite="mid:CAPm8pjohJPw3CiGWkjyvSXW7azR1eHk4JmZGxjiPX1251qQu_Q@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div bgcolor="#FFFFFF" text="#000000">The main thing I want to
            clarify at this step, whether we need at all this thing in
            ES?<br>
            <br>
            Since committee keeps silence, I'd like to consider it
            better as "Yes, we need it and there is nothing to add",
            rather than "We don't need and don't want even to discuss"
            (since there is no big sense in later, because the
            functionality seems useful). However, we need to clarify how
            *exactly* it's useful. Maybe using JS in console is so rare
            case and it isn't required much. OTOH, era of
            client-side-only-JS is behind and JS is also on server now.
            And from this viewpoint, in the console, it's the best to
            get the help, hints for parameters and even type checking
            for functions.<br>
          </div>
        </blockquote>
        <div> </div>
        <div><br>
        </div>
        <div>Brenden weighed in and laid out some of the design space. I
          suspect this functionality can largely be pieced together with
          what harmony already gives us. As Brenden hinted, quasis give
          us multiline strings. The __doc__ key is just screaming to be
          a private name instead (generally true of all wunderbars
          IMHO). This could be tacked onto functions and objects
          imperatively, but it would be pretty goofy to put the doc
          string <i>after</i> its function body. So for this to be
          serviceable we'd need a declarative way to do this inside the
          function body. ISTR some syntax being thrown around to set an
          own-prop on a function from inside its body but I can't recall
          specifics -- is there anything harmonious for this?</div>
        <div><br>
        </div>
        <div>Put the above three bits together with a de facto repl
          plugin syntax and module mapping and you get a more sanitized
          (and extensible) version of python's repl with the same
          developer ergonomics.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, but all this needs to be considered as "needed" first. The lack
    which I mentioned myself of the feature is that the source code will
    be increased (lint tools though will provide "Remove doc-comments"
    for indemnified scripts) and the size of a byte-code to keep
    additional property of a function.<br>
    <br>
    Dmitry.<br>
    <br>
  </body>
</html>