Strange things happen when used with Clojure about condition-inverter

[OvidijusParsiunas]

(Apologies for closing this early due to a misclick)

Hi @PEZ, thankyou very much for the feedback!
The goal of this library is to support as many languages as possible and Clojure would definitely be a great addition. However, based on doing some comparison of this language to other popular ones like Java, it appears that Clojure supports a very unique form of conditional statements that have their own keyword structure. This would prove a little more challenging to implement as it would be hard to reuse a lot of the existing functionality and would require the addition of a significant amount of new code to support all the conditional possibilities (which would inherently also increase the complexity of the library's codebase).

Nevertheless, it is to my understanding that Clojure uses syntax that is similar to Lisp (and other languages within the Lisp family), hence by providing functionality to invert it, would cover those languages too. Hence, I am keen at investigating the possibility of being able to invert this language.

I am currently actively working on 2 other projects so my time is limited. However, I am keen to try and implement this in the near future and will update you about any progress.
Because this project is open source I would ofcourse encourage you to try and implement the new language, but I will get back to it if not.

In regards to the suggestion of displaying a message in vs-code stating that the language is not supported; most conditional statements are quite similar across most programming languages, hence this library leverages their similarities to not necessarily judge the condition code by the file extensions but by the tokens that they represent. Hence there are many languages that we never really built-for specifically that are supported by this library nevertheless. Additionally, the code for the vs-code extension is by architectural design used by the website which has no access to file extensions, hence the inversion algorithm strictly relies on the code that is provided and nothing else. Finally, there are always edge cases in every language where inversions will not work the way they are intended, but they will work for other cases, hence denying the use of the extension for those languages would not be the right choice.
So for the above reasons I am currently not in favor of displaying messages of no support. Hopefully it makes sense.

[OvidijusParsiunas]

Out of curiosity, what should have been the expected outcome for the code snippet that you have provided?

[PEZ]

Very cool that you want to support Lisps, including Clojure!

I hear you about not having access to file extensions. Two ideas pop to mind for me:

1. Consider providing a selector on the web site where the user can specify the language. VS Code has this via cmd+k m, whatever that command is named.
2. When I asked the VS Code team about if we extension authors could get an API to access VS Code's excellent language conjurer, they said at while they figure about that I was welcome to rip out VS Code's tensors for this. This is available in the VS Code repo. So that is maybe something you can also consider, both for the extension and for the website.

If you go for 2, then I think combinig with 1 is good. VS Code does this, after all.

As for displaying a message, in the while you haven't solved the ”figure out which langauge” problem, maybe you can find a way to see when your inverter is not likely to succeed. I just imagine that is easier than guessing the language.

[PEZ]

A problem you will have a hard time solving in a super nice way with Lisps is that they are super strong for meta programming. So people will be inventing new macros for conditionals that you can't, without a considerable amount of work, know are conditionals. You will probably need to go for some best effort and support the built-in conditionals for each Lisp you decide to support, and maybe some basic subset to cover most Lisps.

[PEZ]

Out of curiosity, what should have been the expected outcome for the code snippet that you have provided?

Not so very far from what I got. Tbh, I'm not completely sure what I expect. The equivalent JS for the original snippet would be:

all_replacers.filter((r) => isMap(r) && r.name);

Judging from the result I got, I am guessing that invert would produce this for that JS code:

all_replacers.filter((r) => !isMap(r) || r.name);

If so, the expected Clojure would be:

(filter #(or (not (map? %))
             (:name %)) all-replacers)

In Clojure and is a macro and not is a function. and takes any number of arguments and returns the first non-true-ish of them, or the last one if all are true-ish. not takes one argument and returns the logical not of it. So if the argument is true-ish, the return value will be false, and if it is false-ish, the return value will be true.

So for the thing I tested with, calling the not function with (map? %) would be the equivalent of the C-like ! operator.

(or is a macro taking any number of arguments returning the first true-ish, or the last argumnt, if none of them is true-ish.)

My VS Code Clojure extension, Calva, comes with a command: Fire up the Getting Started REPL, which includes a basic introduction to Clojure. Noting that down here, for when you have the time to try make Clojure work with the inverter. Then it could be a good idea to run through parts of that guide. (It's interactive.). You can read a bit about it here: https://calva.io/getting-started/

[OvidijusParsiunas]

I will do some investigation to see the opportunity for inverting Lisp and its dialects and will have to weigh the problem complexity vs the reward for its support implementation this as there are many other languages that also need support :) So I cannot make any promises and am unfortunately too busy to proceed with this at the moment, so will report in the future.

In regards to adding a button to the website; part of the goal when building the website was to optimise the UX by doing the job of the user by auto-inferring the language; which has been successful so far.
On the VCode extension side of things, I could add an explicit message for languages that are not supported - but that would never be a definite list as there are 100s of languages and new ones being invented all the time. It would ofcourse be easier to instead check for languages that are supported language - but then that would contradict the fact that some unintended languages' conditional statements are supported due to similarities in their conditional statement keywords to other languages, hence denying support for them is not preferable. Another problem is that some languages like UI frameworks encapsulate multiple languages within the same files, html + typescript or html + python and many other SSR examples which cannot be used to ultimately decide the language of the file and by extension the support for it.
By all means I do appreciate the concern that you have raised which helps me understand better on what is needed for the users and whilst I am not considering to add a message at the moment I will still keep it at the back of my head as it is a concern!

[OvidijusParsiunas]

I am keen to understand what the VSCode's language conjurer is as a simple search on the internet did not return anything about it. Is it part of the IDE that interprets languages? I am wondering if it used for semantic analysis of code and what languages does it support.
I am doubtful I can reuse it in my extension/website as the current inversion algorithm works pretty well and I do not have the time to re-write it from scratch :D. But I am very curious! Might you have a link to it? Thanks!

[OvidijusParsiunas]

Out of curiosity, what should have been the expected outcome for the code snippet that you have provided?

Not so very far from what I got. Tbh, I'm not completely sure what I expect. The equivalent JS for the original snippet would be:

all_replacers.filter((r) => isMap(r) && r.name);

Judging from the result I got, I am guessing that invert would produce this for that JS code:

all_replacers.filter((r) => !isMap(r) || r.name);

If so, the expected Clojure would be:

(filter #(or (not (map? %))
             (:name %)) all-replacers)

In Clojure and is a macro and not is a function. and takes any number of arguments and returns the first non-true-ish of them, or the last one if all are true-ish. not takes one argument and returns the logical not of it. So if the argument is true-ish, the return value will be false, and if it is false-ish, the return value will be true.

So for the thing I tested with, calling the not function with (map? %) would be the equivalent of the C-like ! operator.

(or is a macro taking any number of arguments returning the first true-ish, or the last argumnt, if none of them is true-ish.)

My VS Code Clojure extension, Calva, comes with a command: Fire up the Getting Started REPL, which includes a basic introduction to Clojure. Noting that down here, for when you have the time to try make Clojure work with the inverter. Then it could be a good idea to run through parts of that guide. (It's interactive.). You can read a bit about it here: https://calva.io/getting-started/

Thankyou for the explanation! The language of Clojure is alien to me, so the explanation helps! And thankyou for the link! As you noted, because Clojure is a macro based language, so it presents unique challenges, but it is on the top of the Stack Overflow survey for a reason, so I am incentivised to see what I can do to support it :)

[PEZ]

I am keen to understand what the VSCode's language conjurer is as a simple search on the internet did not return anything about it. Is it part of the IDE that interprets languages? I am wondering if it used for semantic analysis of code and what languages does it support.
I am doubtful I can reuse it in my extension/website as the current inversion algorithm works pretty well and I do not have the time to re-write it from scratch :D. But I am very curious! Might you have a link to it? Thanks!

I am probably using the wrong term. Doubt it is information that an internet search can find, though. A search in the VS Code repository is probably what's needed. An example of the feature I am referring to is when you open an empty tab in VS Code (cmd/ctrl+n) and type some code in there. VS Code is remarkably good at conjuring the language, even with very little input. It's some AI stuff, and I've been told that the trained neural networks are checked in to the repository. I have not looked in to it further, as I took another route with the feature I was working on.

My idea here was that if you could copy the neural networks and the core code employing them from VS Code, you would have a powerful way to guess the language, even when small pieces of code are selected in VS Code, or pasted into the website. Might be too much work involved, of course, it is just an idea. 😄