<div dir="ltr"><div>Breaks all my code as I use lots of single names for both a variable, a function that exports it and module that it relates to. I find it handy not to make up three names for one subject. It is obvious which one is referenced from the context.<br><br></div>If there is a breaking change to OpenScad I will stick with the version I have now forever as it does everything I need. Same as Python 2, never used 3 as I need to change all my print statements to functions. Please make such big changes in OpenScad2.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 October 2016 at 23:07, Mark Schafer <span dir="ltr"><<a href="mailto:mschafer@wireframe.biz" target="_blank">mschafer@wireframe.biz</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">
    <p>Does this mean we will have to use unique names for everything ?<br>
    </p><div><div class="h5">
    <br>
    <div class="m_2154711685063479469moz-cite-prefix">On 10/15/2016 2:46 AM, doug moen wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>Bananapeel wrote:<br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IMO, there's just one
            "proper" syntax for this. And that is, that the name<br>
            without () acts as a variable, and () means call. And
            function becomes just<br>
            another type, like string and int. This means functions and
            variables must<br>
            occupy the same namespace. This syntax can also work for
            modules, however,<br>
            this means variables, functions and modules all share the
            same namespace,<br>
            which currently isn't the case.<br>
          </blockquote>
          <div><br>
          </div>
          <div>I agree with this.<br>
            <br>
          </div>
          <div>If we implement function values without uniting the
            namespaces, we have to use ugly, nonstandard syntax for
            things like: calling a function stored in a variable, or
            passing a named function as an argument. This leads to
            complicated rules and ugly syntax, worse than function calls
            in any modern programming language. And that's not in the
            spirit of OpenSCAD, which aims to be simpler than a general
            purpose programming language.</div>
          <div><br>
            Thought experiment: what happens if we change OpenSCAD to
            use 1 namespace in the next release? Answer: we'd break some
            existing code, and that happens in two ways:<br>
            <ol>
              <li>If you define a function and a variable with the same
                name X, in the same scope, then the code no longer
                works. We should report an error (duplicate definition
                of X).</li>
              <li>Currently, a variable defined in an inner scope
                cannot  shadow a variable defined in an outer scope, and
                vice versa. Once we unify the namespaces, the scoping
                rules change, and this sort of shadowing will occur. And
                this could be a silent error?</li>
            </ol>
            So maybe we should make this change in two phases, first
            deprecating the 3 namespaces, then uniting them in a
            subsequent release?<br>
            <ol>
              <li>In release N, we'll deprecate the 3 namespaces. You'll
                get a warning for duplicate definitions in the same
                scope, and a warning for objects with different kinds
                but the same name shadowing each other in nested scopes.</li>
              <li>In release N+1, these warnings turn into errors. We
                won't silently change the meaning of old code: instead,
                we'll detect the old incompatible code, report an error
                and force you to fix it. In this release, we can also
                make functions into first class values, and introduce a
                syntax for anonymous functions. Although the namespaces
                are now unified, modules won't necessarily be first
                class values (that's harder to do, and I won't discuss
                the details here).<br>
              </li>
            </ol>
          </div>
          <div>Even with the deprecation release, this is a disruptive
            change that breaks existing code. It's more work, but we
            could mitigate the problem by providing an upgrade tool that
            automatically renames objects to avoid conflicts. (For
            example, the tool could append a V, F or M to the names of
            variables, functions and modules that conflict with one
            another.) If the upgrade tool is painless enough to use,
            maybe we don't need the deprecation phase?<br>
          </div>
          <div><br>
          </div>
          <div>This is the simplest path I can think of that leads to
            function values with a unified namespace. The backwards
            compatibility scheme I described in the OpenSCAD2 proposal
            is much harder to implement.<br>
          </div>
          <br>
        </div>
        Doug Moen.<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 10 October 2016 at 15:15, Bananapeel
          <span dir="ltr"><<a href="mailto:lunatica.xiaoyu@gmail.com" target="_blank">lunatica.xiaoyu@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't
            know why this thread is inside the thread "Convert from
            object to<br>
            polygon/polyhedron." Anyways, regarding passing functions as
            arguments:<br>
            <br>
            IMO, there's just one "proper" syntax for this. And that is,
            that the name<br>
            without () acts as a variable, and () means call. And
            function becomes just<br>
            another type, like string and int. This means functions and
            variables must<br>
            occupy the same namespace. This syntax can also work for
            modules, however,<br>
            this means variables, functions and modules all share the
            same namespace,<br>
            which currently isn't the case.<br>
            <br>
            Using () on a variable that isn't of type function or module
            would give a<br>
            runtime error.<br>
            <br>
            Example:<br>
            <br>
            //Preferred usage//<br>
            <span>function xsq(x) = x*x;<br>
              function recip(x)=1/x;<br>
              vec1=[1, 2, 3];<br>
            </span>vec2=[0.1, 0.7];<br>
            <br>
            function map(func,vec) = [for (i=vec) func(i)];<br>
            <span>echo(map(xsq,vec1));<br>
              echo(map(xsq,vec2));<br>
              echo(map(recip,vec1));<br>
              echo(map(recip,vec2));<br>
              <br>
              //Other crazy usage//<br>
              function div3(x)=x/3;<br>
              indirect = div3;<br>
              echo(map(indirect,vec2));<br>
              <br>
              <br>
              <br>
              <br>
            </span>--<br>
            View this message in context: <a href="http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18659.html" rel="noreferrer" target="_blank">http://forum.openscad.org/Conv<wbr>ert-from-object-to-polygon-<wbr>polyhedron-tp18522p18659.html</a><br>
            Sent from the OpenSCAD mailing list archive at Nabble.com.<br>
            <div class="m_2154711685063479469HOEnZb">
              <div class="m_2154711685063479469h5"><br>
                ______________________________<wbr>_________________<br>
                OpenSCAD mailing list<br>
                <a href="mailto:Discuss@lists.openscad.org" target="_blank">Discuss@lists.openscad.org</a><br>
                <a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer" target="_blank">http://lists.openscad.org/mail<wbr>man/listinfo/discuss_lists.<wbr>openscad.org</a><br>
                <br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="m_2154711685063479469mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
OpenSCAD mailing list
<a class="m_2154711685063479469moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org" target="_blank">Discuss@lists.openscad.org</a>
<a class="m_2154711685063479469moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" target="_blank">http://lists.openscad.org/<wbr>mailman/listinfo/discuss_<wbr>lists.openscad.org</a>
</pre>
      <br>
      <fieldset class="m_2154711685063479469mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><p color="#000000" align="left">No virus
        found in this message.<br>
        Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a><br>
        Version: 2016.0.7797 / Virus Database: 4664/13206 - Release
        Date: 10/13/16</p>
    </blockquote>
    <br>
  </div>


<br>______________________________<wbr>_________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer" target="_blank">http://lists.openscad.org/<wbr>mailman/listinfo/discuss_<wbr>lists.openscad.org</a><br>
<br></blockquote></div><br></div>