-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
collapsing namespaces #23
Comments
Yes, I've considered this type of design as well. The syntax I came up with was The advantage is for the developer: this makes it easier to implement function values, with a smaller set of changes, without collapsing the namespaces. The disadvantage is for users: it is ugly and overly complicated. |
Well, it isn't really necessary to have a way to specify the 'variable' namespace as that would be default. The parentheses that I used could actually be omitted now that I think about it, so long as there is whitespace between the keyword and the name. I'm not necessarily a fan of compact over more expressive, but the I have many functions that are equivalent module namespace items, such as cube, sphere, etc and is the reason for my like of the separate namespaces. It really bothers me that older, tried and true libraries will be lost due to this incompatibility, requiring a major overhaul and a new debugging cycle. |
The "OpenSCAD2" proposal has a few problems, and one of them is the inability to work with OpenSCAD libraries that define the same name in different namespaces. The However, I also think that 3 namespaces are a bad design and an evolutionary dead end. A next generation OpenSCAD design would do well to break free of this design and support a single namespace, because that's the way to achieve a simpler and more powerful language. So I view the system of identifier prefixes as an ugly kludge for backwards compatibility, and nothing more. |
To each their own. There are a few languages that do this, perl being the most notable one. I still don't know why you need the |
OpenSCAD2 has a single namespace, but it needs to be compatible with libraries written in the older dialect, which has 3 namespaces. Suppose you write some OpenSCAD2 code:
So, |
As I said before, not really a fan of having OpenSCAD2 using 1 namespace and am trying to emphasize this point. A for referencing the two different namespaces, you could use |
I think it's better to go for a simple, concise and obvious syntax. One nice thing is that OpenSCAD is also usable by non-programmers, adding some obscure syntax by default seems not very useful. The current syntax is pretty much ad-hoc, OpenSCAD2 can improve there a lot by unifying concepts and leaving the obscure prefixes only for cases where needed for backward compatibility. |
@Ma-XX-oN said: "for referencing the two different namespaces, you could use M.foo and M.f$foo. Variables wouldn't need the decoration as it is implied." That doesn't work reliably. Suppose that M is an OpenSCAD script (the 3-namespace dialect) containing a function Now suppose that M is updated with new definitions, and there is now a variable called What should happen is that you get an error, and you have to update your code to use |
There are also others in the community who prefer the separate namespace structure. How about this: unless a the symbol exists in more than one namespace, disambiguating would not be necessary, and an error would be displayed when trying to reference an ambiguous symbol name in an ambiguous context, when it doesn't have a decorator. That would allow for the ability to use 3 different namespaces while looking like it is one. If there's concern that some new person may not understand that, then use a keyword or function call that would specify that the current file uses 1 or 3 namespaces. It can be defaulted to 1 but can be set to 3. If 1, then using the same name for different contexts would be considered an error, but if 3, there is no error. |
@doug-moen, that's an interesting scenario, but it would be caught as soon as one attempted to use the contents of the definition |
@Ma-XX-oN said: How about this: unless a the symbol exists in more than one namespace, disambiguating would not be necessary, and an error would be displayed when trying to reference an ambiguous symbol name in an ambiguous context, when it doesn't have a decorator. I'll assume you are proposing this as a modification of the existing OpenSCAD language. I'm not sure what the benefit is, since this isn't backwards compatible with OpenSCAD. For example, if you define a variable and a function |
@Ma-XX-oN said: "use a keyword or function call that would specify that the current file uses 1 or 3 namespaces. It can be defaulted to 1 but can be set to 3. If 1, then using the same name for different contexts would be considered an error, but if 3, there is no error." Yeah, that works. In terms of backwards compatibility, it requires an extra line of code to be added to old OpenSCAD scripts that make use of the 3 namespaces. |
@Ma-XX-oN, I'm not sure what your beef is with the proposed OpenSCAD2 backwards compatibility scheme. Existing OpenSCAD scripts that make use of 3 namespaces continue to work without any changes, but if you take advantage of the new syntax, then you can write code that puts variables and functions into the same namespace. No need for a "a keyword or function call that would specify that the current file uses 1 or 3 namespaces". |
@doug-moen said: I'll assume you are proposing this as a modification of the existing OpenSCAD language. As a modification to your OpenSCAD2 proposal. Personally, I'd prefer the 3 namespace as default and have the 1 as an option, so as to keep backwards compatibility. I only proposed the contrary as a meet halfway proposal. @doug-moen said: I'm not sure what your beef is with the proposed OpenSCAD2 backwards compatibility scheme. My "beef" is that you are kneecapping older scripts for not conforming to a single namespace scheme. Yes, they will work under your compatibility scheme, but if someone wants to do a small mod to an existing library to take advantage of the new functionality, it is no longer is small mod. I think that this project has a lot of potential, but I fear that this will be viewed as a major letdown to the established community. |
@Ma-XX-oN "My "beef" is that you are kneecapping older scripts for not conforming to a single namespace scheme." That's a reasonable point. I would propose solving this using the An important goal of OpenSCAD2 is to support programming using a single namespace. A significant part of the community wants this; the requirement isn't going away. To support this and also support backward compatibility, OpenSCAD2 has 2 dialects, a single namespace dialect and a 3-namespace dialect. The "dialect" is a global property of a script. In the 3-namespace dialect, namespace prefixes would permit 3-namespace scripts to use functions as values, among other things. In the single namespace dialect, the scoping rules change. For example, in the 1-namespace dialect, a local variable definition shadows a global function definition of the same name, and vice versa, whereas in the 3-namespace dialect, this shadowing doesn't occur. There's no way to support the single-namespace goal, and also support backwards compatibility, without having 2 dialects. In my previous message, by "OpenSCAD2 backwards compatibility scheme", what I really meant was the mechanism that OpenSCAD2 uses to determine which dialect is in use. There is more than one way to do this, eg
The specific approach being explored here is that we determine the dialect based on the syntax of function and module definitions. If you use old-style syntax for function and module definitions,
then you are using the 3-namespace dialect. If you use new-style syntax for function and module definitions, you are using the 1-namespace dialect. Since OpenSCAD2 makes shapes into first class values that can be passed as arguments and returned as results, modules can be replaced by functions in 1-namespace mode, so I've proposed to unify functions and modules, which both share the same new-style definitional syntax:
Because we have a developer shortage, I wouldn't try to implement OpenSCAD2 all in one go. I'd split the implementation up into phases. I wouldn't try to unify functions and modules in the first phase, because it's too big a change. The main job of the first phase is to implement the single-namespace dialect. For pragmatic reasons, I would introduce a single-namespace module definition syntax in the first phase that looks like this:
It's identical to the current module definition syntax, with the addition of an There's no technical reason why the 3-namespace dialect should have any limitations on what can be expressed, relative to the 1-namespace dialect. I didn't address this when I wrote the proposal up last year because it wasn't important to me, and because I never received feedback from anybody with different ideas. I'm getting that feedback now, and I thank you for it. In order for the 3-namespace dialect to have full expressive power, we need to have 3 distinct decorators for identifiers, one for each namespace. A single decorator ( Here are some use cases that would be supported with the 3 namespace decorators.
|
I really like what I'm seeing here in this new version specification. However, I do have some issues with the collapsing of the namespaces. I feel that it isn't necessary to collapse the 3 namespaces, and I personally prefer that there are 3 namespaces.
The only reason to have a unified namespace (as you have said) is to be able to reference them. I would propose a selector instead, to indicate what namespace you are going to reference.
I.e. If I was referencing a module, then use
@(module)module_name
, function@(function)function_name
, a definition's contents, justdefinition_name
. So inp2=function(x,y) pow(x,2)
,p2
would be in the definition namespace, referencing a lambda. However, if you wanted to reference an already existing function, it would look like this:So
p2
would be in the function namespace, butp_2
would be in the definition namespace.To call the function
p2
, it would be as normal, as inp2(3)
, but to dereference a definition, a dereference operator would be applied to the definition name, as in@p_2(3)
. Note that what you are dereferencing is implied by context. If the context is that a module is expected, then the definition must be a module (object), if it is a value, then it must be a function.This would keep a much higher compatibility with OpenSCAD1's language, and make learning OpenSCAD2 a more incremental progression.
The text was updated successfully, but these errors were encountered: