Hi, Well many will agree that if you can find a good solution to this problem this is going to be usefull. I tend to agree too.
The question is maybe can you find a good solution? My response would be no. Let me explain: From a theoretical point of view you can always translate one turring complete language to one another; But if you do that you really miss the point of using clojure instead of blurb. Clojure isn't theorycally better. It is not. Every thing you can do in clojure you'll be able to do in any blurb language, at soon at it is turing complete. So this include cobol, vhdl or SQL. If it was easy to transform easilly back and forth to idiomatic blurb language that would mean that there is some sort of bijection between all idiomatic feature of clojure and blurb. But the whole point of using clojure instead of blurb here is because clojure is a "better" or at least different language. With more interresting abstractions than one available in blurb, at least for a specific problem domain. So the bijection is not here. To have this bijection the blurb language would need to be clojure with a different syntax. We could think about common lisp but even there... Immutability and persistent collection could be enough to make the translation not idiomatic at all. And this only for the language. A language is just one part of the problem. You also need the libraries. For example GWT team had to support a good subset of Java API to make GWT usable. To transform back and forth would mean that you'll need a common API for both language, that is an API that would not be idiomatic for at least one of thoses language. More than being not idiomatic this would be an API thoses of blurb would not be used to. Maybe all of this is possible. After all an human can do it manually. But I see it as more a research topic than engineering topic. With low probability of sucess. It is a good thing to work on it then when many things aren't here yet for clojure? Best Regards, Nicolas. On Sep 30, 5:48 am, Hank <h...@123mail.org> wrote: > > I think the major obstacle is likely to be the difference in idioms. > > Any substantial idiomatic piece of Clojure is going to be almost > > impossible to automatically translate to _idiomatic_ code in another > > high-level language that uses different idioms. > > That could very well turn out to be the case. In the spectrum between > "fully manual" and "fully automated" I can picture scenarios like: > - Mostly manual but with some automatic assistance from the IDE: E.g. > the way Eclipse assists you in coding Java, when you press Ctrl+Space. > It doesn't automatically write code for you but it can narrow down the > choice as to what to type next. > - Most automatic but with some manual assistance from the coder: E.g. > annotate the Clojure code with hints about the idioms to translate to > in the target language. Right now in Clojure we use annotations > like :exposes-methods that aren't strictly for the Clojure > functionality itself but for Java interop. So there could be > annotations like :use-design-pattern-x that dictate the choice of > idiom/design pattern in the compilation to the target language. > > > You'd also probably > > have to introduce a number of "coding conventions" to constrain your > > Clojure code in order to avoid "holes" in the translation. > > It's probably a question of how unwieldy the produced code is allowed > to get. If you express the goal of "maintainability" in terms of some > metric like lines of code or whatever then I can see hard limits being > reached. If you don't put a limit on that then I don't see any danger > of holes. > > > Some questions: > > * How do you translate Clojure functions in namespaces spread across > > multiple files into a Java class? > > [...] > > Those are very good questions and I'd have to think about it. Maybe > I'll start a wiki somewhere so we can start collecting "translation > recipes". Generally, if the answer isn't obvious from staring at the > Clojure code, it helps to think about the problems in terms of the > bigger picture, i.e. the business logic/domain knowledge, and then > translate to Blub in the head. E.g. "I want to cache generated web > pages on the disk, how would I do this in Java?" > > > * How would code that uses STM translate to a Blub without it? > > I like this one in particular. People have written concurrent code > before STM. I do it in my job every day. :) How did that work with > explicit locks again?? > > > * How idiomatic would Blub code be when Clojure uses immutable data by > > default? > > A good source for this is the O'Reilly book "Functional Programming in > Java". There you can see how idioms from one language can be applied > to another. I think Java code that uses a lot of immutable data, i.e. > "final" variables all around, would still be accepted by the Java > community. The produced code could even leave out the "final" keyword > in order to not cause too much clutter but still not modify the > variables. It violates the principle of least authority but I see that > in real-world code everywhere. > > > I think it's a fascinating problem to try to solve for any given > > target Blub but I'm not sure how practical it would be, i.e., how > > readable the generated Blub code would be to an "average" Blub > > programmer...? > > The problem may have to be solved first in order to judge the value of > the solution. My day-to-day experience and my guts tell me it's worth > it. :D > > You weren't going to the Conj by any chance, were you? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
