-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Discussion: Re-Implement code-generation for test-cases #204
Comments
@ErikSchierboom @kotp do you have an opinion on that issue? |
Sure. There are definitely other tracks that generate their code (I've written two generators: one for C# and one for F#).
And there are probably many more. I don't think there's a general, elegant solution, as much of it depends on the track that the tests are generated for. Some differences between test generators:
I don't have a strong preference for any of the options, it is mostly what works well for you. As for using I'd also highly recommend writing some accompanying documentation, as that can be invaluable to have external contributors add exercises later. |
The Ruby track uses Ruby to generate the code, I believe Python uses Python to generate their code. It would be good for the language track, where practical, to use the language of the track (because those that maintain are likely going to be familiar with that track language). But I know sometimes that is not practical, and it is easier to do in another language. Imagine writing a test generator in assembly, for example. I would look at the Python track, currently, (Ruby generators are broken, went out of date some time ago, due to file movements). (and I just refreshed and found that there is a good response to show the various generators) |
@ErikSchierboom the thing with python is that the sml-track already uses python (for the current generator). The only minor additional complication is that Yes I like good documentation too. I will have a look into the question whether one should generate SML via SML-code. At the moment I am not that familiar with SML (still learning it, partially with the help of exercism :) ). As for my knowledge the answer could range between "yes of course, super-easy" and "no, don't do that!" :D. @kotp thanks for the tip with the python-track. They actually use If nobody else opens a PR I might provide one. But before, I do some research about what might be the best option. Maybe I come back here again with a proposal. But in any case it might take some time until I have time for this. And of course I don't want to own that problem if anybody reading this wants to do it he/she can just do it. |
I would not consider the requirement to install python a "feature" though. It is another dependency that for the track may be something we do want to do away with. It would be similar if I had taken the time to write a generator in Ruby for the track, but would encourage and understand the want to move to an SML solution. We have plenty of people that have backgrounds in different languages, but everyone here has the one thing in common, and that is the SML language, so that is something that we can and should count on. |
@kotp ok sounds reasonable to me. For the reason you mention but probably also from a didactic point of view. And it is good to point out that it is desired to use the language of the track everywhere (where it makes sense). I did not know that, I just took the setting with python (and this strange Makefile) for granted. I definitely will have a look if the generator could be rewritten in SML (Poly/ML). Might be fun to do it, but would take some time for me (if I would do it). Besides code generation a minimal requirement would be that one can efficiently implement a command-line parser. There is also this |
Bash is available for Windows™, in various forms. |
@kotp is Bash preferred over Python on Windows? |
In my opinion, the preference would be:
I always used |
@rainij For Windows, we provide a PowerShell version of the fetch-configlet script: https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet.ps1 |
@guygastineau we already talked about this issue here #134. It would be nice if you could quickly recall your proposal here (just to have it at the right place) - the thing with the json lib, submodules and thoughts about alternatives to polyml. It sounds good too me, but maybe somebody here has some further suggestions. If you could implement it, I would be pleased to do the first review 🙂. Would that be OK for you @kotp @ErikSchierboom? |
Certainly, I used the testlib.sml from this track as a quick test library for helping a friend test their SML homework using SMLNJ. I didn't have to change much. I just made a generic test function with dependency injection to allow custom comparison and printing functions to be supplied. This let me drop the Well, then I realized I should update So, I got overly ambitious and fairly distracted before more pressing matters took over my spare time for SML. That is as far as I got rewriting This time around, what I would do differently:
Really, the script isn't doing that much. I expect we can achieve greater clarity with SML too. Branching on quality pattern matching will be much nicer than the way the python has to deal with it. IO might give us a little more boiler plate than the python, but there is probably an opportunity to make a mini FileIO library that can be used by various SML scripts/tools for the track; so I don't think that is bad. Anyway, hopefully this let's you know what I was thinking about the test generator from before. Really, it would do the same analysis (hopefully better since I believe MLs are better), and it would output tests that are almost the same. The difference is that we would use monomorphic versions of |
Is a git submodule necessary? Not that I object to that, but git submodules are not always intuitive to work with, especially for any potential contributors. The library's page mentions that the sml package manager can also be used: https://github.com/diku-dk/sml-json#use-of-the-package Is that an option?
This is likely just fine. I'd recommend a nice error message when curl could not be found and maybe some documentation. In general: rewriting it to SML sounds good! |
@ErikSchierboom I have some reservations about using git submodules for it too. I have to use them frequently, but they can be a pain with less experience. I think I mistook part of the sml-pkg documentation to mean it requires using |
I have been working on this some, but I got side-tracked with other PRs and work. I also got all excited and implemented streaming MD5 in native SML for #110, but my digests are coming out wrong :/ Anyway, maybe smlpkg doesn't really require using .mlb files. I think a lot of libraries are distributed with .mlb and maybe .cm files. Recently, I am continuing work where everything can be built using poly, smlnj, and mlton. poly and mlton are great, but smlnj requires extra type annotations sometimes. I don't know why it's inference is less powerful than the inference for the other two implementations. Anyway, I wrote a small poly script for using .mlb files, but it didn't handle the full syntax, and I found it is easier to maintain a separate |
I feel that the current code-generator for the test-cases (
bin/generate
) is really hard to read. I observed this in a previous PR (#193) where I had to adjust some things to make the code generator work again. I propose a re-implementation of the code-generator.I would like to use this issue to decide if this would be a good move (as already said: I think so). Moreover I would like to use this issue to gather some ideas what could be done. How do other tracks generate their code (if they do so)?
In the past I used the python library
jinja2
(https://palletsprojects.com/p/jinja/) for various things, including code generation for C++ (very simple code). Sojinja2
might be an option and I have the feeling that this would achieve the goal that the code-generation is easier to maintain. On the other handjinja2
is not a standard-package. Moreover, I have no deep experience in code generation and much more powerful/nicer/more elegant/more general solutions might exist.The text was updated successfully, but these errors were encountered: