AT&T Archives: The UNIX Operating System

Dots to colons

I changed the dot in `System.nil` into a colon, so now it's `System:nil`. The good part, `.` is now function composition. The bad part, `:` might interfere with CVS, comma separated files, which, despite being called comma separated, often use a colon.

I might change it again. `#`? `$`? I am out of ideas.

Semicolon

What's a language without a semicolon? Since Egel has strict semantics but combinators may be side-effecting, it makes sense to add statements, a bit of a trivial extension, to at least give users the possibility to easily define input/output behavior. For example,

printLine "What's your name?"; let X = readLine in print "Hello, " X "!"

Which is a bit shorter than

let _ = printLine "What's your name?" in let X = readLine in print "Hello, " X "!"

But I guess that'll pay off for longer routines. The easiest manner of generating code for semicolons is therefor a let. But lijero on freenode pointed out that you can also employ a 'semicolon' combinator.

[ X _ -> X ] (let X = readLine in print "Hello, " X "!") (printLine "What's your name?")

So, there are some tradeoffs. The let sugar means I'll generate one combinator for each semicolon, the semicolon combinator needs to be added to the runtime -which I don't like- but you could, for instance, then fold that semicolon over a list.

Then, should the semicolon combinator be a built-in or generated on the fly? I don't know yet. If I had some kind of optimizing compiler, the compiler would need to know about its definition. A C++ defined combinator is a bit faster but also more a bit work.

Looks like I'll go the whole principled way of going for an explicit AST node for a statement, a transform do desugarize that, and built-in C++ combinator.

For a semicolon.

Eight Reasons Egel is Slow

I checked the program `foldl (+) 0 {0,..,1000000}` against GHC and it's about 16 seconds for the Egel interpreter versus maybe at most 300ms for ghci. Because Egel is a term rewriter it turns out `foldl` and `foldr` have roughly the same performance. That in comparison to an old report on GHC behavior.

The odd thing is that it seems to take more time in the IRC bot, a dynamic library seems slower than the compiled interpreter. It's 16 seconds for the console application versus roughly a minute in the bot.

I am two or three orders off. That roughly corresponds to 2^8 to 2^10, so there are in the neighborhood of at least eight reasons why Egel is slower.

1. The Egel interpreter is a vannila term rewriter.
2. The interpreter doesn't optimize.
3. The language is untyped.
4. The interpreter uses idiomatic C++ and classes from the standard library.
5. Thread safe reference counting.
6. No standard arithmetic primitives.
7. The bytecode generated is dumb.
8. The overhead of exceptions.

But not bad for a simplistic robust interpreter. Not bad at all.

I love back-of-an-envelope reasoning.

Changes to the Syntax

Well, I tried to be smart and that didn't pan out. I thought using a comma would shave off some characters from pattern definitions because

[ cons X XX, cons Y YY -> .. ]

versus

[ (cons X XX) (cons Y YY) -> .. ]

That is one comma versus four parentheses.

But, as it turns out, the prelude is exactly as large for both alternatives and the standard manner of writing things made the Conway's Game of Life program a tiny bit shorter.

I changed the syntax to the standard manner because people seemed to like that more.