Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8
From: Niklas Holsti on 29 Jul 2010 16:46
Warren wrote:
> Dmitry A. Kazakov expounded in
> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg(a)40tude.net:
>
>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
> ..
>>> I think you missed my point - perhaps it wasn't expressed
>>> clearly.
>>>
>>> As I understand it, a FP tries to determine conclusions
>>> from a universe of facts, given some inputs. For smaller
>>> problems this can be _exhaustively_ analyzed and results
>>> obtained.
>> And so does any declarative language. You declare some facts in
>> whatever form (as relations, as connections of blocks etc, for that
>> matter, as types in a strongly typed languages like Ada). The system
>> infers from them some executable code.
>
> No, there is a big difference here.
>
> In a non-FP language (Ada), you can solve _any_ problem so long
> as you code it (you are coding the "how"). IOW, you have
> solved the problem and specified it in code.
>
> In FP, you define the "problem" (instead) and require from
> it a solution. But FP cannot always solve that "problem".

Warren, I think your description or understanding of FP matches "logic
programming" or "constraint programming" rather than "functional
programming".

FP programs do specify "how" to compute a solution, although the FP
compiler or interpreter may have to transform the "how" in smart ways to
make it computable on resource-limited machines -- for example, by
converting tail recursion to iteration, or by using lazy evaluation to
avoid infinitely large intermediate results. Proving termination of
functional programs is similar to proving termination of recursive
imperative programs.

It is in logic programming and constraint programming that the
programmer enters facts, rules, and a goal, and the program searches for
solutions (proofs or realisations of the goal) in some way that is not
explicitly encoded in the program.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
From: Warren on 29 Jul 2010 17:01
Dmitry A. Kazakov expounded in
news:17hhchqy1a2si.1akul43vk1sd9.dlg(a)40tude.net:

> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:
>> Dmitry A. Kazakov expounded in
>> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg(a)40tude.net:
>>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
>> ..
>>>> I think you missed my point - perhaps it wasn't expressed
>>>> clearly.
>>>>
>>>> As I understand it, a FP tries to determine conclusions
>>>> from a universe of facts, given some inputs. For smaller
>>>> problems this can be _exhaustively_ analyzed and results
>>>> obtained.
>>>
>>> And so does any declarative language. You declare some facts in
>>> whatever form (as relations, as connections of blocks etc, for that
>>> matter, as types in a strongly typed languages like Ada). The system
>>> infers from them some executable code.
>>
>> No, there is a big difference here.
>>
>> In a non-FP language (Ada), you can solve _any_ problem so long
>> as you code it (you are coding the "how").
>
> Not quite. "How" need to be translated into the Ada code first. In
> some cases it is not simple or even impossible.

It doesn't matter. You've expressed the solution "in Ada".
"You" solved the problem to begin with (i.e. "the how").

>> IOW, you have solved the problem and specified it in code.
>
> No difference here. Any code is a language (Ada language, machine
> language, the language of differential equations and so on). The FP
> code is as code as Ada code is.

Code in the sense that it is the "specification". One
language specifies the "how", and the other specifies the
"problem". Surely you see that.

>> In FP, you define the "problem" (instead) and require from
>> it a solution.
>
> Rather you declare a solution. This is how declarative paradigm works.

Again, in Ada you "declare" the "how". In FP, you "declare"
the "problem" to be solved. In FP, you don't about the
how, beyond how long will it take.

> (Don't forget that Ada has a declarative parts as well. You declare
> types for example, and ask the compiler to solve "range 0..100".)

This is a pre-solved problem- that you re-apply in a
larger solution. The solution has been worked out by
the compiler/library writers. This is not "finding a
solution" in the present tense.

>> But FP cannot always solve that "problem".
>
> Same in Ada. Not every legal Ada program is compilable.

If an Ada program doesn't compile, then the programmer
hasn't spelled out the "how" correctly has he?

A well formed FP OTOH, can yield a suboptimal or missing
result. This is due to no fault in the input "program",
but in the way FP was implemented.

Anyway, I'm done here. I'm starting to feel like
a parrot.

Warren
From: Georg Bauhaus on 29 Jul 2010 19:09
On 7/29/10 11:01 PM, Warren wrote:

> Again, in Ada you "declare" the "how". In FP, you "declare"
> the "problem" to be solved.

> Anyway, I'm done here. I'm starting to feel like
> a parrot.

I guess, then, you will ignore my chatter through the cage's wires. ;)

Is there anything non-FP in

let input = float_of_string Sys.argv.(1) in
let output = print_float in
let square x = x *. x in
output (square input) ;;


I really don't know how it is possible to "declare" the "problem" in FP
without thinking about "how" some functions establish the "what" of the
solution. Even in Prolog.
To me FP always boils down to assembling a solution from "more primitive"
functions. These are ultimately composed of initial functions.

The process of arranging functions properly will establish the "how" part
of FP. I *have* to write the proper equations, choosing the correct
functions; I *have* to write expressions involving the correct
functions. These are not pre-solved. I do *not* in general instruct
an Ada compiler how to chose a sequence of processor instructions
for my Ada program.

The only difference I see is that in true FP there is no explicit
state manipulation. Has there been a true FPL other than inference
engines before the point when Haskell introduced monads?


Georg
From: Dmitry A. Kazakov on 30 Jul 2010 04:50
On Thu, 29 Jul 2010 21:01:35 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:17hhchqy1a2si.1akul43vk1sd9.dlg(a)40tude.net:
>
>> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:

>>> But FP cannot always solve that "problem".
>>
>> Same in Ada. Not every legal Ada program is compilable.
>
> If an Ada program doesn't compile, then the programmer
> hasn't spelled out the "how" correctly has he?

X : constant := 2**(2**(2**(2**9999_9999))) + 1:

is pretty much clear "how", legal, but not compilable.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Niklas Holsti on 30 Jul 2010 05:17
Dmitry A. Kazakov wrote:
> On Thu, 29 Jul 2010 21:01:35 +0000 (UTC), Warren wrote:
>
>> Dmitry A. Kazakov expounded in
>> news:17hhchqy1a2si.1akul43vk1sd9.dlg(a)40tude.net:
>>
>>> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:
>
>>>> But FP cannot always solve that "problem".
>>> Same in Ada. Not every legal Ada program is compilable.
>> If an Ada program doesn't compile, then the programmer
>> hasn't spelled out the "how" correctly has he?
>
> X : constant := 2**(2**(2**(2**9999_9999))) + 1:
>
> is pretty much clear "how", legal, but not compilable.

.... because the binary representation of the value of X needs too many
bits, you mean? But I don't think that a compiler is required to
represent the value in binary form *at compile time*; it could use a
formulaic representation, which needs only a small amount of memory, as
shown by your source line. Depending on how X is used in the rest of the
program, this could make it possible to compile the program.

Of course I agree that a normal Ada compiler will not be able to compile
such things.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8