Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> ... > So I have a little generic function, REF, that I'd had sitting around > unused for some time, and have recently been using all over the place. > Its usage is (ref thing index1 ... indexn), where THING is anything > that can be dereferenced. So, an array, a list, a hash table, etc. > I've been greatly appreciating the uniformity of syntax, plus the fact > that I can write a function without caring a bit what sort of thing > THING is, so long as it has a REF (and maybe a setter) defined for it. > Sort of like ELT for associations.
Why didn't you make it as a macro? (I just wonder.)
>> However, Dylan is so far from that it might as well be in the next >> universe. You've got a much better shot with Java, frankly.
>Java might get the masses, but it's not in the heart of the wizards. >But it's the wizards who would be able to start such a project.
Dont be so sure... The Demeter project and aspectj ( adaptive and aspect oriented programming using extensions to java ) may spawn the next step after oop and functional programming. It is certainly wizardly enough for me
> Even Paul Graham, the > inventor of the silly new toy language "arc", needs to point out how > Common Lisp is superior to his new toy by knocking Common Lisp before he > has anything to show for himself.
How can you judge the sillyness of arc when it has not even been specified yet? (The articles he wrote about arc are very clever in my opinion.)
Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp. I remember whe we talked about free implementations of CL you were very angry and said something like it could not expected of anybody to give away his work for free, etc. Maybe Mr Graham will do this and then many of us will support him by buying his (O'Reilly)-book on arc (that hopefully will become Archlisp). Maybe he will give Lisp the bright future it deserves.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
k...@ashi.footprints.net (Kaz Kylheku) writes: > The decision about what language to use should be made on purely > technical and economic grounds, because the success of the software
You mean economic reasons like e.g. "Who's going to maintain your smart Lisp solution if you're hit by a bus?" Mindshare and the number of available programmers _are_ important.
In article <3C2A856C.52C5B...@his.com>, Feuer wrote: >Bruce Hoult wrote:
>> In article <3C27C7BC.DECCE...@quiotix.com>, Jeffrey Siegal >> <j...@quiotix.com> wrote:
>> > I consider Lisp syntax (or something similarly elegant) to be >> > essential. I suspect that many proponents of Dylan-like languages would >> > consider it unacceptable. I strongly suspect there is no middle ground.
>> I can happily use either. Or paren-less prefix (Logo, ML). Or postfix >> (PostScript, Forth). But even after much use of the others I find that >> I do prefer "conventional" syntax.
>The advantage of a language with significant syntax is that it allows the >programmer to quickly and easily write certain kinds of code. For example, ML >and Haskell syntax make it easy to write curried functions and function >applications, as well as infix operators. It would be quite annoying to call >a simple function by saying >(((foldl f) h) lst)
In Lisp, rather than Scheme, that would be:
(funcall (funcall (foldl f) h) lst)
A ``curried'' function in the first position of a list is not automatically called.
Now the *disadvantage* of significant syntax is that it allows the programmer to quickly and easily write the kinds of code that the language designer thought the programmer ought to be able to write quickly and easily. That approach assumes that the language designer can forsee how the language will be used, which could turn into a self-fulfilling prophecy.
If you don't like chaining the funcalls using nested expressions, you can invent some syntax which folds up the nesting, like
(chained-funcall #'foldfl f h lst)
Another way might be to do it as a mapper:
(mapchain #'start l-1 l-2 ... l-n)
where start has to be a function that takes as many arguments as there are lists. The first element from every list is taken, and turned into an argument list for start, which returns another function that takes as many arguments, and is used for the second elements of the list and so on.
Now, I have no idea how important it is to make this kind of chaining more convenient, or in what way. So if I were designing a language, I would view it as a grave mistake to introduce a special purpose syntax for it, given that people can just experiment with their own, and settle on solutions that are right for them. Then if a pattern of useful primitives emerges from the community, which many people find useful, their functions and macros can be incorporated into the language.
You also mentioned infix. You can find implementations of infix evaluators for Common Lisp, so if you really want infix, it's there.
The point is that special syntax is a really form of premature optimization. Worse, it's a form of optimization based entirely on guessing what is going to be needed. The resulting language might attract users who are looking for exactly that, so that the optimization later appears to have been correct.
In article <bruce-9D1859.18261626122...@news.paradise.net.nz>, Bruce
Hoult wrote: >- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to >read for some people.
Without some formal study, what is readable is just a guess.
Coming to Lisp after half a lifetime using programming languages that have some kind of infix assignment, I have no problem reading setf at all. (That is just anecdotal evidence based on my own experience, and does not extrapolate into what people find readable, hint, hint).
Even if the := notation is found more readable, it may not be wortwhile. What is more important is to be able to manage large, complex programs. Having a simple, programmable syntax is a way of trading some small-scale readability for a more significant goal.
The real question is whether the given language is a suitable target language for one's abstractions.
k...@ashi.footprints.net (Kaz Kylheku) writes: > In article <bruce-9D1859.18261626122...@news.paradise.net.nz>, Bruce > Hoult wrote: > >- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to > >read for some people.
> Without some formal study, what is readable is just a guess.
> Coming to Lisp after half a lifetime using programming languages that > have some kind of infix assignment, I have no problem reading setf at all. > (That is just anecdotal evidence based on my own experience, and does > not extrapolate into what people find readable, hint, hint).
The human visual systems has very low level feature dectors for finding vertical and horizontal lines. You can easily pick out a horizontal line hiding in a field of vertical lines. Just like picking out the green dot in a field of yellow is pretty easy. Having the human visual system parse "setf" takes quite a bit more work.
Most people should find the middle tasks the easiest. If there's any readability advantage to := I doubt it's an infix vs prefix issue. It's probably more low level. Syntax highlighting probably makes the difference go away completely.
skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjd f liwasetf
Do you come across strings like that frequently in your work? Are you using a Lisp *without parentheses*?
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
* Nils Kassube <n...@kassube.de> | You mean economic reasons like e.g. "Who's going to maintain your | smart Lisp solution if you're hit by a bus?" Mindshare and the number | of available programmers _are_ important.
That is why a smart Common Lisp programmer knows at least two other Common Lisp programmers who are willing to take over the code if he dies or whatever. Actually having an answer to this rhetorical question tends to blow the minds of those who ask it. Just because there are more C++ or Java programmers in the world, does not mean that you can find one that will _actually_ be able to take over a non-trivial project.
/// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.
>Do you come across strings like that frequently in your work? Are you using >a Lisp *without parentheses*?
Maybe he's using Fortran. When people developed Fortran, compiler writing was a completely new field. It didn't occur to anyone that removing all spaces in an early phase of translation was a bad idea. This led to atrocities, like the infamous:
DOI=1.3
versus
DOI=1,3
The first means assign 1.3 to variable DOI. The second indicates the start of a DO loop over the variable I from 1 to 3.
Andreas Bogk wrote: >>What happens in Java is that you have to at least declare the exceptions >>up the chain anyway (the compiler will reject a method that doesn't
> Yes, and that bothers me to no end. I want to have specific code that > knows about an exception in exactly two places: where it is generated, > and where it can be handled. All the code inbetween doesn't need to > know more than that an operation has failed and that it needs to clean > up.
[This is also a reply to Bruce's earlier comments.]
You will find views on both sides, not unlike the issue of static typing. It is not always the case that code that isn't written to be thrown through is safe; it may not clean up. Making sure that each method has the appropriate declarations is a way to catch these things at compile time. (Some methodological discipline is required to get any benefit out of this, of course, but when isn't it?)
>>I think what you'd see in any kind of production >>environment if Dylan were used is that almost everything would get >>sealed off, much the way a lot of Java code makes extensive use of >>"final." At that point, you might as well just use a static block >>compiler and let the compiler recognize what is subclassed and what >>isn't.
> I'd hate to use a static block compiler, the turnaround time would be > a nightmare.
You don't generally use a static block compiler when code is in active development. For example, I develop in DrScheme and then block compile with Stalin for performance tuning and production use.
> And I'd like to keep the option of adding classes and gf > methods at runtime.
Bruce Hoult wrote: > I suspect that this is pretty much where Scheme people on one hand and > CL and Dylan people on the other hand part ways. Everyone appreciates > generality and power when they need them, but the latter two groups also > value notational convenience for the common cases. Dylan expands the > "for" macro into a tail-recursive function (and CL does something > similar) precisely because many people find that easier to write, read, > and understand than the explicit tail-recursive form, for most common > cases.
What you snipped is that I rarely use explicit iteration in complex programs. I strongly prefer map-like forms, which are both conceptually powerful and notationally convenient. I don't usually write explicit iteration beyond the standard (let loop ...) idiom.
>>C was the exception of the 80s.
> So what was Pascal?
A flop basically. It had a short stint in academia, and as the programming langauge for the Macintosh, before being overrun by C, but there was very little use in commercial shops, which would be a necessity for a mainstram language.
>>C++ was heavily promoted by Microsoft
> !!!
> Microsoft didn't even *have* a C++ compiler until I'd been using the > language for three or four years. Wasn't 1.0 out in 1993 or so? Well, > it was total crap anyway, and VC++ wasn't really usable until 4.1 or 4.2 > or something like that.
That was well before C++ became a mainstream "hit."
Andreas Bogk <andr...@andreas.org> writes: > Jeffrey Siegal <j...@quiotix.com> writes:
> > What happens in Java is that you have to at least declare the exceptions > > up the chain anyway (the compiler will reject a method that doesn't
> Yes, and that bothers me to no end. I want to have specific code that > knows about an exception in exactly two places: where it is generated, > and where it can be handled. All the code inbetween doesn't need to > know more than that an operation has failed and that it needs to clean > up.
Well you actually do have the choice in Java. Just have your exceptions extend from RuntimeException or Error, and they are no longer required to be declared in the throws clauses.
Then you have the knowledge of the exception to be exactly in the desired places.
To "hide" the fact that you are possibly abusing the notion of "error", have a base application exception class extend from RuntimeException or Error, and have all you other exceptions extend from that.
Personally, though, I prefer having the explicit throws clauses, for then the compiler forces me to be aware of the error issues. At the very least I know to put in the necessary "finally" blocks and rethrow if handling the error is not appropriate.
I have not found the maintenance issue to be too bad. One trick is to rethrow in terms of a more general exception class, so that the methods in between the low level error and the final handler just have one or two exception classes in their throws clauses, as opposed to a miriad of particular ones (which cause the maintenance problem).
The mistake that a lot of Java programmers make is to simply swallow the unexpected exceptions with a stack trace and continue. This is the worst of all possibilities, defeating the purpose of exceptions in the first place.
-- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, bl...@telus.net The Rhythm has my soul.
"Janos Blazi" <jbl...@hotmail.com> writes: > > How many setfs? are in this string
> skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjd f > liwasetf
> Do you come across strings like that frequently in your work? Are you using > a Lisp *without parentheses*?
Even without parentheses the other task of picking out ":=" is *relatively* easier than the "setf" task. I'm sure that with parentheses *both* tasks get easier, but the relative difference is still there. You can argue that adding parenthesese makes both tasks so easy that the relative difference becomes meaningless. I personally do not think this is the case.
I don't have any Lisp code handy. However, if you take a larger piece of source code and ask humans to underline every occurence of "setf" in it. It will take them longer than a similar task where "setf" is replaced by ":=" even if you keep prefix notation... i.e.
(:= e1 e2) is easier to visually recognize than
(setf e1 e2) when dumped in a sea of program text.
If you let people syntax highlight things the task might get easier for setf. Anyway, that just my take on it. I don't have any real experimental evidence for it. However, I just described a relatively simple experiment you can do yourself. I'd happy to hear any evidence either way.
The ease of visually parsing programs is one reason why I prefer { } to BEGIN END. Picking out { and } is simply an easier task for the huuman visual system when compared to BEGIN END.
> Even without parentheses the other task of picking out ":=" is *relatively* > easier than the "setf" task.
But (:= a 5) is not very readable either and looks a bit clumsy as well. In this case I should prefer (= a 5) and (eq a 5) or something like this.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
----- Original Message ----- From: "Janos Blazi" <jbl...@hotmail.com>
Newsgroups: comp.lang.lisp
[I deleted comp.lang.functional and comp.lang.scheme from the header]
> [...] > > Even Paul Graham, the > > inventor of the silly new toy language "arc", needs to point out how > > Common Lisp is superior to his new toy by knocking Common Lisp before he > > has anything to show for himself.
> How can you judge the sillyness of arc when it has not even been specified > yet? (The articles he wrote about arc are very clever in my opinion.)
I think it is not dead wrong to criticize Paul G.'s plan to make the Common Lisp community (unsolicited) happy. I am not a computer scientist, but I am currently studying Lisp (after: P.H.Winston, Berthold K. Horn, "LISP, 3rd Edition").
I also have red Graham's proposal concerning Arc. But honestly speaking: nobody is interested in such a new dialect. The world doesn't need a new Lisp.We are polluted with a many hundred of computer languages.
I think it is highly questionable from Mr. Graham to believe he is entitled to make a new Lisp (yes, yes, he didn't clearly state it).
It is also dangerous to split the Lisp community again. Actually Lisp takes a stand on Java, C, C++,... A new Lisp dialect will only contribute to weaken Common Lisp its position.
> Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp.
My mother also is loving me. When I was a young boy, she actually urged me, that I should contemplate about to become a priest...
> Maybe he will give Lisp the bright future it deserves.
I hardly ever believe this will happen; Mixing postfix and prefix notation as with Arc is utterly insane.
Janos Blazi wrote: > But (:= a 5) is not very readable either and looks a bit clumsy as well. In > this case I should prefer (= a 5) and (eq a 5) or something like this.
I prefer (setf a 5) or (set! a 5) because it reads naturally ("Set a to five"). I'm not sure why being able to pick out these forms visually is an advantage anyway, any more so than any of the other forms one might use.
Bruce Hoult <br...@hoult.org> writes: > In article <xcvu1ud2ywr....@apocalypse.OCF.Berkeley.EDU>, > t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > > > - why do aref and gethash in CL have opposite argument orders?
> > > aref is also opposite to nth.
> > So I have a little generic function, REF, that I'd had sitting around > > unused for some time, and have recently been using all over the place. > > Its usage is (ref thing index1 ... indexn), where THING is anything > > that can be dereferenced. So, an array, a list, a hash table, etc. > > I've been greatly appreciating the uniformity of syntax, plus the fact > > that I can write a function without caring a bit what sort of thing > > THING is, so long as it has a REF (and maybe a setter) defined for it. > > Sort of like ELT for associations.
> I agree that such uniformity is great. Your REF would appear to be the > same as Dylan's "element" GF. Which is written as "element(collection, > key)" or using the sugar "collection[key]". Dylan also has > "element-setter(newVal, collection, key)", which can also be written as > "collection[key] := newVal".
> As you say, it's better to use the AREF ordering if you're going to make > one order fit all.
> Presumably your REF works with SETF?
Usually :-). When I write a getter method, I write a setter if it's easy. Sometimes (alists), it isn't. In that case, I wait til I get an error, then bite the bullet and write it. Or switch data structures, if I don't want to wait.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
<holych...@mail.ru> writes: > Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote: > > ... > > So I have a little generic function, REF, that I'd had sitting around > > unused for some time, and have recently been using all over the place. > > Its usage is (ref thing index1 ... indexn), where THING is anything > > that can be dereferenced. So, an array, a list, a hash table, etc. > > I've been greatly appreciating the uniformity of syntax, plus the fact > > that I can write a function without caring a bit what sort of thing > > THING is, so long as it has a REF (and maybe a setter) defined for it. > > Sort of like ELT for associations.
> Why didn't you make it as a macro? (I just wonder.)
Because there's no need to, and since I don't need any delayed evaluation, a generic function is more flexible.
(defgeneric ref (thing &rest subscripts))
Now, every time I define a new class (say, ENVIRONMENT for the compiler I'm writing, or BINARY-TREE, or anything), I can define a method for it, and use it with REF transparently. I suppose I could have defined it as
but I don't see the point. Except in the most boring cases [eg, (ref '((a . 1) (b . 2)) some-letter) ] REF can't know the type of THING until runtime. A more interesting thing to do might be to write a compiler macro that would take advantage of CMUCL's type inference to transform the call into a direct call to the appropriate method, but unless I've missed a section of the spec, there's no portable way to get at the contents of an environment object.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> I think it is not dead wrong to criticize Paul G.'s plan to make the Common > Lisp community (unsolicited) happy.
I agree with you but he is not criticising the plan, he is criticising the langauge that does not exist yet.
> I am not a computer scientist, but I am > currently studying Lisp (after: P.H.Winston, Berthold K. Horn, "LISP, 3rd > Edition").
> I also have red Graham's proposal concerning Arc. But honestly speaking: > nobody is interested in such a new dialect.
How can you tell? *You* are not interested, others may well be. Just wait and see.
> The world doesn't need a new > Lisp.We are polluted with a many hundred of computer languages.
I do not understand in which possible ways computer languages can constitute a pollution.
> I think it is highly questionable from Mr. Graham to believe he is entitled > to make a new Lisp (yes, yes, he didn't clearly state it).
Everybody is entitled to make a new lisp, even you or I. Are you afraid of Mr Graham's influence?
> It is also dangerous to split the Lisp community again. Actually Lisp takes > a stand on Java, C, C++,... A new Lisp dialect will only contribute to > weaken Common Lisp its position.
Again you cannot predict this at this state of play. It is possible that you are right but it is as well possible the other way.
> > Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp. > My mother also is loving me. When I was a young boy, she actually urged me, > that I should contemplate about to become a priest...
And you have actually become one... Or not? What is wrong with becoming a priest?
> > Maybe he will give Lisp the bright future it deserves. > I hardly ever believe this will happen; Mixing postfix and prefix notation > as with Arc is utterly insane.
Just wait and see. I posted some of his arguments here a few years ago but of course I could not put them so cleverly, smoothely and convincingly.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Bruce Hoult <br...@hoult.org> writes: > In article <3C2A03DC.649F6...@quiotix.com>, Jeffrey Siegal > <j...@quiotix.com> wrote:
> > Bruce Hoult wrote: > > > That's true only in the trivial sense that Lisp has no syntax, so Lisp > > > syntax can't be outgrown.
> > Hardly. It just has a syntax with a very simple and powerful basic > > construction rule. However, on top of that construction rule, > > enormously powerful syntactic abstractions can be (and are) built. What > > Algol-like languages lack is the basic construction rule which allows > > you to decompose the syntax down into elemental componets. That makes > > any macro system either enormously complex or lacking in power, or both.
> > Consider, for example, what low-level Lisp macros would look like in an > > Algol-like language. They can be done but the result is enormously > > complex (and also fragile; if the language syntax is extended, macros > > written that way will likely break).
> There are examples of the same thing happening in reverse. When macros > get sufficiently complex and have enough combinations of different > possibilities, it becomes too difficult to follow a purely S-expresion > syntax. Consider the example of the Dylan "for" macro. How would you > map all that functionality and all those options onto an S-expression > syntax? Well, we can look at what is done in Common Lisp with the > "loop" macro. The same idea, very nearly exactly the same options. And > we find that in fact it does *not* use S-expression syntax, but instead > makes a little infix language that ends up very similar to that part of > Dylan.
But this is an intentional feature of LOOP, it's a little Algol-like mini-language inside of CL. There are other non-standardized packages that provide similar functionality, but use a more lispy approach. One thing that's missing from LOOP as specified in the spec is any way to extend it. Which is too bad, because that would make it even more useful, but this is a (mis)feature of the spec, and isn't inherent in a LOOP macro. MIT LOOP has such a feature, for example.
> Now, I happen to think that the "loop" macro is a *good* thing about > Common Lisp, but:
> 1) building such things yourself isn't well supported in CL (it is in > Dylan)
That's because it's a weird exception in CL. Complicated macros that define a Lispy mini-language *are* well supported, and there's nothing about iteration that makes it require a LOOP-like syntax.
> 2) I find that I actually *prefer* this sort of thing to have infix > syntax, and prefer all loops and other control structures to use it. If > nothing else, it means that you know immediately whether you're looking > at a standard function application or a special form. That's what Dylan > does.
I'm not sure what to say to this. It's usually pretty obvious if something isn't a function call, unless it's supposed to behave like one, in which case, I like that there isn't a visual distinction. If you can't spot
as a macro call, you just haven't read enough Lisp.
In a later post, you mention DO (which is also a Lisp macro). I tend to think of it as a low-level iteration construct, mostly appropriate for building sugary facilities on top of, much like TAGBODY and GO.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> > skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjd f > > liwasetf
> > Do you come across strings like that frequently in your work? Are you using > > a Lisp *without parentheses*?
> Even without parentheses the other task of picking out ":=" is *relatively* > easier than the "setf" task. I'm sure that with parentheses *both* tasks get > easier, but the relative difference is still there. You can argue that > adding parenthesese makes both tasks so easy that the relative difference > becomes meaningless. I personally do not think this is the case.
> I don't have any Lisp code handy. However, if you take a larger piece of > source code and ask humans to underline every occurence of "setf" in it. It > will take them longer than a similar task where "setf" is replaced by ":=" > even if you keep prefix notation... i.e.
> (:= e1 e2) > is easier to visually recognize than
> (setf e1 e2) > when dumped in a sea of program text.
But how often are you looking at a sea of program text? I'm usually looking at a specific part of a program, in which case setting is one of many things that can be done, and I can't think of any reason I'd care so much more about it than anthing else the program could be doing. If you want to find all the instances where e1 is assigned to, use your editor's search facility. And if you really prefer :=, you can define (defmacro := (&rest stuff) (cons 'setf stuff)) That's a bad idea, not the least because := is the symbol (intern "=" "KEYWORD"), but you could use the more visually telling <- if you wanted:
(<- e1 e2 (gethash 'e h1) e2)
But I find that a lot uglier than
(setf e1 e2 (gethash 'e h1) e2)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> > Even Paul Graham, the > > inventor of the silly new toy language "arc", needs to point out how > > Common Lisp is superior to his new toy by knocking Common Lisp before he > > has anything to show for himself.
> How can you judge the sillyness of arc when it has not even been specified > yet? (The articles he wrote about arc are very clever in my opinion.)
One way is to read his webpage about it, cited at the beginning of this thread. I did, and it seemed to me that his ideas were wrong-headed.
t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes: {stuff deleted}
> But how often are you looking at a sea of program text? I'm usually > looking at a specific part of a program, in which case setting is one > of many things that can be done, and I can't think of any reason I'd > care so much more about it than anthing else the program could be > doing. If you want to find all the instances where e1 is assigned to, > use your editor's search facility. And if you really prefer :=, you > can define
Scheme/Lisp has uniform syntax. This makes it easier to play all sorts of crazy macro games with. The :=/setf example is one where Algol languages trade the uniformity of syntax for readability. IMNHO readability has less to do with infix/prefix issues than with uniform/non-uniform. My only claim is that choosing too uniform a syntax can effect readability, and that these readability issues are not just a matter of taste, but have some connection with basic visual processing.
Graphic artist get paid to design logos and visual designs that are easy to parse quickly. They manipulate color, layout, and shape to make things easier to visually parse. Properly indented and syntax highlighted Scheme/Lisp is pretty easy to read. Languages with non-uniform syntax that use infix and more punctuation do not need to rely soo much on indentation or color cues to acheive the same level of readability.
> > But (:= a 5) is not very readable either and looks a bit clumsy as > > well. In > > this case I should prefer (= a 5) and (eq a 5) or something like this.
> I prefer (setf a 5) or (set! a 5) because it reads naturally ("Set a to > five"). I'm not sure why being able to pick out these forms visually is > an advantage anyway, any more so than any of the other forms one might > use.
Because when you're programming in a mostly-functional language you want to have the places that use mutation readily obvious.
