Lee, Thanks for the link - I can see that I have a lot of reading ahead of me :-) - looks very interesting indeed.
Jules On Saturday, 28 November 2015 20:26:48 UTC, Lee wrote: > > > Jules, > > There's work using random variation and selection to do some of the more > ambitious things you've suggested. > > See, for example, http://geneticimprovement2015.com > > It'd be great to see work in this area being done in Clojure, perhaps in > conjunction with some of the more deterministic methods you've suggested > here. > > -Lee > > > > > On Nov 28, 2015, at 1:53 PM, Lucas Bradstreet <lucasbr...@gmail.com > <javascript:>> wrote: > > > > 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....@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 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. > > -- > Lee Spector, Professor of Computer Science > Acting Dean, School of Cognitive Science > Director, Institute for Computational Intelligence > Hampshire College, Amherst, Massachusetts, USA > lspe...@hampshire.edu <javascript:>, http://hampshire.edu/lspector/, > 413-559-5352 > > -- 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.
