I have struggled with FP for many years. What I try and do, is approach these concepts with an open mind and I look for ways of 'saying' what I see which I then rehearse with my FP friends and stick to the one which does not make them wince when I say it.

So this says three true things we know about this 'fac'

Firstly it says it takes an int and it returns an int.

Secondly that if the int it takes is specifically zero then the int it returns is specifically one.

Thirdly and lastly, for all other ints it returns that int, times (in the arithmetic sense) a recursive call to itself of the int one less.

I worry about why it doesn't have to say abs(n) but then I remember two negatives multiplied together are positive.

> I worry about why it doesn't have to say abs(n) but then I remember two negatives multiplied together are positive.

The function doesn't terminate if n is negative, so you are right to worry!

Might be cool to just overload in the function body instead of at the top level:

    fac :: Int -> Int 
      (0) => 1
      (n) => n * fac (n-1)

In Haskell:

    fac :: Int -> Int
    fac x = case x of
      0 -> 1
      n -> n * fac (n-1)

or even

    {-# LANGUAGE LambdaCase #-}

    fac :: Int -> Int
    fac = \case
      0 -> 1
      n -> n * fac (n-1)

Just adding parenthesis to the original would make it clearer and closer to the mathematics expresses the structure. Especially given that parenthesis are clearly used sometimes to designate arguments in here.

    fac :: Int -> Int 
      fac(0) => 1
      fac(n) => n * fac(n-1)

What you're describing is the exact same, just different syntax.

Yes, we are talking about syntax.

OP's first four words: "The thing about syntax".

No, the comment replied to has the first four words "Might be cool to". The differences are so minuscule that the argument could be made for it to be 2 differing standards for the same language.

I don't understand your point, much less why you're using the "first four words" thing back at me on my own comment.

The differences may be miniscule. They are syntactic. "Might be cool to" have this other syntax. You're just belaboring the obvious.

That's the whole point. Syntax can be very influential in how people use (or don't) a language

Yes and no. For what I replied to is essentially garden shedding the language. The overall problem is grasping the concepts, weather or not you want es6 style lambdas, or proper haskell function definitions is irrelevant if you don't understand the concepts.

The style is lifted straight from mathematics tradition. It is a closed definition and so it would be syntax error to insert anything between the lines.

In Haskell you could always avoid that style and use the case syntax (or for this example guard syntax) instead. All varieties eventually desugar to a case analysis anyway. Haskell even added curly braces as an alternate to indentation!

Is it a closed definition? The equivalent in Mathematica would allow one to add things whenever one wants, for example to add definitions for fac for negative integers, or to hard-code the value of fac 100.

If clean has a REPL (which I couldn’t easily find out from its web page) I expect it to have that, too.

In Haskell it certainly is a closed definition, you would get a "multiple declarations" syntax error if you tried to split the definition up. I would assume the same for Clean also.

In the Haskell REPL, you would need to enter the definitions together.

I think this is exactly the same as Haskell. As a matter of fact, I had to actually search their Wiki for the first example that was different from Haskell

I think it’s just a matter of familiarity. Once you learn how it works, it’s actually extremely elegant and in no way “disconnected.”

Also, aren't the types incorrect? Glancing over their docs, Int represents a signed integer. A negative input shouldn't be allowed, nor can you guarantee that your output fits in an int. Now I'm slightly curious as to how they handle overflows. Maybe they do runtime checks?

Conflating of data types with storage types is a surprisingly common occurrence, although I can appreciate it's largely due to pragmatism.

Reminds me of this (old) issue I recently came across wrt factorial in Julia (just googling to figure out promotion to handle 52! - the trick is using a bigint).

Point being, you're spot on about mixing types and even "simple" functions need not be trivial (for various reasons, eg: factorial of a negative number - might be defined as negative infinity):

https://github.com/JuliaLang/julia/issues/6579

Just implemented a List in OOP, just to proof a (different) point.

Everything is way more "disconnected" in OOP. For example I have to implement length in both the classes EmptyElement (0) and Element (1+next->length()). Both belong together, but they are scattered across the source code. With clean like syntax i would have written them right next to each other.

Anyone who hasn't tried a whitespace-significant language in anger is missing out.

I had started with F# and was put off by it like you described. I moved to Haskell and had difficulty understanding it yet again, but when I moved back to F# one more time it was a delight.

I LOVE python, it is the weapon I first take to any battle and the language I recommend to beginners. But, I have to admit that the fact that it is so easy to lose track of which "if" a nested "else" belongs to when modifying code, and, I've seen this being the source of so many bugs, that it has changed my opinion about whitespace-significant languages.

Also, I've come to appreciate when I write in say Rust, the fact that I can let go of the syntax, just write and focus on my ideas and let my editor sort the mess at the end.

> it is so easy to lose track of which "if" a nested "else" belongs to when modifying code, and, I've seen this being the source of so many bugs, that it has changed my opinion about whitespace-significant languages.

Having types and removing statements from the language make this much less of an issue

> I can let go of the syntax, just write and focus on my ideas and let my editor sort the mess at the end.

Elm has a whitespace significant syntax, but it too has an excellent code formatter tool.

How does Rust make it any easier?

All clauses are defined within curly brackets like C so indentation has no meaning and you can let tools take care of that.

Also, with editors like vim, you can press % to go to the matching brace (curly bracket). In fact that works in vi too, right from the early vi days; also, in vim, if you position the cursor on an opening or closing brace, it momentarily highlights the other one (at least if that brace is visible on the screen, can't remember offhand if this works even if not visible).

I still like languages like Python and F# though.

But is it any easier to tell which clause an else is connected to? Python has tools too.

When you refactor, yes. In python, say you add a new condition inside a condition, it's really easy to get lost and indent the wrong one to the wrong level.

as other said it's math tradition, your point about "open" fear is valuable though, you'd have to trust people not to scatter bits of defintion but well it's never a real problem.

About style, after a while spent reading about FP, I just can't solve problems without it.

Most of my code quickly ends up in lines of

  // f <param-1 subset>  <param-2 subset>  => desired structure //// type
  // f <param-1 subset'> <param-2 subset'> => desired structure //// type

which then gets translated on whatever language I end up writing (javascript, java, emacs lisp ..)

I don't program in functional environments, however this seems beautiful to me.

I do understand your argument and tend to agree, I would like to see a syntax error if there is anything between the multiple lines of implementation.

There would be

This is what makes it clear. Instead of burying the value somewhere in an if expression, pattern matching makes it immediately clear what the evaluated value is for a given argument.

I think about it like you're listing various definitions for what something is, given various patterns to match against. For me, this makes it more palatable because each pattern has a different operation associated with it. It's almost like binding multiple functions to one name that are called based on what you pass in, instead of creating one function to do the operation -- even though that's exactly what you're actually doing. It's declarative programming, in a way.

the definition of fact ends when the lines starting with fac end. they aren't doing something nuts like mixing up lines of a function definition if that's what you're getting at.

also, this is syntactic sugar for a case statement.. and you couldn't just use those.

Especially if the function has a longer name.