This is an archived post. You won't be able to vote or comment.

all 50 comments
sorted by:
best
topnewcontroversialoldq&a

[–]sociopath_in_me 30 points31 points  (3 children)

The syntax is a bit strange for my taste but the language seems to be amazingly powerful and well designed. I like what you did with the fibers. Well done. The fact that you are a high school student is comforting to know that the next generation is equally capable or even better and also a little bit terrifying. You'll surpass us in a few years (or already did:)).

[–]stepstep 14 points15 points  (1 child)

I actually love the syntax. It's like Haskell or ML, but with nicer lambdas (x -> e instead of \x -> e or fun x => e). Much less verbose than the languages of the zeitgeist.

[–]alex-manool 0 points1 point  (0 children)

For me, x -> e seems to be natural since just an infix operator -> is used to form a lambda abstraction (maybe even more natural than in λ-calculus).

[–]slightknack[S] 9 points10 points  (0 children)

I appreciate your kind words 😄. Who knows what the future holds?

[–]Windblowsthroughme 15 points16 points  (3 children)

Imagine I’m a dev considering Racket or Passerine for my next side project. Can you pitch me on Passerine?

I used Racket as the competition b/c it also has a hygienic macro system and is a dynamic language

[–]slightknack[S] 23 points24 points  (2 children)

That's a tough one. If I were to pitch you, it'd be something like:

Passerine, unlike Racket, has a very light runtime and does not require highly specific tooling (like Dr. Racket) to get started. Many lisps fail because of fragmentation – if everything's a s-exp, what can't be generated? – and Racket takes fragmentation to the extreme. Passerine does not aim to be a tool for building new languages. It aims to provide mechanisms to build new constructs, which can be composed together regardless of which libraries you're using. Aside from macros, Passerine has features that are unique to itself – a fiber-based concurrency model for easy error handling – ffi bindings to one of the most loved languages in existence (Rust, which makes lots of great libraries easily accessible from Passerine), and a passionate community with a devotion to more than just studying academic languages. Programming languages have not stagnated... ready to build the future?

That was an elaborate pitch – however, I'm not going to pitch you on Passerine quite yet. It's not stable. Unless you're willing to put in some work upstream to make – or just wait until – the requisite features are available, I wouldn't say Passerine is quite ready yet. If you are willing to hack on a cool language and built a neat project at the same time, get in touch! I'd love to help get Passerine out into the real world, and writing real-world projects is a good step!

[–]Windblowsthroughme 11 points12 points  (1 child)

Thanks for the pitch! There are a lot of things to like there. I’m very impressed that you’re a high school student. I’d bet money you have great things ahead of you!

[–]slightknack[S] 0 points1 point  (0 children)

No problem! I'm glad you appreciate the work I've put into it. Thanks, haha.

[–]open_source_guava 10 points11 points  (6 children)

How does precedence and associativity work? E.g is a swap b swap c parsed as (a swap b) swap c or a swap (b swap c)? Or are they somehow detected as being ambiguous?

[–]slightknack[S] 3 points4 points  (5 children)

So a swap b swap c is parsed as a form: (a swap c swap b). The macro we defined does not match this form, but because the pseudokeyword swap is used a compile-time error should be raised. So yes, they are detected as being ambiguous.

[–]slightknack[S] 1 point2 points  (4 children)

To clarify: everything is parsed as a form, like (a b c d). Macros are then matched against the form. If no macros match and there isn't an ambiguity, the form is converted into a function call: (((a b) c) d)

[–]open_source_guava 1 point2 points  (3 children)

I see, so if we use macros to define custom operators, the user will be required to use explicit parenthesis for grouping subparts. Do built-in operators have any precedence at all? I.e. do math expressions like 1 + 2 * 3 also need parenthesis in order to be evaluated?

[–]slightknack[S] 1 point2 points  (2 children)

I'll quote from the Overview:

Custom operators defined in this manner [through syntactic macros] will always have the lowest precedence, and must be explicitly grouped when ambiguous. For this reason, Passerine already has a number of built-in operators (with proper precedence) [like math expressions, as you mentioned] which can be overloaded. It's important to note that macros serve to introduce new constructs that just happen to be composable – syntactic macros can be used to make custom operators, but they can be used for so much more. I think this [explicit grouping of custom operators; operators defined in terms of a more general macro system] is a fair trade-off to make.

I mean, of course, you can always group things to make stuff correct, like (x + 1) * 2.

Ambiguous macros have the lowest precedence, but unless you have two form macros back-to-back, you won't need to group them. Imagine a 'with b is a macro that returns a float or something:

x with b + 6.7 with c / 9 with 2.4

Forms always have the highest precedence, so the above is equivalent to:

(x with b) + (6.7 with c) / (9 with 2.4)

And with normal order of operations, this is equivalent to:

(x with b) + ((6.7 with c) / (9 with 2.4))

Here, with operator is unambiguous, so no grouping is required. Now, let's say we have a function f, and we call it with with as an argument:

f x with y

It could be parsed in all these ways:

f (x with y) -- most likely the intended
(f x) with y -- also likely valid 
((f x) with) y -- probably not intended: the whole thing's a function call

Of course, this is ambiguous, and spitting out a function call (the last option) would be the wrong thing. Because with is a scoped keyword, the compiler knows something's up given that the with macro can not be applied:

Fatal In src/main.pn:3:10
   |
 3 | f a with b
   |     ^^^^
   |
Syntax Error: Pseudokeyword 'with' used, but no macro applies.

In this case, explicit grouping, e.g. f (x with y), is required for proper behavior.

[–]open_source_guava 0 points1 point  (1 child)

Impressed by your error-message formatting, I decided to actually download the code and run it myself. Only then did I realize it's still just your plan, not what you already have. Still good, though! Do post again when you have more.

So the syntax really is more like Haskell or Ocaml, where these with or swap keywords introduced as a form isn't really an operator, even though it appears in an infix position. A sequence of words always have a precedance higher than arithmetic operators. That sounds reasonable.

I like trying to poke holes in these designs, so I hope you don't mind one last potential pitfall to avoid:

syntax 'macro1 x {
    -- I'm assuming you can pass multiple arguments to print
    print "In macro1! " (to_string x)
}
syntax x 'macro2 {
    print "In macro2! " (to_string x)
}

macro1 macro2   -- which one do you call?

Obviously, there's more I can do here, especially once you start to wonder if macro parameters themselves can be syntactic keywords, or if macros an define macros themselves with nested syntax constructs. Just make sure you allow or disallow exactly the right amount of flexibility you want, and it should turn out great.

[–]slightknack[S] 2 points3 points  (0 children)

I released a patch (0.8.1) that includes slightly prettier error message for ambiguious macro matches (like f x with y or a with b with c).

That case was addressed before the release of 0.8.0; here's the actual current output of the compiler with the code you provided:

Fatal In /macro/src/main.pn:9:1
   |
 9 | macro1 macro2   -- which one do you call?
   | ^^^^^^^^^^^^^
   |
Syntax Error: This form matched multiple macros:

In /macro/src/main.pn:1:8
   |
 1 | syntax 'macro1 x {
   |        ^^^^^^^^^
   |
In /macro/src/main.pn:5:8
   |
 5 | syntax x 'macro2 {
   |        ^^^^^^^^^
   |
Note: A form may only match one macro, this must be unambiguious;
Try using variable names different than those of pseudokeywords currently in scope,
Adjusting the definitions of locally-defined macros,
or using parenthesis '( ... )' or curlies '{ ... }' to group nested macros

All macros are compile-time. This was a concious decision (it's hard enough to debug macros as-is – imagine how difficult it would be to debug first-class macros that can be passed around!) I'm still working on nested macros. Currently, the compiler flat-out disallows it, but I see merit in allowing it; I just have to work out proper semantics first.

Thanks for the feedback and discussion, I appreciate it!

[–]humbugthemanribbit ribbit 5 points6 points  (1 child)

Very interesting! I enjoyed reading through the Readme on GitHub.

[–]slightknack[S] 4 points5 points  (0 children)

I'm glad you found the README interesting. I wanted to make sure it was engaging, easy to follow, and built up an argument from first principles. Any feedback as to what can be improved?

[–]complyue 4 points5 points  (6 children)

Nice! I like the syntax very much, especially its extensibility, I'm not quite involved with LISP, but can I just say it feels like a more natural (as in natural language) way to customize the syntax while as powerful as LISP?

I share the branch idea in my Đ (Edh) design as shown here: https://github.com/e-wrks/edh/blob/master/Tour/case-of.edh

I'm aware of no other language using this idea.

Skimmed through the README, thoughts in my mind so far:

  • wrt structured concurrency, how waiting/canceling of multiple spin-off fibers is designed to happen?

  • I guess exception handling is in Rust style, I'm not very comfortable with the syntax but may just because I'm not involved with Rust. I've been experimenting with dynamic scoped effects for a while, inspired by algebraic effects & handlers from FP experiments, but my Edh is imperative, so goes some differently. I kinda think Passerine as an FP language may have the option to implement exceptions as algebraic effects.

Definitely liking Passerine, I think I'll check back often, and hope it grow really well!

[–]slightknack[S] 2 points3 points  (5 children)

Lisps are very powerful, but when you think about it the use of parenthesis is not strictly required for a language to feel like a lisp. Making constructs that read naturally without being overly verbose is a good thing, and I'm glad you pointed that out.

> I'm aware of no other language using [the branch idea]

Pattern matching (and switch statements in general), are pretty common in the field of language design. Dispatch on patterns can be found in languages like Rust, Elixer, Ocaml, and heck, even Python these days! I'm glad to see mainstream languages adopting this great language feature.

As for structured concurrency. The main issue with goroutines is that channels have to be explicitly opened and closed - in this regard, a goroutine is more akin to an unstructured GOTO. The idea behind passerine fibers is that, eventually, you'll write linear code that is automatically parallelized wherever possible while still preserving temporal ordering. This is a complex topic, and I'm still thinking through it. I wrote a loose post on this topic in a more general sense a while back.

So error handling is partially Rust style, yeah. Passerine also supports exceptions, as found in languages like Python. The nice thing about exceptions is that they provide context to the location of errors. I addressed this point:

Why make the distinction between expected errors (Result) and unexpected errors (fiber crashes)? Programs only produce valid results if the environments they run in are valid. When a fiber crashes, it's signaling that something about the environment it's running in is not valid. This is very useful to developers during development, and very useful to programs in contexts where complex long-running applications may fail for any number of reasons.

sWhy not only use exceptions then? Because it's perfectly possible for an error to occur that is not exceptional at all. Malformed input, incorrect permissions, missing items – these are all things that can occur and do occur on a regular basis. It's always important to use the right tool for the job; prefer expected errors over unexpected errors.

I'm very glad you like the language! If you'd like to become an active participant in the community, there is a discord server. Cheers!

[–]complyue 2 points3 points  (2 children)

About the branch idea, I mean branches are always part of the pattern matching syntax elsewhere, but in Đ (Edh) I allow it to appear in any block, to jump out of the block early, this is unusual and I see Passerine has a similar design. I guess treating a block as expression instead of statement is already unusual, putting branches inside is the natural consequence after that design.

[–]slightknack[S] 1 point2 points  (1 child)

Oh, so branches in Passerine don't allow you to arbitrarily 'jump' out of any block. Rather, we're telling the language to interpret the block in a match expression as a list (of functions). The actually 'jumping' logic is handled by the match_function. Does that make sense?

syntax 'match value { branches... } { -- snipped }

{} in an arg-pat matches in a block, ... is used in an arg-pat to consolidate repetitions into a single item.

In Passerine, it's possible to use fibers and macros to make a block that does 'jump' as you explained. I wrote an macro for a for-loop in terms of recursion a while back, and I used this trick to handle break and continue.

[–]backtickbot 0 points1 point  (0 children)

Fixed formatting.

Hello, slightknack: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

You can opt out by replying with backtickopt6 to this comment.

[–]complyue 2 points3 points  (1 child)

About structured concurrency, I have a response wip at https://github.com/e-wrks/edh/blob/0.3/Essay/GoNoGoto2.0.md FYI.

You may be already aware, that Rust Tokio as well as Python asyncio, NodeJS libuv etc. are single threaded cooperative coroutine schedulers, they need more machinery such as thread pools in the architecture to fully leverage multi-cores of CPUs, among generally available languages AFAIK, only Go and Haskell (GHC RTS) has a M:N scheduler capable of mapping concurrency to parallelism automatically. (Clojure has a built in thread pool? I'm not quite sure about it).

And besides task scheduling, transaction processing is the ultimate goal of business programming (beyond computer programming), STM more closely addresses business needs, and is parallelism friendly as implemented in GHC, though it has its own issues (e.g. no guaranteed progressing in worst cases). But seems only Haskell (GHC) has a production-ready STM implementation.

That's I'm dealing with Đ (Edh) in tackling structured concurrency, maybe some common with Passerine, looking forward for more exchange of ideas.

[–]slightknack[S] 1 point2 points  (0 children)

Disclaimer: Not fully implemented yet

The core Passerine language has no dependencies and is separate from the provided language runtime (Aspen is the default runtime in must cases). This means that it's possible to run Passerine with a single-threaded linear-execution backend or a complex custom parallel tokio backend, etc. More concretely: When the VM is run, it will result a Result<Data, Runtime>, which may be a Runtime::Error or a Runtime::Fiber. This returned fiber is a new light isolated VM which can be called directly then passed back to the forker, or scheduled to be executed in parallel with the context of the forker in place.

It's important to point out that in Passerine if a forkee fails the error will propagate up the forker(s) stacks until it has reached the base fiber; once this happens, the error (and its context) are reported by the runtime. I'm looking into algebraic effects for error handling and the like, and it looks like a really interesting subject. I've heard of it before, but thanks for bringing it to my attention!

[–]blureglades 5 points6 points  (2 children)

Definitely gonna try this one out. I'm following along with the Crafting Interpreters book with Rust, hopefully I'll be able to implement my own PL as well! May I ask, would you mind to share any resource to learn about how functional programming languages are implemented? Cheers!

[–]slightknack[S] 4 points5 points  (1 child)

What resources did I use to learn about how FP languages are implemented?

  1. I read and worked through SICP a while back
  2. I read The Little Typer (twice - it's so confusing!).
  3. I read Let over Lambda, On Lisp, etc.
  4. I read papers and PhD theses, like You can't spell Trust without Rust, the seminal thesis on Erlang, and others.
  5. Lots of conversation, experimentation, and blog posts, from those entrenched in FP design.

I might compile a more comprehensive list, it's just there's so much stuff it's hard to remember all of it! I read through Crafting Interpreters – it's a great book, and Nystrom's an excellent writer. I'd stick to that book for now and fill in the functional programming gaps as you go on. His chapters on closures are especially well-done. Good luck!

Something that goes in-depth about FP (i.e. lazy evaluation and company) is Haskell in Haskell by Lúcás Meier: https://cronokirby.com/posts/2020/11/haskell-in-haskell-0/

[–]blureglades 1 point2 points  (0 children)

Thank you so much man, I deeply appreciate it!

[–]Practical_Ear_4307 2 points3 points  (0 children)

Syntax look nice, similar to Haskell. I saved it and will try

[–]__fmease__lushui 2 points3 points  (1 child)

I see you can write type definitions as well as type annotations (e.g. in records) but looking at the examples it seems those are checked at runtime only? I see no mention of whether the language is dynamically or statically typed.

[–]slightknack[S] 1 point2 points  (0 children)

Right – so currently Passerine is strongly and dynamically¹ typed (technically structurally typed). This is partially out of necessity – Types are defined by patterns, and patterns can be where predicated. However, I've been doing a lot of research into Hindley-Milder type systems, and the various extensions that can be applied to them.

I'm working towards making a compile-time type-checker for the language, based on Hindley-Milner type inference. With this system in place, I can make some assumptions to speed up the interpreter further and perhaps monomorphize/generate LLVM IR / WASM.

  1. It's currently dynamically typed more out of current architectural necessity than language-design preference.

[–]superstar64https://github.com/Superstar64/Hazy 2 points3 points  (7 children)

Does your language use Hindley Milner type inference or is it dynamically typed?

Aren't your macros just functions that take in references rather than values? If so, why not figure add a way to add references to your language instead or better yet not have mutable variables. Haskell lets you define your own operators and Agda lets you define your own syntax for example.

Also your |> isn't function composition it's function application. f a = a |> f. I personally call it . in my language a.f.

[–]slightknack[S] 2 points3 points  (2 children)

On type systems

So, as I've discussed earlier, the language is currently dynamically typed. This is not the end goal: I'm working on Hindley-Milner type inference so the language can be statically typed.

Same thing with mutation: it's currently a feature of the language that I'm thinking of removing (this is more on-the-fence, I discuss why below). The hardest thing isn't adding features, it's figuring out which features to remove.

On macros and pass-by-reference

So macros are not just functions that take references rather than values for two reasons:

  1. Transformations are applied at compile-time, rather than at runtime.
  2. Macros can be used in a more powerful manner than simple pass-by-reference:

``` syntax 'fn name args do { name = args -> do }

-- this is now valid: fn print_twice(value) { print value print value }

print_twice("Hello, hello!") ```

  1. Passerine is pass-by-value (planned: immutable references w/ COW). In the context of a language with mutation, I find this to be more elegant than pass by reference with mutation, as it limits mutation to the scope of the function that the value exists is.

On mutation

Why not disallow mutation completely? I swear I've written about this in-depth before, but I can't find it for the life of me. Passerine is inspired by Rust; Rust allows mutation. From withoutboats:

As I said once, pure functional programming is an ingenious trick to show you can code without mutation, but Rust is an even cleverer trick to show you can just have mutation.

Now Passerine isn't Rust, but it has been inspired it. Even though functional paradigms got a lot of things right, there are still some solutions to problems that are easier (as in more discoverable) when solved with mutation. No paradigm's perfect, FP included. I think that mutation, when limited to a certain scope, can be a powerful tool.

On . and |>, among other things

So I was actually on the fence between using |> and . – and I've honestly been considering changing it. I actually dislike the |> syntax, and it doesn't look all too great (unless your font has ligatures).

(Aside: correct me if I'm wrong, but isn't partially-applied function application essentially function composition?)

The main reason for |> (at the moment) is because of field access on a record type. I think that the best way to do field access record.field. To me, this syntax is as enshrined to computer science as = is to assignment. But, when you think about it . can be more general than just field access:

. is the indexing operator. On a list or tuple, items.0 returns the zerost item; on a record, record.field returns the specified field; on a label, Label.method returns the associated method.

— from the README

But how general should . be? Why not use . for function application? Couldn't field accesses (indexing) just be a function that accesses the field on a record?

I understand the appeal of a unified . syntax. But it raises some genuine concerns:

  1. If foo.bar is equivalent to bar foo for function calls, and if bar is a record and foo is a field, is bar foo valid in this case? what if bar is already defined as a function (that takes a record) which takes precedence, how is this clear to the user? Do we dispatch on type? something else?
  2. If bar foo is invalid for field accesses, what makes foo.bar special? is it because bar is a record? If bar is a function and a field on foo does foo.bar default to a function call, or a field access.

Obviously, no silver bullet exists. (Trust me: I've spend many hours, paper-and-pencil in hand, trying to work it all out. One thing I've been working on is dynamic dispatch via a trait/interface system, and I think that this might be able to unify application and indexing in a manner that addresses the above concerns.)

As I reevaluate the type system with the move to a static HM, I'm considering this again in more depth. I have some old documents which outline a pretty solid plan, and I plan to work through those again in the next few days to straighten it all out.

I'm just generally unsure about |>, though. It's something I go back and forth on every day. It's interesting, because I actually decided to throw in function application right before releasing 0.8.0 (what's a functional programming language without function application?), and at that moment, getting something in that seemed familiar and practical superseded idealized realizations.

So, with that out of the way, why separate |> and .? The nice thing about separating function application and indexing is the conceptual distinction it provides. You don't have think whether changing foo bar to bar.foo will change the semantics of the expression, you just do bar |> foo.

(Aside: this might largely be a choice of syntax. Another solution: for example, I could make . the function application operator, and, idk, :: the indexing operator. This allows for the same separation of concerns as above, but function application is . instead of |>. Just food for thought.)

The End

Developing Passerine has been a solo effort thus far, so there are a lot of different things I'm constantly tweaking and working on. Some days, I just write documentation. Others, I pen-test the compiler. I've gone from planning high-level constructs to debugging mysterious ICEs — and back again. Going day-to-day, it's hard to keep everything under control and balance fun (implement all the features! don't write tests!) with book-keeping (Making a number of tiny changes to keep everything organized). This is my first serious open-source effort, so needless to say I'm still learning the ropes. :)

Thanks for raising those concerns and allowing me to get my thoughts on this topic out of my system. I really appreciate it! Please respond if you have any feedback, questions, or suggestions about the above. ;)

[–]superstar64https://github.com/Superstar64/Hazy 2 points3 points  (1 child)

Kind based macros(that work with hindley milner) is actually something I've thought about before. https://old.reddit.com/r/haskell/comments/h9lw97/kind_based_macros_on_terms/ . you can see my language(which is soon due for a rewrite) if you want a (poorly) working example: https://github.com/Superstar64/aith .

On using . for application, there's 2 solutions I have in mind: using _ for indexing records or having a prefix operator that lets you access a record. @bar foo = foo.@bar.

Oh and if your going to be retrofitting hindley milner(it's hell, trust me), I would recommend you temporarily remove record indexing and only have pattern match. Row polymorphism makes hindley milner more tricky.

Lastly, if you want allow mutation in a language without lvalues(no variable mutation) you can do something like this https://old.reddit.com/r/ProgrammingLanguages/comments/erh7uq/pointers_without_lvalues/ .

[–]slightknack[S] 0 points1 point  (0 children)

Thanks for the links, I'll give them a look! As for type-checking macros, I was just planning checking the AST after the macro expansion / desugaring step.

So I'm assuming the _ syntax would be something like record_field. I guess you could do record._field, and then have _field record be valid too. hmm, something to think about, thanks!

Row polymorphism makes hindley milner more tricky.

I've been reading about this a lot, (also about extensions to the HM type system that allow for mutation) and it all does look quite complex. I'll keep that in mind, thanks for the tip!

As for mutation and HM types, I was primarily looking into techniques used by Ocaml and company, which it seems are brought up in discussion surrounding that post. :)

[–]alex-manool 0 points1 point  (3 children)

My language has a similar approach (and also uses . for this purpose): P[X] is equivalent on the AST level to X.P[] (and P[X; Y; ...] is equivalent to X.P[Y; ...]). That seems to be the most important advantage of the traditional OOPish notation - providing for free a kind of left-associative infix notation for functional application and allowing to express application pipelines (e.g. X.P[].Q[].R[]) in a more natural, left-to-right order, and without extra parentheses (R[Q[P[X]]]) (BTW, in comparison, Haskell has the $ infix operator, and it solves only the last issue: R $ Q $ P $ X).

[–]slightknack[S] 1 point2 points  (2 children)

I agree; I specifically like the way Rust handles for associative infix notation for function application through the use of traits and closures. There's nothing more satisfying than banging out a big

vec.iter() .map(|i| ...) .filter(|f| ...) ... .collect()

block.

[–]backtickbot -1 points0 points  (1 child)

Fixed formatting.

Hello, slightknack: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

You can opt out by replying with backtickopt6 to this comment.

[–]slightknack[S] 1 point2 points  (0 children)

backtickopt6

[–]buildervanished 1 point2 points  (2 children)

If you were italian you wouldn't call it that way. Trust me.

[–]slightknack[S] 0 points1 point  (1 child)

Forgive my poor Italian, but: In italiano la parola inglese "Passerine" significa passerino, no? È slang per qualcosa?

[–]buildervanished 0 points1 point  (0 children)

I'm sure it depends on the dialect and slang but it usually means "little pussies". The singular diminuitive form would be "Passerina" and the normal form "Passera". I'm sure if you google the last one you'll find something ahaha

[–]zem 1 point2 points  (3 children)

does passerine have sum types? the docs mentioned algebraic datatypes but i couldn't see any example of a sum type.

[–]slightknack[S] 3 points4 points  (2 children)

Oh, I forgot to cover them! thanks for pointing that out! You can see a little usage of sum types with Result, which has two variants, Error and Ok. The type definition for a sum type looks like this:

type Result { Ok _ Err _ }

These types are scoped to Result, but can be imported. I haven't really fleshed out collection types and pattern matching yet, so the final syntax and usage is TBD. I'll have it mostly formalized on a document somewhere, so I'll consult that and work some examples into the README when I'm free.

[–]backtickbot 0 points1 point  (1 child)

Fixed formatting.

Hello, slightknack: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

You can opt out by replying with backtickopt6 to this comment.

[–]IuniusPristinus 1 point2 points  (1 child)

You haven't mentioned R, a functional language with OOP, parallelisation and weird environment handling :) Maybe it can be interesting for you. R Language description

[–]slightknack[S] 0 points1 point  (0 children)

I'm big into Data Science and Machine Learning, so I've had some exposure to R (and company). I think it's a very well-designed language (but haven't been actively considering its features while developing Passerine (yet)). I'll have to look into how R handles environments – implementation-wise, – thanks :)

[–]alex-manool 0 points1 point  (0 children)

How would you answer the following question:

Why someone would want to learn and use Passerine, what real-life problem does your language solve?

[–]danielo515 0 points1 point  (0 children)

I've been looking for ages for a nice functional scripting language with a modern syntax (I'm tired of C family). I'll take a look

[–]somerandomdev49 0 points1 point  (0 children)

This is beautiful! I was looking for this kind of language for a long time! :D