gracelang / language

Design of the Grace language and its libraries
GNU General Public License v2.0
6 stars 1 forks source link

Mutual interdependencies in product lines (low priority) #147

Closed kjx closed 6 years ago

kjx commented 6 years ago

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'
KimBruce commented 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 .

kjx commented 6 years ago

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...

kjx commented 6 years ago

pointless distraction plus breaks due to circular import