Hacker News Reader

Comment by xaduha | Hacker News Reader

http://www.red-lang.org for those who doesn't necessarily need Lisp, but appreciates homoiconicity and other nice things.

> This executable is a full blown native interpreter with a JIT, GC, etc.

> A small, fast, native lisp

I have issue with the use of the word 'native' here. For me 'native' mostly means AOT compiling.

View on HN

To me Rebol/Red is more lisp than some other lisps out there. It doesn't have so much parens, true, but the idea of like code is data and DLS possibilities are huge things.

First I've heard of Red. Does it implement 'readable' [1] or is it a [parallel school of thought] (can't think of right phrase here but you get what I mean)?

Also has anyone tried to create a 'readable' [1] flavour of Clojure yet? If not, why is that, do lispers consider all the parens to really not be a barrier?

[1] http://readable.sourceforge.net/

Red is basically Rebol rewritten with an important distinction. It comes with a sister language called Red/System that is basically a lightweight static systems language like C, but a lot closer to Red. Therefore, you can run the interpreter or drop down to native code when you need it. The 1.0 release should AOT compile what it can, then JIT, then lastly interpret what you have to. It is hoimoconic like lisp, but not a lisp. There is no install, just a 1 MB interpreter and compiler that can target a lot of architectures. The draw GUI DSL is pretty amazing. There is a Rebol YouTube vid (Red is 98% compatible) where a guy makes a zillion little cool apps with only a few lines of code each.

Link? Searched YouTube but no vids appear to match your description.

https://m.youtube.com/watch?v=lR5Fzv6DP0I

No, the parens don't constitute a barrier of any kind, really. Reading lisp fluently requires very consistent indentation, though. Then you see where an expr starts and where it ends (with nestings and all) without counting any parens whatsoever.

When writing lisp your editor should help you at least a bit to make things enjoyable. They can help a lot, but doesn't have to help much; I found for myself that if the editor just highlights matching parens, I'll be very effective.

Since discovering paredit-mode, I have found a whole new love for Lisp syntax, and now I won't write Lisp without it.

I have tried a structure editor for Haskell but I found it pretty counterintuitive. I wonder if structure editing just assumes a language with very little syntax.

>Does it implement 'readable'

Nope, it has it's own notation which I find very close to the Smalltalk one, for example:

  red>> a: [1]
  == [1]
  red>> pick head append a 1 + 1 2
  == 2
  red>> a
  == [1 2]

So the second expression is good example of how things work, this is how it looks if I put parens (which are unnecessary in this case):

  pick (head (append a (1 + 1))) 2

Here interpreter/compiler knows how many arguments each `word` (you can think `function`) needs, so `append` needs 2 - series and item to append, `head` only one - series, `pick` needs series and index to get element. But what about `+`?

  red>> type? :+
  == op!

Operators are infix things of two arguments and they get priority over function calls, that's why `append` is called with `a` and result of `1 + 1` and not with `a` and `1`.

It looks a bit tricky in the beginning, I understand, but it leads to very compact and easy to read code.

This is brief explanation which should help you to start reading and writing Red/Rebol code :)

Great explanation, thanks!

They said that the interpreter was native. It is - it's AOT compiled. They didn't say that your program was natively compiled. Your program is interpreted - by the interpreter - the native intepreter - and then JIT compiled by meta-tracing the interpreter.

Their terminology is totally consistent with how the field uses these terms.

This technology operates at multiple levels of meta-implementation, so it is easy to get confused what is tracing what, and what is implemented using what at a given time.

It's useless information then, any real executable is native. In that sense you can say Perl is native (Python, Ruby, JavaScript/nodejs).

Well yes any real executable is native. The perl executable is indeed a native program. It's a native interpreter for Perl.

But there are also interpreted interpreters aren't there? Which aren't real executables, and aren't native. It would be possible to write an interpreted interpreter for Perl, maybe in a language like Ruby. Jython is a real example of an interpreted interpreter (if you ignore that the JVM has a JIT, but it isn't AOT, which you've said that you think is an important criteria).

And so it isn't useless information.

The distinction is particularly relevant here because the RPython technology they are using to build their interpreter means they can either interpret their interpreter using the Python interpreter, or they can make a native interpreter by compiling their interpreter to native AOT. That's probably why they used that particular wording.

So, again, not only is their terminology consistent with the rest of the industry, they are also making a specific and interesting point here, and it isn't useless information.

They put that in a headline - A small, fast, native Lisp. It's missleading/clickbaity.

I think it's meant as in comparison to Scala and the like, which run on the JVM, and thus aren't "native" in the same way (right? or am I misinformed about Scala?). There's a lot of languages that sit on top of the JVM at this point, so they might have seen it as a distinguishing characteristic.

> thus aren't "native" in the same way

Sorry, no, this is nonsense. Scala source code is compiled to Java bytecode, which is interpreted and JITed by the JVM. Pixie source code is compiled to the Pixie bytecode which is interpreted and JITed by the Pixie VM. chrisseaton claims that "native" refers to the interpreter, but this is rubbish ... that's not what the industry means by "native".

> But there are also interpreted interpreters aren't there?

I mean, not in use.... What would be the point? Every other interpreter worth using is AOT compiled, it's hardly something to boast about.

One exception might be JRuby, I suppose. Kind of a strange comparison to go out of your way to disabuse.

Not strange at all. The main language inspiring pixie is clojure, whose interpreter runs on the JVM. I might even go so far as to say that the main reason to use pixie is because you want to write clojure but can't afford to use a JVM for the task at hand

There's no such thing as the Clojure interpreter. Clojure programs are translated into Java bytecode, which runs on the JVM, which is a native program. (see http://stackoverflow.com/questions/3107299/how-do-clojure-pr...)

Pixie programs are translated into Pixie bytecode, which runs on the Pixie VM. Bytecode is, by definition, not "native".

If we're going by the traditional idea of "bytecode interpreter" or "threaded interpreter", clojure is emphatically not one of them. It JIT compiles the lisp to JVM bytecode; the equivalent in Pixie would be JIT compiling to native code.

IIRC with RPython/pypy the two techniques are interleaved, but most users I've seen opt for some JIT optimization.

"So, again, not only is their terminology consistent with the rest of the industry"

You have said that twice. It was wrong both times.

> But there are also interpreted interpreters aren't there? Which aren't real executables, and aren't native.

Sure, you can for example run a Prolog interpreter on top of a Lisp interpreter. It's just not fast, but may have other qualities.

They mention Clojure, and the Clojure interpreter is a Java program, which is not native. So there is nonzero information in mentioning that the interpreter is native.

Sorry, but you have absolutely no idea what you're talking about. Clojure produces Java bytecode, which is interpreted (and JITed) by the JVM, which is a native program.

See http://stackoverflow.com/questions/3107299/how-do-clojure-pr...

"They said that the interpreter was native"

Sorry, but that's nonsense. "native lisp" means that the lisp source is compiled down to machine code. To claim that an interpreter is "native" is to misuse the terminology.

>"native lisp" means that the lisp source is compiled down to machine code

No, that would be a lisp that produces native code, not a native lisp.

To contrast, there are non native lisps written in Python, in Javascript , etc., including atop of other Lisps.

Probably the language that I'm most looking forward to. It'd give you the ease of python with the speed of a native language and the best GUI DSL I've ever seen.

Edit: Agreed that I don't like the author's use of native either.

Red is actually quite cool lang. Thanks for posting.

Reply on news.ycombinator.com