Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8
From: Dmitry A. Kazakov on 30 Jul 2010 05:29
On Fri, 30 Jul 2010 12:17:29 +0300, Niklas Holsti wrote:

> 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.

Yes, but you cannot find a representation which would work for any legal
expression. I.e. whatever representation the compiler uses, it is always
possible to write a legal program that would break it. E.g:

X : constant := 2**(3**(2**(3**9999_9999))) + 1:
Y : constant := 3**(2**(5**(2**8999_9979))) - 1:
C : constant Boolean := X > Y;

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

The above expression is supposed to break representations used by "normal
compilers".

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Warren on 30 Jul 2010 09:52
Niklas Holsti expounded in news:8be7luFbvaU1(a)mid.individual.net:
> Warren wrote:
>> 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".

Now that you mention the words "logic programming", I feel
a twinge in the back of my mind..

> 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.

I did start off with "if I understand correctly" - obviously
I mixed these up! This is _exactly_ what I was discussing.

The problem with age is the ever increasing number of memory
parity errors that go uncorrected. ;-)

Apologies to the thread for the confusion.

Warren
From: Randy Brukardt on 2 Aug 2010 23:15
"(see below)" <yaldnif.w(a)blueyonder.co.uk> wrote in message
news:C8762BCC.14B84F%yaldnif.w(a)blueyonder.co.uk...
> On 28/07/2010 17:40, in article
> g24nvegdi17t$.1azxwn1rwjixi$.dlg(a)40tude.net,
> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote:
....
>> This claim was made for each and every programming paradigm. It need to
>> be
>> substantiated, and especially for FP, which does not look very promising
>> at
>> all.
>
> Indeed, it has been "promising", but not delivering, for a very long time.

No kidding. FP was an "old" technique when I studied it as an undergraduate
at the University of Wisconsin. In 1978.

I think it appeals to those that are very mathematically inclined. But they
tend to forget that there is a lot more to programming than just creating
functions and stringing them together. (Not to say that there isn't value to
some of the ideas, but only in a larger framework that deals with typing,
problem mapping, and the like.)

Randy.


From: (see below) on 3 Aug 2010 09:57
On 03/08/2010 04:15, in article i381k9$dcf$1(a)munin.nbi.dk, "Randy Brukardt"
<randy(a)rrsoftware.com> wrote:

> "(see below)" <yaldnif.w(a)blueyonder.co.uk> wrote in message
> news:C8762BCC.14B84F%yaldnif.w(a)blueyonder.co.uk...
>> On 28/07/2010 17:40, in article
>> g24nvegdi17t$.1azxwn1rwjixi$.dlg(a)40tude.net,
>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote:
> ...
>
>>> This claim was made for each and every programming paradigm. It need to
>>> be
>>> substantiated, and especially for FP, which does not look very promising
>>> at
>>> all.
>>
>> Indeed, it has been "promising", but not delivering, for a very long time.
>
> No kidding. FP was an "old" technique when I studied it as an undergraduate
> at the University of Wisconsin. In 1978.
>
> I think it appeals to those that are very mathematically inclined. But they
> tend to forget that there is a lot more to programming than just creating
> functions and stringing them together.

The fetishization of "concision" in FP, as though that had great intrinsic
value, rather that being (as it actually is) a barrier to comprehension, is
undoubtedly part of that: mathematics envy writ small.

> (Not to say that there isn't value to
> some of the ideas, but only in a larger framework that deals with typing,
> problem mapping, and the like.)

Exactly so.

--
Bill Findlay
<surname><forename> chez blueyonder.co.uk


First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8