From: [Jongware] on
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
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


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
"[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
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