Thanks. I did notice ac.scm uses assign where as arcfn talks about 'set'. Anyway, I didn't implement neither assign nor set, not scar not scdr. I just implemented '=' as a special form.

Thanks for #3 btw, my '=' only worked with one variable before; now fixed.

Ah, sorry, typo; I meant b:~c

In arc:

  arc> (ssexpand 'a:b:~c)
  (compose a b (complement c))

  jsarc> (ssexpand 'a:b:~c)
  (compose a b (complement c))

I think closures already work; I just haven't tested them enough.

> How it works is that every function has an environment. This environment contains two bits of information: a mapping between variables and values, and a reference to the outer environment.

> Then, when looking up a variable, you start in the current environment, and if it's not found, you check in the outer environment. You then repeat this process as many times as necessary until you either find the variable, or reach the global scope.

  arc> (apply in (list 1 1 2 3))
  Error: "Can't coerce  #(tagged mac #<procedure: in>) fn"

  (eval `(in 1 ,@your_list))

  arc> (let a '(1 2 3 4) (eval `(in 1 ,@a)))
  t

Quoting from myself,

Quote syntax (as well as fexprs in general) lets you take code you've written use it as data, but it does little to assure you that any of that computation will happen at compile time. If you want some intensive calculation to happen at compile time, you have to do it in a way you know the compiler (as well as any compiler-like functionality you've defined) will be nice enough to constant-propagate and inline for you.

I've realized "compiler-like functionality you've defined" is much easier to create in a compiled language where the code-walking framework already exists than in an interpreted language where you have to make your own.

If part of a language's goal is to be great at syntax, it has a conflict of interest when it comes to fexprs. They're extremely elegant, but user libraries can't get very far beyond them (at least, without making isolated sublanguages). On the other hand, the dilemma can be resolved by seeing that an fexpr call can compile into a call to the fexpr interpreter. The compiler at the core may be less elegant, but the language code can have the best of both worlds.

This is an approach I hope will work for Penknife. In a way, Penknife's a compiled language in order to support fexpr libraries. I don't actually expect to support fexprs in the core, but I may write a library. Kernel-style fexprs really are elegant. ^_^

Speaking of such Kernel-like libraries, I've thrown together a sketch of a Kernel-like interpreter written in Arc. It's totally untested, but if the stars have aligned, it may only have a few crippling typos and omissions. :-p https://gist.github.com/778492

Hmm... not sure what you mean by this. I can define a local variable at the PicoLisp REPL using let just as I would in Arc:

  : x   
  -> NIL
  : (let x 5
      x)  
  -> 5
  : x     
  -> NIL

Speaking of speaking too soon, I may have said "user libraries can't get very far beyond [an fexpr language's core syntax]," but I want to add the disclaimer that there's no way I actually know that.

> This is a form of lexical scoping - though we still have dynamic binding - of symbols, similar to the static keyword in C. [1]

> "But with dynamic binding I cannot implement closures!" This is not true. Closures are a matter of scope, not of binding. [2]

---

[1] http://software-lab.de/doc/faq.html#problems

-

What happens when I locally bind a symbol which has a function definition?

That's not a good idea. The next time that function gets executed within the dynamic context the system may crash. Therefore we have a convention to use an upper case first letter for locally bound symbols:

  (de findCar (Car List)
     (when (member Car (cdr List))
        (list Car (car List)) ) )

  arc> (in 1 (list 1 2 3))
  nil
  arc> (in 1 2 3 1 5)
  t

  arc> (some 1 (list 1 2 3))
  t
  arc> (some 1 (list 2 3 4))
  nil
  arc> (some "a" (list "a" "b" "c"))
  t
  arc> (some "a" (list "r" "b" "k"))
  nil

You have a good point about the rendering oddities with whitespace. There's a lot of room for improvement here. Rendering hints would definitely be nice. For instance, <link> and <input> tag don't typically close themselves. And tags like <a> <b> <u> <em> should just print on a single line.

> I'm definitely a fan of this 'annotate approach to building HTML. I like the idea that as the framework gets more refined, it might be possible to output the same page as either HTML or XHTML with just a configuration change.

haha, I didn't quite think of this at the beginning. My 'render-html is completely decoupled from the building of the HTML. It's just one type of a printer, and it likes to pretty-print things for readability.

We could add easily imagine adding several more printers, and even a system for registering and choosing one, with 'render-html being merely an alias to the chosen one.

    (reg-html-renderer obfuscate-render 'obfuscate')
    (set-html-renderer 'obfuscate')

I have tag-by-tag hints in mine just in case I want two otherwise identical HTML tags to have different rendering behavior, for a browser hack or something. Eventually I do hope to have an 'html hint that causes the element's tag name to be looked up in the renderer's HTML specification of choice, but I may still want to leave that hint out occasionally just to have better control.

For that matter, I didn't know link and meta could have content.

I changed the rendering engine to print some tags inline and self-close some tags.

    (render-html (page 'title "Test" 'js "js.js" 'css "css.css" 
                   
                   (p "Hello world" (e 'em "emhasis!!!") "did you see that?")
                   (p "Btw, this is" (e 'a 'href "google.com" "mylink"))))


    <!doctype html>
    <html>
      <head>
        <title>Test</title>
        <script type="text/javascript" src="js.js"></script>
        <link rel="stylesheet" type="text/css" href="css.css" />
      </head>
      <body>
        <p>Hello world <em>emhasis!!!</em> did you see that?</p> 
        <p>Btw, this is <a href="google.com">mylink</a></p>
      </body>
    </html>

I sort of am, but only in the very long term. It can start as a tiny type that just holds its own specific special-casing behavior, and then it can grow in complexity as complexity is needed. That said, it may be difficult to predict what behavior is specific to a single HTML specification until one's tried to provide a choice between multiple specs.

I changed the rendering engine to print some tags inline and self-close some tags.

Awesome. :D

For that matter, I didn't know link and meta could have content.

They're not supposed to. (It would be interesting to look at the DOM to see if they can in practice.) I'm talking about when I might potentially want to give them content for a weird browser-specific hack.

The tag object is just a hashtable, you can always hack it and insert whatever custom attributes you want, and then use these as rendering hints in the rendering engine/function.

  (some-function a b c d e f g)

  (some-function a b c (d x) (g y))

Now of course, one could still write confusing code:

    (= word 'class)
    ; some pages later:
    (div word "class-name" "actual-content")

Looking at http://arclanguage.org/item?id=11697

It seems like Arc has no concept of scope.