From: [Jongware] on 13 Jan 2010 11:06 Walter Banks wrote: > > Defining goals at a much higher level than C opens the possibilities > for automating algorithmic choices at the function level. Aha -- wouldn't the logical end point be a programming language where you type "word processor", save it as source, compile, and have a word processor? When programming I often have "do what I mean, don't do what I program you to" problems. This tool would surely solve it -- if you can write down what you /mean/. [Jongware]
From: dj3vande on 13 Jan 2010 11:43 In article <4b4def88$0$22938$e4fe514c(a)news.xs4all.nl>, [Jongware] <sorry(a)no.spam.net> wrote: >Walter Banks wrote: >> >> Defining goals at a much higher level than C opens the possibilities >> for automating algorithmic choices at the function level. > >Aha -- wouldn't the logical end point be a programming language where >you type "word processor", save it as source, compile, and have a word >processor? Why bother to compile it? Just have it interpret on-the-fly. That way you could even run it in interactive mode, and it's sufficiently high-level that even non-programmers could usefully use it. Unix people call this a "shell". dave -- Dave Vandervies dj3vande at eskimo dot com They've figured out how to get a 640x480 display into a phone by now, now they're working on getting them back down to a reasonable size. --Dave Brown in the scary devil monastery
From: Walter Banks on 13 Jan 2010 12:08 dj3vande(a)csclub.uwaterloo.ca.invalid wrote: > Why bother to compile it? Just have it interpret on-the-fly. > That way you could even run it in interactive mode, and it's > sufficiently high-level that even non-programmers could usefully use > it. Dave, There are languages like that. LOGO for example is a functional language that is capable of interactively solving some very tough problems. After some applications are developed a stable runnable version of the application is desired including changing the format of the solution to prevent changes. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com
From: Keith Thompson on 13 Jan 2010 21:23 "[Jongware]" <sorry(a)no.spam.net> writes: > Walter Banks wrote: >> Defining goals at a much higher level than C opens the possibilities >> for automating algorithmic choices at the function level. > > Aha -- wouldn't the logical end point be a programming language where > you type "word processor", save it as source, compile, and have a word > processor? The result would be something that does to words what a food processor does to food. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Jon Kirwan on 16 Jan 2010 04:30 On Sat, 16 Jan 2010 03:29:57 -0500, Walter Banks <walter(a)bytecraft.com> wrote: >Jon Kirwan wrote: > >> Since this topic appears to suggest the idea of having a >> compiler do something I consider almost crazy-minded at this >> point in time and since you are contributing to that mindset >> by saying, "A possible implementation might involve trying >> alternative approaches and using compiler metrics. This >> could be automated," > >This could be a first step based on available technology. >A simple automated system with compiler static metrics >reported in a test fixture that swaps function implementations >could provide automated evaluations of alternative >implementations that would provide useful although >incomplete results. I addressed some thoughts of mine to this... in my earliler response to Jim. >> I'd like to remind >> you of a GCD algorithm discussion (at least two of them, >> actually) that I was a part of. I would like to see a c >> compiler do so much as take a simple, standard c algorithm >> for GCD and do the necessary topology transform to make it as >> efficient as a human can _easily_ see to do even there. Get >> past that point, and I'd _start_ to imagine the rest as a >> possibility. > >Separate out algorithmic changes from code optimization >and lets find out how much of this exercise is what the op >was looking for and how much is compiler optimization >weakness. Do you remember the discussions? (I'm not sure.) If not, I'd be happy to revisit the topic with you. However, I'd let you be the judge about the separation. You are in a better position to guide us on that topic. I can merely present the topo change required, as I see it. >> But I don't know of any c compiler that can do >> even the more modest things that most any human can readily >> do, yet. > >C compilers do many things that a human programmer >can't easily do by hand, RAM re-use, instruction scheduling, >complete re-implementation with every code change. Never any doubt in my mind about that. Different subject, entirely, to the idea of replacing bubble sort code with stocked versions of quick sort, though, within the context of the c language. >Our internal data shows that compiled code for last several >years is better than hand written code in size and execution >speed. The underlying reasons are the compiler is better at >control and data flow analysis and makes better use of the >whole instruction set. > >There is a simple way that this can be evaluated. Modify the >code generator on an assembler to emit C with a direct translation >per asm statement. Compile the resulting C and compare to >the original assembler. I was simply addressing myself to the line of reasoning from Hans-Bernhard Br�ker when he wrote: "Nothing stops a compiler from completely reorganizing a given function, as long as it's written in such a way that all effects to the outside are tightly scoped. I.e. a compiler is already allowed to detected a piece of code performs a sort and just call qsort() instead." Unless I'm just too sleepy to recognize something you are way ahead of me on, right now, I'd like to suggest we are talking at cross purposes. Jon
|
Next
|
Last
Pages: 1 2 Prev: How to ascertain the type of files being read Next: Hide application from activities list |