[OpenSCAD] Functions literals / higher order functions

nop head nop.head at gmail.com
Sat Nov 9 14:43:17 EST 2019


I often have code like this:

    screw = iec_screw(type);

...

    screw(screw, screw_length);

screw is both a local variable and a global module. Because it is local it
isn't really appropriate to give it a longer name, like the_screw or
iec_screw. If it was iec_screw then again it is the same name as a
function. In other languages I would have to think up a different name.

On Sat, 9 Nov 2019 at 17:49, adrianv <avm4 at cornell.edu> wrote:

> I wasn't suggesting that the old syntax be removed.  Rather, I was
> pondering
> how to write code in the future.  It appears like with the new function
> syntax that it might make sense to always use the new one.  In other words,
> to treat the old syntax like a sort of old-style method and abandon it.
>
> Out of curiosity, is there some particular use case for using variables
> with
> the same name as functions, or you just find it convenient to make
> variables
> named "square" and "cube" and so on?
>
>
> nophead wrote
> >> But I don't think I'd really miss this.
> >
> > Maybe but people like me would as I have made extensive use of it so
> > changing it would break a lot of code.
> >
> > On Sat, 9 Nov 2019 at 15:47, Torsten Paul <
>
> > Torsten.Paul@
>
> > > wrote:
> >
> >> On 09.11.19 16:15, adrianv wrote:
> >> > Would it be worth adding a simpler mechanism for passing
> >> > existing functions?
> >>
> >> Yes, that certainly is open for discussion. It might even be
> >> possible to bind the built-in functions to the respective
> >> names in the variable namespace.
> >>
> >> As that is one layer up from the top layer available to the
> >> user, it would still be possible to just overwrite those names
> >> in existing code.
> >>
> >> I believe the only non-compatible change is that you can
> >> still observe this by "if (is_undef(sin))" on top level.
> >>
> >> > It seems like the existing scheme creates two independent
> >> > namespaces for functions and it's sort of clumsy to get
> >> > between them.
> >>
> >> The other way around. Those separate namespaces already exist
> >> and cause the issues now. The problem is that first class
> >> functions obviously need to be in the variable namespace as
> >> they are really just values.
> >>
> >> > What would be the disadvantage of writing all of my functions
> >> > using the new syntax. Would there be any problems with this?
> >> > So always write
> >> >
> >> > funcname = function(...) definition....;
> >>
> >> Right now, the only disadvantage I'm aware of is that use<>
> >> will not import them as they are variables, and use<> only
> >> imports (old style) functions and modules.
> >>
> >> That's something which needs to be changed of cause.
> >>
> >> ciao,
> >>   Torsten.
> >>
> >> _______________________________________________
> >> OpenSCAD mailing list
> >>
>
> > Discuss at .openscad
>
> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >>
> >
> > _______________________________________________
> > OpenSCAD mailing list
>
> > Discuss at .openscad
>
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191109/a18b6a66/attachment.html>


More information about the Discuss mailing list