<peepsalot>
damn computer turned itself off while i was doing yard work. pretty sure its nvidia drivers making everything unstable
<peepsalot>
i'm about to start looking for someone to trade me a radeon for my nvidia
JordanBrown has joined #openscad
<JordanBrown>
You can put a reference to a function into a variable. Has anybody given any thought to being able to put a reference to a module into a variable?
<JordanBrown>
x = module(d) cube(d); x(5); would give you a 5-unit cube.
<JordanBrown>
Or something like that.
ur5us_ has quit [Ping timeout: 260 seconds]
LordOfBikes has quit [Ping timeout: 268 seconds]
LordOfBikes has joined #openscad
Junxter has joined #openscad
<InPhase>
JordanBrown: Yes. There's a module literals proposal up there. I think in an issue.
<JordanBrown>
Just thinking about the whole "use" controversy, and wondering if there's a lesson from other languages - e.g., Python.
<JordanBrown>
Maybe there would be an "import" operation that would return an object (in the new JS-like sense) that the library file specifically exported.
<InPhase>
Pretty much no other language from the last 50+ years has done anything like the old use behavior which was fixed did.
<InPhase>
So the fixed version follows all the lessons from other languages.
<JordanBrown>
The current behavior is pretty deranged too.
<JordanBrown>
In particular, that file-level variables are evaluated on every call.
<InPhase>
That will be fixed.
<InPhase>
The previous fix was required first.
<JordanBrown>
With its own controversy, no doubt. 50% :-) 50% :-(
<InPhase>
Well there's pretty much no reason left to be evaluating file variables on every call.
<InPhase>
And the performance overheads are truly massive, not small.
<JordanBrown>
Unless you want those values to be dependent on the call-time $variable values.
<InPhase>
You don't do that. This is a declarative language. The only values which should change should be IN the module or function.
<JordanBrown>
Perhaps one might say that you *shouldn't* do it, but based on the discussion so far it seems likely that people *do* do it.
<InPhase>
function polygon_rotate_angle() = 360/$fn/2;
<JordanBrown>
I didn't say there weren't alternatives.
<JordanBrown>
And in fact I think that evaluating the file-level variables on every call is, as I said, deranged.
<InPhase>
I suspect few people were doing it.
<JordanBrown>
But it *is* what's done now, and it would be unsurprising if somebody assumed it.
<JordanBrown>
And of course the only kind of people who would assume it are those with large and complex infrastructures.
<JordanBrown>
People with simple projects probably never do that sort of thing.
<JordanBrown>
but I was musing about something that would look like:
<JordanBrown>
lib = import("lib.scad");
<JordanBrown>
echo(lib.func1(123));
<JordanBrown>
lib.mod1(321);
<InPhase>
nophead fell into it as a pattern he found useful, and then used it intensively in his parts library. But I think part of the difficulty he's having now is that it's very difficult to trace where the values are actually coming from in that library, so it's hard for him to reason out the fixes. This is because he has use files which include files which include files which include files, and there are
<JordanBrown>
y = lib.var1;
<InPhase>
variables changed in that last included file which then dynamically alter the behavior of the called module. So basically the dynamic value changes are coming out of nowhere like magic.
<InPhase>
But this is also exactly the reason this shouldn't happen. It's extremely difficult to trace, whereas it's a declarative language where all dynamic value changes should come straight down the call chain.
<JordanBrown>
in a scheme like this, the library would have its own namespace. Nothing would leak out of that namespace, except through the explicit export.
<JordanBrown>
(but dropping that Python-esque idea and returning to more-or-less today...)
<JordanBrown>
I think there are two consistent mental models.
<InPhase>
I would be fine with a use literal for namespacing purposes.
<JordanBrown>
In model A, which is what AFAICT OpenSCAD used to do, the file level of a "used" file is effectively a call level that is inbetween the calling function/module and the called function/module in the "used" file.
<InPhase>
Or an include literal. Both would be okay to me.
<JordanBrown>
It's sort of as if the entire "used" file was wrapped up in a module, except that callers can call directly into the functions and modules in it.
<JordanBrown>
In model B, the file level of a "used" file is more like a call level before all calls, so for dynamic-variable purposes the call stack looks like main / used / main-caller / used-callee.
<JordanBrown>
I think that latter is more like a conventional language.
<JordanBrown>
And it has the performance advantage of executing the file-level assignments only once.
<JordanBrown>
I think model B would address nophead's immediate complaints, that the $ variables in the used file are in some ways dropped on the floor, but I get the impression that he wouldn't like the fact that the lexical variables couldn't be based on call-time caller-supplied dynamic variables.
ur5us_ has joined #openscad
<InPhase>
100% of what he wants to do is doable by just calling functions.
<InPhase>
He's basically trying to centralize rules for calculating values dynamically. This is what functions are for.
<InPhase>
He just built a pile of code using the use-reparse behavior instead of functions. But, functions worked before and would work now, just in a clearer manner, being explicit about what is dynamically calculated from a definition above.
snakedLX is now known as snaked
<InPhase>
I tried to give a bunch of examples of how, but he continued to say it couldn't be done for a while after that. And then there were some communication difficulties getting a description of the problem. But, I'm still quite confident it can all be done with functions.
califax- has joined #openscad
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
<JordanBrown>
Functions are slower than variables, no doubt. (Or, well, maybe not, depending on how the internal compilation mechanism works.)
<JordanBrown>
But OTOH not evaluating file-scope values on every call would be a big win.
<JordanBrown>
BTW, does it evaluate file-scope values on *every* call, or just on the calls that cross into the "used" file?
<JordanBrown>
Just on crossing, it appears, not calls inside the "used" file.
<JordanBrown>
WRT functions, I *am* sympathetic to wanting to be able to declare at the top of a file "these are the default values for this file", in a static-assignment sort of way.
<JordanBrown>
Performance tidbits...
<JordanBrown>
for (i = [0:9999], j=[0:99]) {
<JordanBrown>
z = ...;
<JordanBrown>
}
<JordanBrown>
where ... is:
<JordanBrown>
a constant 5: 1.7s
<JordanBrown>
a file-scope lexical variable: 1.8s
<JordanBrown>
a file-scope dynamic variable: 1.9s
<JordanBrown>
a function that returns a constant: 3.2s
<JordanBrown>
So there's not a tremendous difference, but there is some.
JordanBrown has left #openscad [Leaving]
othx has quit [Ping timeout: 268 seconds]
gunnbr_ has joined #openscad
gunnbr has quit [Ping timeout: 268 seconds]
othx has joined #openscad
<InPhase>
There's no intrinsic need for functions to be slower. That's just a missed optimization opportunity. But even with that, the function approach is faster the instant you have two or more variables but needed only one value for a particular routine.