<User>tl: 'x
  <User>x
  <User>tl: (using <arc>v3-packages)
  t
  <User>tl: (unpkg 'x)
  x

Personally I think it's better to do something like this:

  ($.mzscheme-function param1 param2)

  (mac $ (x)
    `(seval ',(<arc>unpkg x)))

  (using <asv>v1)

After all, not everyone will use Arc for web apps ^^

edit:

Also, as.scm attempts to precompile arc.arc into a scheme file. It loads those faster. I'm wondering if it would be possible to integrate the precompilation so that any 'using metacommand will precompile all libraries, just for the faster load times.

More stuff and commentary later.

No arc http server yet, arc http server will need to be ported somewhat due to symbol-based packages.

Need more docs.

Briefly, a "scanner" is any object that has methods defined for 'car and 'cdr (among other things, my Arc fork has/will have CLOS-style generic functions, but won't have inheritance; I'm trying to figure out whether I need inheritance at all in a duck-typed language, especially if I go the generics route for code reuse), and defines identity-function bindings for 'scanner and 'unscan.

'scanner usually throws an error (so that you can't map numbers, for example), but you can overload this for your type so that you return a valid scanner.

'unscan converts a scanner to the desired type.

Additionally, a user-defined type may overload two base functions, '<base>collect-on and '<base>each. Briefly, these functions construct a type iteratively ('<base>collect-on) and iterate over the type for as long as necessary ('<base>each - unlike 'each, this has an early out).

A type doesn't have to define '<base>collect-on and '<base>each, since they will work in terms of 'unscan (for '<base>collect-on) and in terms of 'scanner, 'car, and 'cdr (for '<base>each), but if your type doesn't look like a 'cons cell, it will probably be more efficient if you overload them for your type.

'each is defined in terms of '<base>each, and 'map (or more specifically, 'map1) is defined in terms of <base>collect-on and <base>each.

So yes: pretty much I'm just doing this from a different angle, i.e. typesystems and generic programming.

----- comments on your code:

  (let lazy-map map
    (= lazy-map
      (with-closure lazy-map 'cons lazy-cons)
       lazy-map
      (with-closure lazy-map 'map lazy-map)))

1. If with-closure is a nondestructive operation (returns a copy of the original function plus modifications), then what gets returned is this:

  (= lazy-map1 map)
  (= lazy-map2 (with-closure lazy-map1 'cons lazy-cons))
  (= lazy-map3 (with-closure lazy-map2 'map lazy-map2))
  (= lazy-map lazy-map3)

The proper solution would be:

  (= lazy-map nil)
  (= lazy-map-delay
     (fn rest
       (apply lazy-map rest)))
  (= lazy-map (with-closure (with-closure map 'cons lazy-cons) 'map lazy-map-delay))

3. With-closure is a special form with call-by-name semantics for its third argument.

   (let lexical-var value
      (with-closure function 'name lexical-var)
      (= lexical-var anothervalue))

Um. There's no such thing.

The arc-on-mzscheme implementation uses mzscheme functions for its own functions. What I mean is, something like this:

  (fn (x) x)

  (lambda (x) x)

And true first-class macros will still remain very difficult.

You might be interested in my discussions with shader about how true first-class macros make it very hard to write efficient interpreters, must less even lousy compilers. http://arclanguage.com/item?id=8015

Of course you are free to design and implement any language you want, and I know you've probably been the main contributor.

But I think the original spirit of Arc was to design a simpler language even if it couldn't be implemented as efficiently:

(Quoting pg, The Hundred-Year Language):

For example:

  <User>tl: +
  #<procedure>
  <User>tl: (list +)
  (#4(l-reductor #<procedure> #<procedure> #<procedure>))

Also, overloading <base>+ is simpler: <base>+ only requires that you consider the case of adding two objects. + determines how to handle things when you do (+ foo1 foo2 foo3 foo4), specifically it converts the call to (<base>+ (<base>+ (<base>+ foo1 foo2) foo3) foo4)

  arc> (int->str 1 10)
  "00000000001"
  arc> (int->str 10 10)
  "00000000010"
  arc> (int->str 11 10)
  "00000000011"
  arc> (int->str 100 10)
  "100"

  (def pad (val digits (o char #\ ))
    (= val (string val))
    (string (n-of (- digits (len val)) char) val))

Do you mind if I put a simplified BSD license on the Arc-F section of the arc-book?

"The Arc Cookbook", "Practical Arc"?

> TeX, HTML, Markdown?

This is what I do every week.

LOL.

I need a girlfriend wahahahahahaha

t and nil are now boolean types, not symbols. Sorry. It's hard to reason about them with the newfangled type-based methods if they're symbol types instead of booleans.

Also, because of contexting, asv.arc will have to be rewritten so that it unpackages symbols in (defop ...) and related forms. If it's not rewritten, you'll have to use example.com/%3CUser%3Cyour-page instead of example.com/your-page . I think most asv-based applications will work properly if asv.arc is modded thus.

Also, most of your source files will probably need something like:

  (in-package my-file)
  (using <arc>v3)

Note that <arc>v3 does not even include all arc functions (for example <arc>v3-thread, which includes the threading stuff). There are some rationales for not including everything in <arc>v3, most notably for bits and pieces that are reasonably hard for other implementations, such as threads.

Also, the fork is somewhat slower, especially for function calls T.T . So far I haven't experienced particularly serious slowdowns (due to some serious crazy optimizations in ac.scm that were mostly inspired by my experimentations with implementing the SNAP interpreter).

However the fork does have nice advantages. For example, it has generic functions with methods. So far it's just the ordinary dispatch-on-first-argument-type but I hope to expand that in the future to create full-blown generic functions with dispatch-on-any-combination-of-argument-type.

Also, it's now much easier to integrate your own types into the base arc.arc . For example you can create your own sequence types which will work with 'map, 'join etc. Those functions will even return your type, i.e. map on your type will return the same type. Generic programming FTW!

And of course, packages, whose integration was the biggest headache in the fork T.T . Largely because I decided that everything that gets passed to the compiler should already be in packages; this includes fn -> <axiom>fn etc.

It can be launched from any directory, and will remain in that directory when you program, unlike Anarki which always cd's to the installation directory (but it will auto-search the installation directory for any 'load calls you make)

I think pack.arc is nice enough to integrate into ac.scm and arc.arc (at the very least the package loading part; you can probably still retain the bit that creates packages into pack.arc, since it'll probably be used rarely enough)

  "t and nil are now boolean types, not symbols. Sorry. It's hard to reason about them with the newfangled type-based methods if they're symbol types instead of booleans."

'car and 'cdr are now overloadable - see for example lazy-scanner.arc in arc-f/lib .

However classically (car nil) => nil and (cdr nil) => nil.

So basically we have something like this:

  (def car (x)
    (err "can't apply 'car to object" x))

  (defm car ((t x cons))
    ...some scheme-side code....)

  (defm car ((t x bool))
    (if x
        (err "attempt to scan t")
        nil))

From this point of view, a "list" is anything that happens to be a scanner.

So nil is a list. So are 'cons cells. So are anything that overloads 'scanner, 'unscan, 'car, and 'cdr.

Try:

  (using <lazy-scanner>v1)

Or for a bit of ease of use generate an infinite list of positive integers (after doing the 'using thing):

  (generate [+ _ 1] 1)

However if you mean "list" as in sequence of cons cells:

  (def works-on-cons-cells-and-bools (x)
    (err "this works only on cons cells and bools!"))
  (defm works-on-cons-cells-and-bools ((t x cons))
    (work-on-cons-cells x))
  (defm works-on-cons-cells-and-bools ((t x bool))
    (work-on-bool x))

  (def hooper (x)
    (err "Not convertible to a bool or cons cell" x))
  (defm hooper ((t x cons))
    x)
  (defm hooper ((t x bool))
    x)

  (def work-on-hooper (x)
    (works-on-cons-cells-and-bools (hooper x)))

choice one:

  (defm hooper ((t x my-type))
    (convert-my-type-to-cons x))

  (defm hooper ((t x my-type))
    x)
  (defm works-on-cons-cells-and-bools ((t x my-type))
    (work-on-my-type x))

  (thread
    (while t
      (pack-build-cache)
      (sleep 1000)))

LOL.

  (breakable:map
    [when odd._
          (break _)]
    *list-of-numbers*)

I suggest you turn 'focus into say 'focusable so that the extra variable ref can be dropped and we can abuse the : syntax:

  (focusable:map
    [and odd._
         (or (no (focus))
              (< (focus) _))
         (focus _)]
    *list-of-numbers*)