<br><br><div class="gmail_quote">On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov <span dir="ltr"><<a 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 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>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> </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>