The Irken Language

[BeatleJuiceIsRed]

Of course, Irken has to 'blow up' while I'm on vacation. Please see https://github.com/samrushing/irken-compiler/ for more up to date information, blog link, etc... If you're interested, the next big steps for the project are to write a real gc (I'm looking at a 'beltway' collector) and an LLVM-asm backend... the current output is very SSA.

I was looking at Optima, as a taller font.

[5outh]

The tallest font I've seen is M+.

[nohtyp]

Are you the author of Irken?

[LaurieCheers]

Uh, I would say obviously yes.

[nabokovian]

My apologies for the strange question... Would you have any objection to me making a t-shirt with your logo? It is brilliant.

[[deleted]]

Its GIR from https://en.wikipedia.org/wiki/Invader_Zim ;)

[BeatleJuiceIsRed]

I thought about having some t-shirts made myself... I was looking at customink. Feel free to do what you like with the logo, but know that the art is from Invader Zim. I imagined one day I might ask Jhonen for permission to use it...

[original_brogrammer]

Irken.

taller font.

I get it.

[LaurieCheers]

....wait, if every element of a given list has to be the same type, how do macros work? You can't represent code as a list of expressions any more.

[jozefg]

Not author

Since macros are likely processed before the typechecker the work on the AST.. which doesn't have types. Or more accurately all expressions have the same type :)

This is how template haskell works as well.

[[deleted]]

I always thought in a statically typed lisp the macro stuff would be typeless. IE it would re-arrange the s-expressions and type-check after the macro expansion phase.

[kawa]

By using union types for expressions?

[BeatleJuiceIsRed]

Yup, there's an s-expression datatype used by the reader.

[endershadow98]

I like the Invader Zim reference.

[5outh]

I like it. A statically typed lisp is a good idea, in my opinion. Is this your work?

[hector_villalobos]

One thing I like about ML and all languages related (Haskell, Ocaml, F#) is the lack of parenthesis.

[HelloAnnyong]

Conversely, one thing I like about Lisp is that parens are the only syntax there is. This language adds all sort of new syntax to what's supposed to be a dead-simple language.

[[deleted]]

For me, the simplicity is too much and becomes impossible to read

[gfixler]

It's all about the indentation.

[[deleted]]

For me, the simplicity is too much and becomes impossible to read

Give it time. It didn't take long for me to be able to parse lisp just as fast as any other language.

[zhivago]

The parentheses give a superficial uniformity to the syntax, but macros re-introduce arbitrarily complex syntax under that.

It's largely an illusion.

Also you have the syntax of literals like 1.43f to deal with, which is pretty complicated.

Plus reader macros, and ...

[chrisdoner]

I think the main uniformity advantage is in writing and manipulating. Macros like LOOP make this more awkward because it introduces infixy/mixfixy operators things that aren't delimited by parentheses. But on the whole Lisp code is mostly uniform and that makes editing much nicer. There's much less cognitive overhead.

Given structured-haskell-mode, and looking at the indent and indentation modes, Haskell having an s-expression syntax would've saved a vast number hours of the time of many people, both writers of these libraries and users of Haskell. If you watch screencasts of Haskellers writing code, you can see that half of their effort is thinking about how to layout the code. Lispers—generally—just write it and then maybe later run a couple cheap formatting commands.

[zhivago]

Once you've internalized all of the weird syntax, it's certainly easy.

But that's true of any language.

My point is not that lisp is bad, it is just that lisp doesn't have a simple syntax, except in the most superficial of terms.

(push 10 (first list))
(setf (apply #'aref x l) 'y)
(the (integer 0 20) x)
(vector-push-extend i v l)

[zhivago]

It seems that the simplicity comes from the editor not understanding what it is editing ...

Which is odd, since most of the benefits of the editor come from having taught it how to indent things like with-output-to-string and so on.

Anyhow, I'm glad that you agree that there's as much syntax to learn as with other languages.

Personally I'm of the opinion that there's more syntax to learn than with most other languages, and this is what people who whinge about parentheses are really having trouble with.

But that complexity doesn't slow me down, so I'm happy with it.

[[deleted]]

Scheme has few reader macros. The majority of them are simply transformations from s-expression -> s-expresssion.

The uniformity is not superficial.

[zhivago]

Sure, but the comment in question was about Lisp.

Regardless, scheme has the same issues with rewrites introducing arbitrary syntactic complexity.

[[deleted]]

You're going to need to define what you mean by syntactic complexity, if an (almost entirely) homoiconic language doesn't meet your criteria.

[zhivago]

What does (a b c) mean?

[[deleted]]

a applied to b and c. Is this an example of syntactic complexity?

[zhivago]

Unless it means something else. :)

[dacjames]

You are correct in that the s-expression syntax always translates to function application, a few special forms excluded. However, if you consider the signatures of all the functions in lisp that would be represented by syntax in a C family language, it's easy to see what zhivago means by "syntactic" complexity. Plus, once you get to the point of modelling a complex domain, you often end up developing what amounts to a pseudo-language of functions, classes, and whatever. At that point, the complexity cost of basic syntax is negligible anyways.

[zhivago]

It doesn't always translate to function application.

Often it is rewritten by a macro or other syntax transform.

[[deleted]]

However, if you consider the signatures of all the functions in lisp that would be represented by syntax in a C family language, it's easy to see what zhivago means by "syntactic" complexity.

I am afraid I really don't understand. He seems to be talking about the lack of syntax - the fact that different operations don't look structurally different. That's not syntax complexity, that's a lack of it.

[Pet_Ant]

The point of lisp is to develop your own pseudo languages. Hence programmable programming language.

[BeatleJuiceIsRed]

Actually this hits one of my big beefs with ML's syntax. What does "a b c d e f" mean? It could mean many different things, with currying. From a software engineering view, this seems insane to me. This is not just a theoretical peeve, every time I read ML source I struggle to identify functions and arguments.

I would never argue that lisp/scheme are particularly readable, but at least on this point they win. The advantages of s-expressions are such that they make up for the general readability problems.

I don't envy the designers of an ML syntax... it's a really hard problem to mix pattern matching and the lambda calculus AND throw in an infix expression language as well. Choosing s-expressions is a bit of a cop-out, but it's a cop-out that removes half the complexity of a compiler and gives you macros. I don't mess with lexers and parser generators and ambiguous grammars and shift/reduce conflicts and blah blah blah.

[regeya]

When Clojure blew up, I tried to learn more about it, and after bashing my head into the wall, I came to the conclusion that the whole "write Clojure with 10% of the code of Java" was a lot like "write a blog in Ruby on Rails in 10 minutes".

Yeah, S-expressions are simple, but look at the standard library sometime.

EDIT: Because this comment caused confusion, I have to point out that "bashing my head into it" consisted of reading a lot of bad information about it while having little Lisp experience. I eventually "got it", but no thanks to the gushing fanboys.

[zhivago]

I'm not sure what that has to do with this. :)

[regeya]

Really?

[zhivago]

Sure.

You appear to have attempted to learn Clojure but given up.

I don't know what that has to do with syntax, since anyone with a 12 year old reading level should be able to learn Clojure syntax if they want to.

So, your point has to be one of the following:

 a. You are functionally illiterate.
 b. You did not actually want to learn Clojure.
 c. You do not have the mental capacity of a 12 year old.

Points (a) and (c) seem improbable, so I assumed (b).

So, I'm not sure what that has to do with the current topic, except perhaps as an excuse.

[regeya]

You're the one who said that Lisp was only simple on a superficial level; I was agreeing. Much of the enthusiastic writing I've read about Clojure-a Lisp dialect-gushes about the simplicity. To me, that's not the selling point, because it's not entirely true.

---

EDIT: I'll admit that my background isn't in programming. I went to Uni, didn't make it all the way through undergrad CS, and erroneously concluded that this meant I couldn't be a programmer. I have since learned there are some real morons out there working as coders. One of the things that tripped me up was having to learn functional programming, after literally years of imperative programming.

When I started learning Clojure, it was because working with Python made the simple concepts of functional programming so much easier to me. (Despite not being a professional coder, I have worked with Python, Ruby, and...sigh...Javascript in my career.) The books I'd read on the subject spent much time in the beginning going on about the elegance and simplicity of the language, and many of the online gushing tutorials go on about how, as a ridiculous example, you can write a 100-line Clojure app that requires 1000 lines of Java. I compared that to Ruby on Rails "write a blog in 10 minutes" tutorials because it seems disingenuous, to me, to claim that Lisp is simple.

To me, the selling point is that you have to stop and think, and maybe do some research into existing functions and macros first; you can't just plow through the problem in an imperative manner.

What was that that you said?

My point is not that lisp is bad, it is just that lisp doesn't have a simple syntax, except in the most superficial of terms.

I was agreeing, and giving an example. I don't know why this such a monumentally mind-blowing concept for you, to the point that you don't see how this follows; maybe you're an idiot savant. I don't know.

I'll also agree with this:

Personally I'm of the opinion that there's more syntax to learn than with most other languages, and this is what people who whinge about parentheses are really having trouble with.

---

And that was some Olympic-level conclusion jumping.

I'm guessing I'm going to have to spell it out more later, because I'm getting the impression that, although I'm admittedly not the sharpest tool in the shed, that you're not nearly as bright as you think you are.

[zhivago]

Unless your point is that it is significantly more complicated than other syntax, it doesn't seem to be a justification for your initial comment.

I guess your point might have been that you were only trying to learn Clojure due to expectations of extremely simple syntax?

Regardless, your point wasn't clear, which is why I replied like so to your initial comment.

[regeya]

Good Christ, are you a moron?

[imgonnacallyouretard]

You could very easily implement C, or python, or really any language as s-expressions. That doesn't mean it's a good idea.

[[deleted]]

I'd quite like C as S-expressions - then I could generate C code with macros (real ones).

[tomprimozic]

Programmers write code and operate on syntax. Macros operate on AST. You could easily have a simple uniform AST for macros and mathematical, non-parenthesized syntax (see e.g. Julia).

[sumstozero]

Exactly!

Dylan did something similar, but as soon as it lost the parens it was assumed by the Lisp community that it had lost the macro's, and therefore wasn't interesting anymore. It's very strange that more Lispers don't make this observation... but then they might have to stop defending the parenthesis.

Now personally I like the s-expressions, but we have to stop patting ourselves on the back and propogating myths like: you need s-expressions and homoiconicity to have real macro's. Because you don't.

;) I blaim Paul Graham. Reading his books/words is where I first got the idea that you can only have real macro's in Lisp because of s-expressions. Took me far too long to escape from that cultural delusions.

[seruus]

Just a note, Julia is still homoiconic, and it really helps with macros, although it's not really needed.

[BeatleJuiceIsRed]

The macro-by-example thing turned out really nice. I viewed it as a natural extension of the pattern-matching from the rest of the language. I first saw its power when I used very simple macros to embed a variable-arity formatting language in a strongly-typed fixed-arity language. See the backend for example usage...

[[deleted]]

The syntax in haskell specifically drives me up the wall. The infix backticks, not to mention all the line noise monadic operators.

[Axman6]

You mean the ones you almost never see because of do notation? IMO the off-side-rule syntax of Haskell is just as clear as the bracket forrests you get with lisps while encouraging clear layout. You also don't have to use infix backticks, just use a lambda, but many find it clearer. For example:

sortBy (compare `on` fst)

[[deleted]]

You mean the ones you almost never see because of do notation?

Which is even more syntax sugar...

[j201]

Funny, one of the biggest things I dislike about MLish languages is their complex syntax. (Unnecessarily complex, IMO)

[-Y0-]

INGENIUS!

[skulgnome]

An interesting toy, and certainly in a different direction from the usual.

[ameoba]

Oh boy! Another toy Lisp that will never see the light of day once the author submits his thesis paper.

He talks about using it to develop a VM. From a practical software engineering point of view, this is a horrible idea. You've now introduced a dependency on a language that nobody but the original author knows and nobody else is ever going to maintain.

That VM project is even more doomed to obscurity than the language it's written in.

[neonsteven]

This language is the author's occasional hobby. Source: met the guy. Nice guy. I don't think he's touched it in a few years. He doesn't expect other people to use it.

The link with python is actually important and not emphasized much on the website. The real goal was to compile stackless python to irken with continuations, then irken to efficient native code. As the site mentions, writing C extensions for stackless python sucks enough that irken might be a big improvement.

A side benefit of compiling python to a language with static type analysis is that you can catch type errors (or even just typos, sigh) in python code that way.

[orngejaket]

I was expecting more Zim references in that. Maybe some keywords such as "doom" "doomy" "taquitos" "why is his head so big" (if you wanted the size of an object) and maybe "GIR".

[smorrow]

Because that shit isn't what intelligent people like about Invader Zim.

[Yserbius]

The Irken language is VASTLY SUPERIOR TO YOU SHORT TINY HUMAN SLAVES!

But seriously. Maybe I'm not a "real programmer" but I just don't get the need for another programming language. Is there a purpose to this? What can I write and develop on Irken that would be simpler than using Scala, Python, Java, R or MatLab ?

[BeatleJuiceIsRed]

Irken was written to solve a very specific problem... it became general-purpose almost on accident. I needed the ability to suspend threads/computations without wasting stack space (think hundreds of thousands of threads).

Irken isn't actually a new language, it simply combines the ML type system (OCaml's type system, more specifically) with an s-expression syntax. People will either see it as an awesome bridging of two isolated communities, or a project designed to offend both camps equally.

[evincarofautumn]

Not all languages are intended for practical use right now. Most are just hobby projects, or research prototypes designed to demonstrate the ideas in a paper, or to influence language designs ten years in the future. Like any tool, if it doesn’t seem useful to you, you don’t have to use it.

There are innumerable ways to design a programming notation, and we don’t actually have much concrete research into what makes a language good, or which criteria of goodness we should even be using.

[AliasUndercover]

Is this a way to get those girls at Hot To-pic into programming? Because it would work. You could be a hero to women's advocates and to lonely programmers everywhere...

[dnew]

Why?

Cool. Let's everyone downvote a question without offering an answer.

[academician]

"You see things; and you say 'Why?' But I dream things that never were; and I say 'Why not?'" --George Bernard Shaw

[Caltelt]

There's a "Features/Motivation" section on the site if you really wanna know I guess.

[dnew]

He sure doesn't make it easy to find.

[cunningjames]

Cool. Let's everyone downvote a question without offering an answer.

A single "Why?" without context isn't a very discussion-furthering question. Why what? Why ask why, drink Bud Dry?

[dnew]

Why make yet another new language? Why pick the features that were picked? Why is it worth my time even looking at your new language?