Arc Forumnew | comments | leaders | submitlogin
Ask PG : are they axioms or core functions ?
11 points by sacado 6115 days ago | 16 comments
PG, as you said, ac.scm defines the axioms (things that cannot be defined in arc itself) while arc.arc defines the core of the language (anything that could be useful in any program and can be built from the axioms). Thus the language is, as much as possible, its own specification.

As a consequence, I guess you want as few things in the axioms as possible. Therefore I don't understand why functions like +, < or > belong to the axioms, at least the way they are currently written. These functions are not simply imported from scheme as, say, - or /, they are somewhat redefined to be polymorphic (thus + will work with numbers, strings, lists, ...).

Wouldn't it be better to have these polymorphic definitions in the core rather than in the axioms ? That would imply, e.g. exporting + as num+, string-append as str+ and list-append as lst+, then defining + in arc.arc as a polymorphic call "routing" to these axioms, instead of just exporting your own opaque home-made +.

The main benefit of this would be :

1- arc would be even more written in arc

2- it would be possible to have an "à la carte" +, meaning that you could let more types be added with + (or remove those you don't want). If I understood well, that's one of the main goals of Arc ?

The same is, of course, true of <, >, len and probably others.

So, my question is : why did you do so ? Is it for performance ? Is it because you want to export as little as possible from the underlying implementation, the less axioms the better, even if these axioms are big black boxes ? Is it only temporary ?



4 points by pg 6114 days ago | link

There's currently a lot of stuff in ac.scm that could be moved up into Arc. I'll get to it eventually.

-----

1 point by Darmani 6115 days ago | link

While 1 is important, for pragmatism's sake there does need to be a limit. Things such as

  (def minus (a b)
    (+ a (* -1 b)))
are just silly. Likewise, a<b where a and b are numbers is equivalent to (is (/ (- a b) (abs (- a b))) -1), but that's going too far.

As for 2, while I don't have Arc with me right now to test, I believe you can overload functions like this:

  (let oldplus +
   (def + args
     (if (no (keep [is (type _) 'mytype] args))
        (apply oldplus args)
        <do some alternate behavior of +>)))

-----

2 points by sacado 6115 days ago | link

For 1, that's not what I mean. If + is defined this way :

  (def + args
    (if
      (all [isa _ 'num])
        (apply int+ args)
      (all [isa _ 'string])
        (apply str+ args)
      (all [isa _ 'cons])
        (apply cons+ args)
        (err "oops")))
We just have a formal definition for + that we don't have right now. (As a side note, this is close to the actual implementation of the '+ defined in ac.scm). How can we know it works for strings, lists ? Does it works on chars or not ?

The goal is not to get rid of, say, -, * and / and implement them in Arc. Their signification is obvious and no one would need to see how they are implemented. This is not a math class. But this is not true of +, because by opening the black box it is, we have :

- the possibility for alternative implementations of the arc compiler, as most of the language is defined in itself. Imagine I want to work on a Forth implementation to put Arc code into fridges or TVs ; or pg thinks it's time to move on a C implementation to have a super-fast Arc. The smaller these axioms, the easier it is to get compatible compilers or to avoid bugs from one version to another.

- the possibility to say "I now want to use + for hash tables, let's add it, how is that implemented ?",

- the possibility to say "I don't need + to work for strings or chars or anything, I just want numeric addition because I'm crunching numbers ; +int is the function in need".

Incidentally, if I want to write +int, the only way to do so currently is to do (def +int a b (- a (- b))), and we both agree to say that it's a bad idea.

-----

2 points by sacado 6114 days ago | link

I just read back http://www.paulgraham.com/ilc03.html and found intersting things dealing with what we are talking about (pg doesn't answer, so I'll make hime talk myself ;)

"Letting people rewrite your language is a good idea. You, as the language designer, can't possibly anticipate all the things programmers are going to want to do with it. To the extent they can rewrite the language, you don't have to."

"If you want to overload existing operators to do the right thing when given your new type, you don't need anything new in the core. As long as you have lexical scope, you can just wrap a new definition of the operator around the old one."

" At the conference [pg gave this talk], John McCarthy pointed out that a function to invert a matrix might be better described by writing "inverts a matrix" than by giving the source."

-----

2 points by absz 6115 days ago | link

In fact, the Anarki version of Arc* includes a redef macro:

  (redef + args
    (if (no (keep [is (type _) 'mytype] args))
      (apply old args)
      (frob args)))
This also prevents "* * * redefining +" from being printed.

* EDIT: Used to just say "Arc," but that was wrong.

-----

5 points by kens 6115 days ago | link

I think the redef macro is in the Anarki version, not official Arc

As an aside, has Paul Graham shown any enthusiasm for the Anarki changes?

-----

5 points by sacado 6115 days ago | link

"As an aside, has Paul Graham shown any enthusiasm for the Anarki changes?"

Obviously not.

-----

3 points by cchooper 6115 days ago | link

I can't blame him. Cutting bloat in the language core is clearly a goal. Nothing should go into the official Arc release unless it has proven its value in real code (which is basically News.YC at the moment).

-----

6 points by sacado 6115 days ago | link

Sure, he has to keep the control over the things. The point is that a few bug fixes (the mkdir problem for example), simple conveniences (see arc.sh) and even trivial optimisations (arc< to name it) available in anarki are of interest even in the official release. I'm not talking about experimental stuff (infix numeric notation, vectors, standalone exe, maybe docstrings, experimental module systems, ...)

But I think the few fixes and conveniences should really be taken into consideration. I can't believe none of them are of interest.

-----

2 points by cchooper 6115 days ago | link

They probably are of interest, but let's not forget he's running a company in his spare time, and 3 releases in about 3 weeks is a pretty good work rate.

Of course, as someone running Arc in Windows, I'd love it if a bit more stuff worked out of the box (e.g. the blog, which didn't work in Arc1 IIRC). That's why I'm probably going to switch to developing on Anarki and then testing it on vanilla Arc afterwards.

-----

3 points by sacado 6115 days ago | link

Note that I don't criticize Paul's attitude there. 3 releases in less than a month is much more than what I expected. He didn't release early, but at least he releases often :) I just meant a few things would deserve a little more consideration, at least in the next few weeks/months ?

-----

3 points by cchooper 6114 days ago | link

I'm hoping things will speed up now that the News.YC code is in.

-----

2 points by jbert 6113 days ago | link

You might increase the chances of stuff getting merged back into PG's arc if you separate the different types of changes into different git branches.

That reduces the burden of code review/merging/demerging on the person you'd like to pull the changes (PG).

e.g. have a bugfix branch containing only "obvious" fixes.

It can be difficult to disentangle a bunch of different changes (what depends on what). That's a barrier to adoption.

-----

3 points by byronsalty 6115 days ago | link

Somebody is reading my mind.

-----

1 point by absz 6115 days ago | link

So it is. Thanks.

That's a good question--I'm not really sure, since I just use the Anarki.

-----

2 points by eds 6115 days ago | link

Wow, that's really nice. I think I'll use it in the definition of infix.arc.

-----