I always thought that was just because Scheme tries to be minimal, and using the single special-form "define" for two different purposes helps with that. Scheme also does two different things with "let":

  (let ((foo ...)) ...)

  (let foo ((bar ...)) ...)

  {foo x y z} -> ...
  {bar x y z} -> ...
  {~   x y z} -> ...

  -> x y z (+ x y z)

  (fn (x y z) (+ x y z))

  # Nulan
  (def foo -> a b c ...)
  (def foo 5)

  ; Arc
  (= foo (fn (a b c) ...))
  (= foo 5)

How about a language that's like Haskell/Shen: currying everywhere. This language would be based heavily on functions, of course, which are expressed with "->" as follows:

  foo %x -> %x + 2

  (def foo (x) (+ x 2))

As a quick test of this system, I went through some semi-contrived examples taken from http://en.wikipedia.org/wiki/Duck_typing

  class Duck:
    def quack(self):
      print("Quack")
    def fly(self):
      print("Flap, Flap")
   
  class Person:
    def __init__(self, name):
      self.name = name
    def quack(self):
      print("{} walks in the forest and imitates ducks to draw them".format(self.name))
    def fly(self):
      print("{} takes an airplane".format(self.name))
   
  def quack_and_fly(duck):
    duck.quack()
    duck.fly()
   
  quack_and_fly(Duck())
  quack_and_fly(Person("Jules Verne"))

  duck ->
    [ quack -> prn "Quack"
      fly   -> prn "Flap, Flap" ]

  person %n ->
    [ quack -> prn "@%n walks in the forest and imitates ducks to draw them"
      fly   -> prn "@%n takes an airplane" ]

  quack-and-fly [ quack %q fly %f ] -> %q; %f

  quack-and-fly duck
  quack-and-fly person "Jules Verne"

If you wanted to, you could use parens like Shen instead of no-parens like Haskell.

Some downsides? Well, since it's using currying, there could be some issues with that. In particular, variable argument functions wouldn't be possible. There's also potentially some scoping issues and such.

  [ foo = 5 | bar = 10 ]

  pattern = [ foo = 5 | bar = 10 ]

  pattern [ foo ]
  pattern [ bar ]

  pattern [ foo | bar ]

Also, in Haskell you might write this:

  fib 0 = 0
  fib 1 = 1
  fib n = fib (n-1) + fib (n-2)

  [ fib  0 = 0
  | fib  1 = 1
  | fib %n = fib (%n - 1) + fib (%n - 2) ]

  duck =
    quack = prn "Quack"
    fly   = prn "Flap, Flap"

  person %n =
    quack = prn "@%n walks in the forest and imitates ducks to draw them"
    fly   = prn "@%n takes an airplane"

  quack-and-fly %x = %x quack; %x fly

  quack-and-fly: duck
  quack-and-fly: person "Jules Verne"

  (duck) ->
    [ quack -> (prn "Quack")
      fly   -> (prn "Flap, Flap") ]

  (person %n) ->
    [ quack -> (prn "@%n walks in the forest and imitates ducks to draw them")
      fly   -> (prn "@%n takes an airplane") ]

  (quack-and-fly [ quack %q fly %f ]) -> (%q); (%f)

  (quack-and-fly (duck))
  (quack-and-fly (person "Jules Verne"))

  duck =
    [ quack = (prn "Quack")
      fly   = (prn "Flap, Flap") ]

  person %n =
    [ quack = (prn "@%n walks in the forest and imitates ducks to draw them")
      fly   = (prn "@%n takes an airplane") ]

  quack-and-fly [ quack %q fly %f ] = %q; %f

  quack-and-fly duck
  quack-and-fly person "Jules Verne"

  quack-and-fly person "Jules Verne"

  quack-and-fly (person "Jules Verne")

No, that's a reasonable way to solve it. But I still would like optional args, variable args, and vaus. Wheee a dynamic Haskell with vaus~

Hmm... with a little syntax, you could write this:

  quack-and-fly: person "Jules Verne"

When wart sees a symbol that is punctuation, it treats it as an infix operator, so that (a + b) and (a = b) work, etc.

As for :case, that's basically equivalent to "extend" in Arc. In other words, in Arc you write this:

  (extend foo ... (bar ...))

  def foo ... :case (bar ...)

---

So, if you put it all together, that means this:

  def (a = b)
    ..

  (def = (a b)
    ..)

And this:

  mac (lhs <- rhs) :case list?.lhs
    ..

  (mac <- (lhs rhs)
    (when (list? lhs)
      ..))

I would have to get used to not always seeing the function name first, but I like the symmetry this produces between definition and call.

Added: So when wart got infix (http://arclanguage.org/item?id=16775), Kartik gave this example for defining your own infix ops:

  def (<>) (a b)
    (~iso a b)

  def (a <> b)
    (~iso a b)

  ; Arc
  (mac and args
    (if args
        (if (cdr args)
            `(if ,(car args) (and ,@(cdr args)))
            (car args))
        't))

  ; Shen
  (defmacro andmacro
    [and]       -> true
    [and X]     -> X
    [and X | R] -> [if X [and | R]])

  (defmacro twomacro
    2 -> 2.5)

---

So, does that mean Lisps are "less powerful" because they tend to use a single data structure (cons) for everything? I think there is a lot of power in simplicity and using a single thing to represent everything else.

Certainly static type systems can let you write different programs than dynamic languages: staticness gives you certain powers that you don't have in dynamic languages. But I would argue that dynamic languages, precisely because they lump everything into a single static type, can have certain benefits as well.

---

"For another, you are imposing a serious bit of run-time overhead to represent the class itself (a tag of some sort) and to check and remove and apply the class tag on the value each time it is used."

Indeed. Static languages are well known to be faster than dynamic languages because they have more information at compile-time. Old news. Oh wait, we've developed JIT compilers that can make dynamic languages go astonishingly fast, so the old "performance" argument is a lot weaker nowadays.

---

I don't think I'd have a problem with a language that was dynamic by default but lets you specify optional static types. I think that would be the best of both worlds. Unfortunately, the languages that have good static type systems (Haskell, ML, etc.) tend to also emphasize staticness everywhere, requiring you to jump through some hoops to enable dynamicism.

That reminded me of Steve Yegge's liberal/conservative spectrum: http://plus.google.com/110981030061712822816/posts/KaSKeg4vQ...; http://plus.google.com/110981030061712822816/posts/iuRbQe6Eo...

  ;

  foo;
  bar;
  qux;

---

I don't understand that interpretation. If the last semicolon is its own statement, where's the semicolon that separates it from the previous statement?

  01 nu.rkt
  02 arc.arc
  03 utils.arc
  04 parameters.arc
  05 paths.arc
  06 import.arc
  07 repl.arc

They are loaded in numeric order, but that's controlled by the "arc" executable, so there's nothing stopping you from changing the order, or adding new non-numeric files[1], etc.

Everything else is put into either the "app" or "lib" folder, and none of the files in either folder are numbered.

This means the numbers are purely for documentation purposes, to help people see which parts go where. In particular, changing the numbers doesn't change the order in which things are loaded: you need to make the changes in the "arc" executable.

I think this is a good blend between not being too cumbersome, improving the visibility of order (which matters), and allowing fine-grained control of order.

---

As an experiment I've added a script that creates more mnemonic symlinks to all the files in the repo:

  $ git clone http://github.com/akkartik/wart.git
  $ cd wart
  $ git checkout 8332909aec  # Unnecessary except for visitors in the far future
  $ ./denum                  # New helper
  $ vim -O assign.wart mutate.wart  # etc.

- denum doesn't seem to work with plain /bin/sh,

  ./denum: 9: ./denum: [[: not found

- Slight nitpick over your perl regex:

  $ echo '(prn "hail satan")' > 666thedarklordcometh666.wart
  $ ls | grep thedarklordcometh
  666thedarklordcometh666.wart
  $ ./denum
  $ ls | grep thedarklordcometh
  666thedarklordcometh666.wart
  thedarklordcometh.wart

  s/^[0-9]*//

  find . maxdepth 1 -type l -exec rm {} \;

It's not just wart: readable has the same issue. The problem is that you don't know if the user is finished or if they want to enter a multi-line expression. With parentheses, you always know whether the expression is completed or not, but with whitespace, you don't.

The same is true even in Python. If you type in this:

  >>> def foo(x):
  ...   return x

  >>> 1 + 2

You could require that the user provide an order when defining a new pattern.

---

My idea with Nulan is that functions shouldn't change: they should be static algorithms. Thus, Nulan doesn't allow you to overload functions like you can in Arc or Wart. Instead, if you wish to overload a function, you define a new gensym which can be stuck into any object to overload it:

  $def %foo (uniq)

  $def foo
    { %foo F } -> ...
    ...        -> ...

This gives complete control to the function to decide whether it can be overloaded or not, and exactly how the overloading happens. I think this is the most flexible approach I've ever seen.

As a more concrete example, objects can have a %len key to define a custom (len ...) behavior, an %eval key for custom evaluation behavior, %call for custom call behavior, %pattern-match for custom pattern match behavior, etc.

And because of the way pattern matching works, you can even match against multiple gensyms at once:

  $def %foo (uniq)
  $def %bar (uniq)

  $def foo
    { %foo F
      %bar G } -> ...
    { %foo F } -> ...
    { %bar G } -> ...
    ...        -> ...

---

"So, how do I manipulate quotes in macroexpansions, as needed in qq.wart?"

I think hardcoding symbols (like in quasiquote) is a terrible idea, so I would just not define quasiquote. Instead, I'd use Arc/Nu quasisyntax, which doesn't use quote at all:

  `(foo bar qux)   -> (list foo bar qux)
  `(foo (bar) qux) -> (list foo (list bar) qux)

  `(foo ,'bar qux) -> (list foo (quote bar) qux)

Interesting idea, but the proper mechanism for it eludes me.

- You could have the user give a precedence level, since integers are totally ordered, but that's a terrible idea---magic constants in every generic declaration. Any more restricted domain (e.g., specifying high, medium, or low precedence) gets a little vague.

- You could have a simpler mechanism where each new rule is added to a known, fixed location in the linearization. So basically the order is a double-ended queue and generic declarations have keywords for "push me to the front" or "push me to the back". But that's probably a bit too basic, and still relies on declaration order (in fact, complicating it).

- You could have the user specify a previously-declared chunk of code to execute first, like

  def g(x)
    (prn "default")

  def g(x) :case (odd? x)
    (prn "odd")

  def g(x) :case (x = 1) :before (odd? x)
    (prn "one")

- I'm really scraping the bottom of the barrel now...Have the user supply their own predicate that determines which generic to apply first? Which means the user basically has to implement their own customized partial-order. I really don't see that happening.

I think this is similar to Inform 7's approach, where rules can be referred to by name. Generally, every rule in a library has a name, but individual stories omit them unless necessary.

---

"- I'm really scraping the bottom of the barrel now...Have the user supply their own predicate that determines which generic to apply first? Which means the user basically has to implement their own customized partial-order. I really don't see that happening."

That's the approach I took in Lathe a long time ago.[1] Under my approach, the partial order is itself extensible, and it even determines the ordering of its own extensions. I quite like the expressiveness of this approach, but this expressiveness is barely meaningful for in-the-large programming: In order for the precedence rule programmer to have enough information to make judgments by, they need to require all other programmers to annotate their extensions with appropriate metadata. That or they need to maintain their own up-to-date metadata describing common libraries! Instead of programming language battles, we get framework battles full of boilerplate.

Since finishing that system, I've been pondering the "framework" conventions I'd like to use myself, and I've been trying to fold those decisions into the core of a language design.

Whereas Magpie and many other multimethod systems make a big deal about subclasses, I try to avoid any kind of programming where almost all X's do Xfoo, but some X's are also Z's so they do Zfoo instead. By the same principle, I'd avoid the [odd? _] vs. [= 1 _] case altogether. If fact, as long as I succeed in formulating in the non-overlapping designs I like, I avoid the need for precedence rules altogether... but it's still an option I keep in mind just in case.

Currently, I favor supporting extensibility by way of sealer/unsealer pairs and first-class (multi)sets.

Sealer/unsealer pairs work when each extension is an all new range of possibilities. In Arc, I'd just represent these as tagged values, and I wouldn't bother to pursue the secure encapsulation associated with sealer/unsealer pairs. In linear logic, the additive operators describe this kind of combination.

First-class (multi)sets work for when each extension is a new participant in a single computation. In Arc, a list is a good representation for this. In linear logic, the multiplicative operators describe this kind of combination.

When precedence is necessary, it can be modeled explicitly as a transformation of a (multi)set into a more structured model. I think any programmer who makes an extensible tool should carefully choose a transformation that makes sense for their own purposes--whether it's really "precedence" or something else.

---

"For general predicates, instead of hard-coding an order I'd rather use a big if/case/pattern-match that I at least know is ordered the way I wrote it."

That's my take on it, too. My examples of multi-rule functions have included factorial and exponentiation-by-squaring, but those are unrealistic. There's no reason for an extension to come interfere in that process, so it might as well be the body of a single declaration.

When I was using predicate dispatch more often, I often discovered that I could satisfy most of my use cases with just two extension annotations:

- This is the real meaning of the function, and all the other cases are just for auto-coercion of parameters into the expected format. Use this extension first. (This came up when implementing 'iso in terms of 'is, and it also makes sense for coercion functions themselves, such as 'testify.)

- This extension is the last resort. Use it last. (Maybe it throws an informative error, or maybe it returns false when everything else returns true. This also works for all-accepting coercion functions like 'testify, but I'm suspicious of this kind of design. A call to 'testify always does Xfoo, except when it does Zfoo.)

---

If Nulan had multimethods, I'd probably just require programmers to add additional metadata to the object in addition to the %pattern-match gensym. But Nulan doesn't have linearization or multimethods, so I avoid that whole mess!

---

"Whereas Magpie and many other multimethod systems make a big deal about subclasses"

And I have to agree: objects are amazing, but classes and subclasses are terrible. In fact, I'm of the opinion that probably all hierarchial relationships are too restrictive. Hence Nulan's object system which is completely flat, but has pretty much all the benefits of classes/prototypes.

Obviously that kind of system wouldn't work in wart where predicate dispatch is based on arbitrary function calls. Hence my idea in Nulan of not allowing function mutation. I would write the above code like this:

  $def g
    1        -> (prn "one")
    (odd? X) -> (prn "odd")
    ~        -> (prn "default")

  (def g (x)
    (if (is x 1)
          (prn "one")
        (odd? x)
          (prn "odd")
        (prn "default")))

One possibility is to pin a clause at the front:

  def g(x) :priority-case (x = 1)
    (prn "one")

  (def queue () (list nil nil 0))
  (def qlen (q) (q 2))

  $def queue; ->
    [[] [] 0
      @{ %len: X -> (X 2) }]

  (def queue ()
    (array nil nil 0
      @(dict %len (fn (x) (x 2)))))

  (w/uniq (len left right)
    (def queue ()
      (dict %len  (fn (x) (x len))
            len   0
            left  nil
            right nil)))

In either case, the object that is returned has a %len property, which is a function that computes the length. The "len" function would then be defined like this:

  (def len (x)
    ((x %len) x))

---

* [1]: You might be wondering what's going on here... well, in Nulan, a "list" is just like a JavaScript array: it's an ordinary object which uses numeric keys and has a custom %len property. In particular, that means that all the tools that work on objects work on arrays too.

The @ syntax is used for splicing. So, for instance, to merge 3 objects together, you'd say { @foo @bar @qux }. And because arrays are objects too, you can splice them.

So what we're doing is, we first create an array of 3 elements, and we then splice in a new object. This new object has a custom %len property, which overrides the %len property of the array.

Alternatively, we could have done it like this:

  (set (array nil nil 0) %len ...)

  { @[[] [] 0]
    %len ... }

  [[] [] 0
    @{ %len ... }]

Anyways, JavaScript gets around this problem by allowing you to define a property on an object that is "non-enumerable". But any kind of system that I add in that lets you define "non-enumerable" properties is going to be big and complicated.

Instead, I found a very simple way to create enumerable objects in a way that is completely customizable, and doesn't even need to be built-in:

  (= %keys (uniq))
  
  (def iterable-object ()
    (let keys []
      { %set  (fn (x k v)
                (pushnew k keys))
        %rem  (fn (x k)
                (pull k v))
        %keys (fn (x) keys) }))

The function "iterable-object" returns a new object that has custom %set, %rem, and %keys properties:

%set is called when assigning a property to the object. It takes the key and pushes it into the "keys" array.

%rem is called when deleting a property from the object. It takes the key and removes it from the "keys" array.

%keys just returns the "keys" array.

Now, these objects are capable of being enumerated, which means they could be passed to "map", for instance. But here's the fun part: you can completely control which properties are enumerated and which aren't.

In this case, the object will only enumerate properties that are added or removed after the object is created. So any properties defined previously are still hidden. At least, depending on how I implement splicing and %set...

---

  $def iterable-object ->
    [ %set  -> x k o n
              [ @x %keys -> ~ (pushnew (keys x) k) ]
      %rem  -> x k o
              [ @x %keys -> ~ (pull (keys x) k) ]
      %keys -> ~ {} ]

1) {} is closer to () than [] is, which is really nice in macros:

  $mac $accessor -> n v
    $uniq %a
      {$def n -> %a
        {{%a v} %a}}

---

By the way, in case you're curious about the Nulan syntax... $ is prefixed to vau/macros, which is why it's "$def" rather than "def"

-> is the function macro, which means (-> x y z ...) is equivalent to (fn (x y z) ...) in Arc

~ is the "wildcard syntax" which matches anything, just like _ in Haskell

[ foo bar ] translates to (dict foo bar), and { 1 2 3 } translates to (array 1 2 3)

@ is for splicing. Which means that [ @foo @bar @qux ] merges three objects into one. If you want to update an object with new properties, it's idiomatic to say [ @foo ... ]

  var iterableObject = function () {
    var a = {};
    a.set = function (x, k, o, n) {
      var a = Object.create(x);
      a.keys = function () {
        return pushnew(keys(x), k)
      }
    };
    a.rem = function (x, k, o) {
      var a = Object.create(x);
      a.keys = function () {
        return pull(keys(x), k)
      }
    };
    a.keys = function () {
      return []
    };
    return a
  }