Why don't we write haskell in LISP syntax? (we can!) [closed]

Question

It... kinda works you guys (This absolutely compiles, adapted from https://hackage.haskell.org/package/scotty):

main :: IO ()
main = (do
  (putStrLn "Starting Server....")
  (scotty 3000 (do
    (get "/hello/:name"
        (text ("hello " <> (param "name") <> "!")))

    (get "/users"
      (json allUsers))

    (get "/users/:id"
      (json (filter (matchesId (param "id")) allUsers))))))

(I don't know enough haskell to convert <> to simple parens, but a clever person could easily.)

Why would we do this? We could preprocess Haskell with any lisp macro engine! Trivially!.

Imagine it. HASKELL AND LISP TOGETHER. WE COULD RULE THE GALAXY!

(I know what your thinking, but I've actually thought this through: in this example, Vader is Lisp, Luke is Haskell, and Yoda is Alonzo Church)

(edit "Thanks everyone who answered and commented, I'm now much wiser. The biggest problem with this technique I don't think has been yet mentioned, and was pointed out by a friend IRL: If you write some lispy preprocessor, you lose type checking and syntax highlighting and comprehension in your IDE and tools. That sound like a hard pass from me."

"I'm now following the https://github.com/finkel-lang/finkel project, which is the lisp-flavoured haskell project that I want!")

Answer 1

The syntax of Haskell is historically derived from that of ISWIM, a language which appeared not much later than LISP and which is described in Peter J. Landin's 1966 article The Next 700 Programming Languages.

Section 6 is devoted to the relationship with LISP:

ISWIM can be looked on as an attempt to deliver LISP from its eponymous commitment to lists, its reputation for hand-to-mouth storage allocation, the hardware dependent flavor of its pedagogy, its heavy bracketing, and its compromises with tradition.

Later in the same section:

The textual appearance of ISWIM is not like LISP's S-expressions. It is nearer to LISP's M-expressions (which constitute an informal language used as an intermediate result in hand-preparing LISP programs). ISWIM has the following additional features: [...]

So there was the explicit intention of diverging from LISP syntax, or from S-expressions at least.

Answer 2

Structurally, a Haskell program consists of a set of modules. Each module consists of a set of declarations. Modules and declarations are inert - they cause nothing to happen by their existence alone. They just form entries in a static namespace that the compiler uses to resolve names while generating code.

As an aside, you might quibble about Main.main here. As the entry point, it is run merely for being defined. That's fair. But every other declaration is only used in code generation if it is required by Main.main, rather than just because it exists.

In contrast, Lisps are much more dynamic systems. A Lisp program consists of a sequence of s-expressions that are executed in order. Each one causes code execution with arbitrary side effects, including modification of the global namespace.

Here's where things get a lot more opinion-based. I'd argue that Lisp's dynamic structure is closely tied to the regularity of its syntax. A syntactic examination can't distinguish between s-expressions intended to add values to the global namespace and ones intended to be run for their side effects. Without a syntactic differentiation, it seems very awkward to add a semantic differentiation. So I'm arguing that there is a sense in which Lisp syntax is too regular to be used for a language with the strict semantic separations between different types of code in Haskell. Haskell's syntax, by contrast, provides syntactic distinctions to match the semantic distinctions.