> sudo apt-get install screenie

> screenie

screenie is perfect.

It works:

    func foo (x): fn () x
    print ((foo 4)) // prints 4

I'm afraid I don't understand what you mean by this. Maybe you could give a short example? As I see it, one way or another you need to mark out the "outer" scope, where you declare the lifetime of the variable (even though you don't know its value yet). Then somewhere in two or more branches of that scope the variable is set and used. IIUC you propose to write "varscope" at the top, and "var" further down. Doesn't that mean that whenever you define a variable, you need to write "varscope" before it? I somehow can't believe that, which makes me think I'm still not grokking!

> I assume you mean multiple vars of the same name in the same scope.

Yes, otherwise you quickly run in trouble with parent-scope scheme :)

> One consistent example of my rebellion is with loops, where I have no problem using "for ( var i = ..." for multiple loops in a single function.

The way that's handled in bullet is that when we encounter the for, we push a new environment, run the initialization, then push (and subsequently pop -- the interpreter holds a stack of environments representing runtime frames) an environment for each iteration of the loop. So it's ok to use the same variable name in subsequent for loops: the previous instance is not alive by the time current is reached.

> If func doesn't expand into var, I'd rather it did.

Here's the definition of "func" in bullet:

    macro func (name args :rest exprs)
      qquote
        set ,name
          fn ,args ,@exprs

    func m.foo (): print "m.foo" 
    ==>
    set m.foo: fn (): print "m.foo"

    var macro
      tfm (name args :rest body)
        qquote: set ,name: tfm ,args ,@body

As it should be clear by now, my implementation is a sort of illegitimate child of fexprs and macros. Basically, I've introduced all the weaknesses of fexprs in return for only some of the gains :)

In bullet, macros are values represented by the Transform class. Their definition is almost identical to Lambdas: they hold their formal parameters and their body as an AST. The only difference to Lambdas is how they're treated for evaluation purposes by the interpreter. Transforms (like Primitives which are basically fsubrs) receive their operands unevaluated. They are expanded at runtime, and the result of the expansion is then evaluated in the lexical environment of the call site. That means you can use macros in higher-order functions; they truly are first class.

Until now, this was an artifact of my interpreter design (emphasizing getting something up and running quickly). My intention had been to double back and fix the discrepancy with "real" lisps by doing the standard initial macroexpand traversal of the AST before evaluating. Either that or ditch the interpreter and write a compiler.

However, the material you've presented me with regarding fexprs is truly fascinating (no, I didn't know what they were before I read your post). I've just got to try these fexpr style macros; the idea of just controlling evaluation of operands, but otherwise being just like a regular function is very appealing.

In conclusion, I would appreciate if you could explain the varscope concept further. Again, what I don't get is whether need to write "varscope.." before you can bind a variable using "var..". I bang on about that because I'm loathe to introduce a feature that introduces such a high overhead for a single variable use. Or do you also have "lets" that work as in scheme?

Here's how bullet handles things:

* A variable comes into existence either through a "var" or a "set" declaration. It is an error to have consecutive "var" calls in the same scope. Assignments are much more permissive: obviously you can use any number of them in any scope, and you don't need a "var" to preceed the first instance of a "set".

* If you write "var x ..." in a scope, and again in a child scope, then there is a new binding for x in the child scope that shadows the binding in the parent scope. On the other hand, "set x ..." not create a new binding if one already exists, so it will set x in the parent scope.

* All of this is handled by Environment class, using a rather pedestrian HashMap<Symbol, Variable>, where Variable is nothing more than a box. Obviously we capture variables that escape from functions when we analyze lambda definitions.

* The Environment functionality is reused to provide python-like modules. There is a special evaluation syntax (basically, it's the same syntax as for array/map access in clojure), which coexists quite nicely with the "." syntax:

    set y 5
    var x 42

    module m
      var x 1
      func dblx ()
        set x: + y: * x 2
      func printX ()
        print "x = " x

    print "x = " x
    print "m.dblx = ": m.dblx
    m.printX
    set m.x 50
    print "m.x = " m.x

    // prints:
    // x = 42
    // m.dblx = 7
    // x = 7
    // m.x = 50

    print: str.joinOn " " "modules" "are" "cool"

Also, in bullet "with" resembles pascal's "with" except that it returns the (effected upon) object:

    print: with (new ArrayList)
      add 1
      add "foo"
      ...

For no better reason than I wrote the 'for primitive before I added macros!

I agree about labeled break and continue -- I specifically mention them in the article BTW. And to be honest, it has also occurred to me that this is just a local goto. So I have contemplating adding them.

The "point" approach is very cool. I like that it can translates into JVM features directly while remaining quite general (e.g. it's trivial to implement "return" using point). I think it's pretty easy to implement in the interpreter also, using exceptions (it's not going to win any speed contests), though you'd use labels and gotos when compiling.

It's not even that big of a loss, since you can write:

    if (condition)
        true-clause   // 4-indent.
        false-clause

No, currently attempting to evaluate () is an error (and a bad crash with no error message, I'm embarrassed to say! [but now fixed and pushed]).

Your argument regarding () is pretty convincing. It's a bad idea. But I find the full-stop notation a bit jarring, not sure why. I'll try it and see if I get used to it... And I didn't want to tread on the "!" real-estate, given that's it's commonly used in identifiers.

I have to say I still lean slightly towards preferring a default of invocation for 0-arity functions, and using the "val" (again, id) function for passing the function itself.

1. line processor: text lines are surrounded by brackets (textually!) where appropriated (i.e. 2-indents subject to nesting rules). Infix operators aren't touched. Result is stored in an array of CodeFragment, which is basically text + source code location.

2. reader: the forms are "read" and turned into B-expressions. You could call this the parsing stage, but lisp is a bit strange in some sense: there are two levels of parsing: the reader is the first, and the second is in the...

3. interpreter/compiler: every lisp has a starting phase which takes the "low-level" S-expressions comprising the code and parses it into the true semantic expression of the language: e.g. IfExpr, LambdaExpr, FnApplyExpr, etc.

Indeed, I think this is what makes lisp unique: all other languages have parsers which take you directly to step 3. The AST for semantic analysis purposes trees is basically just the parse tree. In lisp, you have to do work to get the AST -- but that's also why you get flexibility in macro writing.

I'd be happy to exchange implementation details. As I mention in the article, my code resides at

http://code.google.com/p/bullet-lang

My email is

martin at percossi dot com

I opted for the "var" notation because I wanted to emphasize that the bindings are to _variables_; not to _values_ as is the case in (some) other lisps. I wanted to leave "let" for the case when you really want a constant. Another reason is purely aesthetic; the first programming language I learned was Pascal (ah, the fond memories :) which I always thought was a very _clean_ language. I wanted to evoke that (that's also why I use "begin" rather than "do" -- interestingly, once you use the 2/4-indent rules, you actually get pushed to _not_ using two-letter names, since 2/4-indent is ambiguous under 2-letter-name).

Regarding gradual typing, it would be nice because:

1. when programming in the large, knowing which types are expected and returned by a procedure is extremely helpful;

2. typing allows IDE autocompletion as well as refactoring (as you mention!);

3. allows for type hints for unboxed arithmetic, i.e. for performance.

1 & 2 are important, 3 much less so. My thinking is that if you're going for speed, you're probably going to want to do it in Java anyway. (Indeed, that I believe is one of the fallacies of Clojure: very few people are going to do performance-critical code in lisp. Having worked in e.g. a stat-arb fund, I can assert that no manager in their right mind would use anything other than tried-and-tested Java/C++/C# in that scenario.)

    begin
         // 4-indent, so no parens: back in lisp world.
         (if (prefers-s-expresssions user)
           (print "bullet sucks")
           (print "why are you doing this to yourself??"))

The reason the 2-indent would evaluate (i.e. result in an invocation) is that '+', '-', etc. are _primitives_, which behave semantically like _functions_. For all other objects, the (1) rule applies.

Do you think this is too convoluted?

Alternatives I see:

1. The obvious is not to allow (obj-thing) ==> obj-thing. But then we'd need to define (func val (x) x) so that (e.g.):

     print: if (is-saviour name)
       val "go frodo"
       val "don't know you"

2. Make (fn-or-prim) ==> fn-or-prim (i.e. unifiy treatment of functions and objects, and in addition. To force evaluation of a 0-arity function, allow:

    save-middle-earth ()  // <-- () causes invocation.

You can break the line accross by using "begin" in _bullet_:

    cond
      name equals "Martin" ; begin
        print "what a"
        print "fool"
      name equals "Frodo" ; begin
        print "what a"
        print "saviour"
      name equals "Alex" ; begin
        print "err..."
        print "who knows?"

1) Grant admin access to arclanguage.org to a high karma ranking Arc Forum member to update that painfully outdated home page OR update the home page appropriately, with added links to other Arc focused sites such as https://sites.google.com/site/arclanguagewiki/

2) Regarding modifying the current HN based forum:

a. A built in search utility, of course

b. Add 'popular' and 'sticky' tabs to the existing new | threads | comments, etc tabs.

- The 'popular' tab could be a pure karma based collection of the heaviest threads (sum of plus votes, in descending order).

- The 'sticky' tab should be threads created or selected by the admin, usually a collection of how tos, work arounds and frequently sought help. Order should be admin settable, and there should be an area above each thread where the admin can clearly highlight the purpose of the thread.

@akkartik, I realize anarki is bleeding edge. I'm just grateful I stumbled across it and that it's working :) I will revert to the official Arc 3.1 version if it turns out to be too bleeding edge for me.

Now that I've been able to read more threads on this forum, I realize I would have saved a lot of time had I done so earlier. I wouldn't have gone on that long loop with Clojure and Common Lisp.

I think the main problem starts with the Arc Forum | install page (http://arclanguage.org/install). The instructions still are:

"1. Install version 372 of MzScheme. (Don't use the latest version. Versions after 372 made lists immutable.) 2. Get http://ycombinator.com/arc/arc3.tar and untar it.

3. Type mzscheme -m -f as.scm and you should get an Arc prompt.

4. If you ^C an Arc program, you'll get the Scheme REPL. Use (tl) to get back to the Arc REPL.

5. If you have questions or suggestions, post them on the forum. "

I assumed, naturally, that the most prominent page on the forum dedicated to installing Arc would be current. Hence the inevitable install run around.

If either of you are admins here, or if any admin comes across this comment, I would suggest that the Arc Forum | Install page REALLY needs to be updated. A lot of interest in Arc will be killed by frustrating experiences at set up time.

I did visit http://sites.google.com/site/arclanguagewiki (in fact I'd already bookmarked it). However, the instructions there just cover a series of links and could do well with a more detailed instruction set, especially if it is to appear more useful than the Arc Forum install instructions I've referred to above.

It came as a surprise that HN serves directly off port 80- wonder how to they manage ssl from arc. I plan to serve via apache rewrite rules (reverse proxy)- and yes, sadly all ips in the arc logs show the local address. Thanks for this link. Also, who is that strange user on my logs (there are different names on different hosts)? :)