Thanks for this pointer, Lucas - it looks as if I could learn a lot from Kibit - I'll have a good look at it.
Jules On Saturday, 28 November 2015 18:54:11 UTC, Lucas Bradstreet wrote: > > Kibit (https://github.com/jonase/kibit > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjonase%2Fkibit&sa=D&sntz=1&usg=AFQjCNGd-LmdGTKLu8-azmxnx-jlketLjA>) > > 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....@gmail.com <javascript:>> > 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 clo...@googlegroups.com > <javascript:> > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > 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+u...@googlegroups.com <javascript:>. > > 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.
