Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

10 Reasons Why Scheme is Better Than C/C++

136 views
Skip to first unread message

David Hanley

unread,
Nov 27, 1996, 3:00:00 AM11/27/96
to

Just a few corrections, but overall you had some good points:

>GoldenEye wrote:
>1.Since Scheme has an interpreter, you can run individual functions and
>play with your data structures
> without writing stubs.
> 2.Dynamic typing allows you to concentrate on real errors, rather than
> trying to placate the compiler god. It
> also makes code vastly more reusable.

Hardly true. The only time I ever notice the static type checker is
when I get a type mismatch. This would have been a run-time error in
scheme that may have hit for a long time, and been hard to debug.
Dynamic type checking is a hack to allow for faster interpretation which
gives awayt a lot.

> 3.Scheme is actually portable.

If you're using the cortect version.

> 4.Every Scheme function is prefix. We don't need no stinkin' 19-level
> operator precedence heirarchy.
> 5.In C, you have to write the code if you want a really exotic data
> structure, like a linked list.

Not with stl you don't. And I actually think it's easier to do complex
data structures in C++ because you actually have data structures. I
certianly find it easier in java or ML.


> Similarly, you
> have to include a special library if you want to do something
> bizarre, like write to standard output.

#include <iostream.h>

Is not a hard thig to do.

> 6.Scheme has first-class functions and continuations.

Well, C++ has function pointers, which can be used much like
first-class functions, though they are harder to use! I wish scheme had
currying too, I use that a lot.

> 7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.

Bad in 2 ways. With integers, this is not the result you want.
Frequently you want integers to behave like integers. Secondly, this is
a lot easier for me to read:

3*(1/3)

> 8.Scheme has no *&%@#! pointers. Memory management is for compilers.
> 9.It's a lot harder to confuse set! and eq? than = and ==.
> 10.The following is actually a legal C statement, according to The
> UNIX-HATERS Handbook:
>
> for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/8)%2))P("|"+(*u/4)%2);

Doesn't look valid to me. R=; will probably cause a compiler error.

Here's the original post:


2.Dynamic typing allows you to concentrate on real errors, rather than
trying to placate the compiler god. It
also makes code vastly more reusable.
3.Scheme is actually portable.

5.In C, you have to write the code if you want a really exotic data
structure, like a linked list. Similarly, you
have to include a special library if you want to do something
bizarre, like write to standard output.

7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.

10.The following is actually a legal C statement, according to The
UNIX-HATERS Handbook:

for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/8)%2))P("|"+(*u/4)%2);

Doug Bell

unread,
Nov 27, 1996, 3:00:00 AM11/27/96
to

da...@netright.com wrote:

> >GoldenEye wrote:
> > 10.The following is actually a legal C statement, according to The
> > UNIX-HATERS Handbook:
> >
> > for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/8)%2))P("|"+(*u/4)%2);
>
> Doesn't look valid to me. R=; will probably cause a compiler error.

Also, the second 'for' statement is missing the second semicolon which
should be inserted at:

for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/8)%2);)P("|"+(*u/4)%2);
^

I guess the point being that it's not possible to abuse Scheme's syntax?

Doug Bell
db...@shvn.com

J.J.A. Koot

unread,
Nov 28, 1996, 3:00:00 AM11/28/96
to

David Hanley wrote:
> [snip] Well, C++ has function pointers, which can be used much like

> first-class functions, though they are harder to use! I wish scheme had
> currying too, I use that a lot. [snip]

Pointers to functions in C++ are very far from first class functions,
and continuations. Problem (and thrength) of C++ is that all
functions must be known at compile time. A scheme program may pop up
functions the programmer never had dreamed of. Compare this to numbers.
Numeric computations would be very hard in a language in which a
program cannot produce any other numbers than those mentioned somewhere
in the code. If you want a true functional programming facility, then
scheme probably is preferable over C++.

The choice of a programming language depends on many factors,
but let us not forget that personal taste is one of them.
Jacob
--
If Java would not have pointers, we would not need clone.
J. J. A. Koot Stichting Academisch Rekencentrum Amsterdam
Tel: +31 20 5923019 Postbus 94613, 1090 GP, Amsterdam, Netherlands
Fax: +31 20 6683167 http://www.sara.nl/koot Mailto:ko...@sara.nl

Thant Tessman

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

GoldenEye wrote:

[...]

> 2.Dynamic typing allows you to concentrate on real errors, rather
> than trying to placate the compiler god. It also makes code vastly
> more reusable.

David Hanley wrote:

> Hardly true. The only time I ever notice the static type
> checker is when I get a type mismatch. This would have been a
> run-time error in scheme that may have hit for a long time, and

> been hard to debug. [...]

A good type system is better than no type system, but no type system
is better than a bad type system. C++ has a bad type system.


Goldeneye:

> 6.Scheme has first-class functions and continuations. [...]

David Hanley:

> Well, C++ has function pointers, which can be used much like
> first-class functions, though they are harder to use! I wish scheme had
> currying too, I use that a lot.

Function pointers are in no way a substitute for higher-order functions.
As for currying in scheme:

(define (curry f arg)
(lambda rest (apply f (cons arg rest))))

(define add3 (curry + 3))
(add3 4) => 7

...which also happens to be a good example of why function pointers are
in no way a substitute for higher-order functions.


Goldeneye:

> 7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.


David Hanley:

> Bad in 2 ways. With integers, this is not the result you
> want. Frequently you want integers to behave like integers.

No. You mean that sometimes you don't want division to behave like
division:

(* 3 (quotient 1 3))


> Secondly, this is
> a lot easier for me to read:
>
> 3*(1/3)

Do you actually have all the operator precidences in C++ memorized? Or do
you, like me, put redundant parentheses in your code where-ever you're not
sure about them? (Or, do you, like many others, merely discover bugs in
your programs caused by operator precidences you didn't think about?)

Here's my very short list of reasons why Scheme is a better language
than C++:

1) Print out the (R4RS) definition of Scheme and have someone drop it
on your head. Next, print out the (ANSI Draft Standard) definition of
C++ and have someone drop that on your head.

Which is the better language?

I have to admit that there are situations where I would choose C++ over
Scheme. However, my only choices aren't Scheme and C++, and the only
reason I program in C++ at all is because the people I work with don't
have any experience with alternatives. If it weren't for that, I
wouldn't use C++ at all. C++ a disgusting hairball of a language that
should have been abandoned long ago for the obvious mistake that it was.

-thant


--
Thant Tessman <th...@shoreline-studios.com>
http://www.shoreline-studios.com

David Hanley

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

Thant Tessman wrote:
>
> GoldenEye wrote:
>
> [...]
>
> > 2.Dynamic typing allows you to concentrate on real errors, rather
> > than trying to placate the compiler god. It also makes code vastly
> > more reusable.
>
> David Hanley wrote:
>
> > Hardly true. The only time I ever notice the static type
> > checker is when I get a type mismatch. This would have been a
> > run-time error in scheme that may have hit for a long time, and
> > been hard to debug. [...]
>
> A good type system is better than no type system, but no type system
> is better than a bad type system. C++ has a bad type system.

This is, of course, a matter of taste. I would qualify scheme's
runtime determination of all types as a really bad type system. C++'s
type system is actually not all *that* bad, though it certianly could be
better.

Nonetheless, the claim made in the original post was the dynamic typing
is inherently better than static typing, which I personally feel is
incorrect.

>
> Goldeneye:
>
> > 6.Scheme has first-class functions and continuations. [...]
>
> David Hanley:
>
> > Well, C++ has function pointers, which can be used much like
> > first-class functions, though they are harder to use! I wish scheme had
> > currying too, I use that a lot.
>
> Function pointers are in no way a substitute for higher-order functions.

I didn't say that they were as good in all cases; however, in many
cases they serve a similar function.

> As for currying in scheme:
>
> (define (curry f arg)
> (lambda rest (apply f (cons arg rest))))
>
> (define add3 (curry + 3))
> (add3 4) => 7
>
> ...which also happens to be a good example of why function pointers are
> in no way a substitute for higher-order functions.

Eh, no, sorry. That's not a full curry, though it's quite clever. I
was unaware of that construct. As long as we're talking about language
hacks, you could do something similar( though surely not the same not as
nice ) in C++ with either function poiners, or an object chain.

>
> Goldeneye:
>
> > 7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.
>
> David Hanley:
>
> > Bad in 2 ways. With integers, this is not the result you
> > want. Frequently you want integers to behave like integers.
>
> No. You mean that sometimes you don't want division to behave like
> division:

No, the integer division of 1/3 is 0. Period. Claiming this correct
result as a language defect is foolish.

>
> (* 3 (quotient 1 3))
>
> > Secondly, this is
> > a lot easier for me to read:
> >
> > 3*(1/3)
>
> Do you actually have all the operator precidences in C++ memorized?

No, this is not necessary.

> Or do
> you, like me, put redundant parentheses in your code where-ever you're not
> sure about them?

Sure. So what?

>
> Here's my very short list of reasons why Scheme is a better language
> than C++:
>
> 1) Print out the (R4RS) definition of Scheme and have someone drop it
> on your head. Next, print out the (ANSI Draft Standard) definition of
> C++ and have someone drop that on your head.

That's a pretty good reason, actually, but I don't think it's the
end-all either.

>
> Which is the better language?
>
> I have to admit that there are situations where I would choose C++ over
> Scheme. However, my only choices aren't Scheme and C++, and the only
> reason I program in C++ at all is because the people I work with don't
> have any experience with alternatives. If it weren't for that, I
> wouldn't use C++ at all. C++ a disgusting hairball of a language that
> should have been abandoned long ago for the obvious mistake that it was.

I do think that C++ is not a very good language. I'd like to see
better languages succeed. However, language devotees have a serious
problem of refusing to see the flaws in thier pet languages. Heck, if
the language was the best soloution, it would probably be a lot more
widely used, right?

Refusing to see the problems with a something is highly destriental to
advancing it's success.

dave

Jason Orendorff

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

> Do you actually have all the operator precidences in C++ memorized? Or do

> you, like me, put redundant parentheses in your code where-ever you're not
> sure about them? (Or, do you, like many others, merely discover bugs in
> your programs caused by operator precidences you didn't think about?)
There are, in fact, several of us that can consistently remember
that multiplication and division have higher precedence than addition and
subtraction.
*frown* And even if I put parentheses around every single
subexpression I typed in, my C++ program would still have about half as many
parentheses (and would, consequently, be about twice as readable) as the
same program in Scheme.

--Mohammed

Kent Tong

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

Thant Tessman <th...@shoreline-studios.com> wrote:

>A good type system is better than no type system, but no type system
>is better than a bad type system. C++ has a bad type system.

Why do you say that? C++ has a bad type system?

>Function pointers are in no way a substitute for higher-order functions.

>As for currying in scheme:
>
> (define (curry f arg)
> (lambda rest (apply f (cons arg rest))))
>
> (define add3 (curry + 3))
> (add3 4) => 7
>
>...which also happens to be a good example of why function pointers are
>in no way a substitute for higher-order functions.

This can be done in C++ or Java if all the functions take
their parameters from an array or something like that.
Then all we need to do is to store "f" and "arg" in a
(functional) object just like what you did.


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Amit Patel

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

Thant Tessman <th...@shoreline-studios.com> wrote:
>
>Here's my very short list of reasons why Scheme is a better language
>than C++:
>
>1) Print out the (R4RS) definition of Scheme and have someone drop it
>on your head. Next, print out the (ANSI Draft Standard) definition of
>C++ and have someone drop that on your head.
>
>Which is the better language?

Print out the definition of a turing machine and have someone drop it
on your head. Next, print out the (R4RS) definition of Scheme and
have someone drop that on your head.

Which is the better language?

I find the smallness of Scheme to be both a thing of beauty and a
curse. When I want to use exceptions in C++, I just go ahead and do
it. When I want to use them in Scheme, I have to go searching the net
for an exceptions library. When I want to use objects in C++, I just
go ahead and do it. When I want to use them in Scheme, I have to go
searching the net for an objects library. When I want to use sets in
C++, I just go ahead and do it (including <set.h>). When I want to
use them in Scheme, I have to go searching the net for a set library.

The things I have to add to Scheme are not consistent with the next
person's things. If one library's exception system is different from
the next library's exception system, what do I do? Do I keep around
five module systems, three macro systems, eight object systems, and
four exception systems?

I still love Scheme ... it's my favorite language. Yet I never use it
for my projects now .. I've switched to using ML or C++. Big isn't
always Bad.

- Amit

Peter Drake

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

David Hanley <da...@netright.com> writes:

> Thant Tessman wrote:
> >
> > GoldenEye wrote:

(For the record, no he didn't. He took the top ten list off of one of
my pages, http://www.cs.indiana.edu/hyplan/pedrake/scheme.html.)

> > As for currying in scheme:
> >
> > (define (curry f arg)
> > (lambda rest (apply f (cons arg rest))))
> >
> > (define add3 (curry + 3))
> > (add3 4) => 7
> >
> > ...which also happens to be a good example of why function pointers are
> > in no way a substitute for higher-order functions.
>

> Eh, no, sorry. That's not a full curry, though it's quite clever. I

What constitutes a full curry, IYHO?

> was unaware of that construct. As long as we're talking about language
> hacks, you could do something similar( though surely not the same not as
> nice ) in C++ with either function poiners, or an object chain.

I wasn't aware that C++ could generate functions (or methods) on the
fly. Pray tell, what is the C++ code equivalent to the above? Also,
what language does offer easy "full" currying?

> > > 7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.
> >
> > David Hanley:
> >
> > > Bad in 2 ways. With integers, this is not the result you
> > > want. Frequently you want integers to behave like integers.
> >
> > No. You mean that sometimes you don't want division to behave like
> > division:
>
> No, the integer division of 1/3 is 0. Period. Claiming this correct
> result as a language defect is foolish.

I want numbers to behave like numbers; I'd rather do rounding
explicitly in those rare instances where I want it.

> I do think that C++ is not a very good language. I'd like to see
> better languages succeed. However, language devotees have a serious
> problem of refusing to see the flaws in thier pet languages. Heck, if
> the language was the best soloution, it would probably be a lot more
> widely used, right?

Non sequitur. The most widely used things are not the best. Look at
Microsoft products. Look at television. Look at McDonald's.

> Refusing to see the problems with a something is highly destriental to
> advancing it's success.

Granted. One of the things I like about Scheme is that it can be
expanded. Procedural abstraction is quite difficult in most other
languages. While the Powers That Be have not agreed on it yet, many
Scheme systems also have a <snorts manfully> REAL macro system, which
allows for defining new syntax. If there's something you don't like
about C++, you're stuck with it.


--
Peter Drake PhD Student in Cognitive Science, IU Bloomington
ped...@cs.indiana.edu http://www.cs.indiana.edu/hyplan/pedrake.html
"There's nothing wrong with you that an expensive operation can't
prolong." -- Surgeon to Mr. Notlob


Seth Tisue

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

In article <32A373...@netright.com>,

David Hanley <da...@netright.com> wrote:
>> As for currying in scheme:
>> (define (curry f arg)
>> (lambda rest (apply f (cons arg rest))))
>> (define add3 (curry + 3))
>> (add3 4) => 7
>
> Eh, no, sorry. That's not a full curry, though it's quite clever. I
>was unaware of that construct. As long as we're talking about language
>hacks, you could do something similar( though surely not the same not as
>nice ) in C++ with either function poiners, or an object chain.

Could you explain in what way this is not a full curry?

It's not a language hack either, it's fully idiomatic, ordinary Scheme.
--
== Seth Tisue <s-t...@nwu.edu> http://www.cs.nwu.edu/~tisue/

David Hanley

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

> > was unaware of that construct. As long as we're talking about language
> > hacks, you could do something similar( though surely not the same not as
> > nice ) in C++ with either function poiners, or an object chain.
>
> I wasn't aware that C++ could generate functions (or methods) on the
> fly.

You don't need to.

> Pray tell, what is the C++ code equivalent to the above?

class add1
{
int i1;
int apply( int i2 ) { return i1 + i2; }
}

class add2
{
add1 *apply( int iv ) { return new add1( iv ); }
}

This is just one way; I can think of a lot of others offhand. I used a
somewhat similar technique in a sml->java comiler I am writing, though
that scheme was a bit more elegant( no pun intended ).

Since you're promoting a language which doesn't provide much, and asks
for programmed extensions for the simplest things, I hope you don;t
criticize this use of the C++ object system.

> Also,
> what language does offer easy "full" currying?

SML has a pretty nice curry system.


> > No, the integer division of 1/3 is 0. Period. Claiming this correct
> > result as a language defect is foolish.
>
> I want numbers to behave like numbers; I'd rather do rounding
> explicitly in those rare instances where I want it.

Well, I hope you're ready for:

1) Actual computer programmers misunderstanding when they see integer
division not behaving like integer division.
2) You programs running really slow when that cool integer computation
gets faulted to floating pint.



>
> > I do think that C++ is not a very good language. I'd like to see
> > better languages succeed. However, language devotees have a serious
> > problem of refusing to see the flaws in thier pet languages. Heck, if
> > the language was the best soloution, it would probably be a lot more
> > widely used, right?
>
> Non sequitur. The most widely used things are not the best.

If you had read the paragraph above, you would have seen that I already
know that. However, there are reasons that the widely used things are
widely used. Simply waving our arms and saying that the popular option
sucks doesn't advance the art one iota.

Making silly claims about scheme's supposed superiority to C++ won't
make more commercial projects use scheme, especially if the people who
chose C++ for them chose C++ for those supposed defects, such as the
type system.


> > Refusing to see the problems with a something is highly destriental to
> > advancing it's success.
>
> Granted. One of the things I like about Scheme is that it can be
> expanded. Procedural abstraction is quite difficult in most other
> languages. While the Powers That Be have not agreed on it yet, many
> Scheme systems also have a <snorts manfully> REAL macro system, which
> allows for defining new syntax.

Uck. I _hate_ that. The _last_ thing I want to do when trying to
debug someone else's code is trying to decipher the new language
features they've added. That possibility alone has probably caused
scheme not to be used for some projects.

> If there's something you don't like
> about C++, you're stuck with it.

To an extent, yes. Many projects choose not to use some of the more
esoteric concepts, such as multiple inheretence and the like. Though,
in truth, the only feature I've ever really pined for in C++ is garbage
collection, though people have added that in add-on packages.

dave

Raymond Toy

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

David Hanley <da...@netright.com> writes:

> > > No, the integer division of 1/3 is 0. Period. Claiming this correct
> > > result as a language defect is foolish.
> >
> > I want numbers to behave like numbers; I'd rather do rounding
> > explicitly in those rare instances where I want it.
>
> Well, I hope you're ready for:
>
> 1) Actual computer programmers misunderstanding when they see integer
> division not behaving like integer division.
> 2) You programs running really slow when that cool integer computation
> gets faulted to floating pint.

This follows only because many LANGUAGEs define 1 / 3 to be
truncation (or floating point division).

Mathematically, integer division is well defined IF you include
rationals as a possible result. If you do not, you get possible
strange results like

x = 1 / 3
y = 3 * x

and y is 0. Hardly the expected mathematical result of multiplying a
number with is multiplicative inverse.

It's even worse when you multiply large positive integers and get a
negative result because you overflowed a machine register.

Scheme and Lisp try to be mathematically correct. Languages are free
to ignore mathematics in lieu of something that is right most of the
time but is mathematically wrong sometimes.

The bottom line is you must know exactly how the language defines
operations and note that many times they do not match the mathematical
answer.


No need to comment on other things which are basically computer
language flame wars....

Ray

Vassili Bykov

unread,
Dec 3, 1996, 3:00:00 AM12/3/96
to

free...@wr.com.au (Kent Tong) wrote:
> Thant Tessman <th...@shoreline-studios.com> wrote:
> >[...]

> >...which also happens to be a good example of why function pointers are
> >in no way a substitute for higher-order functions.
>
> This can be done in C++ or Java if all the functions take
> their parameters from an array or something like that.
> Then all we need to do is to store "f" and "arg" in a
> (functional) object just like what you did.

Even if it is so, would you mind writing a C analog of the following
recursive factorial:

(define y-fact
((lambda (f)
((lambda (g)
(f (lambda (arg)
((g g) arg))))
(lambda (g)
(f (lambda (arg)
((g g) arg))))))
(lambda (rec)
(lambda (n)
(if (< n 1)
1
(* n (rec (- n 1))))))))

the point is not whether it is possible or not, actually. Just how
contrived will it be, and how much harder will it be to recognize Y
combinator in it? The point is, any language can do anything, but is
good only for what it's good for.

--Vassili

Adam Alpern

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <Pine.OSF.3.91.961202...@odin.cbu.edu>, Jason Orendorff <jore...@odin.cbu.edu> wrote:

> There are, in fact, several of us that can consistently remember
>that multiplication and division have higher precedence than addition and
>subtraction.

Sure, but what about * and [] and -> and :: and . and so and so forth?
It's particularly frustrating now that STL iterators have made
(*foo).something_or_other common again.

> *frown* And even if I put parentheses around every single
>subexpression I typed in, my C++ program would still have about half as many
>parentheses (and would, consequently, be about twice as readable) as the
>same program in Scheme.

However, your C++ program still has an order of magnitude more characters with
special syntactic meaning, making it an order of magnitude harder to read, so
you're still losing. You've got () denoting a function call, {} for blocks, ::
for scope resolution < > for template instantiation, *, ., &, and -> for
dealing with accessing bits (excuse me, "objects"), and operator overloading
and implicit casts making things even harder to follow.

How about this:

for (std::list < Big<Hairy<Template<thingamabob<char *> > > >::const_iterator
i = ((derivedtype *)&baseref)->baz()->begin();
i != ((derivedtype *)&baseref)->baz()->end(); i++ )
{
(*i)->do_something();
}

versus (mapc 'do-something i)

(Sorry, that's Common Lisp, my Scheme is rusty).

And yes, I actually *do* have to deal with code that hairy, due to legacy code
and the need to support 4 C++ compilers, each of which implements a subtly
different language.

C++ makes my eyes boggle. You have to go to incredible lengths to do
*anything* high-level and abstract in it, because you have to manually make up
for C++'s lack of anything remotely resembling a decent programming language.

I wouldn't necessarily choose Scheme for delivering apps in, but I would
choose Dylan, which is a Scheme variant, and I've done commercial development
quite nicely thank you very much in Common Lisp.

Foo.

Rob Warnock

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

David Hanley <da...@netright.com> wrote:
+---------------

| No, the integer division of 1/3 is 0. Period. Claiming this correct
| result as a language defect is foolish.
+---------------

The language defect is C++'s (and C's before it). As we were all taught
in grade school, 1 divided by 3 is 1/3 (one third). And that's what you
get in Scheme... which includes has rational numbers. The fact that C
didn't know about anything but "int" and "double" is a historical wart that
C++ inherited, but it's *NOT* particularly correct -- quite the contrary.

As someone else pointed out, if you *want* truncation in Scheme, you can
*ask* for it, several ways, in fact:

(floor (/ 1 3)) ==> 0
(ceiling (/ 1 3)) ==> 1

or more simply:

(quotient 1 3) ==> 0

It's simply that in Scheme it's not automatic that division of exact numbers
will truncate. Instead, division of exact numbers gives you an exact result,
namely, an exact rational number:

(/ 22674322497976 104331282936392) ==> 617/2839

How do you say *that* in C++?


-Rob

-----
Rob Warnock, 7L-551 rp...@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA


bmb...@acsu.buffalo.edu

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

I only want to address one topic of your message:

David Hanley <da...@netright.com> writes:

[Note: I'm re-adding the Scheme curry function under discussion]

>>>> (define (curry f arg)
>>>> (lambda rest (apply f (cons arg rest))))
>>>>
>>>> (define add3 (curry + 3))
>>>> (add3 4) => 7
>

> > Pray tell, what is the C++ code equivalent to the above?
>
> class add1
> {
> int i1;
> int apply( int i2 ) { return i1 + i2; }
> }
>
> class add2
> {
> add1 *apply( int iv ) { return new add1( iv ); }
> }
>
> This is just one way; I can think of a lot of others offhand. I used a
> somewhat similar technique in a sml->java comiler I am writing, though
> that scheme was a bit more elegant( no pun intended ).

Maybe it's my lack of understanding of C++, but it doesn't look
equivilant to me. Given the above definitions, I would almost say
that the equivilant to your add2 would be (curry curry +).

Give me a curry function in C++ (perhaps heavily templated and
overloaded) that would allow me to do the equivilant of the following
(using the above Scheme definition of the curry function):

(define add3 (curry + 3))

(define 5-or-greater (curry max 5))
(add3 4) => 7
(add3 4 5 6) => 18
(5-or-greater 1) => 5
(5-or-greater 1 2 3 4) => 5
(5-or-greater 4 5 6) => 6

Allowing me to use int add(int,...) and int max(int,...) functions,
although preferrably I'd like to use arbitrary classes and function
arities.

The closest I can see is something like so:

template<Type1,Type2,Type3>
class curry {
Type1 (*fun)(Type2,Type3);
Type2 arg;

public:
curry(Type1 (*f)(Type2,Type3),Type2 a) : fun = f; arg = a; {}
Type1 operator()(Type3 arg2) {return (*fun)(arg,arg2)}
};

But that limits one to reducing functions with two arguments to
functions with one argument, not quite the same as the scheme version.

--
Buddha Buck bmb...@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice

David Hanley

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

Rob Warnock wrote:
>
> David Hanley <da...@netright.com> wrote:
> +---------------
> | No, the integer division of 1/3 is 0. Period. Claiming this correct
> | result as a language defect is foolish.
> +---------------
>
> The language defect is C++'s (and C's before it). As we were all taught
> in grade school, 1 divided by 3 is 1/3 (one third).

Maybe I just went to a bad school, but was learned about something
called "integers" first. If i remember correctly, when dividing these
"integers" 1/3 the correct result was zero. I use this kind of stuff a
lot when I write computer programs, and am saddened that I've been using
an invalid construct all these years. ( note sarcasm )

> And that's what you
> get in Scheme...

The fact it gives a wrong result doesn't impress me too much.

> which includes has rational numbers. The fact that C
> didn't know about anything but "int" and "double"

hardly--it has short, long, float, et al.

dave

Matthias Blume

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <5837bn$l...@tokyo.engr.sgi.com> rp...@rigden.engr.sgi.com (Rob Warnock) writes:

David Hanley <da...@netright.com> wrote:
+---------------
| No, the integer division of 1/3 is 0. Period. Claiming this correct
| result as a language defect is foolish.
+---------------

The language defect is C++'s (and C's before it). As we were all taught

in grade school, 1 divided by 3 is 1/3 (one third). And that's what you
get in Scheme... which includes has rational numbers.

Actually, 1/3 is 2. No, I am not kidding, I am just doing arithmetic
in Z_5 -- the (finite) field you get by taking the integers mod 5.

The "fact" that (/ 1 3) is 1/3, or 0, or 2, ... is nothing but an
_arbitrary_ choice. Of course, 1/3 is the most common choice outside
of computer programming, so you might argue that 1/3 is the "correct"
result. But it is only correct up to the definition of what the
division operator does on integers. The definitions for C and Scheme
are different, both are correct. We can argue about the usefulness of
either, not about correctness.

It's simply that in Scheme it's not automatic that division of exact numbers
will truncate. Instead, division of exact numbers gives you an exact result,
namely, an exact rational number:

(/ 22674322497976 104331282936392) ==> 617/2839

Scheme implementations are only encourages, not required to give the
above result. An error due to implementations restrictions may be
signalled as well. So much for Scheme's alleged portability.

--
-Matthias

David Hanley

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

bmb...@acsu.buffalo.edu wrote:
>
> I only want to address one topic of your message:
>

okay.

> Maybe it's my lack of understanding of C++, but it doesn't look
> equivilant to me. Given the above definitions, I would almost say
> that the equivilant to your add2 would be (curry curry +).
>
> Give me a curry function in C++ (perhaps heavily templated and
> overloaded) that would allow me to do the equivilant of the following
> (using the above Scheme definition of the curry function):
>
> (define add3 (curry + 3))
> (define 5-or-greater (curry max 5))
> (add3 4) => 7
> (add3 4 5 6) => 18
> (5-or-greater 1) => 5
> (5-or-greater 1 2 3 4) => 5
> (5-or-greater 4 5 6) => 6
>

C doesn't have a way ( simple ) way to have a one-parameter funcrion
take a string of parameters, but this is how I implemented this in the
ml->java compiler:

First, in the class library:

class CurryBase {
protected int intApply() { retutn intApplication(); }
virtual intApplication() = 0;
}

class CurryInt : CurryBase
{
int i1;
CurryBase *CurryInt( int i ) { i1 = i; return this; }
}

class CurryIntInt : CurryInt
{
int i2;
CurryInt *CurryInt( int i ) { i2 = i; return this; }
}

Now, we can extend CurryIntInt:

class Adder : CurryIntInt // needs two integers
{
int intApplication() { return i1 + i2; }
}

class Max5 : CurryInt // needs one integer
{
int intApplicaion() { return max( i1 , 5 ); }
}

So, when we want to curry, we extend a class which represents the tuple
we want to process at the result of the curry process. It's more
keystrokes then the scheme code you posted, but I'm not sure if it's
better or worse.

When you apply an integer to an object that wants two integers, you get
an object that wants one integer. When you apply an integer to an
object that wants one integer, you get an object to which you can apply
an application method, yeilding your result. At each step along the
way, you can pass the objects around, etc,etc. The helper class
hierarchy can be generated with templates.

> class Adder extends Curry


> Allowing me to use int add(int,...) and int max(int,...) functions,
> although preferrably I'd like to use arbitrary classes and function
> arities.
>
> The closest I can see is something like so:
>
> template<Type1,Type2,Type3>
> class curry {
> Type1 (*fun)(Type2,Type3);
> Type2 arg;
>
> public:
> curry(Type1 (*f)(Type2,Type3),Type2 a) : fun = f; arg = a; {}
> Type1 operator()(Type3 arg2) {return (*fun)(arg,arg2)}
> };
>
> But that limits one to reducing functions with two arguments to
> functions with one argument, not quite the same as the scheme version.

That would work too, probably faster, though a bit less flexible.

dave

Mike Haertel

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <5837bn$l...@tokyo.engr.sgi.com>,

Rob Warnock <rp...@rigden.engr.sgi.com> wrote:
>It's simply that in Scheme it's not automatic that division of exact numbers
>will truncate. Instead, division of exact numbers gives you an exact result,
>namely, an exact rational number:
>
> (/ 22674322497976 104331282936392) ==> 617/2839

The R4RS does not require all implementations to support rationals.
They are an optional feature. So I strongly disagree with your
blanket statement "In Scheme...".

*Some* scheme implementations support bignums and rationals. Others
don't even unlimited precision "bignum" integers, and have smaller
integers than C implementations on the same machine.

Scheme's generic arithmetic has in some sense been one of the achilles'
heels of the language, since it is difficult to compile to efficient
code in common cases.

>How do you say *that* in C++?

Well, C++ has operator overloading and user-defined types. It would
be pretty easy, just like the usual textbook example of complex numbers.
Remember... "C++: The most elaborate complex number extension ever
added to a language."
--
Mike Haertel <hae...@ichips.intel.com>
Not speaking for Intel.

Charles Bacon

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

Blatant snips of authorship:

> +---------------
> | No, the integer division of 1/3 is 0. Period. Claiming this correct
> | result as a language defect is foolish.
> +---------------
>
> The language defect is C++'s (and C's before it). As we were all taught
> in grade school, 1 divided by 3 is 1/3 (one third). And that's what you
> get in Scheme... which includes has rational numbers.
>
>Actually, 1/3 is 2. No, I am not kidding, I am just doing arithmetic
>in Z_5 -- the (finite) field you get by taking the integers mod 5.

I think this has been the most correct post so far (but then
again, I study math). I personally think that the integer division of
1/3 should be an error, since 1/3 doesn't exist. This probably isn't
the most useful interpretation for computer programming, but then
again, we've strayed from talking about that.
I'd also like to add that, quibbles aside, I thought the 10
reasons were pretty funny. That seems to have been lost in the
shuffle.

Guillermo (Bill) J. Rozas

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <4nenh74a...@rtp.ericsson.se> Raymond Toy <t...@rtp.ericsson.se> writes:

| From: Raymond Toy <t...@rtp.ericsson.se>
| Date: 03 Dec 1996 15:47:08 -0500
|
| It's even worse when you multiply large positive integers and get a
| negative result because you overflowed a machine register.

Or even add them and get a nonsense negative result.

This is a much better example of why generic arithmetic in Lisp and
Scheme is a win in many cases. After all, the ring of integers is
well understood, and so is the ring of integers modulo any value
(including 2^16, 2^32, 2^64).

The problem with the lack of bignums in C and ML (the trapping
behavior of signed overflow in ML is not really adequate) is that it
makes the meaning of a program dependent on the machine word size and
the choice that the compiler-writer made for the size of one or
several flavors of integers.

Yes, this leads to greater efficiency in the absence of both hardware
and runtime system support, but it also leads to porting problems when
going to a different compiler or machine.

Robert McDermid

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In message <4nenh74a...@rtp.ericsson.se> - Raymond Toy

<t...@rtp.ericsson.se>03 Dec 1996 15:47:08 -0500 writes:
>
>
>Mathematically, integer division is well defined IF you include
>rationals as a possible result. If you do not, you get possible
>strange results like
>
> x = 1 / 3
> y = 3 * x
>
>and y is 0. Hardly the expected mathematical result of multiplying a
>number with is multiplicative inverse.


:-) I think you should re-read what you just wrote, as it's
rather funny. If you include rationals as a possible result,
then you're not doing integer division, since a rational number
is, by definition, not an integer - it's a rational. Integer
division of 1 by 3 produces a result of 0 - there's no other
way to present the result in the integer number system. If you
want to handle rational results on a computer, you must use
floating point (and start worrying about round-off error, truncation
error, etc., etc., etc.) Whole courses are taught in
Computer Science which deal with nothing but this single area
of computation - it is by no means a simple topic.

BTW, 1/3 is an irrational, not a rational, and there's no way to
represent that precisely at all (using floating point) on a computer.
Thus, in the example you give, y will never equal x no matter
what computer language you use. (Do any of the symbolic manipulation
packages like Maple have a way of handling this better?)

-- Rob
==============================================================
Rob McDermid Hummingbird Communications Ltd.
mcde...@hcl.com All opinions expressed are my own.
==============================================================


Seth Tisue

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <584nbh$1...@news.hcl.com>, Robert McDermid <mcde...@hcl.com> wrote:
>BTW, 1/3 is an irrational, not a rational

Bzzzzzzzzzzt!

Seth Tisue

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

In article <32A5A2...@netright.com>,

David Hanley <da...@netright.com> wrote:
> C doesn't have a way ( simple ) way to have a one-parameter funcrion
>take a string of parameters, but this is how I implemented this in the
>ml->java compiler:

So what would this code look like if you used templates or whatever to
extend it to work on other things besides integers?

Curious,

Matthias Blume

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <584nbh$1...@news.hcl.com> mcde...@hcl.com (Robert McDermid) writes:

BTW, 1/3 is an irrational, not a rational,

Huh?

and there's no way to
represent that precisely at all (using floating point) on a computer.
Thus, in the example you give, y will never equal x no matter
what computer language you use. (Do any of the symbolic manipulation
packages like Maple have a way of handling this better?)

Of course -- by using rational numbers. (Which, btw, are _not_ to be
confused with floating point.)


--
-Matthias

Mark Meiss

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <584nbh$1...@news.hcl.com>, Robert McDermid <mcde...@hcl.com> wrote:
>
>BTW, 1/3 is an irrational, not a rational, and there's no way to

>represent that precisely at all (using floating point) on a computer.

It is too a rational. It's the ratio of two integers. It's a repeating
decimal. And it can be expressed exactly in base 3 as 0.1, in base 6
as 0.2, in base 12 as 0.25, and so on.

In fact, it would be interesting to write a package that used "BCDD"
(Binary-Coded DuoDecimal) to represent floating-point numbers, since
many more rational numbers would then have exact representations.
IMHO, anyway.

--Mark
--
Mark Meiss (mme...@indiana.edu) | No eternal reward will
Indiana University CS Dept. | forgive us now for - Jim Morrison
Bloomington, Indiana, USA | wasting the dawn.

Chris Dollin

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <584nbh$1...@news.hcl.com> mcde...@hcl.com (Robert McDermid) writes:

BTW, 1/3 is an irrational, not a rational,

This will be news to many generations of mathematicians. 1/3 is more rational
than I am.

and there's no way to represent that precisely at all (using floating
point) on a computer.

Certainly there is; just use base 3 arithmetic. (Of course you'll have to
*implement* it all, which is a tad tricky, and there might be a little
performance reduction, but the principle's sound.)

Perhaps you mean that 1/3 has no finte exact representation in base 2 (or
10)? That's rather different from being ``irrational'', surely?

Thus, in the example you give, y will never equal x no matter
what computer language you use. (Do any of the symbolic manipulation
packages like Maple have a way of handling this better?)

Yes, they represent 1/3 as 1/3. The obvious implementation that comes to mind
is to represent a rational as a pair of integers with highest common factor
1. (That's what Poplog does, although it's not a symbolic manipulation
package.)
--

Regards, | "You're better off not dreaming of the things to come;
Kers. | Dreams are always ending far too soon." - Caravan.

bmb...@acsu.buffalo.edu

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

David Hanley <da...@netright.com> writes:

>
> C doesn't have a way ( simple ) way to have a one-parameter funcrion
> take a string of parameters, but this is how I implemented this in the
> ml->java compiler:

OK, so I'll ignore the multiple arity issue for now.


> First, in the class library:

> class CurryBase {
> protected int intApply() { retutn intApplication(); }
> virtual intApplication() = 0;
> }

> class CurryInt : CurryBase
> {
> int i1;
> CurryBase *CurryInt( int i ) { i1 = i; return this; }
> }

> class CurryIntInt : CurryInt
> {
> int i2;
> CurryInt *CurryInt( int i ) { i2 = i; return this; }
> }

> Now, we can extend CurryIntInt:

> class Adder : CurryIntInt // needs two integers
> {
> int intApplication() { return i1 + i2; }
> }

> class Max5 : CurryInt // needs one integer
> {
> int intApplicaion() { return max( i1 , 5 ); }
> }

> So, when we want to curry, we extend a class which represents the tuple
> we want to process at the result of the curry process. It's more
> keystrokes then the scheme code you posted, but I'm not sure if it's
> better or worse.

OK, but does this scheme allow me to generate curried functions at run-time?

In scheme, I can pass curry a function that I can't determine what is
at compile-time, such as the comparison function used in qsort(). (I
doubt it if creating a less_than_pivot(void*) in this case would be
worth the effort, but is certainly is one implementation).

(This could be solved by having intApplication be not a virtual null
member function, but rather a pointer to an int(int,int), and
modifying the constructor appropriately, I guess. But that sort of
puts you where I was below).

I can also use as my argument to be curried any arbitrary run-time
value, as opposed to the Max5 class above (effectively, a MaxN class).

> When you apply an integer to an object that wants two integers, you get
> an object that wants one integer. When you apply an integer to an
> object that wants one integer, you get an object to which you can apply
> an application method, yeilding your result. At each step along the
> way, you can pass the objects around, etc,etc. The helper class
> hierarchy can be generated with templates.

> > The closest I can see is something like so:

> > template<Type1,Type2,Type3>
> > class curry {
> > Type1 (*fun)(Type2,Type3);
> > Type2 arg;

> > public:
> > curry(Type1 (*f)(Type2,Type3),Type2 a) : fun = f; arg = a; {}
> > Type1 operator()(Type3 arg2) {return (*fun)(arg,arg2)}
> > };

> > But that limits one to reducing functions with two arguments to
> > functions with one argument, not quite the same as the scheme version.

> That would work too, probably faster, though a bit less flexible.

I fail to see it as less flexible. It generates curries at run-time,
instead of using distinct classes for each curry, and allows arbitrary
2-arity functions with arbitrary return values.

Extending this seamlessly to 3-arity or higher functions doesn't seem
as simple as in your example, I will admit.

(If I am missing something, -please- explain: I'm a college student
who has never had a formal class in Scheme or any Lisp-like language,
and this is the first semester that C++ has been thrust upon me. It
is very likely that I am indeed missing something due to lack of
exposure and experience.)

In line with the previous parethesized remark, what, exactly, do you
mean by "full currying" as opposed to what the Scheme implementation
does? You stated a few messages ago that the scheme code didn't do
full currying. To my understanding (albeit limited), it does
(generates a function of n-1 arguments out of a function of n
arguments plus an argument).

Or would you prefer having to use syntax like so:

(define (5args a1 a2 a3 a4 a5)
(+ a1 a2 a3 a4 a5))

((((((curry 5args) 5) 4) 3) 2) 1) => 15

which could be considered "full currying" (replacing a function that
takes n arguments with a series of functions that take one argument
each and return a function that takes one argument each).

> dave

Stuart I Reynolds

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

David Hanley wrote:
>
> Rob Warnock wrote:

> > The language defect is C++'s (and C's before it). As we were all taught
> > in grade school, 1 divided by 3 is 1/3 (one third).


No, no no!!
Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3 are
in the INTEGER domain. To evaluate the division of one integer with
another integer will result in an integer, whether using programming
lanuages, alogrithms on paper or whatever. Integers have well defined
properties as does integer division - this is not in any way a fault of
C++.

Besides, what C++ does do is let you create your own types, which in
turn could represent numbers as numerators and denominators, and
redefine the meaning of operators which act upon them. C++ is pretty
poineering (and still unique, I believe) in this respect. What you have
described in Scheme takes that flexibilty away from you - can it do
integer division?

If you don't want to do integer division, don't use integers. This is
why C++ is a strongly typed language - unlike BBC BASIC say which also
dynamically altered the types of variables.

Are you saying BASIC is better than C++.

Stu

Justin Pearson

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Stuart I Reynolds <s...@cs.bham.ac.bham> writes:

>
> David Hanley wrote:
>
> If you don't want to do integer division, don't use integers. This is
> why C++ is a strongly typed language - unlike BBC BASIC say which also
> dynamically altered the types of variables.

\begin{Pedant mode}
Actually BBC BASIC was in a sense strongly typed, just that the typing
information was included in the variable name.
So A$ could only hold string values
A could only hold floating point values and A% could only hold integer
values.
Further A$ A% and A where distinct variables. I don't think there was
a way of dynamically altering the types of variables in BBC Basic.

\end{Pedant mode}

Will Ware

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Mark Meiss (mme...@beavis.indiana.edu) wrote:
: In article <584nbh$1...@news.hcl.com>, Robert McDermid <mcde...@hcl.com> wrote:
: >
: >BTW, 1/3 is an irrational, not a rational...
: It is too a rational. It's the ratio of two integers. It's a repeating

: decimal. And it can be expressed exactly in base 3 as 0.1, in base 6
: as 0.2, in base 12 as 0.25, and so on.

Sorry to pick nits, but the number in base 12 is 0.4.
--
-------------------------------------------------------------
Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289

Mark Meiss

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <E1y1K...@world.std.com>, Will Ware <ww...@world.std.com> wrote:
>Mark Meiss (mme...@beavis.indiana.edu) wrote:
>: In article <584nbh$1...@news.hcl.com>, Robert McDermid <mcde...@hcl.com> wrote:
>: >
>: >BTW, 1/3 is an irrational, not a rational...
>: It is too a rational. It's the ratio of two integers. It's a repeating
>: decimal. And it can be expressed exactly in base 3 as 0.1, in base 6
>: as 0.2, in base 12 as 0.25, and so on.
>
>Sorry to pick nits, but the number in base 12 is 0.4.

Well, if I'm picking nits, I deserve to have my nits picked too.
Yeah, what you said. My brain burped halfway back into base 10 there.

a...@laphroig.mch.sni.de

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

David Hanley wrote:
>>
>> Goldeneye:

>>
>> > 7.In Scheme, (* 3 (/ 1 3)) evaluates to 1.
>>
>> David Hanley:
>>
>> > Bad in 2 ways. With integers, this is not the result you
>> > want. Frequently you want integers to behave like integers.
>>
>> No. You mean that sometimes you don't want division to behave like
>> division:
>
> No, the integer division of 1/3 is 0. Period. Claiming this correct
>result as a language defect is foolish.

That's simply not true! You just can't divide the integer 1 by the
integer 3 and get an integer result. It certainly is not zero. You can
enlarge the ring of integers with their field of fractions to get the
rational numbers and then 1 / 3 = 1/3. If you want a result like 0 you
should take the floor or the the Gauss bracket of 1/3. Scheme is
(thankfully) one of the few languages that gets arithmetic right.


Andreas Eder

Thant Tessman

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

[comp.lang.java.programmer taken out of followups]


I wrote:

> Function pointers are in no way a substitute for
> higher-order functions.


> As for currying in scheme:
>

> (define (curry f arg)
> (lambda rest (apply f (cons arg rest))))
>

> (define add3 (curry + 3))

> (add3 4) => 7


>
>...which also happens to be a good example of why function
> pointers are in no way a substitute for higher-order functions.

Kent Tong wrote:

> This can be done in C++ or Java if all the functions take
> their parameters from an array or something like that.
> Then all we need to do is to store "f" and "arg" in a
> (functional) object just like what you did.

How convenient.

Actually, I've built a curry system for C++ using templates. You
can do things like this:

void f(const int& i, const int& j) {
cout << i << " " << j << endl;
}

Thunk1<int> f2 = curry1(f, 23);
Thunk0 f3 = curry0(f2, 5);

f3();

"curry0" and "curry1" are function templates that automatically
instantiate other helper template classes. "f2" is a function
object taking a single integer as an argument, and "f3" is a
function object taking no arguments. The output of evaluating
"f3()" is "23 5" as one would expect. You can even combine
the two statements and evaluate them immediately like this:

(curry0(curry1(f, 23), 5))();

Now given that we're working in C++, you gotta admit this is
pretty cool--certainly better than passing arguments in by way
of an array. But let's start comparing it to, say, the Scheme
example above, or the equally fully-polymorphic yet type-safe
equivalent in SML.

First off, this C++ version was a pain to write, and it took a
long time to get it correct. Second, it's a pain to use because
you have to produce a different version of the template function
for every possible number of arguments (note the "1" and "0" in
curry1 and curry0 and Thunk1 and Thunk0) *and* for every possible
return type. (I've only built them for functions and function
objects returning void.) Also, you have to have a different
version for whether you're going to pass arguments by reference,
or literally on the stack. (I've only implemented the former,
which is why "f" takes "const int&" instead of "int".)

And to top it off, I have a completely different set of
template functions for packaging up objects and member
function pairs into thunks. (They do mix and match though.)

Some people might think that this is a good demonstration
of how expressive C++ is. Compared to C, yeah, sure. But
the truth is that it took several orders-of-magnitude longer
to implement than the equivalent Scheme or SML construct, and
yet it is also a much more awkward and less general solution.
And attempts to further generalize the solution always start
looking like full-fledged interpreters in their own right, so
you lose the supposed benefits of using C++ in the first place.

C++ just plain sucks. But you'll never know that if all you've
ever programmed in is C++ (or C, or Pascal, or Fortran, or
COBOL).

-thant

--
Thant Tessman <th...@acm.org>

Dennis Weldy

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Stuart I Reynolds <s...@cs.bham.ac.bham> wrote in article
<32A6B7...@cs.bham.ac.bham>...

> Besides, what C++ does do is let you create your own types, which in
> turn could represent numbers as numerators and denominators, and
> redefine the meaning of operators which act upon them. C++ is pretty
> poineering (and still unique, I believe) in this respect. What you have
> described in Scheme takes that flexibilty away from you - can it do
> integer division?
>
Not quite - Ada also allowed operator overloading. Indeed, when I learned
about Ada in grad school, I thought "gosh, I'd love a langugae that
combined the best of C and Ada!"
Little did I know it already existed as C++. :-)

Dennis

Dennis Weldy

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

If you need to do work like that in your programs, use Scheme or SML!

OK, try doing low-level work in scheme? Previous posts in the assembly vs
C/C++ thread referred to blit-scale function. ;-). I've no idea if this
could be written in Scheme or not. Does Scheme support pointers? I've no
idea.

C/C++ is a systems programming language. I doubt the developers of C cared
about whether 1/3 would be represented as a fraction, or about currying.
;-).

There any Scheme-based operating systems about?

Scheme, SML, C, C++, heck even assembly Use the right tool for the work
you're trying to do.

Dennis

Thant Tessman <th...@shoreline-studios.com> wrote in article
<32A6F7...@shoreline-studios.com>...

a...@laphroig.mch.sni.de

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Davide Hanley wrote:
>> Pray tell, what is the C++ code equivalent to the above?
>
>class add1
>{
> int i1;
> int apply( int i2 ) { return i1 + i2; }
>}
>
>class add2
>{
> add1 *apply( int iv ) { return new add1( iv ); }
>}
>
That's only good if you like writing out the gory detail for thousands
of different addn classes. In scheme you can do it once and for all if
you define a function addn:
(define addn (lambda (n) (lambda (x) (+ xn))))
and then if you need, say add1024, you do (define add1024 (addn 1024))
and that's it.

>> > No, the integer division of 1/3 is 0. Period. Claiming this correct
>> > result as a language defect is foolish.
>>

>> I want numbers to behave like numbers; I'd rather do rounding
>> explicitly in those rare instances where I want it.
>
> Well, I hope you're ready for:
>
> 1) Actual computer programmers misunderstanding when they see integer
>division not behaving like integer division.
> 2) You programs running really slow when that cool integer computation
>gets faulted to floating pint.

In scheme integer arithmetic will never get faulted to floating point!
Integer arithmetic will always stay integer arithmetic; if you cross the
fixnum boundary it might get slower, but at least you will get the right
result. And integer + integer is never a floating point, but always
integer.

>> Non sequitur. The most widely used things are not the best.
>
> If you had read the paragraph above, you would have seen that I already
>know that. However, there are reasons that the widely used things are
>widely used. Simply waving our arms and saying that the popular option
>sucks doesn't advance the art one iota.
>
> Making silly claims about scheme's supposed superiority to C++ won't
>make more commercial projects use scheme, especially if the people who
>chose C++ for them chose C++ for those supposed defects, such as the
>type system.

There"s no need here to advance the art. There are already better
things, and the reasons why the aren't used but obvioulsy inferior
things are mor of a psychological end educational nature. (You could
also say marketing). Do you really think that most commercial projects
are done in C or C++, because they are technically superior to other
languages ? No, it's because they simply don't know about modern
developments in programming languages!

>> > Refusing to see the problems with a something is highly destriental to
>> > advancing it's success.
>>
>> Granted. One of the things I like about Scheme is that it can be
>> expanded. Procedural abstraction is quite difficult in most other
>> languages. While the Powers That Be have not agreed on it yet, many
>> Scheme systems also have a <snorts manfully> REAL macro system, which
>> allows for defining new syntax.
>
> Uck. I _hate_ that. The _last_ thing I want to do when trying to
>debug someone else's code is trying to decipher the new language
>features they've added. That possibility alone has probably caused
>scheme not to be used for some projects.

Uck. I _hate_ that. The _last_ thing I want to do when trying to
debug someone else's code is trying to decipher the new procedures
they've added. Why can't they just use the predefined functions and
write everything in one big file full of asm statements. :-)
Seriously, abstraction helps to debug other peoples code, if it's done
right. And to do that properly you often need a good macro system. (Not
what C programmers think is a macro system).

Andreas


a...@laphroig.mch.sni.de

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Robert McDermid wrote:
>Integer division of 1 by 3 produces a result of 0 - there's no other
>way to present the result in the integer number system. If you
>want to handle rational results on a computer, you must use
>floating point (and start worrying about round-off error, truncation
Of course - if you insist on an integer result for dividing 1 by 3
there is much more choice than just 0. I personally prefer 42 :-)
And certainly 1/3 is not a floating point number but rational. You can
easily represent it as a pair of integers. And by the way, we don't need
negative numbers too, we can also easily represent them as a pair of
natural numbers. And if go into the other direction, we can also exactly
represent algebraic numbers without resort to floating point and you can
even do exact arithmetic on all computable numbers.

Andreas

Robert McDermid

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In message <585pah$o...@dismay.ucs.indiana.edu> - mme...@beavis.indiana.edu

(Mark Meiss)5 Dec 1996 06:15:45 GMT writes:
>
>In article <584nbh$1...@news.hcl.com>, Robert McDermid <mcde...@hcl.com> wrote:
>>
>>BTW, 1/3 is an irrational, not a rational, and there's no way to

>>represent that precisely at all (using floating point) on a computer.
>
>It is too a rational. It's the ratio of two integers. It's a repeating
>decimal. And it can be expressed exactly in base 3 as 0.1, in base 6
>as 0.2, in base 12 as 0.25, and so on.

Oops. Sorry, brain wasn't working very well towards the end of the day.


>
>In fact, it would be interesting to write a package that used "BCDD"
>(Binary-Coded DuoDecimal) to represent floating-point numbers, since
>many more rational numbers would then have exact representations.
>IMHO, anyway.
>

Didn't Borland used to have this as part of their C library? Or was
it just BCD?

Once you start getting into special-purpose math packages you can
do almost anything, of course, at the expense of efficiency (at least
on a binary-hardware computer). Of course, all of the compromises
we routinely make in mathematics on computers are directly related
to increasing the computation speed in binary, for general purpose
computation.

Michael Simpson

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <01bbe2d0$58931610$12938781@weldypc> Dennis Weldy,
dmw...@ingr.com writes:
>Subject: Re: 10 Reasons Why Scheme is Better Than C/C++
>From: Dennis Weldy, dmw...@ingr.com
>Date: 5 Dec 1996 17:20:17 GMT

>>If you need to do work like that in your programs, use Scheme or SML!
>
>OK, try doing low-level work in scheme? Previous posts in the assembly vs
>C/C++ thread referred to blit-scale function. ;-). I've no idea if this
>could be written in Scheme or not. Does Scheme support pointers? I've no
>idea.
>
>C/C++ is a systems programming language. I doubt the developers of C cared
>about whether 1/3 would be represented as a fraction, or about currying.
>;-).
>
>There any Scheme-based operating systems about?
>
>Scheme, SML, C, C++, heck even assembly Use the right tool for the work
>you're trying to do.
>
>Dennis
>

This is a pretty rediculous thread. Do you think any C++ programmers are
going to think, "Gee, currying is so much easier in Scheme, I think I
will switch." Hell, I don't even know what currying is. It is the same
for the blit-scale function in assembler is better argument. It is such
a infinitesimal part of what we do that it contributes nothing to the
discusion of what language is better. In addition, before this thread, I
have never even heard of Scheme. I'm not aware of a Borland, Symantec,
Microsoft or Metrowerks Scheme compiler. Where is the support for the
great language? It really would not matter if the Scheme semantics were
100 times better than C++. I'm going to use the language that brings me
the highest hourly rate and the most billable hours period.

Michael

Guillermo (Bill) J. Rozas

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <32A6B7...@cs.bham.ac.bham> Stuart I Reynolds <s...@cs.bham.ac.bham> writes:

| From: Stuart I Reynolds <s...@cs.bham.ac.bham>
| Date: Thu, 05 Dec 1996 11:53:45 +0000
|
| Besides, what C++ does do is let you create your own types, which in
| turn could represent numbers as numerators and denominators, and
| redefine the meaning of operators which act upon them. C++ is pretty
| poineering (and still unique, I believe) in this respect. What you have
| described in Scheme takes that flexibilty away from you - can it do
| integer division?

Scheme can do both integer and complex number division (in an
implementation that supports the full numeric tower).

The / operator performs complex division. The quotient operator
performs integer division.

Scheme has not taken the flexibility away. It has just made a
different choice on the meaning of a common operator.

The generic arithmetic of Scheme (and other Lisps) isolates from
word-size vagaries (implementations often have limited-size operators
as well, but not the standard) and some loss of accuracy.

Jason Orendorff

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

> > There are, in fact, several of us that can consistently remember
> >that multiplication and division have higher precedence than addition and
> >subtraction.
> Sure, but what about * and [] and -> and :: and . and so and so forth?
> It's particularly frustrating now that STL iterators have made
> (*foo).something_or_other common again.
Okay-- I can't speak for everybody, but I have no problem
remembering that :: is the fastest, that -> and . and [] all have the same
precedence, and that * is a little slower. Maybe it's because I use C++
pretty frequently.

> However, your C++ program still has an order of magnitude more characters with
> special syntactic meaning, making it an order of magnitude harder to read, so
> you're still losing. You've got () denoting a function call, {} for blocks, ::
> for scope resolution < > for template instantiation, *, ., &, and -> for
> dealing with accessing bits (excuse me, "objects"), and operator overloading
> and implicit casts making things even harder to follow.
I disagree. A language in which you have [] for array element
access is easier to read than one that uses (), especially if () has
other meanings.
I like having {} for blocks and () for function calls... versus
() for blocks and () for function calls. Yeesh.
* . & -> are used for two reasons: (a) with pointers, because
C++ can do that kind of thing; (b) with iterators, because C++ has no
lambdas (ouch).

> How about this:
>
> for (std::list < Big<Hairy<Template<thingamabob<char *> > > >::const_iterator
> i = ((derivedtype *)&baseref)->baz()->begin();
> i != ((derivedtype *)&baseref)->baz()->end(); i++ )
> {
> (*i)->do_something();
> }
>
> versus (mapc 'do-something i)
Well, the C++ will actually work, but your Lisp is buggy. (Lisp
also would give you the error in the wrong place, whereas if there were an
error in the C++ code, the compiler would flag it at the actual line where
your typo was.)

> And yes, I actually *do* have to deal with code that hairy,
Everybody does. :o\ The fact that C++ is as yet nonstandard
hurts a lot.
But in a feeble attempt to show the good side of C++, even in a
bad situation: In C++, you know that the cast to (derivedtype *) isn't
entirely safe (and you have plenty of time to think about it, as you
type... *ruegrin*) And of course the C++ will run faster, and without
unnecessary runtime checking.
Priorities...

> C++ makes my eyes boggle. You have to go to incredible lengths to do
> *anything* high-level and abstract in it, because you have to manually make up
> for C++'s lack of anything remotely resembling a decent programming language.
*laugh* I'll have to keep that one. Thanks for the food for
thought.

--Mohammed


scha...@wat.hookup.net

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In <32A59F...@netright.com>, David Hanley <da...@netright.com> writes:
> ...
> Maybe I just went to a bad school, but was learned about something
>called "integers" first. If i remember correctly, when dividing these
>"integers" 1/3 the correct result was zero. I use this kind of stuff a

No: the correct result in the domain of integers is 0 with a remainder of 2.
to handle such results more concisely, fractions were invented.

>lot when I write computer programs, and am saddened that I've been using
>an invalid construct all these years. ( note sarcasm )
> ...
> The fact it gives a wrong result doesn't impress me too much.

It gives you the right result in the domain of rational numbers, and there
either is a library function or you can write one yourself for each of the
following desired results:

- integer quotient
- remainder
- pair of quotient and remainder

>> which includes has rational numbers. The fact that C
>> didn't know about anything but "int" and "double"
>
> hardly--it has short, long, float, et al.
>
> dave

Hartmann Schaffer


Matthias Blume

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <32A6B7...@cs.bham.ac.bham> Stuart I Reynolds <s...@cs.bham.ac.bham> writes:

Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3 are
in the INTEGER domain.

Nonsense. There is no division in the integer domain. That is to
say, in the ring of integers there doesn't exist a multiplicative
inverse for most of the elements. What you call integer division is a
very different concept. And here the answer 0 for 1/3 is not even
complete, because you forgot to mention the remainder. The result of
integer division is _two_ numbers: a quotient and a remainder.
Unfortunately, languages which get this right are extremely rare, even
though most microprocessors actually calculate both numbers at the
same time.

To evaluate the division of one integer with
another integer will result in an integer, whether using programming
lanuages, alogrithms on paper or whatever. Integers have well defined
properties as does integer division - this is not in any way a fault of
C++.

Yes, it is just a different concept, not at all the same as taking the
inverse in a domain that provides such multiplicative inverses. If
you make clear beforehand what you are talking about, then, of course,
there is no confusion later on. As I pointed out in another reply
before, you could just as easily define 1/3 to be 2. And it would
even make sense.

It is C's fault to denote two very different concepts by the same
symbol: /. C++ has inherited this fault. Furthermore, by allowing
programmers to add their own overloads it has made the situation
worse. Example: cout << 2 << 2. This one should print "22". On
the other hand: cout << (2 << 2) completely changes the meaning of the
second << and prints "8".

Besides, what C++ does do is let you create your own types, which in
turn could represent numbers as numerators and denominators, and
redefine the meaning of operators which act upon them. C++ is pretty
poineering (and still unique, I believe) in this respect.

Huh? Do you actually know any other language. C++ is by no means
pioneering in _any_ respect.

What you have
described in Scheme takes that flexibilty away from you - can it do
integer division?

Of course. Except, in Scheme you use a different name for that
operation (which is appropriate, since it is conceptually very
different).

--
-Matthias

David Hanley

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

a...@laphroig.mch.sni.de wrote:
>
> Davide Hanley wrote:
> >> Pray tell, what is the C++ code equivalent to the above?
> >
> >class add1
> >{
> > int i1;
> > int apply( int i2 ) { return i1 + i2; }
> >}
> >
> >class add2
> >{
> > add1 *apply( int iv ) { return new add1( iv ); }
> >}
> >
> That's only good if you like writing out the gory detail for thousands
> of different addn classes. In scheme you can do it once and for all if
> you define a function addn:
> (define addn (lambda (n) (lambda (x) (+ xn))))
> and then if you need, say add1024, you do (define add1024 (addn 1024))
> and that's it.

That's what the c++ version was doing. You could learn a little c++
before criticizing it.

ish.
> >>
> >> I want numbers to behave like numbers; I'd rather do rounding
> >> explicitly in those rare instances where I want it.
> >
> > Well, I hope you're ready for:
> >
> > 1) Actual computer programmers misunderstanding when they see integer
> >division not behaving like integer division.
> > 2) You programs running really slow when that cool integer computation
> >gets faulted to floating pint.
>
> In scheme integer arithmetic will never get faulted to floating point!
> Integer arithmetic will always stay integer arithmetic; if you cross the
> fixnum boundary it might get slower, but at least you will get the right
> result.

No. The correct result of an integer (1/3)*3 is zero. Now, it's fine
to have a language that gives the wrong result for integer math, along
wiht a big speed hit, but I was trying to point out that it's silly to
riticize other languages for doing something right. There's a lot of
bad stuff in C++ that could be picked on, like MI, casting, and it's
header file approach to project management.

> And integer + integer is never a floating point, but always
> integer.
>

> > Making silly claims about scheme's supposed superiority to C++ won't
> >make more commercial projects use scheme, especially if the people who
> >chose C++ for them chose C++ for those supposed defects, such as the
> >type system.
>
> There"s no need here to advance the art. There are already better
> things, and the reasons why the aren't used but obvioulsy inferior
> things are mor of a psychological end educational nature.

Frankly, I don't buy that argument for a minute. People _are_ moving
away from C++. 4GL's are common, Java is catching on fast, and a lot of
applications are written in visual basic, for crying out loud.
Pprogrammers have demonstrated their ability to change technologies when
there is something better suited waiting.

? (You could


> also say marketing). Do you really think that most commercial projects
> are done in C or C++, because they are technically superior to other
> languages ? No, it's because they simply don't know about modern
> developments in programming languages!

This is not my experience. A lot of people would be happy to stop
using C++ if there was a better alternative--a better language, similar
in speed, with as good enviornments, and a similar array of tools. I
don't think anyone is going to claim that scheme can fill this need.


> > Uck. I _hate_ that. The _last_ thing I want to do when trying to
> >debug someone else's code is trying to decipher the new language
> >features they've added. That possibility alone has probably caused
> >scheme not to be used for some projects.
>
> Uck. I _hate_ that. The _last_ thing I want to do when trying to
> debug someone else's code is trying to decipher the new procedures
> they've added.

Haha. Funny. Are you trying to claim that it's easier to decipher a
procedure in a language that you know, rather than deciphering a new
language? i _really_ doubt that.

dave

James Lee

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

mcde...@hcl.com wrote in <584nbh$1...@news.hcl.com>:

] :-) I think you should re-read what you just wrote, as it's
] rather funny.

Maybe you should take your own advice.

] want to handle rational results on a computer, you must use


] floating point (and start worrying about round-off error, truncation

] error, etc., etc., etc.)

No, if you want to handle rational results, you must use
rational numbers (p/q, p q in Z), which *are not* floating point.

] BTW, 1/3 is an irrational, not a rational, and there's no way to

;-)


--
James Lee <jl...@math.purdue.edu> / Dirk <di...@purdue.edu>
Fingerprint = 2F 00 21 17 A5 16 04 7 8D EC 4E C7 9D 90 22 5F
PGP mail encouraged Key ID: 1024/39A4CC25 Finger for public key

Alan Bawden

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <32A6B7...@cs.bham.ac.bham>
Stuart I Reynolds <s...@cs.bham.ac.bham> writes:

> > The language defect is C++'s (and C's before it). As we were all taught
> > in grade school, 1 divided by 3 is 1/3 (one third).

No, no no!!


Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3 are
in the INTEGER domain.

You're all wrong.

The correct answer should depend on the size of an int. On a 32 bit
machine, the correct answer is: -1431655765

I am surrounded by morons.
--
Alan Bawden Al...@LCS.MIT.EDU
617/492-7274 06BF9EB8FC4CFC24DC75BDAE3BB25C4B

Raffael Cavallaro

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

In article <584nbh$1...@news.hcl.com>, mcde...@hcl.com wrote:


> BTW, 1/3 is an irrational, not a rational, and there's no way to

> represent that precisely at all (using floating point) on a computer.

You're confusing a repeating decimal with an irrational number. There a
rational number is any number that can be expressed by the ratio of two
integers. That's why they're called *rational* numbers (get it?--ratio,
rational).1/3 is *obviously* a rational number. Pi is irrational -- it
can't be expressed by the ratio of two integers.

Just because 1/3 is an infinitely repeating number in the *decimal*
system, doesn't make it irrational. After all, in base 3, 1/3 is expressed
as .1

Raf

Christopher Oliver

unread,
Dec 5, 1996, 3:00:00 AM12/5/96
to

Stuart I Reynolds (s...@cs.bham.ac.bham) wrote:
: No, no no!!

: Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3 are
: in the INTEGER domain.

Ummmm... no.

I think the hardened mathematicians will agree that division isn't closed
over the integers, and that there is no integer value for the ratio 1/3.

--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
oli...@traverse.com Traverse City, Michigan, 49684
The loop macro: because no language is complete without a little COBOL.

Kent Tong

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

Thant Tessman <th...@shoreline-studios.com> wrote:

>> This can be done in C++ or Java if all the functions take
>> their parameters from an array or something like that.
>> Then all we need to do is to store "f" and "arg" in a
>> (functional) object just like what you did.
>
>How convenient.
>
>Actually, I've built a curry system for C++ using templates. You
>can do things like this:
>
> void f(const int& i, const int& j) {
> cout << i << " " << j << endl;
> }
>
> Thunk1<int> f2 = curry1(f, 23);
> Thunk0 f3 = curry0(f2, 5);
>
> f3();

You must have missed my point of why we needed to pass the
arguments as a sequence. This is because to mimic the
behavior of your +, max, and etc in scheme that take a
variable number of arguments. Strictly speaking they're
not really functions because functions must have a constant
arity.

>"curry0" and "curry1" are function templates that automatically
>instantiate other helper template classes. "f2" is a function
>object taking a single integer as an argument, and "f3" is a
>function object taking no arguments. The output of evaluating
>"f3()" is "23 5" as one would expect. You can even combine
>the two statements and evaluate them immediately like this:
>
> (curry0(curry1(f, 23), 5))();
>
>Now given that we're working in C++, you gotta admit this is
>pretty cool--certainly better than passing arguments in by way
>of an array.

That's not the purpose of using arrays. Besides, I don't see
why it's cool. In fact, I think it sucks because you have
a separate curry for a different arity.

>First off, this C++ version was a pain to write, and it took a
>long time to get it correct.

Why? Because you don't know C++ well enough?

> Second, it's a pain to use because
>you have to produce a different version of the template function
>for every possible number of arguments (note the "1" and "0" in
>curry1 and curry0 and Thunk1 and Thunk0)

As I said.

>*and* for every possible
>return type. (I've only built them for functions and function
>objects returning void.)

No need. Since all functions of the type:

T1 -> T2 -> T3 -> T4

is in fact of the type:

T1 -> (T2 -> (T3 -> T4))

Function currying is the same as function application. In
C++, as long as all function objects belong to the
following class:

template<T1, T2> class func
{
public:

virtual T2 app(T1 arg) = 0;
};

To curry f, all we need is f.app(arg).

To be fair, there is indeed a difficulty in doing so in C++.
That is we need to convert a C++ function to a functional
object in the first place. This is not really that hard,
however, considering it's hard to find functions taking
more than 10 parameters and thus pre-building 10 template
functions to do the conversion isn't really that difficult.

>Also, you have to have a different
>version for whether you're going to pass arguments by reference,
>or literally on the stack. (I've only implemented the former,
>which is why "f" takes "const int&" instead of "int".)

You can always pass by value. To pass by reference, just
pass the pointer by value.


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Faried Nawaz

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <587390$4...@qualcomm.com> Michael Simpson <simp...@cts.com> writes:

I'm not aware of a Borland, Symantec,
Microsoft or Metrowerks Scheme compiler. Where is the support for the
great language?

Read the second part of the comp.lang.scheme faq. It lists
many implementations, commercial or otherwise, and also lists
mailing lists that deal with Scheme.


It really would not matter if the Scheme semantics were
100 times better than C++. I'm going to use the language that brings me
the highest hourly rate and the most billable hours period.

Then whether a language is good or not isn't all that important to you.


faried.
--
faried nawaz WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE
box 3582, moscow, id 83843-1914, usa linux, the ms-dos of the nineties
AT&T YOU WILL!!!11 let all the poisons that lurk in the mud hatch out
not a system janitor. People's Front Against WWW

Alberto C Moreira

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <587dlg$5...@bert.traverse.com>, oli...@co.traverse.com says...

> Stuart I Reynolds (s...@cs.bham.ac.bham) wrote:
> : No, no no!!
> : Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3
are
> : in the INTEGER domain.
>
> Ummmm... no.
>
> I think the hardened mathematicians will agree that division isn't
closed
> over the integers, and that there is no integer value for the ratio
1/3.


I tought the quotient of two positive integers a/b under integer
division was the number q such that (1) 0 < q <= a, (2) 0 <= r < b, and
(3) a = qb + r.

At least that's what they taught me back in elementary school, and it's
quite a useful definition.


Alberto.

Clifford Beshers

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

Michael Simpson <simp...@cts.com> writes:


> In article <01bbe2d0$58931610$12938781@weldypc> Dennis Weldy,
> dmw...@ingr.com writes:
> >Subject: Re: 10 Reasons Why Scheme is Better Than C/C++
> >From: Dennis Weldy, dmw...@ingr.com
> >Date: 5 Dec 1996 17:20:17 GMT
> >>If you need to do work like that in your programs, use Scheme or SML!
> >
> >OK, try doing low-level work in scheme? Previous posts in the assembly vs
> >C/C++ thread referred to blit-scale function. ;-). I've no idea if this
> >could be written in Scheme or not. Does Scheme support pointers? I've no
> >idea.
> >
> >C/C++ is a systems programming language. I doubt the developers of C cared
> >about whether 1/3 would be represented as a fraction, or about currying.
> >;-).
> >
> >There any Scheme-based operating systems about?

There may be soon. There is a Scheme-based extensible version of NFS.

> >
> >Scheme, SML, C, C++, heck even assembly Use the right tool for the work
> >you're trying to do.
> >
> >Dennis
> >
>
> This is a pretty rediculous thread. Do you think any C++ programmers are
> going to think, "Gee, currying is so much easier in Scheme, I think I
> will switch." Hell, I don't even know what currying is. It is the same

It is not ridiculous. I am an example of such a person. I just
submitted a paper arguing that it is impossible to build my
application optimally in C++, in part because it has zero support for
currying. The facilities of a reflective language with higher-order
functions help tremendously. Partial evaluation and dynamic
compilation help even more.

Oh yes, I made this switch because my programs design and generate
interactive, real-time visualizations on the fly. C++ by itself was a
deep, dark pit for this. The more I convert to Scheme, the better my
application runs. I still do use C++, but I use it when it helps me
do something, not because there are commercial compilers for it.

> for the blit-scale function in assembler is better argument. It is such
> a infinitesimal part of what we do that it contributes nothing to the
> discusion of what language is better. In addition, before this thread, I

> have never even heard of Scheme. I'm not aware of a Borland, Symantec,


> Microsoft or Metrowerks Scheme compiler. Where is the support for the
> great language?

A good place for you to start your education would be:

http://www.cs.indiana.edu/scheme-repository/

> It really would not matter if the Scheme semantics were
> 100 times better than C++. I'm going to use the language that brings me
> the highest hourly rate and the most billable hours period.
>

Nice. You clearly are a far-thinking individual.

--
Clifford Beshers Computer Graphics and User Interfaces Lab
bes...@cs.columbia.edu Department of Computer Science
http://www.cs.columbia.edu/~beshers Columbia University

Matthias Blume

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

The following article is a reply to e-mail from Thomas Breuel, who by
means of clever sender address design cannot be reached otherwise....

In some e-mail that was sent to me Thomas Breuel <t...@intentionally.blank>
writes:

> bl...@dynamic.cs.princeton.edu (Matthias Blume) writes:
> > It is C's fault to denote two very different concepts by the same
> > symbol: /.

> Actually, Fortran did this before, and C simply followed established
> practice (just like many other programming languages). For writing
> numerical algorithms, this convention seems to be much more useful
> than dynamically switching to a rational number representation.

I fail to see the usefulness of it. Why can't you have a different
name for integer division, like so many other languages actually do to
avoid this sort of confusion?

BTW, Fortran is hardly the prototypical example to look at when
studying good language design. [I don't blame the designers of
Fortran, after all, there was hardly any prior art at that time. But
I do blame the designers of C, and even more so, of C++ for making the
same mistakes (and then some) all over again.]

-Matthias
--
-Matthias

Rainer Joswig

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <587390$4...@qualcomm.com>, Michael Simpson <simp...@cts.com> wrote:


> 100 times better than C++. I'm going to use the language that brings me
> the highest hourly rate and the most billable hours period.

I don't know about your hourly rate but C++ will surely
get you the most billable hours. ;-)

Michael Simpson

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <imbuc7n...@elk.cs.uidaho.edu> Faried Nawaz, f...@uidaho.edu
writes:

>
> It really would not matter if the Scheme semantics were
> 100 times better than C++. I'm going to use the language that brings me
> the highest hourly rate and the most billable hours period.
>
>Then whether a language is good or not isn't all that important to you.
>
>

C/C++ accomplishes everything I need it to do as efficient as I need it
to be. I don't see hundreds of help wanted ads asking for scheme
programmers. I do see hundreds of help-wanted C/C++ ads.

Too many programmers are chasing the perfect language that will enable
them to write what they want without errors. Maybe they just aren't good
programmers.

Michael

Michael Simpson

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <yl9afrr...@zippy.cs.columbia.edu> Clifford Beshers,

bes...@zippy.cs.columbia.edu writes:
>Subject: Re: 10 Reasons Why Scheme is Better Than C/C++
>From: Clifford Beshers, bes...@zippy.cs.columbia.edu
>Date: 06 Dec 1996 11:09:54 -0500

>>Michael Simpson <simp...@cts.com> writes:
>
>> This is a pretty rediculous thread. Do you think any C++ programmers are
>> going to think, "Gee, currying is so much easier in Scheme, I think I
>> will switch." Hell, I don't even know what currying is. It is the same
>
>It is not ridiculous. I am an example of such a person. I just
>submitted a paper arguing that it is impossible to build my
>application optimally in C++, in part because it has zero support for
>currying. The facilities of a reflective language with higher-order
>functions help tremendously. Partial evaluation and dynamic
>compilation help even more.

So I ask, what is curring? What is there about currying that has
prevented me from doing my job as a commercial programmer? By the way,
your paper arguing that it is impossible to build you application
optimally in C++ would be wrong. It should be title "It is impossible
for Clifford to build his application optimally in C++."

>Oh yes, I made this switch because my programs design and generate
>interactive, real-time visualizations on the fly. C++ by itself was a
>deep, dark pit for this. The more I convert to Scheme, the better my
>application runs. I still do use C++, but I use it when it helps me
>do something, not because there are commercial compilers for it.

I think you just demonstrated my point. You say Scheme is superior to
C++ and yet you have to resort to C++ to solve problems not addressed by
your language. In the work I do, I don't have to do the hunt and peck
search for languages. Sometimes what I want to do is not easy but it
does not mean it can not be done. The point is that your employer is
not going to pay you to hack together some system with multiple
languages. That just creates a Human Resources headache trying to find
another C/C++/Scheme/Java programmer-hacker. You know, I just don't see
that job description being advertised.

Commercial compilers are important in that you have a single entity that
is being paid to maintain and support a product. You get what you pay
for. Don't even tell me that the gnu stuff is as good as any commercial
environment. The last time I was forced to use the gnu C compiler, it
could not even do a simple implicit short to long conversion. Sheeshh.

>> for the blit-scale function in assembler is better argument. It is such
>> a infinitesimal part of what we do that it contributes nothing to the
>> discusion of what language is better. In addition, before this thread, I
>> have never even heard of Scheme. I'm not aware of a Borland, Symantec,
>> Microsoft or Metrowerks Scheme compiler. Where is the support for the
>> great language?
>
>A good place for you to start your education would be:
>
> http://www.cs.indiana.edu/scheme-repository/

I will take a look. From the look at the code fragments posted, however,
it looks like someone is trying to remarket Lisp.

>> It really would not matter if the Scheme semantics were
>> 100 times better than C++. I'm going to use the language that brings me
>> the highest hourly rate and the most billable hours period.
>>
>

>Nice. You clearly are a far-thinking individual.
>

All the Scheme supporters seem to have .edu addresses. Get out in the
real world of commercial programming then write back. Tell me how you
are doing then. Don't tell me how you are programming at the university.
With few exceptions, programmers who are still in school or programming
at a school don't have a clue and couldn't program their way out of a
paper bag.

I've been to .edu and am now at .com. I'm certain my life's programming
experiences make me a farther thinking individual than you.

Michael

Buddha M Buck

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <MPLANET.32a8427...@news.tiac.net>,

Alberto C Moreira <amor...@nine.com> wrote:
>In article <587dlg$5...@bert.traverse.com>, oli...@co.traverse.com says...
>> Stuart I Reynolds (s...@cs.bham.ac.bham) wrote:
>> : No, no no!!
>> : Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3
>> : are in the INTEGER domain.

>> Ummmm... no.

>> I think the hardened mathematicians will agree that division isn't closed
>> over the integers, and that there is no integer value for the ratio 1/3.

>I tought the quotient of two positive integers a/b under integer
>division was the number q such that (1) 0 < q <= a, (2) 0 <= r < b, and
>(3) a = qb + r.

Yes, that is the quotient, but that's not what we were discussing (we
were talking about integer division, not quotients).

The standard definition of integer division I've seen is that q=a/b
iff qb == a and b != 0. For any given a,b, q is unique if it exists
at all. Division is the operation that expands integers into
rationals (much the same way that subtraction is the operation that
expands naturals into integers). Scheme, when using the full numeric
tower recommended by the Scheme standard, automatically converts the
result of (/ a b) into a rational if no q as defined above exists. It
uses a -different- terminology for your quotient.

Are you saying that integer division in C acts like the quotient rule
above? In that case, does C say that (-3)/2 is -2 or -1?

>At least that's what they taught me back in elementary school, and it's
>quite a useful definition.

True, and few languages exactly implement it, especially in the face
of negative integers.

I don't even know if Scheme requires:

(eq? a (+ (* b (quotient a b)) (remainder a b))) ==> #t

for all integers a,b with b != 0. I know C does -not- require

(a == b*(a/b) + a%b)

to be true for all signed integers a,b (b!=0).

Grant Edwards

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

Robert McDermid (mcde...@hcl.com) wrote:

: BTW, 1/3 is an irrational, not a rational,

Wow. Things have changed a bit since I was in school. Anything that could
be expressed as a "ratio" of two integers was a "ratio"nal number.

: and there's no way to represent that precisely at all (using floating
: point) on a computer.

Maybe on _you're_ computer there isn't. I could design you one upon which
1/3 could be represented exactly in floating point. The cost/performance
would be worse that current architectures -- being able to exactly represent
1/3 in floating point isn't seen as a big performance gain. I can't
guarantee that this computer I design you will be able to exactly represent
_all_ rational numbers. In fact, the architecture I have in mind won't
represent 1/10 or 1/2 exactly.

: Thus, in the example you give, y will never equal x no matter what computer
: language you use.

Depends on the language and the underlying representation. One could design
a computer and a language that would do it. Why one would do such a thing
is another matter.

: (Do any of the symbolic manipulation packages like Maple have a way of
: handling this better?)

--
Grant Edwards | Microsoft isn't the | Yow! Do you have exactly
Rosemount Inc. | answer. Microsoft | what I want in a plaid
| is the question, and | poindexter bar bat??
gra...@rosemount.com | the answer is no. |

Faried Nawaz

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

In article <589p1v$8...@qualcomm.com> Michael Simpson <simp...@cts.com> writes:


C/C++ accomplishes everything I need it to do as efficient as I need it
to be. I don't see hundreds of help wanted ads asking for scheme
programmers. I do see hundreds of help-wanted C/C++ ads.

You say that C/C++ does all you want it to do. So, for you, it is
a perfect language (or something reasonably close to that for all
your purposes). It also meets your needs efficiently -- it does the
work, it's good code, and it has no bugs (assuming working, efficient
code has no bugs). You say that you see a lot of help-wanted ads for
C/C++ programmers (compared to Scheme programmers), and so there's a
large demand for C/C++ programmers; presumably a lot of C/C++
programmers exist (or will exist) to meet that demand.

And then you say



Too many programmers are chasing the perfect language that will enable
them to write what they want without errors. Maybe they just aren't good
programmers.


I guess you've finally realized that you need to learn something
more than C/C++ to be a good programmer.


Isn't self-enlightenment such a beautiful, wonderous thing?

faried.
--
faried nawaz WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE
box 3582, moscow, id 83843-1914, usa linux, the ms-dos of the nineties
AT&T YOU WILL!!!11 let all the poisons that lurk in the mud hatch out

not a system janitor would you die for me?

Daniel Wang

unread,
Dec 6, 1996, 3:00:00 AM12/6/96
to

>>>>> "David" == David Hanley <da...@netright.com> writes:

David> Thant Tessman wrote:
>> GoldenEye wrote:
>>
>> [...]
>>
>> > 2.Dynamic typing allows you to concentrate on real errors, rather >
>> than trying to placate the compiler god. It also makes code vastly >
>> more reusable.
>>
>> David Hanley wrote:
>>
>> > Hardly true. The only time I ever notice the static type > checker
>> is when I get a type mismatch. This would have been a > run-time
>> error in scheme that may have hit for a long time, and > been hard to
>> debug. [...]
>>
>> A good type system is better than no type system, but no type system
>> is better than a bad type system. C++ has a bad type system.

David> This is, of course, a matter of taste. I would qualify
David> scheme's runtime determination of all types as a really bad type
David> system. C++'s type system is actually not all *that* bad, though
David> it certianly could be better.

David> Nonetheless, the claim made in the original post was the
David> dynamic typing is inherently better than static typing, which I
David> personally feel is incorrect.

Hmm I always thought static "typing" was better than dynamic "typing" but never
had anything but my own personal experience to back this claim up. I was
groveling through some old books when I ran across this following tidbit.
[It's a shame that the research in this area has been neglected, I doubt that
there's been any recent replication of the experiment with modern languages.]

(Shneiderman, Ben,_Software_Psychology_, pg 89-99 c1980 Winthrop Publishers.)

\begin{quote}
Gannon (1977) studied the impact of statically-typed versus non-typed
languages on error statistics. In statically-typed languages (e.g. COBOL,
PL/I, FORTAN), declarations statements associate a data type with an
identifier to permit type checking and prevent mixed mode operations. In
non-typed languages (e.g. BCPL, BLISS or Assemblers), each identifier refers
to a group of bits and no restrictions on operations are
imposed. Thirty-eight graduate and advanced undergraduates subjects were
divided into two groups for this counterbalanced ordering experiment: 21
subjects worked with the statically-typed language first and then the
non-typed language while the remaining 17 did the tasks in the reverse
order. The sequence of 48 to 297 line listings and were collected and errors
counted (Table...).

[Abbreviated Table]

Typeless/Statically Typed Group (Order)

Typeless Typed
Total occurrences 125.80 31.40

Statically Typed Group/Typeless (Order)

Typeless Typed
Total occurrences 99.61 51.72

...

The results favoring the statically-typed language are statistically
significant by most measures. The order effect suggests that those who begin
with static typing carry their learned data abstractions to the non-typed
language.
\end{quote}

The Gannon reference is

Gannon, John D., "An experimental evaluation of data type conventions",
Communications of the ACM, 20, 8, (August 1977), 584-595.

I've got to go track it down myself and look at the details to figure out of
the conclusion it makes would probably hold with some of the more popular
langauges of today. (My experience suggests that this is the case..)

I suspect any advantage Scheme has over C/C++ is probably not related to
"dynamic types"..

Dennis Weldy

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

pi is an irrational number, as theres no way to write it as a ratio of two
numbers, a close approximation is 22/7. the number e is also irrational.

1/3 is a rational number, as one can write it as a ratio of two numbers,
namely 1 and 3.
1 is a third of 3, 3 is three times 1. A nice ratio.

:-)

Dennis
James Lee <jl...@math.purdue.edu> wrote in article
<587j9j$2...@mozo.cc.purdue.edu>...

Dennis Weldy

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

People already complain about the number of operators in c/c++.
Oh yeah, lets add another. :-)

Personally, I prefer C/C++ single operator approach. One operator to handle
both integer and floating point division. I know what's going on based on
they types of the variables I'm using.

But, if you want a second operator do the following:

#define div /

int func(int x, int y)
{
int v ;
if(y != 0)
{
v = x div y ;
}
}

There, y'have your operator. :-)

Dennis

Matthias Blume <bl...@dynamic.cs.princeton.edu> wrote in article
<izwwuvy...@dynamic.CS.Princeton.EDU>...


>
> I fail to see the usefulness of it. Why can't you have a different
> name for integer division, like so many other languages actually do to
> avoid this sort of confusion?
>

> -Matthias
>

Seth Tisue

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

In article <32A733...@netright.com>,

David Hanley <da...@netright.com> wrote:
>> > Uck. I _hate_ that. The _last_ thing I want to do when trying to
>> >debug someone else's code is trying to decipher the new language
>> >features they've added. That possibility alone has probably caused
>> >scheme not to be used for some projects.
>>
>> Uck. I _hate_ that. The _last_ thing I want to do when trying to
>> debug someone else's code is trying to decipher the new procedures
>> they've added.
>
> Haha. Funny. Are you trying to claim that it's easier to decipher a
>procedure in a language that you know, rather than deciphering a new
>language? i _really_ doubt that.

It will be easier, if the addition of the new language features
results in a considerable enough overall simplification of the code.
Which is the only justification for adding new language features in
the first place.

--
== Seth Tisue <s-t...@nwu.edu> http://www.cs.nwu.edu/~tisue/

Seth Tisue

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

In article <r8t3exj...@salomon.CS.Princeton.EDU>,

Daniel Wang <dan...@salomon.CS.Princeton.EDU> wrote:
>Hmm I always thought static "typing" was better than dynamic "typing" but never
>had anything but my own personal experience to back this claim up. I was
>groveling through some old books when I ran across this following tidbit.
>[It's a shame that the research in this area has been neglected, I doubt that
>there's been any recent replication of the experiment with modern languages.]

The study you cite compares static typing versus no typing, not static
typing versus dynamic typing.

For example, in assembler, adding two pointers produces a probably
nonsensical answer but does not signal an error.

In a dynamically typed language such as Lisp, trying to add two
non-numeric objects immediately signals an error.

A less confusing terminology might be "compile-time type-checking"
versus "run-time type-checking" versus "no type-checking".

James McCartney

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

In article <joswig-ya0231800...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:

> In article <587390$4...@qualcomm.com>, Michael Simpson <simp...@cts.com>
wrote:
>
>

> > 100 times better than C++. I'm going to use the language that brings me
> > the highest hourly rate and the most billable hours period.

Then you should probably be using Smalltalk.

>
> I don't know about your hourly rate but C++ will surely
> get you the most billable hours. ;-)

ROFL!

--- james mccartney ja...@clyde.as.utexas.edu ja...@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx

David Hanley

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

Seth Tisue wrote:
>
> >> Uck. I _hate_ that. The _last_ thing I want to do when trying to
> >> debug someone else's code is trying to decipher the new procedures
> >> they've added.
> >
> > Haha. Funny. Are you trying to claim that it's easier to decipher a
> >procedure in a language that you know, rather than deciphering a new
> >language? i _really_ doubt that.
>
> It will be easier, if the addition of the new language features
> results in a considerable enough overall simplification of the code.
> Which is the only justification for adding new language features in
> the first place.

I suppose that what I doubt is that, using a macro system, a programmer
could perform an application-specific language extension that would be
"better" ( making the code smaller and easier to debug ) than adding a
new procedure or two. In any case, I haven't seen many examples of
this.

Now, I suppose in certian instances, such as an object system, it's
possible.. But most languages come with that anyaways, and I wouldn't
exactly be thrilled about having to decipher code using someone's (
probably buggy ) homebrewed object system.

Having had to spend a lot of time debugging code written by others, I
have a vast appreciation for the stupid and contrived mistakes people
make. I can just imagine if I had to regularly had to debug code writen
for a subtly different language.


dave

Daniel Wang

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

>>>>> "Seth" == Seth Tisue <ti...@cs.nwu.edu> writes:

Seth> In article <r8t3exj...@salomon.CS.Princeton.EDU>, Daniel Wang


Seth> <dan...@salomon.CS.Princeton.EDU> wrote:
>> Hmm I always thought static "typing" was better than dynamic "typing"
>> but never had anything but my own personal experience to back this
>> claim up. I was groveling through some old books when I ran across
>> this following tidbit. [It's a shame that the research in this area
>> has been neglected, I doubt that there's been any recent replication
>> of the experiment with modern languages.]

Seth> The study you cite compares static typing versus no typing, not
Seth> static typing versus dynamic typing.

Regardless of the dynamic/no-typing distinction the conclusion that
static-types (or at least variables declared with a specific type) helps
people reason and write correct programs is supported.

i.e. The average difference between the number of errors between the typeless
and static-type groups may not be relevant, but the fact that people did
better in the typeless condition if they did the static types first than if
they did the typless condition second is an important result. It shows that
if you do static types first you learn how to do the typeless problems
better. However if you do the typless problems first it doesn't help you
solve the static types problems.

Writing with types helps you think about how to write correct programs
regardless of whether the progamming language supports types or not.

Daniel Wang

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

>>>>> "Daniel" == Daniel Wang <dan...@hart.CS.Princeton.EDU> writes:
{following up myself}
Daniel> Writing with types helps you think about how to write correct
Daniel> programs regardless of whether the progamming language supports
Daniel> types or not.


Well, I headed off to the library and dug up the CACM article to read myself
some specific details that might be of interest are that the languages used
were created specifically for the test, and the difference I talk about
above is seen mostly in "noivce" programmers. The article is a pretty
interesting read... (One of these days, I've got to go sit in the library
and start browsing all the old CACM's it's way more educational than surfing
the web :).. Anyways there's also an article about Mesa that talks about
some anecdotal comments about types and the Mesa system.


scha...@wat.hookup.net

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

checking out problem with newsserver


Clifford Beshers

unread,
Dec 7, 1996, 3:00:00 AM12/7/96
to

Michael Simpson <simp...@cts.com> writes:

>
> This message contains non-ASCII text, but the iso-8859-1 font
> has apparently not yet been installed on this machine.
> (There is no directory named /n/ober/src/solaris/mail/mm2.7/src/fonts.)
> What follows may be partially unreadable, but the English (ASCII) parts
> should still be readable.


>
> In article <yl9afrr...@zippy.cs.columbia.edu> Clifford Beshers,
> bes...@zippy.cs.columbia.edu writes:
> >Subject: Re: 10 Reasons Why Scheme is Better Than C/C++
> >From: Clifford Beshers, bes...@zippy.cs.columbia.edu
> >Date: 06 Dec 1996 11:09:54 -0500
> >>Michael Simpson <simp...@cts.com> writes:
> >
> >> This is a pretty rediculous thread. Do you think any C++ programmers are
> >> going to think, "Gee, currying is so much easier in Scheme, I think I
> >> will switch." Hell, I don't even know what currying is. It is the same
> >
> >It is not ridiculous. I am an example of such a person. I just
> >submitted a paper arguing that it is impossible to build my
> >application optimally in C++, in part because it has zero support for
> >currying. The facilities of a reflective language with higher-order
> >functions help tremendously. Partial evaluation and dynamic
> >compilation help even more.
>
> So I ask, what is curring? What is there about currying that has
> prevented me from doing my job as a commercial programmer?

I refer you to the following URL. Simply search for ``curried''.

http://wagner.princeton.edu/foldoc

> By the way,
> your paper arguing that it is impossible to build you application
> optimally in C++ would be wrong. It should be title "It is impossible
> for Clifford to build his application optimally in C++."

How do you know that? You haven't read my paper, I haven't posted
the details. How can you be so certain that I am wrong in my assertion?

The key word is optimally. I built my application in C++. It ran
fine. I am rebuilding it with Scheme and C++. The program is
clearer, more flexible, smaller, and more efficient. I could have
built this in C++, but to do so, I would have had to build in many of
the features in Scheme. Why shouldn't a use a language where someone
has already done the work, and done it better?

>
> >Oh yes, I made this switch because my programs design and generate
> >interactive, real-time visualizations on the fly. C++ by itself was a
> >deep, dark pit for this. The more I convert to Scheme, the better my
> >application runs. I still do use C++, but I use it when it helps me
> >do something, not because there are commercial compilers for it.
>
> I think you just demonstrated my point. You say Scheme is superior to
> C++ and yet you have to resort to C++ to solve problems not addressed by
> your language.

I don't ``resort'' to C++. I use it when it because I already have
modules written in it that I would rather not rewrite, and beause
certain parts of my program can be expressed clearly in it and run
more efficiently than they would with the version of Scheme that I am
using. Were I using a Scheme compiler, rather than an
interpreter, I would change those components to Scheme, because there
would be no litte of no difference in efficiency.

I like C++. I have been using it for years, have advocated it's use,
and helped many other people using it. However, it has flaws and
limitations, and I believe there are better alternatives coming along.

> In the work I do, I don't have to do the hunt and peck
> search for languages.

You're lucky. I'd rather not hunt and peck for languages either, but
I don't do the work that you do.

> Sometimes what I want to do is not easy but it
> does not mean it can not be done.

That something is hard to do does not imply that it cannot be done, I
agree. However, this also does not rule out the possibility that
there exists something which you have not thought of doing, which
cannot be done. Specifically, I know of know no portable way to
generate optimal machine code at run time for a function that is
specified at run time.

> The point is that your employer is
> not going to pay you to hack together some system with multiple
> languages.

On the contrary. My employer ``in .com'' pays me to do exactly that.

> That just creates a Human Resources headache trying to find
> another C/C++/Scheme/Java programmer-hacker. You know, I just don't see
> that job description being advertised.

You haven't looked very hard. I have. Uncommon, yes, but not
non-existent. The paper used to be full of ads for JCL programmers;
now they aren't. Will things always be this way?

> Commercial compilers are important in that you have a single entity that
> is being paid to maintain and support a product.

Yes, I agree. Commercial compilers can also be a nuisance, because
customers have little control over fixing bugs, supporting new
platforms, etc.

> You get what you pay
> for. Don't even tell me that the gnu stuff is as good as any commercial
> environment.

I never said anything about the GNU tools. They are better than some
commercial environments, in some ways, not in others.

> The last time I was forced to use the gnu C compiler, it
> could not even do a simple implicit short to long conversion. Sheeshh.
>

I have used commercial compilers that had similar problems. All are
built by humans, who are prone to error. An advantage of the GNU
system is that if one person finds and fixes the bug, you can get a
new distribution right away. It's not for everyone, but the system
works well for many.

> >> for the blit-scale function in assembler is better argument. It is such
> >> a infinitesimal part of what we do that it contributes nothing to the
> >> discusion of what language is better. In addition, before this thread, I
> >> have never even heard of Scheme. I'm not aware of a Borland, Symantec,
> >> Microsoft or Metrowerks Scheme compiler. Where is the support for the
> >> great language?
> >
> >A good place for you to start your education would be:
> >
> > http://www.cs.indiana.edu/scheme-repository/
>
> I will take a look. From the look at the code fragments posted, however,
> it looks like someone is trying to remarket Lisp.
>

To promote the use of a simple and powerful language that is a
descendent of Lisp, yes.

> >> It really would not matter if the Scheme semantics were

> >> 100 times better than C++. I'm going to use the language that brings me
> >> the highest hourly rate and the most billable hours period.
> >>
> >

> >Nice. You clearly are a far-thinking individual.
> >
>
> All the Scheme supporters seem to have .edu addresses. Get out in the
> real world of commercial programming then write back. Tell me how you
> are doing then. Don't tell me how you are programming at the university.
> With few exceptions, programmers who are still in school or programming
> at a school don't have a clue and couldn't program their way out of a
> paper bag.
>

Your skepticism aside, how do you know that I'm not one of the exceptions?

I have been out in ``the real world.'' It's a mess, which isn't so
bad in itself, but it can really lead to trouble. I'm in the
University, because I felt it was important to build better tools for
those in ``the real world'' to use, and because I thought myself
capable of doing so.

> I've been to .edu and am now at .com. I'm certain my life's programming
> experiences make me a farther thinking individual than you.
>
> Michael

I've been at .edu and .com and .edu and .com and .edu. I'm not
certain at all what your experiences have been, so I cannot compare
them with mine. However, I do work closely with people in industry,
and they appreciate it when I build or find them a better tool.

How very certain you seem to be about so many things. Personally, I
hope you get your wish, and spend the rest of your life programming in
C++.

Thomas Lindgren

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

Michael Simpson <simp...@cts.com> writes:
> In article <yl9afrr...@zippy.cs.columbia.edu> Clifford Beshers,
> bes...@zippy.cs.columbia.edu writes:
> >> This is a pretty rediculous thread. Do you think any C++ programmers are
> >> going to think, "Gee, currying is so much easier in Scheme, I think I
> >> will switch." Hell, I don't even know what currying is. It is the same
> >
> >It is not ridiculous. I am an example of such a person. I just
> >submitted a paper arguing that it is impossible to build my
> >application optimally in C++, in part because it has zero support for
> >currying. The facilities of a reflective language with higher-order
> >functions help tremendously. Partial evaluation and dynamic
> >compilation help even more.
>
> So I ask, what is curring? What is there about currying that has
> prevented me from doing my job as a commercial programmer?

I'm not the original author, but here goes:

I see higher-order functions and currying like this: object-oriented
languages provide data abstraction; higher-order languages provide
control abstraction.

Of course, other languages also provide _some_ support for these
concepts: data abstraction originated in the 70's and was done in good
old C and its siblings; likewise, control abstraction can be done in,
say, C++ by writing iterators and so on.

But it may be _easier_ to do data/control abstraction in languages
that actively support such a programming style. OO programming can be
done in C, but it is easier in C++ or Java. When the language makes it easy
for you to think about something, you can develop your thinking
quicker in those directions. For example, you can start thinking about
how objects interact, rather than how to get around the gotchas of
implementing them.

So what is currying then?

Currying is based on treating functions like any other object in your
language. Just as you can create new numbers at runtime (by adding
them together, say), currying lets you create new functions at
runtime (by composing them, or by filling in some of the parameters
of an existing function and leaving the rest to be filled in later).

The main practical advantage in my mind is that one can encapsulate common
programming idioms, such as "apply a function to all elements of a
collection", into a single procedure. Other programmers can then fill in this
template at the points it is used, which reuses your efforts. Sort
of a customizable standard library.

(Since those encapsulations are themselves functions, it's possible
to get creative at this point.)

> >A good place for you to start your education would be:
> >
> > http://www.cs.indiana.edu/scheme-repository/
>
> I will take a look. From the look at the code fragments posted, however,
> it looks like someone is trying to remarket Lisp.

Isn't that what Java is all about? :-)

> All the Scheme supporters seem to have .edu addresses. Get out in the
> real world of commercial programming then write back. Tell me how you
> are doing then. Don't tell me how you are programming at the university.

Commercial programming. Okay, here goes.

Ericsson is using Erlang, a functional language somewhat similar to
Scheme, in developing and selling telecom products that you can buy
today. At present, they are running at least three big Erlang projects
and a number of smaller ones. There are other examples, of course.

Take a look at:

http://www.ericsson.se/erlang/
http://www.ericsson.se/erlang/bulletin/enews/june96/en-june96.html

(Erlang also has direct support for concurrency, fault tolerance,
soft realtime, simple distributed execution, real-time databases and
other goodies. Why make the programmer's job harder than necessary? :-)

> With few exceptions, programmers who are still in school or programming
> at a school don't have a clue and couldn't program their way out of a
> paper bag.

... And then they get programming jobs out in .com-land. Too bad
they don't magically transform into good programmers at that point.
The general state of commercial software today speaks for itself, if you
know what I mean.

--
Thomas Lindgren, Uppsala University
tho...@csd.uu.se, lind...@sics.se
http://www.csd.uu.se/~thomasl/

Copyright Thomas Lindgren, 1996. Distribution on Microsoft Network prohibited.

Fergus Henderson

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

a...@laphroig.mch.sni.de writes:

>You just can't divide the integer 1 by the
>integer 3 and get an integer result. It certainly is not zero.

Yes, that's because division on integers is a partial function.
And the only language that _I_ know of in which you can directly
implement partial functions such as this one is Mercury.
For example:

:- func '/'(int, int) = int.
:- mode '/'(in, in) = out is semidet. % "semidet" means it is
% a partial function
A / B = Result :-
% check divisor not equal to zero
B \= 0,
% check divisibility
A mod B = 0,
% compute result ("//" is truncating integer division)
Result = A // B.

:- func div3(int) = int.
:- mode div3(in) = out is semidet.
div3(X) = X / 3.

:- func foo(int) = int.
foo(X) = if div3(X) > 10 then 42 else X + 1.
% ... then foo(31) = 32, not 42

For more info on Mercury, see <http://www.cs.mu.oz.au/mercury>.

(Please CC me a copy of any followups, I don't usually read these groups.)

--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.

scha...@wat.hookup.net

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

In <58c493$f...@Godzilla.cs.nwu.edu>, ti...@cs.nwu.edu (Seth Tisue) writes:
> ...
>The study you cite compares static typing versus no typing, not static
>typing versus dynamic typing.
>

>For example, in assembler, adding two pointers produces a probably
>nonsensical answer but does not signal an error.
>
>In a dynamically typed language such as Lisp, trying to add two
>non-numeric objects immediately signals an error.
>
>A less confusing terminology might be "compile-time type-checking"
>versus "run-time type-checking" versus "no type-checking".

Some Lisp compilers put lots of effort into compile time type checking, so
your terminology would create yet another type of confusion. How about
variable bound typing versus valu bound typing?

Hartmann Schaffer


Seth Tisue

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

In article <32A9BA...@netright.com>,

David Hanley <da...@netright.com> wrote:
> I suppose that what I doubt is that, using a macro system, a programmer
>could perform an application-specific language extension that would be
>"better" ( making the code smaller and easier to debug ) than adding a
>new procedure or two. In any case, I haven't seen many examples of
>this.

You might be interested in looking through Paul Graham's book "On
Lisp", which is an extended series of such examples.

Seth Tisue

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

In article <58c493$f...@Godzilla.cs.nwu.edu>,

Seth Tisue <ti...@cs.nwu.edu> wrote:
>A less confusing terminology might be "compile-time type-checking"
>versus "run-time type-checking" versus "no type-checking".

OK, enough people have now pointed out that this was a pretty bad
suggestion. Remind me not to tack on last minute additions to my
posts...

Matt Kennel

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Seth Tisue (ti...@cs.nwu.edu) wrote:
: In article <r8t3exj...@salomon.CS.Princeton.EDU>,

: Daniel Wang <dan...@salomon.CS.Princeton.EDU> wrote:
: >Hmm I always thought static "typing" was better than dynamic "typing" but never
: >had anything but my own personal experience to back this claim up. I was
: >groveling through some old books when I ran across this following tidbit.
: >[It's a shame that the research in this area has been neglected, I doubt that
: >there's been any recent replication of the experiment with modern languages.]

: The study you cite compares static typing versus no typing, not static
: typing versus dynamic typing.

: For example, in assembler, adding two pointers produces a probably
: nonsensical answer but does not signal an error.

: In a dynamically typed language such as Lisp, trying to add two
: non-numeric objects immediately signals an error.

: A less confusing terminology might be "compile-time type-checking"


: versus "run-time type-checking" versus "no type-checking".

Not quite. Idiomatic programs in a 'statically typed' language
possess more assertions about the intended operation of the program.

The 'static typing' is really 'static type constraints and assertions'.

Some may be checked at compile time, some at run time, but there
are simply more there to check.

"static typing" also needn't imply explicit, manifest typing: the programmer
doesn't always have to explicitly provide names for the type constraints.

: --

--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
I would not, could not SAVE ON PHONE, |==================================
I would not, could not BUY YOUR LOAN, |The US Government does not like
I would not, could not MAKE MONEY FAST, |spam either. It is ILLEGAL!
I would not, could not SEND NO CA$H, |USC Title 47, section 227
I would not, could not SEE YOUR SITE, |p (b)(1)(C) www.law.cornell.edu/
I would not, could not EAT VEG-I-MITE, | /uscode/47/227.html
I do *not* *like* GREEN CARDS AND SPAM! |==================================
M A D - I - A M!


Stuart I Reynolds

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

David Hanley wrote:
>
> Rob Warnock wrote:
> > The language defect is C++'s (and C's before it). As we were all taught
> > in grade school, 1 divided by 3 is 1/3 (one third).


No, no no!!
Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3 are

in the INTEGER domain. To evaluate the division of one integer with
another integer will result in an integer, whether using programming
lanuages, alogrithms on paper or whatever. Integers have well defined
properties as does integer division - this is not in any way a fault of
C++.

Besides, what C++ does do is let you create your own types, which in
turn could represent numbers as numerators and denominators, and
redefine the meaning of operators which act upon them. C++ is pretty
poineering (and still unique, I believe) in this respect. What you have
described in Scheme takes that flexibilty away from you - can it do
integer division?

If you don't want to do integer division, don't use integers. This is
why C++ is a strongly typed language - unlike BBC BASIC say which also
dynamically altered the types of variables.

Are you saying BASIC is better than C++.

Stu

Seth Tisue

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Hey everybody, let's post 100 *more* messages about what 1 divided by
3 is!!

ko besuijen

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Chris Bitmead wrote:
>
> David Hanley <da...@netright.com> writes:
>
> > > > Bad in 2 ways. With integers, this is not the result you
> > > > want. Frequently you want integers to behave like integers.
> > >
> > > No. You mean that sometimes you don't want division to behave like
> > > division:
> >
> > No, the integer division of 1/3 is 0. Period. Claiming this correct
> > result as a language defect is foolish.
>
> But who said that 1/3 is integer division? Take someone off the street
> and say that if he gives you 1/3 of a dollar you'll give him 0 dollars
> which is the same.

If he would cut his dollar in two parts that is exactly what would
happen.


>
> Perhaps I'm naive, but I reckon 1/3 equals 1/3.

Matthias Blume

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <m3g21fv...@thepla.net> Chris Bitmead <Chr...@thepla.net> writes:

David Hanley <da...@netright.com> writes:

> Hardly true. The only time I ever notice the static type checker is
> when I get a type mismatch. This would have been a run-time error in
> scheme that may have hit for a long time, and been hard to debug.

> Dynamic type checking is a hack to allow for faster interpretation which
> gives awayt a lot.

Obviously you havn't spent a great deal of time writing scheme
code. Consider the scheme function "map". Consider how powerful it
is. Also consider that you can't do anything this powerful in
C++. Consider how many reusable abstractions you can write if you
abandon static type checking.

Obviously you havn't spent a great deal of time writing SML
code. Consider the scheme function "map". Consider how powerful it
is. Also consider that you can't do anything this powerful in
C++. Consider how many reusable abstractions you can write even if you
don't abandon static type checking.

Don't get me wrong, I can see the advantages of static checking. I've
used Sather and Eiffel and they have a lot of good points. But I can
do more in less space with scheme, and reuse more too.

Don't get me wrong, I can see some advantages of dynamic
checking. I've used Scheme (have even written a compiler for it) and
it has a lot of good points. But I can do more in less space with
SML, and reuse at least as much too.

[Of course, this is a bit off topic. Maybe I should add comp.lang.ml
to the list of newsgroups -- just to make sure this flamefest keeps
going.]

Regards,
--
-Matthias

Matthias Blume

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <m3g21fv...@thepla.net> Chris Bitmead <Chr...@thepla.net> writes:

David Hanley <da...@netright.com> writes:

> Hardly true. The only time I ever notice the static type checker is
> when I get a type mismatch. This would have been a run-time error in
> scheme that may have hit for a long time, and been hard to debug.
> Dynamic type checking is a hack to allow for faster interpretation which
> gives awayt a lot.

Obviously you havn't spent a great deal of time writing scheme
code. Consider the scheme function "map". Consider how powerful it
is. Also consider that you can't do anything this powerful in
C++. Consider how many reusable abstractions you can write if you
abandon static type checking.

Obviously you havn't spent a great deal of time writing SML

code. Consider the SML function "map". Consider how powerful it


is. Also consider that you can't do anything this powerful in
C++. Consider how many reusable abstractions you can write even if you
don't abandon static type checking.

Don't get me wrong, I can see the advantages of static checking. I've
used Sather and Eiffel and they have a lot of good points. But I can
do more in less space with scheme, and reuse more too.

Don't get me wrong, I can see some advantages of dynamic

checking. I've used Scheme (and have even written a compiler for it)


and it has a lot of good points. But I can do more in less space with
SML, and reuse at least as much too.

[Of course, this is a bit off topic. Maybe I should add comp.lang.ml
to the list of newsgroups -- just to make sure this flamefest keeps

going. (Not that there is any danger for it to die soon even now.)]

Regards,
--
-Matthias

Bruce Stephens

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

>>>>> "Stuart" == Stuart I Reynolds <s...@cs.bham.ac.bham> writes:

> Even the most hardend mathematicians agree that 1/3 is 0 if 1 and 3
> are in the INTEGER domain.

What does 1 in the rational domain look like? How do I write it?
Should sqrt(3) evaluate to 1?
--
Bruce Stephens | email: B.Ste...@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht, The Netherlands

David Hanley

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Chris Bitmead wrote:
>
> David Hanley <da...@netright.com> writes:
>
> > > 2.Dynamic typing allows you to concentrate on real errors, rather than
> > > trying to placate the compiler god. It
> > > also makes code vastly more reusable.
> >
> > Hardly true. The only time I ever notice the static type checker is
> > when I get a type mismatch. This would have been a run-time error in
> > scheme that may have hit for a long time, and been hard to debug.
> > Dynamic type checking is a hack to allow for faster interpretation which
> > gives awayt a lot.
>
> Obviously you havn't spent a great deal of time writing scheme
> code. Consider the scheme function "map". Consider how powerful it
> is.

SML also has a 'map' function which works perfectly well, and SML has a
more encompasing type system than C++.

> Consider how many reusable abstractions you can write if you
> abandon static type checking.

I don't necessarily agree with that. Could I see some examples of
abstractions that are possible only in a dynamically typed language?

dave

David Hanley

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Chris Bitmead wrote:
>
> David Hanley <da...@netright.com> writes:
>
> > > > Bad in 2 ways. With integers, this is not the result you
> > > > want. Frequently you want integers to behave like integers.
> > >
> > > No. You mean that sometimes you don't want division to behave like
> > > division:
> >
> > No, the integer division of 1/3 is 0. Period. Claiming this correct
> > result as a language defect is foolish.
>
> But who said that 1/3 is integer division? Take someone off the street
> and say that if he gives you 1/3 of a dollar you'll give him 0 dollars
> which is the same.

Not the same thing at all, but thank you, you've made my point
beautifully.

A dollar is 100 cents. If you get back 1/3 of a dollar, you're going
to get 33 cents, every time. No one will even think about this. Maybe
a nice person will give you 34 cents, if the money's not going into
their pocket.

What do you think you're going to get when the store has a penny, and
you're owed 1/3rd of it? Probably zero, right?

It seems that th only people unable to comprehend integer mathemaics
here are the scheme advocates. :) ( it's a JOKE! )

>
> Perhaps I'm naive, but I reckon 1/3 equals 1/3.

Did you ever get fired as a cashier?

dave

Patric Jonsson

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

David Hanley wrote:
> I suppose that what I doubt is that, using a macro system, a programmer
> could perform an application-specific language extension that would be
> "better" ( making the code smaller and easier to debug ) than adding a
> new procedure or two. In any case, I haven't seen many examples of
> this.
>
Try
http://www.stat.ucla.edu/develop/lisp/common/docs/Evolution-of-Lisp.ps.gz
Exercise 2
Page 59

David Doolin

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <m3d8wjv...@thepla.net>, Chris Bitmead <Chr...@thepla.net> writes:
|> David Hanley <da...@netright.com> writes:
|>
|> > > > Bad in 2 ways. With integers, this is not the result you
|> > > > want. Frequently you want integers to behave like integers.
|> > >
|> > > No. You mean that sometimes you don't want division to behave like
|> > > division:
|> >
|> > No, the integer division of 1/3 is 0. Period. Claiming this correct
|> > result as a language defect is foolish.
|>
|> But who said that 1/3 is integer division? Take someone off the street
|> and say that if he gives you 1/3 of a dollar you'll give him 0 dollars
|> which is the same.
|>
|> Perhaps I'm naive, but I reckon 1/3 equals 1/3.
|>

Well, you said it. Check any text on elementary number theory
or abstract algebra. The integer division of 1/3 is 0. Period.
^^^^^^^^^^^^^^^^

--
David M. Doolin Institute for Geotechnology
doo...@cs.utk.edu Department of Civil Eng. UTK


__________________________________________________

You may add me to your junk email list for $1000.00,
payable in US currency. Otherwise, don't call me,
I'll call you. Sending me junk email from a list
obligates you to this contract.
_________________________________________________

Michael Simpson

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <james-ya02328000...@newshost.cc.utexas.edu>
James McCartney,
>>In article <joswig-ya0231800...@news.lavielle.com>,
>jos...@lavielle.com (Rainer Joswig) wrote:
>
>> In article <587390$4...@qualcomm.com>, Michael Simpson <simp...@cts.com>
>wrote:
>>
>>
>> > 100 times better than C++. I'm going to use the language that brings me
>> > the highest hourly rate and the most billable hours period.
>
>Then you should probably be using Smalltalk.

In my industry (PC and Mac shrink-wrapped commercial software), there is
very little demand for Smalltalk. The other language hot language right
now in business is Visual Basic. Visual Basic programmers are getting
$50 and hour consistantly and long term.

>>
>> I don't know about your hourly rate but C++ will surely
>> get you the most billable hours. ;-)
>
>ROFL!

James,
How is this supposed to be interpreted? I know what ROFL; is but what do
you mean by it? We can't read you mind.

Michael Simpson

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <3mpw0ko...@groucho.csd.uu.se> Thomas Lindgren,
tho...@groucho.csd.uu.se writes:
>Subject: Re: Divison. Was Re: 10 Reasons Why Scheme is Better Than C/C++
>From: Thomas Lindgren, tho...@groucho.csd.uu.se
>Date: 08 Dec 1996 19:41:30 +0100

>>
>Michael Simpson <simp...@cts.com> writes:
>> In article <yl9afrr...@zippy.cs.columbia.edu> Clifford Beshers,
>> bes...@zippy.cs.columbia.edu writes:
>> >> This is a pretty rediculous thread. ...
>> >
>> >It is not ridiculous. ...
>>
>> So I ask, what is curring? ...

>
>I'm not the original author, but here goes:
>
[Clip]

>
>So what is currying then?
>
>Currying is based on treating functions like any other object in your
>language. Just as you can create new numbers at runtime (by adding
>them together, say), currying lets you create new functions at
>runtime (by composing them, or by filling in some of the parameters
>of an existing function and leaving the rest to be filled in later).
>
>The main practical advantage in my mind is that one can encapsulate common
>programming idioms, such as "apply a function to all elements of a
>collection", into a single procedure. Other programmers can then fill in this
>template at the points it is used, which reuses your efforts. Sort
>of a customizable standard library.
>
>(Since those encapsulations are themselves functions, it's possible
>to get creative at this point.)
>
Thomas,
This is a prime example of newsnet at it's best. What you described is
certainly an interesting concept. (Others also were kind enough to send
me the information) I think it may be the evolution of OOP. My original
point is that the my language is better than your language is a
rediculous thread. What is not rediculous are the interesting concepts
and paradyms that the newer languages bring to the science. I just take
exception with the idea of don't learn/use C or C++ because Scheme is
better.

Scheme may just be the language we have all been waiting for. It is just
I am willing to wait for it to mature before abandoning all I know in
pursuit of the new mantra. I can only bleed so much being on the cutting
edge. I'm will to let others take the risks now.

>
>Commercial programming. Okay, here goes.
>
>Ericsson is using Erlang, a functional language somewhat similar to
>Scheme, in developing and selling telecom products that you can buy
>today. At present, they are running at least three big Erlang projects
>and a number of smaller ones. There are other examples, of course.

Close but no banana. The product is telecom equipment. The software is
secondary in this case because Ericsson controls the enviroment in which
it runs. It is part of the main product.

>
>(Erlang also has direct support for concurrency, fault tolerance,
>soft realtime, simple distributed execution, real-time databases and
>other goodies. Why make the programmer's job harder than necessary? :-)

I would rather have the OS support concurrency, fault tolerance and
distributed execution. I agree you should use the tools that make life
easier.

>> With few exceptions, programmers who are still in school or programming
>> at a school don't have a clue and couldn't program their way out of a
>> paper bag.
>

>... And then they get programming jobs out in .com-land. Too bad
>they don't magically transform into good programmers at that point.
>The general state of commercial software today speaks for itself, if you
>know what I mean.

Yes, I do. The programs are getting larger and slower with questionable
doubt as to the increase functionality's value. I really don't mind
bending young minds when the get out of school. I remember getting out
of school. Two other guys were hired with me and we were so gung ho.
Hell, we were going to change the world. We just couldn't figure out why
the older workers did not share our enthusiam. ;-)

Michael
sim...@cts.com

Alberto C Moreira

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <589unn$1...@prometheus.acsu.buffalo.edu>,
bmb...@acsu.buffalo.edu says...

> The standard definition of integer division I've seen is that q=a/b
> iff qb == a and b != 0. For any given a,b, q is unique if it exists
> at all. Division is the operation that expands integers into
> rationals (much the same way that subtraction is the operation that
> expands naturals into integers).

Sorry, I haven't bumped into this definition of integer division yet.
I thought the result of "integer division" of two integers a and b
was the quotient of a divided by b.

> Scheme, when using the full numeric
> tower recommended by the Scheme standard, automatically converts the
> result of (/ a b) into a rational if no q as defined above exists. It
> uses a -different- terminology for your quotient.

In other words, it uses a different operation for the "/" operator.
Maybe the real issue is, we're comparing apples and oranges.

> Are you saying that integer division in C acts like the quotient rule
> above? In that case, does C say that (-3)/2 is -2 or -1?

My compiler (MSVC++ 4.2) says (-3)/2 = -1, remainder -1.

> True, and few languages exactly implement it, especially in the face
> of negative integers.

I'm not too sure about the C standard, but there's been extensive
debate on the relative benefits of rounding towards zero vs.
rounding towards minus infinity. I believe the C standard says
"round towards zero", but I'm not sure. Anyone knows the answer ?

> I don't even know if Scheme requires:
>
> (eq? a (+ (* b (quotient a b)) (remainder a b))) ==> #t
>
> for all integers a,b with b != 0. I know C does -not- require
>
> (a == b*(a/b) + a%b)
>
> to be true for all signed integers a,b (b!=0).

From "C, A Reference Manual", by Harbison and Steele, p. 187:

" It is always true that (a/b)*b + a%b is equal to a if b is not zero,
so the behavior of the remainder operation is coupled to that of
integer division". I don't know however if the standard says that.


Alberto.

scha...@wat.hookup.net

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In <584nbh$1...@news.hcl.com>, mcde...@hcl.com (Robert McDermid) writes:
> ...
>:-) I think you should re-read what you just wrote, as it's
>rather funny. If you include rationals as a possible result,
>then you're not doing integer division, since a rational number
>is, by definition, not an integer - it's a rational. Integer

Have you ever heard of functions (operators) where the result is not the
same type as the arguments? Operations on integers producing rational
results seem perfectly legitimate to me.

>division of 1 by 3 produces a result of 0 - there's no other
>way to present the result in the integer number system. If you

This is only a partial result: the true result is the pair (quotient= 0,
remainder= 1). Too bad that you seem to think in a language that permits
only single function values.

>want to handle rational results on a computer, you must use
>floating point (and start worrying about round-off error, truncation
>error, etc., etc., etc.) Whole courses are taught in

Ignorance must be bliss! You can encode a rational number as a pair of
integers.

>Computer Science which deal with nothing but this single area
>of computation - it is by no means a simple topic.

Have you taken any of them?

>BTW, 1/3 is an irrational, not a rational, and there's no way to

Is this New Math? When I went to school it was rational, and according to
the definition I learned then it still is.

>represent that precisely at all (using floating point) on a computer.

Who else is talking about floating point?

>Thus, in the example you give, y will never equal x no matter
>what computer language you use. (Do any of the symbolic manipulation
>packages like Maple have a way of handling this better?)
>
>-- Rob
>==============================================================
>Rob McDermid Hummingbird Communications Ltd.
>mcde...@hcl.com All opinions expressed are my own.
>==============================================================
>

Hartmann Schaffer


Michael Simpson

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <yl9iv6d...@dynamo.cs.columbia.edu> Clifford Beshers,
bes...@dynamo.cs.columbia.edu writes:
>Subject: Re: Divison. Was Re: 10 Reasons Why Scheme is Better Than C/C++
>From: Clifford Beshers, bes...@dynamo.cs.columbia.edu
>Date: 07 Dec 1996 22:17:04 -0500

>>Michael Simpson <simp...@cts.com> writes:
>
>>
>> In article <yl9afrr...@zippy.cs.columbia.edu> Clifford Beshers,
>> bes...@zippy.cs.columbia.edu writes:
>> >Subject: Re: 10 Reasons Why Scheme is Better Than C/C++
>> >From: Clifford Beshers, bes...@zippy.cs.columbia.edu
>> >Date: 06 Dec 1996 11:09:54 -0500

>> >>Michael Simpson <simp...@cts.com> writes:
>> >> This is a pretty rediculous thread. Do you think any C++ programmers are
>> >> going to think, "Gee, currying is so much easier in Scheme, I think I
>> >> will switch." Hell, I don't even know what currying is. It is the same
>>

[more deletia]

>
>> By the way,
>> your paper arguing that it is impossible to build you application
>> optimally in C++ would be wrong. It should be title "It is impossible
>> for Clifford to build his application optimally in C++."
>
>How do you know that? You haven't read my paper, I haven't posted
>the details. How can you be so certain that I am wrong in my assertion?

Your assertion in you paper's title is not valid until your peers can
review your work. That is just the way research is done and presented.
Reread your previous statement carefully. Then reread my statement
carefully. Don't read between the lines or try to generate an
interpretation. You stated that it was impossible to do optimally. That
is not a fact. It is an opinion. My revised statement could be true if
you were to issue that statement. I'm not saying that it is true. Do
you understand what I am saying?

[Subject matter clipped]

>Your skepticism aside, how do you know that I'm not one of the exceptions?
>

Clifford,
You may well be the exception. I'm certain you are bright. You write
well and your arguements are well thought out. However, experienced
programmers should know better than saying their language is better than
another language. I get personal e-mail from students who say they are
confused by professors who say that C/C++ sucks and that it is a horrible
language to use. That the professor refuses to teach such a language.
That sort of behavior is negligent.

I tell these students to learn all that they can. Become as well rounded
as possible. Take C, C++, comparative languages, assembly, database,
data structures and even Scheme (or whatever else is offered.) What is
important for students is not learning the semantics of any one language
but the concepts and mechanics behind the language. That way, no matter
what comes down the pipeline, the student is prepared for the change.

I stand by my original assertion that "my language is better than your
language" is a rediculous thread. What would be more valuable is, "Look
at these features of Scheme. Aren't they cool?" I would then read about
the idea of currying and think about a possibility that I had not
previously considered. That would open up a pleasant discussion of new
ideas instead of what is integer 1 into integer 3.

Michael
sim...@cts.com

David Fox

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Michael Simpson <simp...@cts.com> writes:

] It really would not matter if the Scheme semantics were
] 100 times better than C++. I'm going to use the language that brings me


] the highest hourly rate and the most billable hours period.

Well, lets stop beating around the bush. What's your hourly rate?
How many billable hours this year?
--
David Fox http://www.cat.nyu.edu/fox xoF divaD
NYU Media Research Lab f...@cat.nyu.edu baL hcraeseR aideM UYN

Michael Simpson

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <y5ahglv...@graphics.cat.nyu.edu> David Fox,
f...@no.junk.mail.cat.nyu.edu writes:
>Subject: Re: Divison. Was Re: 10 Reasons Why Scheme is Better Than C/C++
>From: David Fox, f...@no.junk.mail.cat.nyu.edu
>Date: 09 Dec 1996 12:19:42 -0500
>>Michael Simpson <simp...@cts.com> writes:
>
>] It really would not matter if the Scheme semantics were

>] 100 times better than C++. I'm going to use the language that brings me
>] the highest hourly rate and the most billable hours period.
>
>Well, lets stop beating around the bush. What's your hourly rate?
>How many billable hours this year?

A little personal. Let me put it this way. Every programmer I know,
doing what I do (including myself) is making well over $100,000 a year.
I only worked a little over 2000 hours this year because I wanted to
spend more time with my family. Essentially though, I could have worked
many hours more than that. When I was in Switzerland, I was working 80+
hour weeks. (not a typo) Many of the programmers I work with put in
about 60 hours a week.

The reason the highest rate per billable hour is important to me is
because I want to work less hours. I would rather spend the time with my
family. The reason for maximum billable hours is so that I can work the
extra time should I want to do something special with my family, i.e. go
on vacation.

Life is very short guys. I truely enjoy programming but there are so
many other things to do in life that I'm not going to spend every waking
moment concerned about what the hottest language is. There are places to
go and things to see. Programming fulfills my desire to experience those
things while at the same time giving me job (life) satisfaction.

So what is it I do? I am a contractor with a consulting firm (Stellcom
Technologies: http:\\www.stellcom.com) in San Diego, Ca. I specialize in
Windows and Mac programming (C/C++) in the commercial enviroment. There
are many shrink-wrapped packages at CompUSA that I can point to and say
"I had a part in producing that product". (My name is in the credits to
prove it.) And...I was able to do it without Scheme. I'm not negating
the features of Scheme. The original statement was "This thread is
rediculous". "My language rules" arguements are stupid. The same can be
said for Mac vs. PC or any other variant of this tired argument. As I
pointed out in anther post, a better subject would be "Check out these
cool features in Scheme." Then you hope for more significant discussion
of these Scheme features instead of what 1 divided into 3 equals.

Michael
sim...@cts.com

Mukesh Prasad

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Fergus Henderson wrote:
>
> a...@laphroig.mch.sni.de writes:
>
> >You just can't divide the integer 1 by the
> >integer 3 and get an integer result. It certainly is not zero.
>
> Yes, that's because division on integers is a partial function.
> And the only language that _I_ know of in which you can directly
> implement partial functions such as this one is Mercury.
> For example:

There is the "multiple returns" approach, as in CLU

int result, remainder := div( 5, 3 )

will leave "result" set to 1 and "remainder" to 2.

David Hanley

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Sorry, I couldn't download this. In any case, A few people have
misunderstood me on this point. I've seen examples of it, I just
haven't seen any that I think would be smaller, faster, and easier to
debug than just using a few new procedures. The last criteria is pretty
subjective, I think anyone would agree.

The point is that that "great feature" of scheme is a "great feature"
only in a few person's opinions; others might not like it at all. For
example, in C++ you can cast pointers to integers and add them. It's a
feature C++ has that scheme doesn't ( I think it's bad too ). Does that
fact that C++ has this feature make it better than scheme, for that
reason?

---------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Dennis Weldy

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

Please take a look at Ada. Its has this feature also. I can define an ada
package where I can define what it means to "add" two items of my type, or
my type and another type.

Possibly Smalltalk allows this as well.

Stuart I Reynolds <s...@cs.bham.ac.bham> wrote in article
<32ABEA...@cs.bham.ac.bham>...

James L. Preston

unread,
Dec 9, 1996, 3:00:00 AM12/9/96
to

In article <58holb$4...@qualcomm.com> Michael Simpson <simp...@cts.com> writes:

> I stand by my original assertion that "my language is better than your
> language" is a rediculous thread. What would be more valuable is, "Look
> at these features of Scheme. Aren't they cool?" I would then read about
> the idea of currying and think about a possibility that I had not
> previously considered. That would open up a pleasant discussion of new
> ideas instead of what is integer 1 into integer 3.

Hear! Hear!!

On this topic, I can offer a bit of experience. I have been doing lots
of C++ programming for several years now, and recently spent quite
a bit of time trying to determine what to use as an embedded interpreter/
scripting language for the large software system that I take care of.
I worked on Scheme for quite a while (not long enough to get very good
at it) and there is no doubt that it can be a very powerful tool. But
then I discovered Python through some discussion on another newsgroup
and I checked that out. If you want to see some "cool features,"
check out Python at www.python.org (Freely distributed!!)
Python is a language that was designed by someone (Guido van Rossum)
from scratch, based upon considerable experience in the design of
other languages (ABC, etc.) Python is deeply object-oriented, extensible,
dynamically typed, embeddable, interpreted. I would describe it as
having just about all of the best features of Lisp/Scheme, C++,
Perl, Tcl and Java. People talk about what language will work
to decouple the monolithic applications so that the parts can work
independently, yet be linked together in a flexible manner when
appropriate. Well, from what I have seen, Python is a very good
language for this purpose. Anyone interested in interpreted languages
should check it out. You will not be disappointed (except perhaps
with the lack of parentheses ':)

later,
jlp


Chris Bitmead

unread,
Dec 10, 1996, 3:00:00 AM12/10/96
to

David Hanley <da...@netright.com> writes:

> > 2.Dynamic typing allows you to concentrate on real errors, rather than
> > trying to placate the compiler god. It
> > also makes code vastly more reusable.
>
> Hardly true. The only time I ever notice the static type checker is
> when I get a type mismatch. This would have been a run-time error in
> scheme that may have hit for a long time, and been hard to debug.
> Dynamic type checking is a hack to allow for faster interpretation which
> gives awayt a lot.

Obviously you havn't spent a great deal of time writing scheme
code. Consider the scheme function "map". Consider how powerful it

is. Also consider that you can't do anything this powerful in

C++. Consider how many reusable abstractions you can write if you
abandon static type checking.

Don't get me wrong, I can see the advantages of static checking. I've

It is loading more messages.
0 new messages