[Resolved] [Beyond] Split lang-specific code

[alfonsogarciacaro]

RESOLVED: There's been already a lot of work done for Rust and Python. So let's keep the current structure even and try to release Fable 4 for general use. We can worry about cleaning up the repo later when things stabilize.

Following the discussion here I'm working in a new structure so we can abstract the Replacements module and make it specific for each language. It's not as easy as I expected but it's doable with some work. I also want to abstract some other lang-specific helpers like the identifier sanitizer including the keyword list. This will be a good opportunity to isolate "common" code from Fable.Transforms in its own project/assembly and put lang-specific code (including Babel-JS) in their own project. I can think of 3 possibilities to do this:

1. Split languages but keep them in this repo and have a diamond-shape structure

             Fable.Transforms

Fable.Javascript    Fable.Php   Fable.Python

                Fable.CLI

2. Have the same diamond structure but put the language projects in different repos. In this case we should likely have a dynamic assembly loader in Fable.CLI (we already do something similar for plugins) to load the appropriate assembly without a direct dependency.

3. Have the language projects in different repos and also have different apps for each language target (though we can keep the common Fable.CLI parts in a shared assembly).

What do you think @ncave @thinkbeforecoding @dbrattli? 1 requires more coordination (making sure all languages compile with every change, resolving conflicts), but with 2/3 we may lose some synergies.

[thinkbeforecoding]

I have very limited access to the internet the two next week, but I'll have a peek when I'm back 👍 Le lun. 26 juil. 2021 à 12:36, Alfonso Garcia-Caro ***@***.***> a écrit :

…

Following the discussion here <#2339 (comment)> I'm working in a new structure so we can abstract the Replacements module and make it specific for each language. It's not as easy as I expected but it's doable with some work. I also want to abstract some other lang-specific helpers like the identifier sanitizer including the keyword list. This will be a good opportunity to isolate "common" code from Fable.Transforms in its own project/assembly and put lang-specific code (including Babel-JS) in their own project. I can think of 3 possibilities to do this: 1. Split languages but keep them in this repo and have a diamond-shape structure Fable.Transforms Fable.Javascript Fable.Php Fable.Python Fable.CLI 1. Have the same diamond structure but put the language projects in different repos. In this case we should likely have a dynamic assembly loader in Fable.CLI (we already do something similar for plugins) to load the appropriate assembly without a direct dependency. 2. Have the language projects in different repos and also have different apps for each language target (though we can keep the common Fable.CLI parts in a shared assembly). What do you think @ncave <https://github.com/ncave> @thinkbeforecoding <https://github.com/thinkbeforecoding> @dbrattli <https://github.com/dbrattli>? 1 requires more coordination (making sure all languages compile with every change, resolving conflicts), but with 2/3 we may lose some synergies. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2499>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABD2HPTVYGDA4YRSZTGXUDTZU2OFANCNFSM5A7Z6FUA> .

[dbrattli]

@alfonsogarciacaro Thank you so much for doing this and that you are so positive to extend Fable with additional languages 🥰 Scaling horizontally is not easy. The problem of keeping all languages in the same repo is that it will generate conflicts and breaking unit-tests (in a language you don't know). This may slow down the overall development of Fable when every changes needs to be debugged for multiple languages. But the "monolith" is also good in the sense that it forces every language to be up-to-date. Splitting into separate repos may eventually make a language obsolete if no-one have time to keep it up-to-date (or if it falls too far behind).

I feel we should not break things more up than necessary so perhaps a multi-stage rocket. Start with 1) to not slow things down too much right now, and then consider 2) or 3) if / when 1) becomes too painful. Especially if we get a handful of new languages, then we will eventually be forced to move to 2) or 3).

[dbrattli]

@alfonsogarciacaro The work on splitting Replacements is blocking further improvements of the Python support. I'm finding myself replacing the replacements. How is this work / planning going? Is there a way I can move forward, or should I focus on some other part (e.g fable-library) while we figure this out?

[alfonsogarciacaro]

Hi @dbrattli! There's some work in this branch but I still need to fix build errors and make some changes in order to abstract the Replacements module. I hope to finish it next week but if it's blocking you, you can just edit Replacements (or use if com.Lang = Python) in your branch and wait until the split is ready. Then we can merge and you can put your changes in Python's own Replacement module.

[dbrattli]

@alfonsogarciacaro That is a great idea, thanks!

[dbrattli]

Adding this code to FSharp2Fable for now:

        member this.TryReplace(ctx, r, t, info, thisArg, args) =
            match this.Options.Language with
            | Python -> Python.Replacements.tryCall this ctx r t info thisArg args
            | _ -> Replacements.tryCall this ctx r t info thisArg args

[dbrattli]

@alfonsogarciacaro How should we do things with FSharp2Fable and ``getIdentUniqueNameand Prelude.fs and Naming module, e.gsanitizeIdent`. Where is the best place to dispatch between the different languages?. I'm making Prelude.fs for Python with Python keywords, etc.

[dbrattli]

FYI: This is how I have started this work: https://github.com/fable-compiler/Fable/pull/2503/files