Donal K. Fellows (fellowsd...@man.ac.uk) wrote: : > the SPARC architecture has several instructions that C compilers doesn't : > use, but which are convenient with type-tagged languages. the _fact_ is : > that it has an the instruction, with Sun's recommended mnemonic "taddcctv", : > that is specifically useful in Lisp, and specifically unused in C. other : > instructions are also measurably useful in languages _other_ than C. : : What does the instruction do? I've not got a SPARC manual to hand and : I'm quite sure that there are other people reading this thread who are : also unaware of the meaning of that instruction.
The Sparc architecture has support for a "tagged integer" data type. The two low-weight bits of a tagged word contain a tag, the other bits contain a 30-bit integer. The two provided operations (add and substract) work as one would expect on words with tag=0. With other values, they generate an overflow error. taddcctv (resp. tsubcctv) adds (resp. subtracts) two tagged words, sets the condition codes (cc) and traps on overflow; alternatively, one may use taddcc/tsubcc, which do not trap.
This is meant for use with dynamically typed languages. Integers are tagged 0, and the most commonly used operations (add/sub) on them work transparently. Pointers are tagged with 1, 2 or 3. If a pointer is mistakenly used as an integer, it generates an error (and maybe a trap). To compensate for the tag, data is accessed with relative offsets -1, -2 or -3 respectively from a tagged pointer. As words are 4-byte aligned, addressing data with the wrong offset generates a bus error. That is, data with one tag used mistakenly as if it were to bear another tag make the processor trap.
(all this taken from "The Sparc architecture manual, version 8").
The tags may be used by the garbage collection process to see what words contain integers and what words contain pointers. I do not have examples of implementations using the Sparc tagged arithmetic, but the only garbage collecting implementation I know quite well, Objective CAML, tags data using the lowest weight bit.
Hope this helps.
-- David
PS: Sorry, but the overall aggressive tone of the discussions around ("You aren't competent on that topic! - Yes, I am, it's you who don't know anything about what is talked of!") disturb me. We should spend more time actually working on improving computer languages, tools and libraries, and less arguing about, as Xavier Leroy said, whether angels are male or female. :-)
PS2: I've trimmed the followup-to. If we are to discuss generally upon the use of processor features for garbage collection and sanity checks in garbage-collected language, I think we can restrict ourselves to comp.lang.functional...
* Thant Tessman | more energy has gone into developing C++'s tools than has gone into | developing tools for any of the far superior languages that exist.
* Andrew Koenig | Which suggests that perhaps your opinion of what is superior is not | universal.
the odd thing about energy and superiority is that more work is always _necessary_ on the inferior product than on the superior. we also observe that much more is published on inferior products than on superior products, such as on virus detection and protection for Microsoft "operating systems", such as undocumented features in MS-DOS to make the machine perform reasonably fast in the display subsystem of games, etc. we find that the more someone is dissatisfied with his working environment, the more fuss they make, too. the whole of USENET can be seen as evidence that people do not write articles to express their agreement with each other.
it is rather curious that someone who _must_ know better argues that the superiority of something and the energy poured into it are not inversely related. or are you saying that C++ is a superior language for the same reason that MS-DOS is a superior operating system, Andrew?
that said, the draft subject to the second ISO CD registration vote for C++ contains remarkably good work in the standard template library. it's a pity all that energy is wasted on C++. "what a magnificent waste!"
#\Erik -- if we work harder, will obsolescence be farther ahead or closer?
In article <3071563530695...@naggum.no> Erik Naggum <e...@naggum.no> writes: > * Andrew Koenig > | Which suggests that perhaps your opinion of what is superior is not > | universal. > it is rather curious that someone who _must_ know better argues that the > superiority of something and the energy poured into it are not inversely > related. or are you saying that C++ is a superior language for the same > reason that MS-DOS is a superior operating system, Andrew?
I am saying just what I said before, which is that not everyone has the same opinion about what is superior to what. Such divergence of opinion is usually called `personal taste,' and the more I see of the world, the more I realize just how divergent people's tastes really are. -- --Andrew Koenig a...@research.att.com http://www.research.att.com/info/ark
>>>>> "EN" == Erik Naggum <e...@naggum.no> writes:
EN> let's make it:
EN> X: C++ is lousy because of FOO.
EN> Y: FOO/n is true of C, etc
EN> X: but n is a huge number! C++ _multiplies_ most weaknesses of C by EN> this huge number, and does very little to alleviate any others.
EN> Y: no direct, rational response is possible.
Er... Where did you drop the army shoes?
-- Marc Girod Phone: +358-9-511 63331 Nokia Telecommunications Valimo 1/2 Fax: +358-9-511 63310 Information Networking Systems P.O. Box 315 Mobile: +358-40-5051853 00045 NOKIA Group Finland marc.gi...@ntc.nokia.com
Since that was what started the thread: ML is such a ^^^^^^^^^^^^ language, and it gets this issue exactly right. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not so sure. Let me give you some examples:
1. We all agree that that EQUAL? should not be defined on procedures. Because EQUAL? is defined extensionally and equality of procedures is undecidable. But it is nonetheless *useful* to compare *intensions* of procedures (i.e. representations of procedures, in other words code pointers) for equality. Inter alia, this arrises in the following situation. Suppose I had a representation of logic variables. And I could attach constraints to them. For efficiency, I would want to make sure that the same constraint doesn't get attached multiple times.
(define-structure logic-variable value constraints)
Now, I can't do (MEMBER CONSTRAINT (LOGIC-VARIABLE-CONSTRAINTS LOGIC-VARIABLE)) because this uses EQUAL? which is undefined on procedures. But procedures (at least ones without closures) are immutable. So I can't do (MEMQ CONSTRAINT (LOGIC-VARIABLE-CONSTRAINTS LOGIC-VARIABLE)) either because this uses EQ?. But I *want* to be able to do this. Because it is *useful*. It can reduce the complexity class of many algorithms. IMHO, this is an issue that ML gets dead wrong and Scheme gets almost right.
2. Scheme doesn't get this quite right either. In fact, no language that I know of gets this right. As the following example shows. We already said that EQUAL? is undefined on procedures. And EQ? only really works on procedures without closures. (Ignore for the moment that it is undecidable whether a procedure requires a closure: (lambda (x) (lambda () (if (goldbachs-conjecture-is-true?) x #f)))) Suppose, using the above example, I wish to do:
(define (assert->! x n) (assert! (lambda (y) (> y n)) x)) (let ((x (create-logic-variable))) (assert->! x 1) (assert->! x 1))
In order to not redundantly assert the same constraint twice, I need to compare closures for equivalence. I can't do that in Scheme (or ML, or any language that I know of). Extending EQUAL? to compare closures is really not the right thing to do because EQUAL? does a comparison of unbounded depth. Often, I want to do something between EQ? and EQUAL?. Like:
So I need to be able to build my own equality predicates. To do that I need component accessors. In Scheme, I can access pair and structure slots, and I can access vector and string elements. But I can't access closure slots.
3. This leads to a third example. One that doesn't involve procedural equality. But does involve shallow versus deep comparisons. Suppose I wish to represent sets as lists without duplicates. And I have the usual complement of procedures to do so. Such procedures ultimately must compare objects for equality to build the notion of duplicate. Now suppose I wish to have sets of circular objects. In most existing implementations, the only way to create circular objects is by mutation. But one could imagine situations where I only mutated objects to create circular representations and then never mutated them again. And one could imagine a language that allowed me to declare such objects as immutable after their creation. Or one could imagine an implementation that infered that such objects were immutable after their creation. I can't compare such objects for equality using EQUAL? because EQUAL? won't terminate on circular objects. (Though I could make a version of EQUAL? that did work.) So I might want to use EQ?. But I can only do so if EQ? works on immutable objects. And even if I could use EQUAL? (either because I made a circular version or because I wasn't using circular object), I might have large objects and I might intern them precisely so I could later compare them with EQ? instead of EQUAL?
> * Thant Tessman > | more energy has gone into developing C++'s tools than has gone into > | developing tools for any of the far superior languages that exist.
> * Andrew Koenig > | Which suggests that perhaps your opinion of what is superior is not > | universal.
> the odd thing about energy and superiority is that more work is always > _necessary_ on the inferior product than on the superior. we also observe > that much more is published on inferior products than on superior products, > such as on virus detection and protection for Microsoft "operating > systems", such as undocumented features in MS-DOS to make the machine > perform reasonably fast in the display subsystem of games, etc. we find > that the more someone is dissatisfied with his working environment, the > more fuss they make, too. the whole of USENET can be seen as evidence that > people do not write articles to express their agreement with each other.
> it is rather curious that someone who _must_ know better argues that the > superiority of something and the energy poured into it are not inversely > related. or are you saying that C++ is a superior language for the same > reason that MS-DOS is a superior operating system, Andrew?
> that said, the draft subject to the second ISO CD registration vote for C++ > contains remarkably good work in the standard template library. it's a > pity all that energy is wasted on C++. "what a magnificent waste!"
Being responsible for the standard template library, I could assure you that C++ does have merits. I tried to implement STL in a variety of languages and failed. I had a very modest goal - to be able to express linear search in a such way that it would work for any data structure for which it makes sense. C++ was the only language in which I could do it. There are many things I do not like about it - OOP is the main example. There are some things that I really miss - an ability to describe conforming families of types (iterators, for example). But I still do not know any other language in which I could express what I wanted to express. I teach a course on Generic Programming at my place of work, and while I curse C++ constantly during my lectures, I still use it.
Do I mean to say that C++ is the ultimate programming language? Perish the thought! We do need a better programming language. But I do not believe that anything better already exists. And, yes, I tried Scheme, ML, Ada, Java... And I tried them quite seriously, spending years on every fad that comes out of POPL.
So there is at least one person who believes that C++ with all its flaws is the most remarkable piece of work in programming languages since C, and that any future progress in programming languages must be based on lessons of C++.
> #\Erik > -- > if we work harder, will obsolescence be farther ahead or closer?
Jeffrey Mark Siskind <q...@ai.emba.uvm.edu> wrote in article <xoh207phlrq....@ai.emba.uvm.edu>...
> 1. We all agree that that EQUAL? should not be defined on procedures. Because > EQUAL? is defined extensionally and equality of procedures is undecidable. > But it is nonetheless *useful* to compare *intensions* of procedures (i.e. > representations of procedures, in other words code pointers) for
equality.
Let me clarify. Pointer-equality is a useful thing -- I didn't contest that. I claimed that the ability to write code that specifies that a value (be it a cons-cell, closure, or integer) is immutable is an important thing to have, be it for program reasoning purposes or for optimization.
As long as Pointer-equality is defined as in languages like O'Caml, it disrupts neither reasoning nor optimization, simply because the compiler is free to return "false" even if two references appear to be pointing to the same object at the source-level (e.g., "let x = (a,b) in x == x end" may evaluate to true or false, depending upon the implementation.)
> 2. Scheme doesn't get this quite right either. In fact, no language that I > know of gets this right.
Agreed. Non-deterministic semantics aside, a general conservative pointer equality predicate (in the style of O'Caml but extended to cover all values) is generally useful. A hash function or in general, an order on all values would also be useful, but requires considerably more support in the presence of a copying garbage collector.
It's truly ironic that Scheme requires a non-deterministic semantics in order to deal with the argument evalution order issue, but doesn't extend eq to closures.
Alexander Stepanov wrote: > So there is at least one person who believes that C++ with all its flaws is > the most remarkable piece of work in programming languages since C, and that > any future progress in programming languages must be based on lessons of C++.
Yes, I can see myself saying exactly the same words, but I'd probably intend them to mean something else.
> the odd thing about energy and superiority is that more work is always > _necessary_ on the inferior product than on the superior.
taking something like lisp and building hardware, user interfaces, complex environments etc. around it seems like lot more work than what was typically expected for an average language; you have either just proven lisp machines were somehow inferior, or the relationship between energy and superiority is nowhere near as simple as you would prefer...
Andrew Koenig <a...@research.att.com> writes: > x(y);
No one would write a declaration like that.
In real man's C, every user-defined type begins with "struct", and we like it that way. This style has several real advantages.
Letting users add type names is some new-fangled OO thing, but it does have its merits. We know that it adds some feedback into the parser, but once this is done, it's case closed on any example like above.
In article <BITMEADC.97Apr29134...@Alcatel.com.au> Chris Bitmead uid(x22068) <Chris.Bitm...@Alcatel.com.au> writes:
>True, but also C++ takes the issue to new levels of obscurity.
It's sublime.
In normal C, a block has some declarations, a blank line, then what follows is executable code. (I never use local initializers myself.) It just doesn't happen that anyone could confuse the two.
With C++, anything goes, and you just never know. It's a good joke if you're in the right mood and you don't really need your program to work. The exact same thing can be a declaration or executable code depending on what you had for dinner, and don't look at it funny either.
Being responsible for the standard template library, I could assure you that C++ does have merits. I tried to implement STL in a variety of languages and failed. I had a very modest goal - to be able to express linear search in a such way that it would work for any data structure for which it makes sense. C++ was the only language in which I could do it.
Your comparative language experiences would make a great article (or book). Any chance you've published an account of your various attempts anywhere?
In article <336A4D79.4...@mti.sgi.com>, Alexander Stepanov wrote: >Being responsible for the standard template library, I could assure you that >C++ does have merits. I tried to implement STL in a variety of languages >and failed. I had a very modest goal - to be able to express linear search >in a such way that it would work for any data structure for which it makes >sense. C++ was the only language in which I could do it.
Really? How odd. Why couldn't this be done in Smalltalk, Eiffel, or Java?
My biggest gripes with STL is that it's inefficient and bloated (ie, you store objects directly meaning that full copies must be made often when manipulating things; and you get the *entire* class in a template, not just a template that provides a type safe wrapper to a library). I could live with such problems if the C++ experts would actually admit they're problems rather than cite these as benefits (which implies they're not going to bother fixing them).
In article <5k45qk$4k...@goanna.cs.rmit.EDU.AU>, o...@goanna.cs.rmit.EDU.AU
(Richard A. O'Keefe) wrote: > Of all people, Ousterhout should know that Sun have a very nice > Scheme implementation which is freely available. It's called "esh" > (I believe it originally stood for 'embeddable shell' hint hint). > And it offers the smoothest simplest interoperation with C that I > have ever seen. I do wish Sun would either make it a product or > else release the sources so that someone else could. Is the attempt > to pretend that Scheme _can't_ work well with C really an piece of > internal politicking against the ESH people?
With a mighty <E9J3Fx....@research.att.com>, a...@research.att.com uttered these wise words...
> Which suggests that perhaps your opinion of what is superior is not universal.
No opinions are universal.
Followups set to comp.lang.misc. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Programmer and Information Broker | London, UK Please note: my email address is gubbish.
In article <slrn5mkihg.32v.da...@connectnet1.connectnet.com> da...@usa.net.delete_me (Darin Johnson) writes:
> There are three conflicting trains of thought on this. > 1) Things that are superior become popular. > 2) Things that are popular are claimed to be superior. > 3) Superiority and popularity are unrelated.
I believe
4) Saying that one thing is superior to another is meaningful only in context, which usuallly includes a purpose.
Anyone who claims, for example, that a Ferrari is superior to a Ford without considering context is cordially invited to try to get a Ferrari up my driveway with two inches of snow on it. In that context, a Ferrari is probably useless and a Ford is so-so, unless it happens to have four-wheel drive, in which case it might be OK.
If you don't agree on a context before comparing tools, the result of the comparison is unlikely to have any useful meaning. -- --Andrew Koenig a...@research.att.com http://www.research.att.com/info/ark
In article <5ke17p$...@shellx.best.com> Joe Keane <j...@jgk.org> writes: > In real man's C, every user-defined type begins with "struct", and we > like it that way. This style has several real advantages.
Don't make the mistake of believing that your taste is universal.
> In normal C, a block has some declarations, a blank line, then what > follows is executable code. (I never use local initializers myself.) > It just doesn't happen that anyone could confuse the two.
That's simply not true. Such ambiguities exist in C as well:
typedef int x;
void f() { const x; /* ? */ }
Is the line with the comment a redeclaration of x as a variable of type `const int' or is it a declaration of an empty list of variables of type `const x' ? C needs a special disambiguating rule to handle this case.
> With C++, anything goes, and you just never know. It's a good joke if > you're in the right mood and you don't really need your program to work. > The exact same thing can be a declaration or executable code depending > on what you had for dinner, and don't look at it funny either.
Have you ever heard of the Obfuscated C contest?
People can write incomprehensible trash in C, or in C++, or in any language. They can also write crystal-clear programs.
> I'm with Mr. Naggum here. I think Mr. Koenig's argument is like saying, > someone once broke wind, so we might as well set off the hydrogen bombs.
Alexander Stepanov wrote: > Being responsible for the standard template library, I could assure you > that C++ does have merits. I tried to implement STL in a variety of > languages and failed. I had a very modest goal - to be able to express > linear search in a such way that it would work for any data structure for > which it makes sense. C++ was the only language in which I could do it. > [...] And, yes, I tried Scheme, ML, Ada, Java... And I tried them quite > seriously, spending years on every fad that comes out of POPL.
I will admit that templates and the STL are utterly amazing creations given the fact that it's C++, but I find the above VERY hard to believe.
Here's why: I've implemented function overloading in Scheme using macros. This, plus Scheme's dynamic type system gives the programmer just as much genericity (if not more genericity) in Scheme as in C++. My implementation was of course slower than C++'s templates (because dispatching on overloaded functions was done dynamically), but believe me it was far easier to implement than the STL (let alone templates). And the programming language Dylan provides this expressiveness at the language level giving the compiler the chance to statically dispatch when possible in order to provide good performance.
As for SML, C++'s template functions are a pale imitation of SML's support for generic polymorphism, and C++'s template classes are a pale imitation of SML's functors. There are differences, some possibly in C++'s favor. For example, SML doesn't allow overloaded functions. But to the degree that overloaded functions are resolved statically, overloading is merely syntactic sugar. And to the degree that they are resolved dynamically (via virtual member functions in the case of C++), we're talking OO, which you said you don't like.
Another difference between SML's functors and C++' templates is that templates are generiated automatically in pieces as needed. Although some people hate this, I happen to think this is cool, and I suspect that this is at the heart of any advantage you may think C++ has over SML. This latter property of templates has allowed me to do some truly scary things with templates that I don't think I could do using functors. But the template tricks I've come up with are UNIVERSALLY used to get around the other problems of C++.
As for the STL itself, as cool as it is, it really comes off as being an attempt to make it easier to do the kind of things in C++ that have always been easy in other languages. I welcome examples to the contrary if they exist.
***
Alexander Stepanov's dissillusionment with OO reminds me of something I've been thinking about for a while. Object-oriented methodology is a collection of techniques for managing program complexity. A very large "a-ha" for me was that higher-order functions could be used to build OO systems. Therefore, higher-order functions are a more fundamental/powerful concept than OO.
(The only reason to build OO into the language (as opposed to providing it in a library) is to give the compiler the chance to optimize on those techniques, which is why Dylan, for example, provides both higher-order functions and OO.)
The strange thing is that I've never seen a defender of C++ acknowledge the power of higher-order functions. Higher-order functions are simply functions that build other functions. But I can't help but get the impression that the defenders of C++ just don't get it. This would explain why they feel it is necessary to build all this other complex machinery.
Joe Keane wrote: > [...] In real man's C, every user-defined type begins with > "struct", and we like it that way. This style has several > real advantages. [...]
When you want to start a fire by rubbing two sticks together, is it more important for the sticks to be pointy or rounded?
In <x6vi51eu0y....@ds9.rnd.border.com>, o...@ds9.rnd.border.com (ozan s. yigit) writes:
>Erik Naggum:
>> the odd thing about energy and superiority is that more work is always >> _necessary_ on the inferior product than on the superior.
>taking something like lisp and building hardware, user interfaces, complex >environments etc. around it seems like lot more work than what was typically >expected for an average language; you have either just proven lisp machines >were somehow inferior, or the relationship between energy and superiority >is nowhere near as simple as you would prefer...
>oz
From my understanding, the Lisp machines were built on an already existing environment (that had been used at MIT for quite some time already).
In article <336B72C8.4...@nospam.acm.org> Thant Tessman <th...@nospam.acm.org> writes: > I will admit that templates and the STL are utterly amazing creations > given the fact that it's C++, but I find the above VERY hard to believe.
It's easy to toss gratuitous insults into what you say, but that doesn't make your statements any more or less valid.
> Here's why: I've implemented function overloading in Scheme using > macros. This, plus Scheme's dynamic type system gives the programmer > just as much genericity (if not more genericity) in Scheme as in C++. > My implementation was of course slower than C++'s templates (because > dispatching on overloaded functions was done dynamically), but believe > me it was far easier to implement than the STL (let alone templates). > And the programming language Dylan provides this expressiveness at the > language level giving the compiler the chance to statically dispatch > when possible in order to provide good performance.
Perhaps Alex will confirm the following: He said that C++ was the only language in which he could implement linear search so that it would work on any reasonable data structure, but I suspect he may have omitted to add ``without substantial run-time overhead compared to a straightforward hand-coded solution.''
I do not think it's particularly difficult to write a generic linear search in any of a number of languages, but it invariably runs much more slowly than the same algorithm recoded for the particular data structure being searched.
> As for SML, C++'s template functions are a pale imitation of SML's > support for generic polymorphism, and C++'s template classes are > a pale imitation of SML's functors. There are differences, some > possibly in C++'s favor. For example, SML doesn't allow overloaded > functions. But to the degree that overloaded functions are resolved > statically, overloading is merely syntactic sugar. And to the degree > that they are resolved dynamically (via virtual member functions in > the case of C++), we're talking OO, which you said you don't like.
C++ template functions aren't an imitation of SML, because Bjarne was unfamiliar with SML when he designed templates. Moreover, there are significant differences between the two notions. See, for example, my article ``An Example of Language-Sensitive Design'', in the Journal of Object-Oriented Programming, Vol. 8, no. 4. The gist of that article is to show a C++ program that, translated directly into SML, yields a lousy SML program. If we redesign the program to fit well with SML, and then try to translate it to C++, we get a lousy C++ program. The point is that the two languages have different enough views of the world that the same techniques just don't apply.
> Another difference between SML's functors and C++' templates is that > templates are generiated automatically in pieces as needed. Although > some people hate this, I happen to think this is cool, and I suspect > that this is at the heart of any advantage you may think C++ has over > SML. This latter property of templates has allowed me to do some truly > scary things with templates that I don't think I could do using functors. > But the template tricks I've come up with are UNIVERSALLY used to get > around the other problems of C++.
Well, if you start with the attitude that the language is full of problems to be overcome, you'll certainly find them. That's true of any language.
> As for the STL itself, as cool as it is, it really comes off as being > an attempt to make it easier to do the kind of things in C++ that have > always been easy in other languages. I welcome examples to the contrary > if they exist.
The thing I find particularly interesting about STL is not that it makes it easier to do things in C++ that I could already do in other languages. Rather, STL makes it easier to do things EFFICIENTLY in C++ that I could not do efficiently in ANY other language readily available to me.
It is very easy to write a library in any of a number of languages that will sort a generic data structure, but that library will probably do a dynamic type dispatch for every comparison. What's nice about C++ templates is that that dynamic type dispatch is done at compile time, and is used as a way of getting the compiler to lay down appropriate code at run time. Other languages I have seen either don't do that at all, or make it substantially harder. Of course a counterexample may exist, but if it does, it doesn't seem to be a widespread part of current practice.
> Alexander Stepanov's dissillusionment with OO reminds me of something > I've been thinking about for a while. Object-oriented methodology > is a collection of techniques for managing program complexity. A > very large "a-ha" for me was that higher-order functions could be > used to build OO systems. Therefore, higher-order functions are > a more fundamental/powerful concept than OO.
I suspect that they are a dual, in the logical sense. OO: `Everything is data, even programs' FP: `Everything is program, even data'
> (The only reason to build OO into the language (as opposed to > providing it in a library) is to give the compiler the chance to > optimize on those techniques, which is why Dylan, for example, > provides both higher-order functions and OO.)
I think there are other reasons as well. OOP is particularly useful for simulations, and lots of commercial applications involve simulation in one way or another.
> The strange thing is that I've never seen a defender of C++ > acknowledge the power of higher-order functions. Higher-order > functions are simply functions that build other functions. But > I can't help but get the impression that the defenders of C++ just > don't get it. This would explain why they feel it is necessary to > build all this other complex machinery.
Perhaps you haven't looked hard enough. You might start with STL function adaptors, which are nothing more or less than higher-order functios, or come to my Usenix tutorial at the COOTS conference this June, which will talk a good bit about how to use templates to simulate higher-order functions in C++. I will completely agree with you that it would be nice if C++ had a more direct way of supporting higher-order functions, but that desire is mostly abstract -- in practice I don't see it getting in the way of using C++ to solve problems that arise for real. -- --Andrew Koenig a...@research.att.com http://www.research.att.com/info/ark
<schaf...@wat.hookup.net.this.should.stop.spam> wrote: >From my understanding, the Lisp machines were built on an already existing >environment (that had been used at MIT for quite some time already).
Nope, they were essentially built from scratch from the ground up. The people who wrote the LispM OS had previously implemented ITS, a timesharing OS for PDP-6 and PDP-10 systems, and implemented ITS MacLisp. So they had experience in OS and Lisp design and implementation, but the LispM environment is at all like ITS (in fact, it has more high-level conceptual similarities with Multics than ITS). -- Barry Margolin BBN Corporation, Cambridge, MA bar...@bbnplanet.com (BBN customers, call (800) 632-7638 option 1 for support)
> In article <336B72C8.4...@nospam.acm.org> Thant Tessman <th...@nospam.acm.org> writes:
> > I will admit that templates and the STL are utterly amazing creations > > given the fact that it's C++, but I find the above VERY hard to believe.
> It's easy to toss gratuitous insults into what you say, > but that doesn't make your statements any more or less valid.
> > Here's why: I've implemented function overloading in Scheme using > > macros. This, plus Scheme's dynamic type system gives the programmer > > just as much genericity (if not more genericity) in Scheme as in C++. > > My implementation was of course slower than C++'s templates (because > > dispatching on overloaded functions was done dynamically), but believe > > me it was far easier to implement than the STL (let alone templates). > > And the programming language Dylan provides this expressiveness at the > > language level giving the compiler the chance to statically dispatch > > when possible in order to provide good performance.
> Perhaps Alex will confirm the following: He said that C++ was the only > language in which he could implement linear search so that it would work > on any reasonable data structure, but I suspect he may have omitted to > add ``without substantial run-time overhead compared to a straightforward > hand-coded solution.''
While what you are saying is true, the amazing fact is that I could not even do a slow generic linear search in Scheme. I taught a graduate course in algorithm design based on Scheme for 10 consequitive semesters. (There are almost 500 students who had been exposed to my ridiculous attempts to express complex algorithms in a language that hides memory, - I have been fortunate, however, since none of them had taken me to court.) Time after time, I tried to generalize over vectors and lists, and failed. Common Lisp is an example of the similar attempt: the position function returns an integer index for both list and vector if an element is found and nil otherwise. It is a not very useful result for lists - using integers as iterator for all the sequence types is plainly not what one needs. It is equaly important to see how subranges are dealt with: keyword arguments :start and :end are integers - not a very useful choice for lists.
> I do not think it's particularly difficult to write a generic linear > search in any of a number of languages, but it invariably runs much more > slowly than the same algorithm recoded for the particular data structure > being searched.
> > As for SML, C++'s template functions are a pale imitation of SML's > > support for generic polymorphism, and C++'s template classes are > > a pale imitation of SML's functors. There are differences, some > > possibly in C++'s favor. For example, SML doesn't allow overloaded > > functions. But to the degree that overloaded functions are resolved > > statically, overloading is merely syntactic sugar. And to the degree > > that they are resolved dynamically (via virtual member functions in > > the case of C++), we're talking OO, which you said you don't like.
> C++ template functions aren't an imitation of SML, because Bjarne was > unfamiliar with SML when he designed templates. Moreover, there are > significant differences between the two notions. See, for example, > my article ``An Example of Language-Sensitive Design'', in the Journal > of Object-Oriented Programming, Vol. 8, no. 4. The gist of that article > is to show a C++ program that, translated directly into SML, yields a > lousy SML program. If we redesign the program to fit well with SML, > and then try to translate it to C++, we get a lousy C++ program. The > point is that the two languages have different enough views of the world > that the same techniques just don't apply.
Well, a world recognized ML authority spent some time working with me on - guess what - expressing linear search. I still have a long message from him explaining why it could not be done. I would gladly switch to ML if somebody can show me how I can express what I want to express in it. I have no personal stake in C++. I use it as a tool. And both Bjarne and Andy could attest to my long standing criticism of some of its main features.
> > Another difference between SML's functors and C++' templates is that > > templates are generiated automatically in pieces as needed. Although > > some people hate this, I happen to think this is cool, and I suspect > > that this is at the heart of any advantage you may think C++ has over > > SML. This latter property of templates has allowed me to do some truly > > scary things with templates that I don't think I could do using functors. > > But the template tricks I've come up with are UNIVERSALLY used to get > > around the other problems of C++.
> Well, if you start with the attitude that the language is full of problems > to be overcome, you'll certainly find them. That's true of any language.
> > As for the STL itself, as cool as it is, it really comes off as being > > an attempt to make it easier to do the kind of things in C++ that have > > always been easy in other languages. I welcome examples to the contrary > > if they exist.
I guess you are a much better programmer than I am, since you find that it is easy to do what I find totally impossible. If you ever come to the Bay Area, please stop by and give a talk on library design to our group. (The remark is addressed to Thant Tessman, and not to Andy Koenig. Andy, however, is always welcome too, and I hope that he knows it.)
> The thing I find particularly interesting about STL is not that it makes > it easier to do things in C++ that I could already do in other languages. > Rather, STL makes it easier to do things EFFICIENTLY in C++ that I could > not do efficiently in ANY other language readily available to me.
> It is very easy to write a library in any of a number of languages that > will sort a generic data structure, but that library will probably do a > dynamic type dispatch for every comparison. What's nice about C++ templates > is that that dynamic type dispatch is done at compile time, and is used as > a way of getting the compiler to lay down appropriate code at run time. > Other languages I have seen either don't do that at all, or make it substantially > harder. Of course a counterexample may exist, but if it does, it doesn't > seem to be a widespread part of current practice.
> > Alexander Stepanov's dissillusionment with OO reminds me of something > > I've been thinking about for a while. Object-oriented methodology > > is a collection of techniques for managing program complexity. A > > very large "a-ha" for me was that higher-order functions could be > > used to build OO systems. Therefore, higher-order functions are > > a more fundamental/powerful concept than OO.
> I suspect that they are a dual, in the logical sense. > OO: `Everything is data, even programs' > FP: `Everything is program, even data'
Hear, hear. One of them tells us that binary search is an object, while the other insists that stack is a function.
> > (The only reason to build OO into the language (as opposed to > > providing it in a library) is to give the compiler the chance to > > optimize on those techniques, which is why Dylan, for example, > > provides both higher-order functions and OO.)
> I think there are other reasons as well. OOP is particularly useful > for simulations, and lots of commercial applications involve > simulation in one way or another.
> > The strange thing is that I've never seen a defender of C++ > > acknowledge the power of higher-order functions. Higher-order > > functions are simply functions that build other functions. But > > I can't help but get the impression that the defenders of C++ just > > don't get it. This would explain why they feel it is necessary to > > build all this other complex machinery.
> Perhaps you haven't looked hard enough. You might start with STL > function adaptors, which are nothing more or less than higher-order > functios, or come to my Usenix tutorial at the COOTS conference this > June, which will talk a good bit about how to use templates to simulate > higher-order functions in C++. I will completely agree with you that > it would be nice if C++ had a more direct way of supporting higher-order > functions, but that desire is mostly abstract -- in practice I don't see > it getting in the way of using C++ to solve problems that arise for real.
I should add that I had been a proponent of functional programming for more than a decade - one of my first papers was presented at the First Functional Programming Conference. I have acknowledged the power of higher order functions. My problem was that I was not interested in doing tail recursive factorials or memoizing Fibonacci numbers - I wanted to implement algorithms that people could use when they build their systems. And that forced me to use C++.
And, believe me, my life would have been much easier if I stayed with one of the officially approved religions. In the circles where I circulate, it is not politically acceptable to defend C++, especially if you like C and not ++. I wish I could love Java...
On Fri, 2 May 1997 12:59:52 GMT, Andrew Koenig <a...@research.att.com> wrote:
: :In article <3071563530695...@naggum.no> Erik Naggum <e...@naggum.no> writes: : :> * Andrew Koenig :> | Which suggests that perhaps your opinion of what is superior is not :> | universal. : :> it is rather curious that someone who _must_ know better argues that the :> superiority of something and the energy poured into it are not inversely :> related. or are you saying that C++ is a superior language for the same :> reason that MS-DOS is a superior operating system, Andrew? : :I am saying just what I said before, which is that not everyone has the :same opinion about what is superior to what. Such divergence of opinion :is usually called `personal taste,' and the more I see of the world, :the more I realize just how divergent people's tastes really are.
My opinion is that a properly designed langauge is the best and most effective tool, and that alternate extra-language tools are often feeble makeups for that tool's insufficiency.
-- Matthew B. Kennel/Institute for Nonlinear Science, UCSD/ Don't blame me, I voted for Emperor Mollari.
In article <336A4D79.4...@mti.sgi.com> Alexander Stepanov <stepa...@mti.sgi.com> writes: > of types (iterators, for example). But I still do not know any other > language in which I could express what I wanted to express. I teach ... > Do I mean to say that C++ is the ultimate programming language? Perish the > thought! We do need a better programming language. But I do not believe that > anything better already exists. And, yes, I tried Scheme, ML, Ada, Java... > And I tried them quite seriously, spending years on every fad that comes out > of POPL.
How do you square this with the fact that STL has been implemented in Ada95??? As the saying goes, "if it happens, it must be possible".
/Jon
-- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 j...@organon.com
|
