Arc Forumnew | comments | leaders | submit | pau's commentslogin
2 points by pau 4999 days ago | link | parent | on: CL-Arc: Arc Compiler in Common Lisp

If anybody invites me to github (pau.duran, GMail acount), I'll push an implementation of Arc in SBCL... It loads arc.arc right now, and continuations are implemented. Also has a little test suite.

It could happen that my mistakes are useful to you... ;)

-----

1 point by eds 4999 days ago | link

Invite sent.

I am curious how far you got on your implementation because I wouldn't have much of a project if it was already finished.

-----

2 points by pau 4998 days ago | link

Thanks, eds. You can access the code at:

  git://github.com/pauek/arc-sbcl.git
I ended up creating a public copy of my own git repo not to mess with Anarki...

As for your concerns, I think you shouldn't be too worried. Just check it out, there is ample room for improvement, especially in speed, which I understand is your primary objective. No network yet, no threads, continuations are implemented as chains of closures (I honestly don't know better than that)... it just loads plain arc.arc, and I haven't checked it thoroughly.

For me, this was a very nice opportunity to learn about the CPS transformation. Arc is perfect in this respect (only 4 special forms). I'm pretty sure that, as an exercise, it's full of bugs and misconceptions, because I love to learn by doing (and make lots of silly mistakes along the way)...

I'll be happy enough if it helps just a tiny bit...

-----


In fact I have an implementation in SBCL half way (it basically can load arc.arc, but I haven't bothered with network/thread functions yet). To solve the call/cc problem I got to the point of doing a CPS transform, and since Arc has only 4 special forms (very few axioms, as you say) this was 'easy'...

-----

1 point by pau 5014 days ago | link | parent | on: Poll: Where are you from ?

Spain

-----


Well, thanks for asking! I personally would add:

  A foreing function interface
Sure I could use the MzScheme for this but I would do it in a "non-standard" way, e.g. it would be my personal hack. But right now, I would jump into programming a web application in Arc if I had an easy (and "official") way to interface SQLite3...

-----

4 points by stefano 5024 days ago | link

Arc really needs a FFI. This would make possible using graphical libraries such as GTK+. I know Arc is web-oriented, but for some type of applications a conventional GUI is simply better.

-----

3 points by sacado 5021 days ago | link

As a matter of fact, I'd love Arc to not be only web-oriented. Anyway, what will the web be like in a hundred years ?

-----


At the same time, it's good to have some 'central planning' since this gives motivation to contributors and makes them feel part of "Arc's history" (not that reading Arc's forum is not engaging enough, but...), otherwise they may feel that their work is not appreciated and just stop hanging around...

-----

2 points by mcoles 5026 days ago | link

As much as everyone wants freedom (as in speech not beer) it's not so much fun when your working code is on the line. Even in a 3-week old experimental programming language. Funny that.

-----

5 points by pau 5033 days ago | link | parent | on: Does Arc need modules? Maybe not.

At some point the amount of code in arc-wiki.git will cross a threshold, and a solution will be needed. If we wait until then, the way to solve it might be more obvious.

I also wanted to mention a fourth benefit that I think modules can offer, which is:

4. They allow some form of management of dependencies between pieces of code.

This is optional, but I would integrate it in the discussion about what problems modules solve...

-----

1 point by cchooper 5033 days ago | link

A list of such problems would be another good starting point.

-----

2 points by pau 5033 days ago | link | parent | on: Does Arc need modules? Maybe not.

> pgs sentiment that modules are a cognitive barrier

Can you give pointers to PGs essays or books about this?

-----

1 point by drcode 5033 days ago | link

I think it's in the ansi common lisp book- unfortunately, my copy became too dog eared (the paperback is unfortunately a bit flimsy) and I threw it out, otherwise I'd let you know for sure. I think he was complaining about the CL module system being to hard to understand...

-----

6 points by pau 5033 days ago | link

Found it, I think!

"The kind of modularity provided by packages is actually a bit odd. We have modules not of objects, but of names. Every package that uses 'common-lisp' has access to the name 'cons', because 'common-lisp' includes a function with that name. But in consequence a variable called 'cons' would also be visible in every package that used 'common-lisp'. If packages are confusing, this is the main reason why; they're not based on objects, but on their names".

You know, I now remember having read this... ;)

-----

5 points by cchooper 5033 days ago | link

I like the interesting footnote, very relevant to this discussion:

> So perhaps packages will turn out to be a reasonable way of providing modularity. It is prima facie evidence on their side that they resemble the techniques that programmers naturally use in the absence of a formal module system.

-----

5 points by Jesin 5033 days ago | link

He seems not to be saying we shouldn't have modules, but instead that we shouldn't use this kind of module.

-----

4 points by pau 5035 days ago | link | parent | on: Arc's defset : a little anti-arc?

Arc's 'defset' is similar to CL's 'get-setf-method'. These functions return a list of information to get or set a 'generalized variable'. When the macro '=' is invoked, it uses this information to generate the code. I guess you could write something like CL's 'defsetf' in Arc (maybe 'def='?). In CLTL2 Common Lisp, this 'defsetf' can be expressed as (defun (setf ...) ...), which seems more natural.

Take a look at PG's book 'On Lisp', chapter 12, pages 171 and 178...

-----

2 points by pau 5035 days ago | link | parent | on: Modules : a proposition

I think that discussing a module system is valuable in itself. I also think it must be done sooner rather than later. For missing things, take a look at http://arclanguage.org/item?id=2580.

There is some convergence, but only in the ugliness of '@'... ;)

-----

4 points by pau 5036 days ago | link | parent | on: Docstrings: a contrarian view

If my opinion counts for something, I totally support your view, CatDancer. The same happens to me, I always want to remove distraction. But it's a personal thing, I realize that. Everyone has deep reasons to prefer their own way, and I am no exception. I also should confess that I program mostly "alone", that's why my opinion maybe doesn't count as much as everyone else's.

In my case, I kind of think about it as "typographical" reasons. For instance, all manuals of typography tell you that it's uncomfortable to read very long lines of text if they are too close (in fact, this forum is above the limit, whereas PGs essays, if you remember, are almost perfect). The reason is that when you try to find the exact line that is the continuation of the one you are on, you have to search. Best measures for this have been tabulated by the professionals, of course. And, you know, lately I've discovered myself trying all the time to make programs not surpass the 65th column, and using the "wc -L" command all the time, so that programs occupy mostly your field of vision without moving your eyes... Stupid maybe? Perfectionism? Yes, I know. But I think this goes in the lines of your comment, since documentation breaks this 'unity' of code, I don't like it in the middle.

And the one thing that has attracted me towards Arc is, as a matter of fact, "the PG style", this minimalist, amazing (for my taste) coding style that I saw in "On Lisp" and "ANSI Common Lisp". It feels right to me, and you feel that code becomes a 'definition', so I now think I should be trained enough to read "arc.arc" _without_ documentation, as if I was reading math or something. And since Arc seemed like a language built with those principles, the addition of documentation, while certainly useful, didn't feel right to me.

In fact, I would die to know what PG thinks about this... ;)

-----

3 points by kens 5035 days ago | link

I find it hard to believe that reading the code can be a replacement for documentation. For example, I would find a one-line description much more useful than trying to figure out:

  (def qne (obj q)
    (atomic
      (++ (q 2))
      (if (no (car q))
          (= (cadr q) (= (car q) (list obj)))
          (= (cdr (cadr q)) (list obj)
             (cadr q)       (cdr (cadr q))))
      (car q)))
Seriously, I'd like to know if I can expect to get to the point where the above is just obvious.

-----

3 points by kens 5034 days ago | link

In case anyone was wondering... this is Arc's enqueue operation, which atomically adds obj to the queue q. Arc's queue data structure provide constant-time enqueue, dequeue, length, and conversion to list operations. My point is that documentation is a good thing, since understanding raw code can be difficult for mere mortals such as myself.

-----

2 points by almkglor 5035 days ago | link

>It feels right to me, and you feel that code becomes a 'definition', so I now think I should be trained enough to read "arc.arc" _without_ documentation, as if I was reading math or something

Sure, sure. Then you completely forget wtf 'on is supposed to do, and how it's different from 'in, and have to read it again.

-----

1 point by pau 5035 days ago | link

Well, if you completely forget about some function, you will have to read something anyway. I guess what you say is that the documentation is obviously more readable than code, but I'm not so sure...

-----

2 points by kennytilton 5034 days ago | link

It probably varies. Natural language is a mess, and in the hands of geeks...ugh. So if I have an interesting function to understand I would just as soon see the code. But if I am looking at standard library stuff it will be hard to muck up the one very short sentence description. Add to that that we have a new language with a lot of shortcut syntax and that its a Lisp and a lot of non-Lispers are hopefully looking at the language, I think maybe the ball was dropped when we were told to just read the code, as much as I grok that sentiment. It is something I am much faster to say when we have people asking about application code in a language everyone asking is supposed to know.

-----

1 point by almkglor 5035 days ago | link

  (mac in (x . choices)
    (w/uniq g
      `(let ,g ,x
         (or ,@(map1 (fn (c) `(is ,g ,c)) choices)))))

  (mac on (var s . body)
    (if (is var 'index)
        (err "Can't use index as first arg to on.")
        (w/uniq gs
          `(let ,gs ,s
             (forlen index ,gs
               (let ,var (,gs index)
                 ,@body))))))
versus:

  (from "arc.arc")
  [mac] (in x . choices)
   Returns true if the first argument is one of the other arguments.
      See also [[some]] [[mem]]

  (from "arc.arc")
  [mac] (on var s . body)
   Loops across the sequence `s', assigning each element to `var',
      and providing the current index in `index'.
      See also [[each]] [[forlen]] 
The main point is this: documentation says "what this code should do". Code says: "this is how we do it". In many cases, the user of a function or macro is interested in what the code is supposed to do; how it's done is less important.

-----

2 points by cpfr 5035 days ago | link

almkglor that documentation is beautiful

-----

2 points by almkglor 5035 days ago | link

The full documentation is available on arc-wiki.git. Wanna make a guess on who did most of the documentation?

-----

1 point by pau 5034 days ago | link

I am really sorry I gave the impression that I was critisizing your work... my apologies.

-----

1 point by almkglor 5034 days ago | link

Err, sorry, but that's not what I meant. Just tooting my own horn ^^. In any case, the documentation can be improved. I did most of that while I was sick, and I'm not 100% sure it's correct - there may be subtle uses that I haven't documented. Also, the docs are far from complete - there are a huge bunch of functions without decent "see also" links. And I've only completed arc.arc yet, still haven't had time to do srv.arc, html.arc, app.arc, and prompt.arc

-----

More