The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.

The Clojure version of Norvig's spelling corrector appears to be one line shorter than Norvig's Python version:

http://arclanguage.com/item?id=8554

I would really like to see an Arc version of that. I translated Norvig's Python version to Ruby easily, so I expect that someone fluent in Arc could do it easily.

The other Lisp versions I've seen (Scheme/Common Lisp) were quite a bit longer and less elegant IMO.

I'm not super excited about Clojure's dependence on the JVM, but on the other hand, that gives it a huge head start with libraries and state of the art VM/JIT technology.

Rich Hickey doesn't seem to have the star power of pg, but he is very involved in the language and community. He seems like more of a Matz or Guido which doesn't seem that bad - he seems quite sharp in his web cast presentations.

However, in my opinion (and I'm a nobody so you may want to stop reading here), the arc core as well as some of the code that ships with it (news.arc, blog.arc, html.arc) rank amongst the best examples of working lisp code that highlight the power of lisp. news.arc is a great example of the use of macros and arc.arc is a great example of the power of embedded languages (feel free to point out better). To say nothing of the fact that this stuff is simply beautiful in a way I don't get from script-fu, elisp (slime being the one exception), edi weitz libraries, SICP etc. (it probl has something to do with how concise arc is).

1) How long was it between you first hearing about Arc, and you seeing the first prototype? For me, it was a long time. Expect similar changes to happen along similar timeframes.

2) Arc is a Lisp: a language notorious for community fragmentation and trivially incompatible implementations. Without a strong, active leader, expect more of the same.

Mutation. It's one thing to allow functional programming. It's another thing to force it.

The only thing constant is change.

> * The read table is currently not accessible to user programs

Neither does Arc, although Anarki does allow redefining of 'ssyntax and 'ssexpand, which almost gives you the same thing.

IMO not giving access to the read table is a good thing. There are very subtle problems with this, starting with: the read table affects all code loaded after the readtable modification.

It affects them whether or not the code was written by you, and whether or not it was written with that readtable definition in mind.

This can cause unfortunate library breakage when two libraries try to modify the same readtable entry; the poor user is thus left at the mercy of which library loaded last.

In fact Arc-F has revoked Anarki's feature which allows 'ssyntax and 'ssexpand to be modified; redefine them all you want, Arc-F will use the built-in traditional 4 ssyntaxes : ~ ! .

HOWEVER, there are currently two reserved context metacommands which will eventually allow ssyntax redefinition at the level of the individual file: 'import-ssyntax and 'interface-ssyntax.

The important thing is that they are context-based, and because they are context-based, they are not global and they will (in general) affect only one loaded file.

> * Keywords are not Symbols

Unimportant - salt to taste.

> * Symbols are not storage locations (see Var) > * immutable data

Side effect (LOL) of the enforced FP.

> * first is clojure's car ;)

  This software is copyright (c) Paul Graham and Robert Morris.  Permission
  to use it is granted under the Perl Foundations's Artistic License 2.0.

It's a bit late/early and IANAL, but my reading of the Artistic License is that we are OK given section 4. Section 4 says that we can distribute modified versions of the source provided we document the differences and either: (a) make the modified version available to the original creator under the original license; (b) ensure that one can install both the modified and original versions separately and that the modified one has a different name; or (c) allow redistribution of the source under either this license or another free license. We're definitely doing (a) and (c) and we're probably doing (b), so if I understand this correctly, we should be in the clear.

I think I will be dead in 100 years.

> I'm not sure if there is any good way to solve this dilemma

anywho, i took a glance at the code. i know you're going for performance so maybe that affected the mechanisms you used, but here's some suggestions anyways:

* Lua's string concatenation operator is .., as in

  return "str1" .. "str2"

  local tinsert = table.insert

* string.gsub might be faster than iterated replacement

* a key in a table can be anything, even functions and other tables, for the hex2int you can therefore have something like:

  { ["1"] = 1, ["2"] = 2, ... ["a"] = 10 }

* as far as ipairs is concerned, a nil value signifies the end of a table, so if you have:

  { 1, 2, nil, 3, 4 }

* table.concat might be useful somewheres

* a map-like function where on each iteration you return not just a value, but a key-value pair might be useful. eg pretending you don't care about performance, reverse could be written:

  function reverse( a )
      local len = #a
      return tblmap( a, function( k, v )
          return len-k+1, v
      end )
  end

* one way i've set up bi-directional tables before is with __call. in that form, tbl[key] would access one way, and tbl(key) would access it in reverse. another option is something like tbl[1][key]/tbl[-1][key]. depending on how you're using the table, you can memoize in one of the directions and/or set up some sort of little database hidden behind that single table

* Lua doesn't have macros, but it does have first-class environments. among many other things this means it has anaphoric macro-like capabilities, except for the need to pass in expressions through closures or strings. take for example these lines from luarc.lua:

  local sep     = sep or ' '
  local pattern = string.format ('[^%s]+', sep)
  local f       = string.gmatch (s, pattern)
  local match   = f()

  function seq( ... )
      local that = nil
      local original_env = getfenv( select( 1, ... ) )
  
      for i = 1, select( '#', ... ) do
          local fn = select( i, ... )
  
          local new_env = { ["that"] = that }
  
          -- have new environment inherit from old, otherwise
          -- any global variables used in the fns will be unavailabe
          setmetatable( new_env, { __index = original_env } )
  
          setfenv( fn, new_env )
  
          that = fn()
      end
  
      return that
  end

  function seq( ... )
      local that = nil
  
      for i = 1, select( '#', ... ) do
          local fn = select( i, ... )
  
          that = with( { ["that"] = that }, fn )()
      end
  
      return that
  end

  local match = seq(
      function() return sep or " " end,
      function() return string.format( "[^%s]+", that ) end,
      function() return string.gmatch( s, that ) end,
      function() return that() end )

  do
      local test_env = {}
  
      local i = 0
      setmetatable( test_env, { __index = function( tbl, var )
          if var == "var" then
              i = i + 1
              return i
          else
              return _G[var]
          end
      end } )
  
      setfenv( 0, test_env )
  end


  > print( var )
  1
  > print( var )
  2
  > print( var )
  3

http://www.lua.org/manual/5.1/manual.html

Strings may have gotten grandfathered into this behavior because they were thought of as similar to symbols.

  "do we really want is to ret t for distinct strings?"

Moreover, my point was that the differences between releases are relatively easy to cope with -- yes, even for py3k. Sure, there are a hefty number of changes, but they mostly occur in a more "library" level (if you will) rather than at the base language, and much of it is just cleaning up inconsistencies. It's not as though the entire "16 years of Python" flies out the window with an overhaul like this. It'll be something of a pain in the ass to update code, but it won't make your collected knowledge obsolete, per se.

On a less contentious matter, Arc is also a tiny language. Its changes won't be all that drastic at this point. This is little consolation, as the aim is probably to build up a respectable library base. To that end, my overarching point is that you should learn Lisp in a more platonic sense (hardly a waste of time, break-prone versions aside). This can be done with pretty much any dialect, for the record. Libraries may become obsolete, but this sort of philosophical knowledge will not.

Whether this entails using Arc needn't be a grueling decision: it's a small, simple dialect (cf the responses in the aforementioned thread), and still a Lisp. The impression I get from the announcement is more of a heads-up "we reserve the right to..." thing. Besides which, changes to Arc entail, to a significant enough extent, code written in Arc itself. What better way to understand and play with the language than to read over the definition of 'trav (as a real example of a change between arc1 and arc2; http://arclanguage.org/item?id=2504)? Regardless, as Arc stands it's stable enough for learning, but this education has far more impact than being some sort of fleeting "woops, new version, guess I don't understand Lisp anymore." I focus on this idealized learning-experience viewpoint because that's the reason I tend to play with other languages: to expand my mind.

If, however, it comes down to consistency that you'd like for a Lisp in a production environment, well:

Hah. someome made ruby run on v8 and made a small benchmark of it. Interesting:

  Firefox3: 5.8 sec
  Chrome  : 2.2 sec

FYI- If any of you are confused by the extra 2 in rincewinds code, it is NOT one of the numbers to be added. The currying code just requires it because of the impedance mismatch between variable arguments and currying. The Haskell core doesn't have variable argument support, so this is not an issue in Haskell.

Keep in mind that "On Lisp" covers currying, whereas arc currently does not. I assume this is because pg is still trying to decide on a currying approach, whether it will be implicit currying, syntax-based currying, or function-based currying.

Here's an awesome variant based on your approach I'm probably going to try and implement soon, now that I've thought of it- Have a number in the function position (currently an error) initiate currying!

For example:

  > (2 +)
  #<procedure>

  > ((2 +) 7)
  #<procedure>

  > (((2 +) 7) 5)
  12

  > (map ((2 +) 7) '(1 2 3))
  (8 9 10)

  > (map (2.+ 7) '(1 2 3))
  (8 9 10)

  (these next ones assume my mods to the intrasymbol syntax are in place http://arclanguage.org/item?id=7644)

  > (map 2.+.7 '(1 2 3))
  (8 9 10)

  (for those of you wondering why the "2" is necessary)

  > (map 3.+.7 '(1 2 3))
  (#<procedure> #<procedure> #<procedure>)

  > (map [_ 100] (map 3.+.7 '(1 2 3)))
  (108 109 110)

  the last release was 163 days ago, and
  the main feature was simply including news.arc
  the /leaders bug hasn't been fixed yet