Is this why unicode is absolutely broken on ycnews? :( Seems a shame not to be even to use characters like pi in comments/titles IMHO Does a pound sign work? GBP

edit: no it doesn't. Seriously, if done right unicode support doesn't have to take that long. Especially if you're building something without the need for backward compatibility.

People care if a website is using correct unicode characters or not.

PG just released an entirely new dialect of lisp for web programming, he's mentoring about 20 startups right now, and runs Hacker News... "Oh, and can you add Unicode support, it would only take 2 or 3 days..."

I know that not having Unicode supported in your web language is inconvenient, and at times is a show-stopper. But really. Give the guy a break. If PG doesn't want to "spend a single day on character sets". Don't ask him to spend a day on character sets.

If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my idea is that a string is a sequence of characters, regardless of how a 'character' is represented", then somebody can go ahead to change Arc Unicode-clean (it won't be much work assuming MzScheme has support of Unicode).

http://iolanguage.com/scm/git/checkout/Io/docs/guide.html#TO...

> In Io, symbols, strings, and vectors are unified into a single Sequence prototype which is an array of any available hardware data type

> A String is just a Sequence with a text encoding, a Symbol is an immutable String and a Vector is a Sequence with a number encoding.

I thought representative Lisp hackers liked long descriptive names over short cryptic ones? ;P

PS: I feel my karma's going to hell in 3, 2, 1...

Depends on what you're talking about; anything that uses microformats does, for example.

Tools generally can't assume that tables are semantic, because they've been so heavily abused. That's not going to change though. Perhaps the best solution is a <yes-this-is-really-a-table> element.

> tables aren't much moreso than divs.

Are you hoping to build a user community for Arc? If so, and why would you release Arc if you weren't, then why are you not interested in keeping track of changes that break things users might design/code against? Am I being stupid and missing something here?

  $ git clone http://codewikia.com/arc

"We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."

Is that really wise? What's wrong with doing a simple changelog with every modification? Since you'd expect only experienced programmers to be using Arc, you don't have to hold our hand explaining the implications of the changes - but making us diff the source would probably be a bit much.

I mean it doesn't have to be verbose even. Or even tidy. This would be better than nothing:

* Added a global weak reference hash map to treat any object like a hash using {} syntax, ie, (= {someobj hashindexobj} 5).

The Scheme language sneakily increased the scope of the language designer's powers. From very early, maybe from the begining, the Scheme spec said that conforming implementations must do tail call elimination. The first time I read this, I thought "wait, can you require this in a spec?" Arc will see this increase, and raise it by some standards for profiling.

  $ wc -l arc0/*
    1093 ac.scm
     535 app.arc
    1496 arc.arc
      16 as.scm
     107 blog.arc
      48 brackets.scm
      61 code.arc
       2 copyright
     360 html.arc
       7 libs.arc
      80 pprint.arc
     119 prompt.arc
     462 srv.arc
     223 strings.arc
    4609 total

> MzScheme installations with unhygienic macros and empty lists that

1. I think using cons to represent lists is an ugly hack. I mean, why should a cons only hold 2 elements? Why not generalize them to n elements, and call them lists?

2. Has anyone tried unifying macros and functions? The distinctions between the two is one of the worst part of Lisp IMO, and I don't think there should be anything fundamental about it.

1. Recursion and cons cells naturally complement one another. They can stand in for n-ary tuples, vectors, and arrays reasonably well for small values of n, and when your dataset gets large, well, you switch to a more efficient data structure. Hell, with Arc you even get 'push' and 'pop' as built-in functions. What exactly is the problem?

2. Again, I don't see how this is a problem. Macros are compile-time rewriting rules. In an eagerly-evaluated language like Lisp, they are pretty much a necessary evil to prevent unnecessary side-effects while still allowing for flexible syntax. I can imagine doing without them in a lazy language like Haskell, but I'm not aware of any popular, lazy languages in the Lisp family.

2. Macros come with a ton of pitfalls and limitations. On Lisp has a nice list of reasons to avoid macros. But consider if your macros are really called at run-time rather than compile-time, and you have a special operator like eval, but that evaluates in the calling context. Then you can write normal functions like this:

   (defmacro average (x y)
       (/ (+ (eval-in-caller x) (eval-in-caller y)) 2))

   (defmacro my-if (condition x y)
       (cond ((eval-in-caller condition) (eval-in-caller x))
             (t (eval-in-caller y))))

   (defun do-many-tymes (n-times &not-evaluated body) ...)

(1) Let's separate implementation and semantics issues. In semantics level, list as a datatype is defined recursively:

  List a = () | (a, List a)

It also maps well to the implementation that uses cons cell, but as you say, it's not the only way to implement it. There was a technique called CDR-coding, which represents a list as if it's a vector (e.g. cell's CDR doesn't contain a pointer but it overlaps the next cell's CAR); specially tagged pointer distinguished normal cells and CDR-coded cells. I guess it was abandoned since deailng with set-cdr! would be very messy. But if you're creating a new dialect, you can go for big change like dropping set-cdr! (some of Scheme people even talking about dropping mutable cells.) In today's computer where access locality means a lot, maybe you can shed a new light to this old technique.

(2) I think the current state of macro was the result of simplification. IIRC, the old lisp dialects allow to pass around syntactic values (FSUBRs) as if it's first class, but it's easily messes up the semantics. It's conceptually simpler to restrict macros as curretly they are. If passing macro around is allowed, you'll never know how (+ 1 2) in the following function is evaluated until runtime:

  (defun call-it (x) (funcall x (+ 1 2)))

  (defmacro call-it (x) `(,x (+ 1 2)))

2. call-it: What's the problem with not knowing (+ 1 2) until run-time? Efficiency? Then I would argue that expressive power of the core language ought to take precedence. In an actual implementation, funcall could leave (+ 1 2) to be evaluated (or not) inside the function body. I would add funcall-normal-function to the language, which would amount to a funcall + (declare (normal-function f)). Both for documentation and for efficiency.

Of course, not knowing if (funcall x (print 2)) will print 2 is unsettling in a way, but that's the same basic argument that's made against macros. They disrupt the evaluation order.

Not only efficiency. You don't even know if (+ 1 2) means "1 plus 2" or "choose 1 or 2 randomly" or "generate a sequence of numbers between 1 and 2" until you know what x really is (assuming funcall does delay evaluation of its arguments and passes the original form in case x is indeed a macro).

The macro version of call-it has the same problem, of course, but if you embrace first-class macros in the above way, every higher order function call will have the problem. Considering how often HOF is used, the impact is huge.

However, as you suggested, you can have two versions of funcalls, one of which evaluates args no matter what x is; then this problem will be solved.

Well, yes, that would be the point :)

    (keep [progn _] seq)

"I spent a fews days"

Tables are meant for tabular data, and when you use them for layout it breaks those semantics, which in turn makes it much harder for screen readers to make sense out of it.

   (while 1 (pr "This is so exciting! "))

    bash-3.2$ ls | xargs -n 1 wc -l 

      1093 ac.scm
       535 app.arc
      1496 arc.arc
        16 as.scm
       107 blog.arc
        48 brackets.scm
        61 code.arc
         2 copyright
       360 html.arc
         7 libs.arc
        80 pprint.arc
       119 prompt.arc
       462 srv.arc
       223 strings.arc

    wc -l *

    (load "blog.arc")

  http://mooseyard.com/Jens/2008/01/96-characters-ought-to-be-enough-for-anyone/

If he can do all that in one hour, I am really impressed. It would take me more than one hour alone to research the utf-8 and CP-1252 encodings. Changing regular expressions libraries to work with 16 bit, as well as the index operations for strings might take some work, too.