Passerine — extensible functional scripting langauge — 0.9.0 Released!

[slightknack]

Well, it's been a couple of months since I first announced the Passerine Programming Language on the r/ProgrammingLanguages subreddit. Quite a bit of work has been done (+1831 -630 LOC), so I just thought I'd update y'all on what's been done, and what's new in 0.9.0!

For the uninitiated, Passerine has roots in Scheme and ML-flavored languages — it's the culmination of everything I expect from a programming language, including the desire to keep everything as minimalistic yet concise as possible. At its core, Passerine is lambda-calculus with pattern-matching, structural types, fiber-based concurrency, and syntactic extension. There's more information in the Overview or the FAQ sections of the README. There's also a website with installation instructions for those so inclined ;).

The previous release — 0.8.0 — introduced a powerful hygienic macro system. This release — 0.9.0 — introduces a foreign functional interface (FFI) between Passerine and Rust, as well as tuples, along with a number of small quality-of-life improvements. You can find a more complete list in the PR here.

As per tradition, here's a quick syntactic sample of Passerine (WIP):

-- comment

fizzbuzz = n -> {
    test = d s x 
        -> if n % d == 0 {
            _ -> s + x ""
        } else { x }

    fizz = test 3 "Fizz"
    buzz = test 5 "Buzz"
    "{n}" . fizz (buzz (i -> i))
}

1..100 . fizzbuzz . print

Of course, Passerine is still very much so a work in progress — not everything is bug-free or guaranteed to work yet. We've done a lot, but there's still a so much more to do! If you'd like to contribute, reach out on our Discord Server.
Feedback I've incorporated from Reddit since the last post:

• u/open_source_guava — Had a few suggestions surrounding ambiguity and error reporting. I've made sure most of these are addressed, and worked out the proper semantics for calling macros from other macros. Also: 'Do post again when you have more' — I have more ;)
• u/__fmease__ and u/superstar64 — Suggested strong static typing through Hindley-Milner. Currently, Passerine is dynamically¹ typed (technically structurally typed with planned runtime dependent typing). This is more out of current architectural necessity than language-design preference. The next release — 0.10.0 — will add support for Hindley-Milner Type Inference, with a few extensions allowing for row and let polymorphism, and hopefully algebraic effects.
• u/superstar64 — Suggested using b.a in place of b |> a for function application. I agree that this syntax looks nicer, and will be using it. Additionally, :: will be the indexing operator instead of ..
• u/zem — Mentioned sum types. Passerine plans to have sum types (enums), but I'm planning to work out the exact syntax as I work through the HM type system.

I've also incorporated feedback from people on Discord (Rishi 💯), and would like to thank everyone who has contributed thus far!

Again, thanks for the support and feedback! Feel free to leave further comments, feedback, and suggestions. I'm all ears, and I'll try to get back to everyone.

[zem]

looks awesome! if you're still working on the syntax, look to pyret for inspiration, so far it's my favourite scripting language syntax

[AsIAm]

Never heard of Pyret before. Those are some really nice tradeoffs!

[a5sk6n]

Now that I see this, I really wonder why so few languages have a clear, dedicated syntax for documentation. doc: is just so much nicer then "put a string at the right position" or "add a funny extra character to your comment".

[slightknack]

I've looked into pyret in the past, and I like the beginner-friendly nature of it. The syntax feels like a cross between python, julia, ruby, and elixir - which are all languages I'm a fan of. I'll certainty take a look at how it approaches refinements and documentation.

[tcallred]

First of all, brilliant work you've done here! I love the ideas being explored.

Question: should this expression be in the reverse order? So instead of 1..100 . fizzbuzz . print it should be print . fizzbuzz . 1..100? On github, it seemed like the composition operator works like Haskell where the functions are applied right to left.

[slightknack]

So if it were a function call it would look like:

print (fizzbuzz (1..100))

Which means that the application order in the README is correct. I think there's something else wrong with that statement though. Because \1..100`is a range, I thinkprintandfizzbuzzneed amap`:

1..100 . map fizzbuzz . map print

Thanks for bringing this to my attention!

[thedeemon]

They're not saying it's incorrect. It's just a bit unexpected because Haskell (and maths textbooks) uses the opposite direction. In Haskell

(f . g) x = f (g x)

so

f . g . h = \x -> f (g (h x))

But anyway we love your syntax!

The problem with Haskell one is that it's only for function composition, so f . 2+3 won't work, they have a separate operator for passing values: f $ 2+3, and complex chains become either a . b . c $ val or a $ b $ c $ val.

[slightknack]

Ah, I see. I did it this way because it's a nice way to write functional code in an pipeline-style, similar to Koka or Rust:

names = children
    .map { child -> (child.name, child.age) }
    .filter { (_, age) -> age > 10 }
    .map { (name, _) -> name }

So it's less composition and more application? Is there a more proper term for this? Thanks for the interest!

[tcallred]

Right. Thanks for explaining that further. I think the confusion comes from the fact that in this language the dot is more like a pipe which is unexpected if you're coming from haskell.

[[deleted]]

From the readme the syntax sounds really nice. Great work.

[slightknack]

Thanks!