Apparently, while you were complaining, someone else was solving.

Arc is already capable of supporting some subset of applications that are serious in your sense. News.YC is at least moderately serious in that sense.

At least you were kind enough to let us know.

Actually I think I have seen a library for MzScheme that does it this way.

Sure, it's somewhat more verbose for this toy examples - but every intermediate expression (and the whole thing) is a Lisp-Object in its own right.

You would not even need macros.

Edit: There is a place for macros here to make things less verbose. Just write a macro that 'compiles': (* (+ a (* b))) into the form above.

For convenience you can offer a function that builds RegExps out of strings in the usual way.

"It's not for everyone. In fact, Arc embodies just about every form of political incorrectness possible in a programming language. It doesn't have strong typing, or even type declarations; it uses overlays on hash tables instead of conventional objects; its macros are unhygienic; it doesn't distinguish between falsity and the empty list, or between form and content in web pages; it doesn't have modules or any predefined form of encapsulation except closures; it doesn't support any character sets except ascii. Such things may have their uses, but there's also a place for a language that skips them, just as there is a place in architecture for markers as well as laser printers." (http://arclanguage.com/)

I certainly interpreted this as ASCII-only (along with presentational markup) was an explicit design decision, and I don't think this is a far-fetched interpretation. Luckily PG has clarified (http://news.ycombinator.com/item?id=111189) that this is not really what he meant, and now everyone is happy and has regained trust in Arc!

Edit: heh, "thanks grandma" has even more than that.

Edit: btw it's funny that i'm still being upmodded

- a simple, popular comment

- a comment suggesting maybe the first one shouldn't have been upmodded so much

- a comment backing off

Why would you downmod all of them? If you like dislike the first comment, you should like the second, and vice versa. And if you're unhappy with me in general for the first two, you should like the third one.

2) Simplest explanation for that case would be that he's downmodding the latter two as noise. You can agree to a comment and still believe it doesn't add anything to the topic in which it appears.

(Sorry, I couldn't resist)

If you made a keyboard that had every character in every language spoken in the EU, you could even file to make it a standard with whatever earnest standards body is in charge of such things. No linguistic minority should have to use control keys! It would be like giving peanut butter to a dog.

But smart people don't endeavor to regulate minutia.

I think you just implied that all politicians are dumb. I agree.

http://www.unicode.org/charts/symbols.html (geometrical shapes etc)

As I understand only UTF-8 is supported, so forget characters for UTF-16 and UTF-32 (but you rarely need these anyway)

to answer my own question.

If so: I really don't want to be a negativity guy but it seems like every language that has made an 8-bit string the default string type has regretted it later because it is so painful to change it without breaking code. Okay, Paul says that he won't mind breaking code. Maybe he means it, but it doesn't make any sense to me to knowingly and consciously repeat a design mistake that dozens of other people have made and regretted.

It really just takes one day to get this right. You need to distinguish between the raw bytes read from a device and the true string type (which needs to be 21 bit or greater). You need a trivial converter from one to the other (which you can presumably steal from MZScheme) and back.

That's it. You get this right at the beginning and you never have to backtrack or break code.

My apologies in advance if this post is based on incorrect premises. I'm trying to help.

I don't think anyone at this point would claim that Arc supports unicode-in-general.

If you treat strings as octets OTOH even simple operations like concatenating two strings might lead to headache if the strings are in two different encodings. And how do you keep track of the encodings of individual strings? Madness lies down that road.

/sarcasm

    (define Y
      (λ (m)
        ((λ (f) (m (λ (a) ((f f) a))))
         (λ (f) (m (λ (a) ((f f) a)))))))

Make λ an alias of fn, and have it replace automatically in whatever editor you use?

fn is fast to write, but λ is much more readable, 'cos it stands out.

And now for the less serious part:

ሞሡሢ Am I the only one whom these Ethiopic characters remind of Tengwar? BTW, are there Unicode chars for Tengwar? I think there should be! (But not for Klingon, because it sucks.) I have fun wirting this on my ⌨, but ℐ∫ ᚾℍℹ⑀ not pointless? Who cares? Anyway, now we can use distinct characters for Roman numerals: Ⅰ,Ⅱ,Ⅲ,Ⅳ,Ⅴ,Ⅵ,Ⅶ,Ⅷ,Ⅹ,Ⅻ,Ⅽ,Ⅿ! Ye darn kids! Everythin we had was 7-bit ASCII, without parity, and we were damn greatful for it? You think you had it bad? I had to use Morse code for browsing porn, back in my days! And I had to etch my public key into the wall of a rotten ol' cave! We did not have this fancy-shmancy routed network, i had to remember the way from here to there all by myself!

--- this post was presented to you by Too Much Coffee.

Damn fast...

There's a difference between things I don't care about, and things I'm actively against. I don't care about character sets and css, so those things will no doubt gradually get better.

Classic static typing, however, I think is actually a bad idea in a general-purpose language. It makes languages weaker. So it's never likely to happen in Arc itself. However, one of the explicit goals of Arc is to be a good language for writing other languages on top of, and I can imagine plenty of languages for specific types of problems (e.g. circuit design) in which static typing would be a good idea.

I used to agree with you, by the way -- static typing in most languages feels like a straight-jacket. ML wasn't enough to change my mind. It took Haskell.

Anyway, I find that usually when I want a heterogenous list in Lisp, all I really need is a tuple. I want an ad-hoc way to group some values together (i.e., I don't want to bother creating a named structure), but I generally know the type I want in each position.

In the rare situations where I really do want a heterogenous list, Haskell does make it possible. The standard library has a Dynamic type that stores an arbitrary object along with a first-class manifest type identifier. These type identifiers have to be generated at compile time, but GHC has built-in syntax for this, and if it didn't it could still be implemented as a Template Haskell macro, or failing even that, just done by hand once for each user-defined type. That's all the support that's necessary from the core language -- the rest of the dynamic typing system is just an ordinary library.

Now, granted, if you wanted to use manifest typing for everything in Haskell, it would be ridiculously cumbersome and you'd be much better off just using a dynamic language[1]. But if you use it only where it's needed, then the dynamic casts will bloat your program by a couple symbols per thousand lines, and in return you get programs that damn near always work the first time they compile, along with a few other nicities like the one I mentioned above with map.

[1] There are plenty of cases where the converse is true. To name an obvious one, you could write a set of Lisp macros to implement lazy evaluation. But if you wanted to use them everywhere, you'd be much better off in Haskell.

  let mylist = [`Int 5; `Char '5']

What am I missing?

If the first Arc apps had not been full-featured Web apps, but had instead looked like examples from SICP, everyone would be complaining that the language was only good for computing Fibonacci sequences and writing interpreters for itself.

OTOH, you can't expect a new language to immediately offer the library resources of, say, Perl.

So the plan for Arc's early days seems to be similar to what the Pragmatic Programmer guys called the "tracer bullet" approach:

Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy.

On day zero, Arc let you construct and deploy every aspect of a useful software system (a web app)... but it took a very narrow and direct path to that goal: emphasis on tables, no Unicode support, borrowing some functionality from an existing Scheme environment, etc., etc. That is what PG was trying to convey in his announcement: the strategic plan for Arc's early days is to work on designing a complete skeleton, but not add a lot of flesh.

It was a pretty odd situation to be in. If I'd been releasing Arc into a neutral environment, I probably would have said what I wrote in http://paulgraham.com/core.html. But maybe it's just as well I gave all the flames something to expend themselves on before talking about subtler questions.

   ArrayList myList = new ArrayList(new Object[] { "foo", 42, new Bar() });
   for(Object elem : myList) {
      if(elem instanceof String) doStringThing((String) elem);
      else if(elem instanceof Number) doNumberThing((Number) elem);
      else if(elem instanceof Bar) doBarThing((Bar) elem);
      else doObjectThing(elem);
   }

I suspected you deliberately mentioned ASCII-only and presentational markup because you knew it would tick off (and hopefully scare away) a certain type of perfectionist which you consider non-productive for explorative hacking.

The excitement comes from the fact that Hacker News is programmed in Arc, and the change to Hacker News implies that Arc will soon support utf-8 too.

U+007E ~ U+301C 〜 U+FF5E ～

This is my language - Dhivehi. Written right to left.