Dogelang – A Python with Haskell Syntax

But it's much more common, at least for me, to eg just guess at operator precedences and leave out parens, because for the most part the type system will yell at you, if you get it wrong.

This is in stark contrast to the likes of C or C++, where the rule of thumb is 'when in doubt, add parens', because even when you get the precedence right when writing the code after looking it up, you'll most likely will have forgotten by the time you or someone else reads the code again; so you save everyone time with the extra parens.

The main thing I'd want from a better Python syntax would be to make more constructs in the language expressions with values instead of statements. For example, if-then-else. And introduce pattern matching.

The surface syntax might want to take more inspiration from Lisp instead of Haskell. Lisps are traditionally dynamically typed, so you can look at quite a few already thought through solutions.

    >>> f = lambda x: (
    ...   (
    ...     print('a') or
    ...     print('b')
    ...   ) if x % 2
    ...   else (
    ...     print('c') or
    ...     print('d')
    ...   )
    ... )
    >>> f(42)
    c
    d
    >>> f(43)
    a
    b

    func(
        lambda: otherfunc(
            1, 2, 3, 4
        )
    )

The route is via the OverloadedStrings extension, and then implementing an instance for IsString (String -> String) and IsString (String -> String -> String) etc.

I believe this is how it's called in non-English languages, but all my instructors and PL/semantics textbooks referred to this process as "currying" [0]. Which, if that's what you meant, is not what your parent comment was talking about. I believe they were talking just about syntax, not semantics, i.e., they wish in Python you could do `foo x y` instead of `foo(x, y)`.

[0] https://en.wikipedia.org/wiki/Currying

https://en.wikipedia.org/wiki/Currying#Contrast_with_partial...

but there are strict impure languages with white space function application. i suppose they handle the issue by using an object of a type with only one value.

in principle, you could handle the issue by contrasting (print) with (print ()), with () a pseudo value only existing at syntax level.

i'm not sure if white space function application carries it's own weight once we abandon partial application, so this feels like a contrivance to save a bursted balloon.

Implementing a vararg printf in Haskell is a popular enough exercise.

A relatively common examples in practice is the testing library QuickCheck: your properties (ie tests) can take any number of arguments that the library fills with samples inputs.

I don’t know if that makes them worthwhile, but I always find them a breath of fresh air.

  about(haskell).flatMap(a -> {
    return so(unreadable).map(s -> {
      return whats(s, a);
    });
  });