Magpie has a precedence system with its multimethods:

  foo <- X Y Z -> X + Y + Z

  n |<- 0

One problem with this super-simple system is that I wasn't able to figure out how functions fit into it... And fexprs just seemed to really muck things up even worse, and it's just a big pain and all.

But I wasn't really able to get rid of fexprs, or to be more specific, I couldn't find a better idea. Haskell has all this loveliness going on by using functions for pretty much everything, but I want to try a different route. I want to see how far I can push a functional OOP language with immutable objects and gensyms.

So for now, here's the plan. $vau will have to be built-in (duh) but using this system, it could in principle be written in user-land, provided you had a few other primitives like $quote, each, etc.

$vau will return an object. This object has a %call property, which lets you specify custom behavior when calling an object. This %call property is actually another object, which has an %argument, %environment, %body, and %closure properties.

Each property is a Nulan datatype, like an object or number or whatever, so this avoids the problem of using native JavaScript functions (I don't want to expose native things to Nulan that have the same purpose as Nulan data types, unless the reason is for speed).

That means that this vau:

  ($vau E [Args Body]
    (wrap (eval E [$vau ~ Args Body])))

  { %call { %argument    ($quote [Args Body])
            %environment ($quote E)
            %body        ($quote (wrap (eval E [$vau ~ Args Body])))
            %closure     ... }}

It also lets you attach arbitrary properties to vaus. Including other things, this means that (in principle) you can implement "wrap" in user-land:

  $def %wrapped (uniq)

  $def wrap
    $vau E [F]
      $let F (eval E F)
        { @($vau E X
             (F (each X; X -> (eval E X))))
          %wrapped F }

  $def $fn
    $vau E [Args Body]
      wrap (eval E [$vau ~ Args Body])

  $def unwrap
    $fn [{ %wrapped F }]
      F

It'll be interesting to see how these immutable objects combine with the functional/recursive style of Nulan.

---

  : creates a new list that continues until either ; or ( or ) is encountered
  ; creates a new list that continues until either ; or ) is encountered

  foo: bar: qux; corge -> (foo (bar (qux)) (corge))
  foo: bar; qux; corge -> (foo (bar) (qux) (corge))
  foo: bar: qux: corge -> (foo (bar (qux (corge))))
  foo: bar (qux corge) -> (foo (bar) (qux corge))

  : now terminates on (

  ; creates a new list in addition to terminating all previous : and ;
     (before, it only terminated and didn't create a new list)

  ; now terminates ; in addition to :

   mac accessor -> n v
     uniqs %a
       {def n -> %a
         {{%a v} %a}}

   def or: casevau env
     x    -> (eval x)
     x @r -> let x (eval x)
               if x x (eval {or @r})

  $mac accessor; N V ->
    $uniqs %A
      [$def N; %A ->
        [[%A V] %A]]

  $defvau $or Env
    X    -> eval X
    X @R -> $let X: eval X
              $if X X: eval [$or @R]

foo; bar; qux ;corge (foo(bar(qux))corge

foo; something is foo(something)

  and: foo 1; bar 2; qux 3 -> (and (foo 1) (bar 2) (qux 3))

Now that I'm more lenient toward parens, I'll probably simplify ":" and get rid of ";"

---

There is one other situation where I use ";" in Nulan: functions that continue on the next line:

  $def foo; X Y ->
    ...

  def foo -> x y
    ...

I don't think so. Nulan completely ditched Arc's ssyntax and only uses significant whitespace, ":" and ";". Yet, despite that, it's capable of getting rid of almost all parentheses.

Racket has this built-in (scroll down to "case-lambda"):

http://docs.racket-lang.org/reference/lambda.html?q=case-lam...)

It's not hard to write a macro in Arc/Nu that uses Racket's case-lambda, and in fact I had a semi-working version, but I gave that up when I started work on Nulan.

Unlike Arc, Nulan doesn't have optional args, so you have to use arity overloading:

  $def foo
    X Y -> X + Y       # 2 argument version
    X   -> (foo X 10)  # 1 argument version: default for Y is 10

  $def foo
    X (opt Y 10) -> X + Y

- Numbers and strings can be types. You already talk about using numbers as keys (aka types) for array access, so it's a bit surprising you haven't mentioned this option yourself.

- Numbers and strings can be objects whose types happen to be out of scope in user code. As far as the programmer is concerned, the core utilities were constructed with those types in scope, so it makes sense for them to be able to reach inside. I like the thought of everything being a weak table (and this philosophy underlies my garbage collector, Cairntaker), so this is the kind of choice I would make.

Hm... I suppose that might work... yeah you're right that might be a really good idea. Thanks, I didn't think about that. But... hm... I wonder if that'll really work...

---

"Numbers and strings can be objects whose types happen to be out of scope in user code."

That's the problem. If I create the object using an ordinary closure to hide the data, how do I actually get the data when doing things like "lt" and "is" comparisons? I'd have to store it in the object itself, in which case now it's exposed to user code.

---

"Numbers and strings can be functions. Why not? :-p"

If the type is out of scope in user code, then there's nothing user code can do to extract that value, right? The user code can't extract a list of types for an object, can it?

---

"Because I'm trying to make a clean separation between data and algorithm. Though I already blur that a little by making $vau return an object. Plus I'm not sure how I'd implement that anyways, could you give an example?"

I don't know what numbers and strings would do as functions, but they could potentially take a secret key and return some other internal representation. This secret key would not be in scope in user code. ;)

I was thinking about letting code loop through an object, similar to the "for ... in" loop in JavaScript. An example of where that would be helpful is map, filter, etc.

If I gave that up, then, sure, I could store it in the object and user code wouldn't be able to reach it.

---

"Of course, if user code can inspect lexical closure data anyway, it's impossible to hide things this way. I kinda recommend making the %closure key mean "the lexical closure, or nil if it happens to be unavailable.""

That's right. I think if I'm going to go the "everything is an object" way, then I want everything to be open. Of course, I might change my mind and try some other route...

I think I've figured out what it is that I want in a programming language, at least at a high level. I want a programming language that's basically like Lego blocks. You have these little atomic pieces that are useful in and of themself, but because they share a similar interface, you can plug them together to create bigger pieces.

In other words, it's the Unix philosophy of "write programs that do one thing and do it well" as well as the functional philosophy of "avoiding state". The reason for this is to be able to treat the program as a black box that can be plugged into other black boxes to get the behavior.

I've given up on extensibility and being able to hack other people's code. Why? If their code is insufficient, it's probably easier to just rewrite it from scratch anyways. As long as the new code has the same interface as the old code, it'll work just fine.

Haskell's Monads are quite elegant. This is the best tutorial I've found thus far about them: http://mvanier.livejournal.com/3917.html

Okay, I think I got it really figured out. Symbols and numbers will be atomic. Everything else is a tree: strings will be a list of symbols.

I'll have gensyms too, which are atomic like symbols, but are unique. It would be possible to build gensyms using just numbers + trees, but I think it's more consistent to make them atomic, since they're a kind of symbol.