Kibit (https://github.com/jonase/kibit) does many of the things that you describe, though it doesn't go as far you dream. It also uses core.logic to suggest equivalent substitutions.
I'd be happy to see more work in this area. Lucas On 29 November 2015 at 02:01, Jules <jules.gosn...@gmail.com> wrote: > Guys, > > I've had pieces of this idea wandering around my head for years now and have > finally decided that the time might be right for putting them together in > the context of Clojure. I'm sure that others have had similar ideas before : > > Imagine my Clojure program which reads in your Clojure program and spits out > a smaller, simpler, faster Clojure program which does exactly what yours > did... > > Of course, you are such a good programmer that your program could not be > improved ? In which case we need you writing my Clojure program :-) > > This is opening the door onto a very large but very interesting problem > space. > > Starting the project off in a language that is homoiconic should deliver > enormous benefits straight away as the language itself provides a reader, an > Abstract Syntax Tree (itself) , a macro language (itself) etc... > > I have some initial ideas - > > - I was thinking of looking at core.logic to see if I might be able to use > it to match code to which refactorings might be applied. > > - I was wondering whether analysing a class/methods transitive bytecode > might be enough to decide whether a function/method was effectively pure or > not. > > - I was wondering whether a simple initial approach would be to inline all > but the recursive macros and functions in a program and then work backwards > from the fully expanded program applying refactorings to extract shared code > etc. > > - I was thinking that some of this machinery would be a nice thing to have > in a Clojure IDE, advising you about potential refactorings and applying > them as you type. > > - I was imagining that ultimately the inputs might not be have to be > Clojure, but maybe anything that compiled down to Java bytecode. > > - I was wondering whether there was much synergy with core.typed. > > - I was wondering whether you could work out how many cpu cycles a function > might take to run by inspecting its bytecode or optimise for mechanical > sympathy if your system knew a bit about the right things. > > - I was wondering whether my program could benchmark functions then rewrite > them and benchmark them again to confirm that they were faster. > > - i was considering which metrics should be used to decide that a program > was simpler, > > - I was wondering whether a Clojure program could learn much about writing > Clojure programs from analysing all the Clojure programs stored on e.g. > GitHub. > > - I am dreaming of the day when programs are written by more abstract > programs which are written by more abstract programs... which are written by > AIs :-) > > > I guess I am talking about writing an Expert System whose problem domain is > Clojure [and Java bytecode], which encodes a set of rules for transforming > one form of its input into another form that in some way satisfies some sort > of [sub]goal. A system which can plan refactorings from an initial state to > an 'improved' goal state. > > I haven't written any code yet. I realise that this is a huge subject and > that the best thing to do would be to talk to lots of people much smarter > than myself about it - so here I am. > > What does everyone think ? > > Is this worth discussing or just pie in the sky ? > > Looking forward to hearing your thoughts, > > > Jules > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
