Lambda abstractions in C++ vs. Scheme 
Author Message
 Lambda abstractions in C++ vs. Scheme

Quote:

>Notice how Scheme and C++ code are close _semantically_.

Notice how the Scheme and C++ are quite dissimilar syntactically, i.e.,
the Scheme is actually readable.

Notice how the C++ was only made semantically similar to the Scheme code
by the use of a bizarre preprocessor macro which fundamentally rewrites
C++ syntax.

Question: why jump through these hoops when there are perfectly good
Scheme->C compilers which generate code that runs *faster* than C++ code?
(e.g., Gambit-C)

raf

--
Raffael Cavallaro



Thu, 12 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

Quote:

>This article is to exhibit lambda abstractions in C++ in comparison
>with those of traditional functional languages (e.g., Scheme). The
>article will try to demonstrate that "applicable values" in C++ not
>only look similar to their functional cousins. They are equal in
>_meaning_ as well. [...]

C++ is a fiendishly flexible language, what with the preprocessor,
templates, operator overloading, various abuses of inheritance, and so on.
That it can be twisted to emulate an impure functional language is not
terribly surprising. This does not make C++ a functional language, however,
since at best it can be said that functional-style programming is
_possible_ in C++, not _convenient_; nor does the language particularly
encourage functional programming. (Certainly not pure functional
programming, since C++ in no way discourages side effects.)

Quote:
>The same can be said for currying.

I find this far less convincing. Your example of "currying" in C++ is:

Quote:
>As a matter of fact, currying is built into C++. Compare the following
>C multi-argument application

>        printf("%s%d%c\n","passing many arguments: ",4,'!');

>with an equivalent C++ code

>        cout << "passing many arguments: " << 4 << '!' << endl;

>Simply read operator << as an infix 'apply'.

Sorry, no, that's just nonsense.

The return value of the iostream << operator is a reference to the stream
itself; "cout << whatever" returns cout, which can then be applied to
another <<, and so on for as long as you like.

Real currying does not mean "a function of one argument that returns itself
to allow indefinitely-long application expressions", which is what your
example is doing; it means something more like "a nesting of n functions of
one argument each, such that evaluation of less than n arguments will
return a function, but evaluation of n arguments will return the final
result". Not the same thing at all; there is no "final result" to be gotten
out of the iostream << operator.

It is probably possible to emulate currying in C++ better than your example
does, but I don't think it's worth bothering. The solution would surely be
ugly even in comparison to the stranger aspects of the STL, and usable only
with functions that were written with it in mind (i.e. absolutely nothing
in existence today in any common C++ library, including the STL), and
besides, if you really want a functional language, why not use a real one?

Craig



Thu, 12 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

| Notice how the Scheme and C++ are quite dissimilar syntactically, i.e.,
| the Scheme is actually readable.

  and how about dotted lambda lists (&REST arguments) and APPLY?  to me,
  that's essential to passing functions around.

| Notice how the C++ was only made semantically similar to the Scheme code
| by the use of a bizarre preprocessor macro which fundamentally rewrites
| C++ syntax.

  that's unfair.  we'd have to do much the same thing in Scheme and Lisp to
  make it look like C++.  (sorry. :)

  I thought it was interesting to see how impractical C++ is, but I hope
  this mode of C++ programming catches on.  then it will be a lot easier to
  show C++ victims how programming doesn't have to be so painful.

  nonetheless, one gotta admire anyone who is willing to suffer so much.

#:Erik
--
  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

Just for the heck of it....  you can do pretty much the same in
Ada95. I am positive that Ada enthusiasts will deem the result
superior to C++ :)

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme
NO, I will not compare the languages once more, don't worry...

This is a different comment.
Oleg Kiselyov (who has a curious habit of *not* signing his Web pages
and often his letters...)

shows that it is possible to emulate Scheme or other functional
languages in C++ by some very clever class declarations.

Some people protest, for example Craig{*filter*}son points out that we
should not confuse currying and multi-argument functions.

Others suggest that instead of struggling with the C++ preprocessor,
and some very tortuous tricks, the author should take a "real"
functional
language, eventually use the compiler Scheme->C, etc. I don't think
that this is an appropriate attitude.

1. First, everybody is free to implement what he wishes in any language,
   even crazy things, and a newsgroup which discourages *ANY* creativity
   serves the devil.

2. Such essays on mapping the lambda abstraction etc. onto the C++
classes
   may help those people who want to write compilers of functional
   languages ! Or to write functional virtual machines at a higher level
   than basic tree or postfix code interpreters.

3. In order to convince people attached to C++ that functional languages
   are Good and Nice, we have to show that the formulation of many
   algorithms in functional *style* is useful and pleasant. Having some
   functional tools in C++ it will be easier for them to test it. Then
   their eventual reconversion is a matter of their personal freedom...

I find Oleg's papers nice to read, and enriching, although I will not
use them practically. But I will be very grateful if Oleg or somebody
tells me how to implement in a decent, efficient and pedagogically
acceptable way the lazy evaluation in C++...

==

Jerzy Karczmarczuk
Caen, France.



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

 > This article is to exhibit lambda abstractions in C++ in comparison
 > with those of traditional functional languages (e.g., Scheme).

<snip>

 > Example 1: simple expressions
<snip>
 > Example 2: recursive lambda-expressions
<snip>
 > Example 3: higher-order functions
<snip>
 > Example 4. Currying
<snip>

How about Example 5. Closures?  I'll write the Scheme part for you.
Good luck on the C++ part.

(define (f a b)
   (let* ((u 1)
          (v (h u 2))    ;; h & g return functions.
          (w (g u v 3))
          (x 4)
          (y 5)
          (z 6))
      (lambda (p q) (+ u (v (w x y) a) z p q b))))

I take it you'll have to explicitely build in the variables from the
local environment...

--
Harvey J. Stein
BFM Financial Research



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

Quote:

>> The same can be said for currying.



CD> I find this far less convincing. Your example of "currying" in C++ is:

Quote:
>> cout << "passing many arguments: " << 4 << '!' << endl;

>> Simply read operator << as an infix 'apply'.

CD> Sorry, no, that's just nonsense.

That's too strong a statement.  If you think of cout as having the
recursive type

  mu T . string->T

then `<<' can indeed be understood as an infix apply -- or perhaps,
more convincingly, a postfix `unroll'.

(Where unroll is of type `(mu T.string->T)->string->(mu T.string->T)'.)

CD> Real currying...

You mean `currying of non-recursive types'.

CD> It is probably possible to emulate currying in C++ better than
CD> your example does,

Definitely.

CD> but I don't think it's worth bothering.

Yep.

[good arguments snipped]

CD> and besides, if you really want a functional language, why not use
CD> a real one?

That's the point.  While one can probably prove that anything can be
done in C++, a technique is of no value if it's too inconvenient.

Perhaps more significantly, the problems linked with doing
object-oriented or higher-order programming in a language with no GC
are rather unpleasant.

                                        J.

[Followups snipped]



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

Quote:

> > [ ... ]
> How about Example 5. Closures?  I'll write the Scheme part for you.
> Good luck on the C++ part.

> (define (f a b)
>    (let* ((u 1)
>      (v (h u 2))    ;; h & g return functions.
>      (w (g u v 3))
>      (x 4)
>      (y 5)
>      (z 6))
>       (lambda (p q) (+ u (v (w x y) a) z p q b))))

> I take it you'll have to explicitely build in the variables from the
> local environment...

        You can do it (fairly) trivially[1] by defining a class with a
member function operator() (of two parameters p and q), and a
constructor that takes parameters. The parameters to the constructor
are bound to member variables; operator() uses the values of these to
generate the result. In this particular case, the member variables h
and g could themselves be objects, with a defined operator().

        STL (the C++ Standard Template library) uses this mechanism
extensively.

Footnotes:
[1]  But not elegantly...

--
Raymond Wiker, Orion Systems AS
+47 370 61150



Fri, 13 Jul 2001 03:00:00 GMT  
 Lambda abstractions in C++ vs. Scheme

[...]

Jerzy> I find Oleg's papers nice to read, and enriching, although I will not
Jerzy> use them practically. But I will be very grateful if Oleg or somebody
Jerzy> tells me how to implement in a decent, efficient and pedagogically
Jerzy> acceptable way the lazy evaluation in C++...

Maybe you might want to take a look at the section 22.4.7 of

        "The C++ Programming Language", 3rd edition
        Bjarne Stroustrup, 1997 Addison Wesley.

Best,

-- Gaby



Fri, 13 Jul 2001 03:00:00 GMT  
 
 [ 48 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Lambda abstractions in C++ vs. Scheme

2. Lambda abstractions in C++ vs. Scheme

3. Cellular automata benchmarks: Java vs C++ vs Java vs C++

4. Subroutine, lambda abstraction, tacit form

5. Re-writing abstractions, or Lambda: the ultimate pattern macro

6. Re-writing abstractions, or Lambda: the ultimate pattern macro

7. lambda abstraction in Tcl?

8. (lambda ()) vs #'(lambda ())

9. Translations from Scheme to C++ as aid to teaching C++ after Scheme

10. Metaprogramming: C++ templates vs Scheme macros?

11. Metaprogramming: C++ templates vs Scheme macros?

12. scheme vs c++ performance question

 

 
Powered by phpBB® Forum Software