Allow to derive custom DSL interpreters from kscript

[ilanpillemer]

I am writing a DSL and using kscript to execute the DSL.. so in the end I am going to need to hide away stuff like..

//INCLUDE SemanticModel.kt
//INCLUDE Config.kt
//INCLUDE Model.kt

Do you think I should fork the repository when I start doing this or this is something you would like to include in kscript?

[holgerbrandl]

Actually, I've presented this idea on the roadmap for kscript at kotlinconf, see https://holgerbrandl.github.io/kscript_kotlinconf_2017/kscript_kotlinconf.html#56

So it's great having somebody coming forward with an actual usecase. :-)

My original idea was more about having a standard set of default dependencies (//DEPS ...), which would give you faster script execution. This is because when using //INCLUDE the included code needs to be compiled for each script, whereas when using //DEPS you pull in a precompiled dependency. So I'd strongly suggest to bundle and deploy your DSL code as an artefact to jcenter or similar.

For the technical realization, I thought about the following: Instead of the standard kscript launcher script (see https://github.com/holgerbrandl/kscript/blob/master/kscript) we/you would create new one that defines a header template (listing your dsl depndencies) to be injected into the user-script.

mydsl:

#!/usr/bin/env bash

export KSCRIPT_DSL_HEADER="
@file:DependsOn("foo:bar:1.0")
@file:Include("util.kt")

// or in case you can not use artfacts do some direct inclusion
//INCLUDE SemanticModel.kt
//INCLUDE Config.kt
//INCLUDE Model.kt

// initialize certain fields/services if needed
val mother = buildMother()
"

kscript $@

Fo dsl scripts you would just point to your dsl interpreter in the shebang:

#!/usr/bin/env mydsl

val sm = SemanticModel()
/...

The KSCRIPT_DSL_HEADER is not yet supported but that should be an easy one. kscript would simple prefix your scripts with it (after stripping the shebang line away) and then proceed as normal.

What do you think?

For sure if you think that forking is better, please go ahead, I'm happy to learn from you. :-)

[ilanpillemer]

I think what you say makes sense! I will spend some time reading the code and then expect to see some pull requests to discuss/change/laugh at etc. Glad to hear it fits with your vision.

[ilanpillemer]

What I like about direct inclusion is they can be URLs as well, which means you can distribute a script and the included files then can be updated individually real time by updating the page the url points at.

So for example.. I have a script that has remote includes to www.aaa.com/include1.kt and www.bbb.com/include2.kt. The user gets the script and that is all he or she knows. She can then update or write his or her own new scripts and run it. And unless new includes become necessary (unless the header file is also a URL) then the engine supporting the simple DSL can be updated real time. Does this seem far fetched? or silly?

Hmm.. This could perhaps be DSL-as-as-Service on the cloud?

[holgerbrandl]

Please have a look (not yet released, but via repo) and feel welcome to report problems. I've added some basic howto under https://github.com/holgerbrandl/kscript/blob/master/docs/user_guide.md#create-interpreters-for-custom-dsls