14 Apr 2002 chalst   » (Master)

arc: I've a few ideas about programming languages that I think might be right for Paul Graham's arc language. I'll try to get them a bit more polished than this and then send them in, but here are the general themes:
  • Alan Bawden suggested that arc might benefit from a module system based on his `first-class macros', ie. where procedures can take macros as arguments and still have everything resolved at compiler time. I think this would be wonderful, and would really allow arc to stand out as a technically innovative programming language.
  • `Unix won'
    1. Case sensitivity: I'm not sure about this - Unix has won the battles so far, but it still might be displaced by an MS/NT system as the de facto server standard. A practical consequence: it can sometimes be a bit of a nuisance to handle MS filesystems using a case sensitive symbol system. I'd like to see a way to make this something that the user can configure at run-time. I'm putting together a proposal on how to handle this.
    2. UNIX awareness: This is a good thing, but I'd like to see an attempt to be multi-platform. Python has got this almost right, with language design being focussed around what is practical to do on all platforms. Having said this, sometimes Python has a lowest-common-denominator feel. Perhaps having parallel arc/UNIX, arc/JVM and arc.NET implementations, with an attempt to keep the intersection of the three (Portable arc?) as large as possible, would be a good thing?
  • Soft typing: I'd like to see language support for soft typing, perhaps based on intersection types.
  • Infix/currying/laziness:I'd like to see something allowing it easy to incorporate Haskell style user definable infix operators, currying and lazy functions/list manipulations. I've an idea that this can be done all with special forms:
    1. We have a [...] special form that allows infix notation of non-function types.
    2. We have a [> ...] special form that allows curried infix notation with eager semantics: the syntax is as before but we allow `_' parameters which are treated as parameters of a fn/lambda construction (so [_ + _] is (fn (x y) (+ x y)));
    3. We have a [< ...] special form similar to the eager form, that allows curried infix notation with lazy semantics, handed using some future like mechanism;
    All of these would macro-expand into normal S-expressions.

    The idea behing the `<' and `>' mnemonic is that eager reduction strategies in the lambda calculus tends to evaluate beta redexes further to the right than lazy reduction strategies do. This would allow a lot of the Bird--Meertens formalism to be modelled painlessly in arc;

  • Regexps: I'd like to see support for regular expressions in the core language, perhaps following the proposal of Olin Shivers.
  • Lexemes: I've an idea about extending usual treatment of environments with combinator parsing-like ideas: we extend environments so that instead of just mapping symbols to values, they also allow us to map patterns that can stand into infinitely many symbols to combintor parsers that recursively build up an expression. This might be nice for handling Perl-style regexps.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!