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.

Reply via email to