Arc Forumnew | comments | leaders | submit | cje's commentslogin
3 points by cje 5056 days ago | link | parent | on: EQ, EQL, EQUAL, ...?

Arc embodies just about every form of political incorrectness possible in a programming language.

-- Paul Graham,

He wasn't kidding, you see.


1 point by cje 5056 days ago | link | parent | on: Table constructor

I've no idea what this is useful for, but:

  (def table-w/keys (value . keys)
    (= tab (table))
    (each key keys
      (= (tab key) value))
Also, the feature you want in table is easily done by fill-table:

  (def new-table args
     (fill-table (table) args))
Use the source, Luke!


1 point by bogomipz 5056 days ago | link

table-w/keys is useful for counting. After creating the table in icemaze's exemple you can for instance do

  (++ (h 'cars))
Even more useful, however, is to specify a default value for keys not yet in the table, so you can do the above without first initializing for the keys you intend to use. PG mentioned in Arc at 3 Weeks that lookup failure should return the global value * fail* , in which case you would be able to do

  (with (h (table) *fail* 0)
        (++ (h 'red))
        (++ (h 'blue))
        (++ (h 'blue))
        (++ (h 'green))
which returns a table where red is 1, blue is 2, green is 1, and no other keys exist. The example is kind of stupid, but the concept is quite powerful.

Edit: spaces added so * fail* doesn't become fail


1 point by bogomipz 5056 days ago | link

Good point about fill-table. I didn't think of how easy it is to give this function a newly created table. It still kind of feels like a shortcoming that (table) doesn't accept values like (list) does. And I don't want to define a different function to behave like this. If it's a good idea, it should be in the main table constructor. PG seems to have thought of this already because there's a comment in ac.arc with a definition that involves fill-table. I do, however, see that this would slightly bloat the constructor.


7 points by cje 5056 days ago | link | parent | on: a defense of arc

That's your community. Given how much you've been proselytizing, I assume you're involved with that project.

But Arc is not newLISP, and isn't trying to be. If you prefer to use newLISP, please do so -- and stop trying to get people to ignore Arc in favor of it.

And by the way, newLISP is by no means "mainstream".


4 points by cje 5056 days ago | link | parent | on: EQ, EQL, EQUAL, ...?

It's not really any "simpler" -- pg just picked two (EQ and EQUAL) and ignored the others.


6 points by pg 5056 days ago | link

The is operator isn't quite eq. For strings it behaves like equal, because that's how one tends to use strings.


1 point by hilbertastro 5056 days ago | link

I usually don't directly compare strings for (character-wise) equality; I search for substrings or regexes, parse out data of another type, or compare modulo case. Strings are just sequences to me; I don't have a reason to process them differently than any other kind of sequence, unless I'm working in C and have to use strings as a hacked-up replacement for symbols. That being said, other languages have chosen to make strings a "value type" (e.g., C++'s std::string).

Thanks for clarifying! From what I've read on CL over the past 3-4 years, EQ/EQL/EQUAL seems to be one of the outstanding issues. (People also complain about the lack of extensible sequences (though some implementations may offer this) and a few things about CLOS. Well, they complain about _everything_ but usually don't offer to fix anything ;-) .)


2 points by cje 5056 days ago | link

Ah, right. Do hash tables work properly with strings, then? I've had CL hash tables with :test #'equal, which always seemed annoying to me.


2 points by cje 5056 days ago | link | parent | on: Optional Parenthesis

Parens are an issue -- you need to have all of them. Omitting some parens under some circumstances makes the code slightly shorter, but at the expense of partially hiding the structure of the code.

But here's the real problem: the reader has to understand the forms where parens can be omitted. If you write a macro that creates (def ...) forms, you can't elide the parens around it, because the reader doesn't know it can.


2 points by EliAndrewC 5056 days ago | link

Well I agree that we should only omit parens where it's 100% unambiguous where the actual parens would be. There'd need to be a very small number of simple rules/exceptions (such as "every new level of indentation denotes an extra parenthesis unless ____").

A few years ago Paul Graham seemed to think this would work. However, it may be that he tried it and found that it would be too problematic. I'm hoping that he simply has been too busy to implement it so far.


2 points by cje 5056 days ago | link | parent | on: Arc as first Lisp

Be cautious choosing Arc as a first lisp -- It's still in heavy development, so there may be unexpected sharp edges that we lisp veterans instinctivly avoid. You may prefer PLT Scheme (atop which Arc is written), as it's quite similar to Arc at the moment.


3 points by cje 5056 days ago | link | parent | on: Arc web form REPL?

It's already there in arc0/app.arc. It's a bit tricky to use, though.


3 points by cje 5056 days ago | link | parent | on: Arc as a better "common" Lisp?

Actually, quite a few features Arc uses are taken from the underlying scheme -- like garbage collection, numbers, closures, basic I/O, strings, and so on. In that case, you'll need to count most of PLT Scheme, which dwarfs Arc's 3450 lines. So Arc isn't nearly self hosting yet. But it will be.


2 points by cje 5057 days ago | link | parent | on: Profiling?

Since there isn't a standard yet, there's no spec to have dropped the idea from. Still, I doubt the idea's been dropped -- it's too good an idea.

Hopefully, somebody will contribute a profiler before long, and fill this unfortunate gap.


1 point by cje 5057 days ago | link | parent | on: A question about the tutorial

Not exactly, no. The first argument isn't evaluated, but "=" looks at it to let you do convenient things like that.

In fact, "=" is actually a fancy macro, which transforms (= (car x) 'z) into (scar x 'z), where "scar" is the set-car function.

For example:

  arc> (= x '(a b c))
  (a b c)
  arc> (= (car x) 'new)
  arc> x
  (new b c)
The fancy bit here is that only the "outermost" form of the first argument is specially processed:

  arc> (= (car (cdr x)) 'second)
  arc> x
  (new second c)
  arc> (= (car (cdr (cdr x))) 'third)
  arc> x
  (new second third)
These last two examples would expand to

  (scar (cdr x) 'second)

  (scar (cdr (cdr x)) 'third))
Common Lisp does essentially the same thing with "setf".