Closed kjx closed 6 years ago
I was thinking about ideas like this about 20 years ago. I believe Mesa had both an internal language for programming & an external language for wiring things together. I still think it’s an important idea, though out of the scope for core Grace. On Mon, Jan 15, 2018 at 3:59 AM kjx notifications@github.com wrote:
Say I'm writing a system as a bunch of interdependent Grace modules. Interdependent means that the module graph is a DAG, so some modules are imported several times by other modules.
Now: the problem is: say I want to make different configurations of the system by swapping modules around. I can customise parts of things with inheritance. The catch is: how (without lots of copying) can I build and link different combinations of modules, and make them consistent.
My earlier answer was: import name to module binding is outside the language. Have some configuration file which says which modules to bind, and run that configuration.
import "parser-v3" as p import "lexer-v3" as l import "pretty-printer-v3" as pp
My latest bad idea is - reserve an import name - probably "system", or "main" - to represent the whole system, or the module that was actually invoked and starts running. Then that main module can import the right versions itself and export a set of defs that will be bound to the right actual modules. The actual modules import "main" and use it to get to the other modules - pretty much like NS's platform argument. Hmm.
modules do
import "main" as main def p = main.parser def l = main.lexer def pp = main.prettyPrinter
while each alternative main module does:
import "parser-v3" as parser' import "lexer-v3" as lexer' import "pretty-printer-v3" as prettyPrinter' def parser is public = parser' def lexer is public = lexer' def prettyPrinter is public = prettyPrinter'
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/147, or mute the thread https://github.com/notifications/unsubscribe-auth/ABuh-vCO7wveuUeAlipDFtN_hnAlVT6jks5tKz2zgaJpZM4ReT87 .
I still think it’s an important idea, though out of the scope for core Grace.
Well a Grace system has to be able to find it's modules somehow, and that was intentionally left unspecified. If it comes down to having a "main" import name binding to the first module that starts running, that's not too much to ask. A more interesting question is how much of a security risk is it?
In a world where any module can ask for anything, it's no worse than what we have now - it's just another convention. In a world where someone cared more about security (e.g. and used some kind of external configuration) well presumably they could configure that too...
pointless distraction plus breaks due to circular import
Say I'm writing a system as a bunch of interdependent Grace modules. Interdependent means that the module graph is a DAG, so some modules are imported several times by other modules.
Now: the problem is: say I want to make different configurations of the system by swapping modules around. I can customise parts of things with inheritance. The catch is: how (without lots of copying) can I build and link different combinations of modules, and make them consistent.
My earlier answer was: import name to module binding is outside the language. Have some configuration file which says which modules to bind, and run that configuration.
My latest bad idea is - reserve an import name - probably "system", or "main" - to represent the whole system, or the module that was actually invoked and starts running. Then that main module can import the right versions itself and export a set of defs that will be bound to the right actual modules. The actual modules import "main" and use it to get to the other modules - pretty much like NS's
platform
argument. Hmm.modules do
while each alternative main module does: