On 21/11/2022 17:08, Dmitry A. Kazakov wrote:
> On 2022-11-21 16:23, David Brown wrote:
>> On 18/11/2022 14:14, Dmitry A. Kazakov wrote:
>>> On 2022-11-18 13:36, David Brown wrote:
>>>
>>>> If you want to know what a function does before running it, look at
>>>> its definition - along with the definition of any other functions it
>>>> calls, what data it has, what constants it uses, and so on.  That
>>>> applies to all languages.
>>>
>>> That is exactly the problem. In mathematics and in declarative
>>> approaches that follow closely, definition is the function itself.
>>> E.g. all sorts of recursive definitions. Analysis of function
>>> behavior is in the core of mathematics. Basically it presents
>>> something, you do not know what, though its definition is before your
>>> eyes! Your objective is to figure it out, to study it. This is
>>> because mathematical functions exist on their own.
>>
>> "Functions" in functional programming and in mathematics are not the
>> same thing.
>>
>> In mathematics, the functions "sin(x)" and "cos(x + π/2)" are exactly
>> the same thing.  They are indistinguishable.  Any definition that
>> gives the same mapping from the source domain to the destination
>> domain is the same function.
>>
>> In functional programming languages - real, practical functional
>> programming languages, that is not the case.  You might argue that in
>> a hypothetical sense two functional programming language functions
>> that give the same results are the same function - but you can argue
>> exactly the same about any kind of programming language.  In reality,
>> functional programming language functions are much like functions in
>> imperative languages - compilers can manipulate them to make variants
>> that give the same results more efficiently (this is "optimisation"),
>> but otherwise they do what the function definition says.
>
> Yes. In short. Functional paradigm does not stand for its promises. That
> is an open secret... (:-))
>

Functional programming languages are programming languages where
functions are first-class objects. I don't know what you are thinking
about, but it is /not/ functional programming languages.

>> A difference, perhaps, is that imperative functions go from the bottom
>> up (or start to finish) while functional programming language
>> functions are often more top-down (describe the end result that you
>> want, and then the partial results to get there).
>
> Well, not really. Whether the ultimate program is
>
>    do_it;

That would be imperative coding.

>
> or
>
>    let_it_be_done;

That would be declarative. (Note that functional programming is not the
only kind of declarative programming.)

>
> makes little difference. Levels of indirection not necessary translate
> into higher abstraction and conversely. Imperative approach has one
> level less.

I think perhaps, like many programmers, you have worked all your life
with imperative programming and can't imagine or understand other
paradigms. You consider imperative as "the best" or "the most natural",
simply because it is the most familiar to you.

>
>>> This is not how engineering and programming as engineering activity
>>> work. There you create something in order to achieve something.
>>
>> Sorry, but you are completely wrong in your distinction.
>>
>> Programming with FP languages is as much "engineering" as programming
>> with imperative languages or any other paradigm.  When telephone
>> switching systems are programmed in the functional programming
>> language Erlang (which was developed with that application in mind),
>> do you think it is not "achieving something"?  When people make
>> programmable logic designs using FP languages such as Lava (build on
>> Haskell), Confluence (from OCaml), or SpinalHDL (from Scala), it is as
>> clear and solid engineering as you can get.  And of course, "normal"
>> functional programming is programming just like any other programming.
>
> You confuse application with intent. Yes, you can achieve something by
> programming in awful languages in awful manner. I do not mean here FPL
> specifically. Just for the sake of argument. You will wonder to know
> what software was written in VisualBasic...
>

Oh, so you think functional programming languages are designed and
intended to be useless, and it is only by accident or stubbornness that
anyone can actually make use of them? That is an "interesting" argument.

>>> Pragmatically, separation of specification and implementation is
>>> difficult when functions become first class objects.
>>
>> Again, that is an imaginary distinction.
>
> In is not imaginary. If you cannot use functions as a vehicle do define
> interface you need to come up with something else or drop the idea
> altogether.

Again, I can't figure out what you are talking about.

>
>> Whether the language supports first-class functions or not makes no
>> difference as to how well specified functions are, or whether the
>> implementation follows that specification or not.
>
> Specification is a declarative layer on top of the object language. In
> imperative procedural languages that layer is declaration of
> subprograms.

No, that is not what "specification" means. A declaration is just the
name, parameters, types, etc., of a function. A specification says what
the function /does/. In most programming, specifications are not
written in the language itself though some allow a limited form of
formal specification (such as pre-conditions and post-conditions).

> In OOPL it is types (classes) defined in terms of methods
> (members are built-in getter/setter methods). In FPL, typically, there
> is none, unless you introduce some meta functions, whatever. E.g.
> generics/templates exist for infinity and still have no reasonable
> specifications, and thus, are fundamentally non-testable. I do not care
> even a little bit about FP, but, my guess is that it must have similar
> issues.
>

So you think that in C, this is a "specification" :

int times_two(int);

while the Haskell equivalent :

times :: Int -> Int

is somehow completely different?

>>> Another issue is treatment of types when each function is an
>>> operation on some types and nothing else.
>>
>> I can't understand what you mean.  Functional programming language
>> functions are not operations on types.
>
> Yep.

Oh, so you think functions in functional programming languages don't
have types or act on types? Maybe you are thinking of Forth, rather
than functional programming languages? Certainly you seem to have got a
very strange idea of functional programming.

Functional programming languages have supported generic programming and
type inference for a lot longer than most imperative languages, but
those are both standard for any serious modern imperative language (in
C++ you have templates and "auto", in other languages you have similar
features).

>
>> Conversely, all functions in all languages operate on some types and
>> nothing else.
>
> No, in OOPL a method operates on the class. A "free function" takes some
> arguments in unrelated types.
>

Methods in OOPL (or most people think of as Object Oriented programming,
such as C++, Java, Python, etc., rather than the original intention of
OOP which is now commonly called "actors" paradigm) are syntactic sugar
for a function with the class instance as the first parameter.

On 2022-11-21 20:56, David Brown wrote:
> On 21/11/2022 17:08, Dmitry A. Kazakov wrote:

> I think perhaps, like many programmers, you have worked all your life
> with imperative programming and can't imagine or understand other
> paradigms.  You consider imperative as "the best" or "the most natural",
> simply because it is the most familiar to you.

Actually I worked a lot with declarative languages in AI (Prologue,
expert systems etc) and pattern matching (e.g. SNOBOL). My deep distrust
to declarative approach come from that time greatly supported by
relational paradigm.

> Oh, so you think functional programming languages are designed and
> intended to be useless, and it is only by accident or stubbornness that
> anyone can actually make use of them?  That is an "interesting" argument.

Absolutely. Most languages fall into this category. It is not a unique
feature of FPLs...

>>>> Pragmatically, separation of specification and implementation is
>>>> difficult when functions become first class objects.
>>>
>>> Again, that is an imaginary distinction.
>>
>> In is not imaginary. If you cannot use functions as a vehicle do
>> define interface you need to come up with something else or drop the
>> idea altogether.
>
> Again, I can't figure out what you are talking about.

About specifications stating some part of behavior, but not implementing
the behavior.

>>> Whether the language supports first-class functions or not makes no
>>> difference as to how well specified functions are, or whether the
>>> implementation follows that specification or not.
>>
>> Specification is a declarative layer on top of the object language. In
>> imperative procedural languages that layer is declaration of subprograms.
>
> No, that is not what "specification" means.  A declaration is just the
> name, parameters, types, etc., of a function.  A specification says what
> the function /does/.

That is same. When you specify type, to say what the object "does" by
being of that type.

> In most programming, specifications are not
> written in the language itself though some allow a limited form of
> formal specification (such as pre-conditions and post-conditions).

You have them in the languages or you have not. Clearly specifications
form a meta language on top of the object core language.

>> In OOPL it is types (classes) defined in terms of methods (members are
>> built-in getter/setter methods). In FPL, typically, there is none,
>> unless you introduce some meta functions, whatever. E.g.
>> generics/templates exist for infinity and still have no reasonable
>> specifications, and thus, are fundamentally non-testable. I do not
>> care even a little bit about FP, but, my guess is that it must have
>> similar issues.
>>
>
> So you think that in C, this is a "specification" :
>
>     int times_two(int);
>
> while the Haskell equivalent :
>
>     times :: Int -> Int
>
> is somehow completely different?

No. But also there is nothing specifically "functional" in these
primitive specifications. They are not even first class. You didn't wrote:

int (int) times_two; // Some functional C (no pun intended (:-))

The point is that if you take some really fancy functional stuff, it
would be difficult or, maybe, useless to formally describe in some meta
language of specifications.

>>>> Another issue is treatment of types when each function is an
>>>> operation on some types and nothing else.
>>>
>>> I can't understand what you mean.  Functional programming language
>>> functions are not operations on types.
>>
>> Yep.
>
> Oh, so you think functions in functional programming languages don't
> have types or act on types?

It was you who said "Functional programming language functions are not
operations on types." I only agreed with you. Again, it might be
possible to build a complete type algebra on top of "functional" quirks.
But there are enough unresolved problems already without bringing
first-class functions in. So, why bother? Passing a subprogram as
parameter (downward closure) covers all my needs. Objects parametrized
by functions? That looks too much. Yes, I hate templates and generics,
before you ask... (:-))

> Functional programming languages have supported generic programming and
> type inference for a lot longer than most imperative languages, but
> those are both standard for any serious modern imperative language (in
> C++ you have templates and "auto", in other languages you have similar
> features).

Type inference is a separate, and very controversial issue.

>>> Conversely, all functions in all languages operate on some types and
>>> nothing else.
>>
>> No, in OOPL a method operates on the class. A "free function" takes
>> some arguments in unrelated types.
>
> Methods in OOPL (or most people think of as Object Oriented programming,
> such as C++, Java, Python, etc., rather than the original intention of
> OOP which is now commonly called "actors" paradigm) are syntactic sugar
> for a function with the class instance as the first parameter.

Not really, because methods dispatch. A method acts on the class and its
implementation consists of separate bodies, which is the core of OO
decomposition as opposed to other paradigms.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 21/11/2022 22:25, Dmitry A. Kazakov wrote:
> On 2022-11-21 20:56, David Brown wrote:
>> On 21/11/2022 17:08, Dmitry A. Kazakov wrote:
>
>> I think perhaps, like many programmers, you have worked all your life
>> with imperative programming and can't imagine or understand other
>> paradigms.  You consider imperative as "the best" or "the most
>> natural", simply because it is the most familiar to you.
>
> Actually I worked a lot with declarative languages in AI (Prologue,
> expert systems etc) and pattern matching (e.g. SNOBOL). My deep distrust
> to declarative approach come from that time greatly supported by
> relational paradigm.

Assuming you mean Prolog (there may be a language called Prologue that I
don't know about), it is declarative (rather than imperative) but it is
not a functional programming language. And SNOBOL is considered
imperative, not declarative, but is really in a class of its own.
Familiarity with these gives you a broader background than many
programmers, but no insight or experience with functional programming.

>
>> Oh, so you think functional programming languages are designed and
>> intended to be useless, and it is only by accident or stubbornness
>> that anyone can actually make use of them?  That is an "interesting"
>> argument.
>
> Absolutely. Most languages fall into this category. It is not a unique
> feature of FPLs...
>

That is quite a cynical viewpoint!

>>>>> Pragmatically, separation of specification and implementation is
>>>>> difficult when functions become first class objects.
>>>>
>>>> Again, that is an imaginary distinction.
>>>
>>> In is not imaginary. If you cannot use functions as a vehicle do
>>> define interface you need to come up with something else or drop the
>>> idea altogether.
>>
>> Again, I can't figure out what you are talking about.
>
> About specifications stating some part of behavior, but not implementing
> the behavior.
>
>>>> Whether the language supports first-class functions or not makes no
>>>> difference as to how well specified functions are, or whether the
>>>> implementation follows that specification or not.
>>>
>>> Specification is a declarative layer on top of the object language.
>>> In imperative procedural languages that layer is declaration of
>>> subprograms.
>>
>> No, that is not what "specification" means.  A declaration is just the
>> name, parameters, types, etc., of a function.  A specification says
>> what the function /does/.
>
> That is same. When you specify type, to say what the object "does" by
> being of that type.
>

No, they are not the same at all. A declaration is needed to use the
function (or other object) in the language. A specification says what
the function does (or should do). There may be a bit of overlap (maybe
both say they take an integer input parameter), but that's usually all.

>> In most programming, specifications are not written in the language
>> itself though some allow a limited form of formal specification (such
>> as pre-conditions and post-conditions).
>
> You have them in the languages or you have not. Clearly specifications
> form a meta language on top of the object core language.
>

No, it is not "clearly" at all. If a programming language allows
specifications of some sort as part of the language, then it is part of
the language. If it does not, then it is not part of the language -
specifications then have to be written independently (such as in a
separate human-language document) and are not in a "meta language".

>>> In OOPL it is types (classes) defined in terms of methods (members
>>> are built-in getter/setter methods). In FPL, typically, there is
>>> none, unless you introduce some meta functions, whatever. E.g.
>>> generics/templates exist for infinity and still have no reasonable
>>> specifications, and thus, are fundamentally non-testable. I do not
>>> care even a little bit about FP, but, my guess is that it must have
>>> similar issues.
>>>
>>
>> So you think that in C, this is a "specification" :
>>
>>      int times_two(int);
>>
>> while the Haskell equivalent :
>>
>>      times :: Int -> Int
>>
>> is somehow completely different?
>
> No. But also there is nothing specifically "functional" in these
> primitive specifications.

There was not intended to be anything "functional" about them. You said
that in imperative languages, a declaration is a specification, while in
functional programming languages you have no specifications. I showed
that you can have exactly the same kind of declarations in both
languages - the differences you are claiming are imaginary. (Such
declarations are not specifications in either language.)

Incidentally, you /do/ understand that "object oriented" is orthogonal
to imperative/declarative ? Many functional programming are object
oriented, just as many imperative languages are not.

> They are not even first class.

"Int" is a first class object type in Haskell and C. The "times"
function is a first class object type in Haskell, but not in C.

> You didn't wrote:
>
>    int (int) times_two;  // Some functional C (no pun intended (:-))
>

Indeed I didn't write that - it is not syntactically correct in either
sample language.

I could have written a declaration for a higher order function in Haskell:

do_twice :: (Int -> Int) -> (Int -> Int)

That takes a function that is int-to-int, and returns a function that is
int-to-int.

But then it would have been impossible to give the equivalent in C. The
nearest you could do would be :

typedef int (*int_to_int_fp)(int);
int_to_int_fp do_twice(int_to_int_fp);

It needs a typedef (there is, AFAIK, no way to return a function pointer
type without it), and it is in terms of function pointers, not functions.

And again - these are declarations, not specifications.

> The point is that if you take some really fancy functional stuff, it
> would be difficult or, maybe, useless to formally describe in some meta
> language of specifications.
>

A function that cannot sensibly be described is of little use to anyone.
That is completely independent of the programming language paradigm.
If no one can tell you want "foo" does, you can't use it. I cannot see
any way in which imperative languages differ from declarative languages
in that respect.

>>>>> Another issue is treatment of types when each function is an
>>>>> operation on some types and nothing else.
>>>>
>>>> I can't understand what you mean.  Functional programming language
>>>> functions are not operations on types.
>>>
>>> Yep.
>>
>> Oh, so you think functions in functional programming languages don't
>> have types or act on types?
>
> It was you who said "Functional programming language functions are not
> operations on types." I only agreed with you.

I think I see the source of confusion. When you wrote "each function is
an operation on some types", you mean functions that operate on
/instances/ of certain types. There is a vast difference between
operating on /instances/, and operating on /types/.

In functional programming languages (and languages that support
functional programming features, such as C++), functions can operate on
/instances/ (like "foo(100)") and on /functions/ (like "foo(bar)"), but
not on /types/ (like "foo(int)"). A function on types could be, say, a
"make_pair" function that took a type as its parameter and returned a
type that was a tuple of two of that type.

Some languages support this kind of thing, to some extent at least. In
a functional programming language you might have "constructor" functions
that create new values of a given type, and of course you could have a
higher-order function that takes constructor functions and returns
constructor functions. In C++, you can have a class template that takes
other types as parameters. In Python, you can operate on classes as
first-class objects. In C, you can do some type manipulation with macros.

I think what you meant to say was that in imperative languages, you
define functions to act on particular types (the types of the
parameters), while in functional programming you don't give the types of
the parameters so they operate on "anything".

On 2022-11-22 15:11, David Brown wrote:

> Familiarity with these gives you a broader background than many
> programmers, but no insight or experience with functional programming.

I don't pretend. I said I don't buy declarative approach and I don't buy
first-class functions, however you shape them.

>>> Oh, so you think functional programming languages are designed and
>>> intended to be useless, and it is only by accident or stubbornness
>>> that anyone can actually make use of them?  That is an "interesting"
>>> argument.
>>
>> Absolutely. Most languages fall into this category. It is not a unique
>> feature of FPLs...
>
> That is quite a cynical viewpoint!

Grows from familiarity... (:-))

>>>>> Whether the language supports first-class functions or not makes no
>>>>> difference as to how well specified functions are, or whether the
>>>>> implementation follows that specification or not.
>>>>
>>>> Specification is a declarative layer on top of the object language.
>>>> In imperative procedural languages that layer is declaration of
>>>> subprograms.
>>>
>>> No, that is not what "specification" means.  A declaration is just
>>> the name, parameters, types, etc., of a function.  A specification
>>> says what the function /does/.
>>
>> That is same. When you specify type, to say what the object "does" by
>> being of that type.
>
> No, they are not the same at all.  A declaration is needed to use the
> function (or other object) in the language.

Almost no language declare naked names. Most combine that with
specification of what these names are supposed to mean = behave.

>>> In most programming, specifications are not written in the language
>>> itself though some allow a limited form of formal specification (such
>>> as pre-conditions and post-conditions).
>>
>> You have them in the languages or you have not. Clearly specifications
>> form a meta language on top of the object core language.
>
> No, it is not "clearly" at all.  If a programming language allows
> specifications of some sort as part of the language, then it is part of
> the language.  If it does not, then it is not part of the language -
> specifications then have to be written independently (such as in a
> separate human-language document) and are not in a "meta language".

If it is not a part of the language, then there is nothing to talk about.

>>>> In OOPL it is types (classes) defined in terms of methods (members
>>>> are built-in getter/setter methods). In FPL, typically, there is
>>>> none, unless you introduce some meta functions, whatever. E.g.
>>>> generics/templates exist for infinity and still have no reasonable
>>>> specifications, and thus, are fundamentally non-testable. I do not
>>>> care even a little bit about FP, but, my guess is that it must have
>>>> similar issues.
>>>>
>>>
>>> So you think that in C, this is a "specification" :
>>>
>>>      int times_two(int);
>>>
>>> while the Haskell equivalent :
>>>
>>>      times :: Int -> Int
>>>
>>> is somehow completely different?
>>
>> No. But also there is nothing specifically "functional" in these
>> primitive specifications.
>
> There was not intended to be anything "functional" about them.  You said
> that in imperative languages, a declaration is a specification, while in
> functional programming languages you have no specifications.  I showed
> that you can have exactly the same kind of declarations in both
> languages - the differences you are claiming are imaginary.  (Such
> declarations are not specifications in either language.)

You showed a non-functional part. I said that marrying specifications
with "functional" would be IMO difficult. Too much power of function
construction to predict and constrain the behavior.

> Incidentally, you /do/ understand that "object oriented" is orthogonal
> to imperative/declarative ?  Many functional programming are object
> oriented, just as many imperative languages are not.
>
>> They are not even first class.
>
> "Int" is a first class object type in Haskell and C.  The "times"
> function is a first class object type in Haskell, but not in C.
>
>> You didn't wrote:
>>
>>     int (int) times_two;  // Some functional C (no pun intended (:-))
>>
>
> Indeed I didn't write that - it is not syntactically correct in either
> sample language.
>
> I could have written a declaration for a higher order function in Haskell:
>
>     do_twice :: (Int -> Int) -> (Int -> Int)
>
> That takes a function that is int-to-int, and returns a function that is
> int-to-int.

Not the same. int (int) times_two; is supposedly a variable which values
are int-valued functions taking one int argument. That would be the
least possible case of first-class functions.

> And again - these are declarations, not specifications.

They are rudimentary specifications. To elaborate them is difficult in C
and in an FPL.

>> The point is that if you take some really fancy functional stuff, it
>> would be difficult or, maybe, useless to formally describe in some
>> meta language of specifications.
>
> A function that cannot sensibly be described is of little use to anyone.
>  That is completely independent of the programming language paradigm.
> If no one can tell you want "foo" does, you can't use it.  I cannot see
> any way in which imperative languages differ from declarative languages
> in that respect.

That comment was on the first-class functions. If you have a
sufficiently complex algebra generating functions, especially during
run-time, it becomes difficult to describe the result in specifications.

Declarative approach is merely difficult to understand and thus to reuse
and maintain code.

>>>>>> Another issue is treatment of types when each function is an
>>>>>> operation on some types and nothing else.
>>>>>
>>>>> I can't understand what you mean.  Functional programming language
>>>>> functions are not operations on types.
>>>>
>>>> Yep.
>>>
>>> Oh, so you think functions in functional programming languages don't
>>> have types or act on types?
>>
>> It was you who said "Functional programming language functions are not
>> operations on types." I only agreed with you.
>
> I think I see the source of confusion.  When you wrote "each function is
> an operation on some types", you mean functions that operate on
> /instances/ of certain types.  There is a vast difference between
> operating on /instances/, and operating on /types/.

I did not mean first-class type objects (types of types). They raise the
same objections as first-class procedural objects (types of
subprograms). It would be surely interesting as an academia research and
a nightmare in production code.

Acting on a type means being a function of the type domain. E.g. sine
acts on R. R is a type ("field" etc).

> I think what you meant to say was that in imperative languages, you
> define functions to act on particular types (the types of the
> parameters), while in functional programming you don't give the types of
> the parameters so they operate on "anything".

No, that would be untyped. Most FPLs are typed, I hope.

> This is, of course, wrong in both senses.  More advanced imperative let
> you define functions that operate on many types - they are known as
> template functions in C++, generics in Ada, and similarly in other
> languages.

That is acting on a class. Class is a set of types, e.g. built by
derivation closure in OO or ad-hoc as "any macro expansion the compiler
would swallow" in the case of templates... (:-))

> And in functional programming languages you can specify
> types as precisely or generically as you want.

I don't see why an FPL could not include some "non-functional" core.
Like C++ contains non-OO stuff borrowed from C. But talking about
advantages and disadvantages of a given paradigm we must discuss the new
stuff. Old stuff usually indicates incompleteness of the paradigm. E.g.
C++, Java, Ada are nowhere close to be 100% OO. On the contrary, they
are non-OO most of the time.

On 13/12/2022 14:06, David Brown wrote:
> On 12/12/2022 23:30, James Harris wrote:
>> On 12/12/2022 15:18, David Brown wrote:
>>> On 12/12/2022 11:26, Bart wrote:
>>>
>>>> And as David said, cube roots aren't that common. It might have a
>>>> button for it on my Casio, that might be because it's oriented
>>>> towards solving school maths problems.
>>>>
>>>
>>> I think rather than having a cube root function, perhaps an nth root
>>> function would make some sense.  Then you could write "root(x, 3)" -
>>> that's about as neat and potentially as accurate as any other solution.
>>
>> I like that! I'd have to work through issues including integers vs
>> floats but it would appear to be simple, clear, and general. I may do
>> something similar, perhaps with the root first to permit results to be
>> tuples.
>>
>>    root(3, ....)  ;cube root
>>
>> so that
>>
>>    root(3, 8) -> 2
>>    root(3, 8, 1000) -> (2, 10)
>>
>
> This last one is :
>
>     root(n, a, b) -> (a ^ 1/n, b ^ 1/n)
>
> ?

Yes, although not restricted to one or two values.

>
> Is that a general feature you have - allowing functions to take extra
> arguments and returning tuples?  If so, what is the point?  (I don't
> mean I think it is pointless, I mean I'd like to know what you think is
> the use-case!)

No, it was not meant to be any kind of proposal at this stage (or of a
functional approach such as you mentioned in text now snipped), only a
principle of including fixed parameters before any that may potentially
be repeated.

--
James Harris

On 13/12/2022 15:06, Bart wrote:

....

>
> I think James' language is not that high level so functional would not
> be a good fit, but he says this is making use of 'tuples'.

You are right. I wouldn't gratuitously add high-level features to a
low-level language.

And I went off tuples after hearing too many people call them tupples.

:-)

--
James Harris