Prev: Hide application from activities list
Next: hacking
From: Walter Banks on 14 Jan 2010 08:59


David Brown wrote:

> The reason I think Walter does not mean Logo is that I can't think of
> any features it has that would make it a good choice for general
> programming or the "tough problems" he mentioned. It is a great
> language for its purpose, but not for tough problems.

I used LOGO illustrate an example of a language that is
used to where most users rarely think about application
implementation. The kids who use LOGO think about results
and objectives.

LOGO is not a general purpose language for "tough
problems" but we can learn a lot from its use about
what in language design makes users think in abstract
objectives as opposed to implementation.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com



From: David Brown on 16 Jan 2010 11:25
Walter Banks wrote:
>
> Jon Kirwan wrote:
>
>> the idea of replacing bubble sort code with
>> stocked versions of quick sort, though, within the context of
>> the c language.
>
> It has been pointed out that recognizing and replacing a bubble
> sort with a quick sort may not always be in the best interest
> of a given application. I don't agree that C compilers have the
> right to argue with the application developer over their choice
> implementation algorithm.
>

They do have the "right" to modify the algorithm, as long as the code
does the correct thing (as defined by the C virtual machine). Of
course, it is only really practical on a small scale (changing a
constant multiply to shifts and adds being an example). And while the
compiler may have the right to modify the algorithm according to the C
standards, the user might not want this - there are already plenty of C
programmers who refuse to enable "optimisations" because they don't want
the compiler to "mess" with their code.

> The C language as defined by its standards gives compilers
> a reasonable amount of freedom to translate applications
> as written to the executable machine code. To give a
> compiler the additional flexibility to select appropriate
> application implementation algorithm at the function level
> requires a language designed to describe application
> objectives rather than implementation.
>

Theoretically, a C compiler could rearrange algorithms. But in
practice, it would be very rare that it could do so usefully while still
remaining entirely true to the standards (many compilers have flags that
relax the standards to allow the generation of better target code - to
be useful, algorithm optimisation would require much more of this). As
you say, to do algorithmic optimisation practically and usefully, we
would have to have a different sort of programming language. Jon says
the thousand mile journey has to start with a single step - I say if we
want get to the end of this journey, we shouldn't start from here!

> To illustrate this point. Your exact timing example is not a
> C compiler limitation but a language limitation. How do
> you describe exact timing all paths in a function in an
> unambiguous way in C? Exact timing is an application
> objective.
>
> Regards,
>
> --
> Walter Banks
> Byte Craft Limited
> http://www.bytecraft.com
>
>
>
>
>
>
> --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Jon Kirwan on 16 Jan 2010 16:47
On Sat, 16 Jan 2010 05:18:20 -0500, Walter Banks
<walter(a)bytecraft.com> wrote:

>Jon Kirwan wrote:
>
>> the idea of replacing bubble sort code with
>> stocked versions of quick sort, though, within the context of
>> the c language.
>
>It has been pointed out that recognizing and replacing a bubble
>sort with a quick sort may not always be in the best interest
>of a given application. I don't agree that C compilers have the
>right to argue with the application developer over their choice
>implementation algorithm.

I guess I wondered where you were coming down.

>The C language as defined by its standards gives compilers
>a reasonable amount of freedom to translate applications
>as written to the executable machine code. To give a
>compiler the additional flexibility to select appropriate
>application implementation algorithm at the function level
>requires a language designed to describe application
>objectives rather than implementation.

As I said, I was following the 'thread' of responses downward
from Hans-Bernhard Br�ker's comment. I assumed (wrongly)
that you were addressing yourself along similar lines.

Regarding your assertion here about what a c compiler is
permitted to do and not, I'm not an expert on the subject. I
am merely "somewhat dangerous" and I will defer to your (and
those of others similarly experienced) opinion about it, for
now. You are in far better position than I am to speak to
this.

>To illustrate this point. Your exact timing example is not a
>C compiler limitation but a language limitation. How do
>you describe exact timing all paths in a function in an
>unambiguous way in C? Exact timing is an application
>objective.

Of course it is. But if you've read the Bulldog thesis (and
I assume you have -- who hasn't who works on compilers? --
even I've read it thoroughly and enjoyed it and I'm merely a
hobbyist on the matter, if that much), you will see how those
kinds of "goals" (as well as other "clues") were provided a
suggested implementation (because it was _actually_
implemented.)

It's possible to extend c for embedded use here just as it
has always _been_ extended. Ad hoc methods. #pragma being a
somewhat "allowable" method among others.

....

I am now left wondering what you meant in the post I first
responded to. I'll have to go reread it again, taking into
account the new information here and see if I can see how it
fits with Mr. Br�ker's comments, too.

Jon
First  |  Prev  | 
Pages: 1 2
Prev: Hide application from activities list
Next: hacking