Re: Paul Graham's Arc is released today... what is the long term impact?

Eli Barzilay wrote:

Pascal Costanza <pc@xxxxxxxxx> writes:

Here are just two citations from his articles: [...]

If somebody brings out a new programming language, and claims that
it will bring us even closer to what a programming language would
look like 100 years from now, and even implicitly claims that it
will be much better than anything (!) we have today, including
existing Lisp dialects, then I expect something fundamentally
different than a syntactically slightly different variation of R3RS
Scheme, with some neat minor extensions on top.

This was your major gripe with arc -- and something that I never
talked about. I even said that explicitly at some point. The only
point which I claimed is false (and still do) is that you can view arc
as "a plain thin library". That's all. I swear. And this falsehood
claim is not tied in any way to being innovative -- it is perfectly
reasonable to expect libraries that are true innovations and
non-Lisp-family-languages that are truly not.

OK, fine by me.

Now, if you still claim that are *can* be *implemented* as a plain
thin library, then you definitely need to have a better backup than
"this guy I know translated Basic and claimed that it was a new
language".

This was clearly meant as tongue-in-cheek analogy. My hope was that this would be obvious: You don't even need macros for the kind of translation that guy did.

If your only point is that arc is boring/disappointing/etc
then please don't post that as a reply to what I write, since it
cannot be a reply to something I wrote.

It's related. Even if you cannot get 100% of the design of Arc with any of the existing Lisp dialects, but only 99% or 98%, I would still stick to my claim. It cannot possibly be that such nuances make a difference in a hundred-year perspective.

(BTW, I consider naive use of CL lacking in that aspect: to
consider a reader macro as a "library", I'd want it to not
interfere with code that doesn't use that library).
That's already there: compile-file binds *readtable* and *package*
to the values they held before processing a file. So you can change
the syntax per source file, without interfering with the syntax with
other files. [...]

That's not enough, in a similar way that macros can mess things up.
But did I mention that I don't want to get into a CL--(PLT)Scheme
pissing contest? Oh yes, I did.

Sorry, I'm lost. I didn't mean this as a CL-vs.-Scheme pissing contest either. Either I am allowed to talk about technical aspects, or I'm not. It can't be both. Please make up your mind.

For the records, if you can't implement Arc as a plain library in CL, but only in some Scheme implementation, this would still support my position.

Keeping this in mind, I'll have a
few brief comments on the following, keeping my zipper closed:

* redefine the meaning of the function application form (eg, in
mzscheme that's `#%app')
If the CLOS MOP is available, you can get there with funcallable
objects.

...which will make it very hard to still pretend that the result is a
library. For example, in arc lists are applicable. If you'll
implement this with CLOS objects, then you'll need to tranlsate them
to lists -- which makes it a foreign interface, which makes it not be
a plain thin library.

Since when is it a requirement that a library seamlessly interacts with everything else in a language?

If you insist on that, well yes, I think that can work as well.

* write symbol macros, and make them access the name of the symbol (eg
the `foo:bar' trick)
':' cannot be redefined, but if you can live with other special
characters in its place, that's also not problematic in CL.

Sure it can
[...]

Even better.



Pascal

--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
.

Relevant Pages

  • Re: ftp client in C
    ... Ritchie, "The C Programming Language", 1st and 2nd editions). ... support must be provided by additional libraries, ... You say you're using Borland C++. ... the source distribution and take a look at docs/INSTALL, searching for ...
    (comp.lang.c)
  • Re: compilation of ms crypto api program
    ... >> I'm not talking about teaching a programming language, ... Image Processing and Modern Control Theory ... the libraries, that can either standard libraries that ... Like C and C++, Java ...
    (sci.crypt)
  • Re: ftp client in C
    ... Ritchie, "The C Programming Language", 1st and 2nd editions). ... support must be provided by additional libraries, ... You say you're using Borland C++. ... the source distribution and take a look at docs/INSTALL, searching for ...
    (comp.lang.c)
  • Re: globals?
    ... But it adds an additional keyword to the programming language and thus makes the programming language more rich ... Classic VB has been largely used for prototyping applications later developed using other programming languages because it provided 'Option Explicit Off'-style functionality. ... I do not claim that everybody should work with 'Option Strict Off', but it's a neat feature in some cases, especially when dealing with Office automation and/or targetting different incompatible versions of certain libraries. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Dealing with ad hominem attacks in comp.programming
    ... adding units to programming language variables, ... Here are some of the libraries that I have collated in various ... I have previously spent a large amount of time discussing quan (used ...
    (comp.programming)