·······@ibm.net wrote:
: In <··········@agate.berkeley.edu>, ·····@stat.Berkeley.EDU (Travis C. Porco) writes:
: >In article <··········@nonexistent.com>, vlad <····@world2u.com> wrote:
: >>·····@stat.Berkeley.EDU (Travis C. Porco) wrote:
: >
: >>>I'd rather spend what time and imagination I have on the problem at hand,
: >>>freed from trying to understand the arcana of a language as needlessly
: >>>complex as C++.
: We all at times forget what programming is all about: Solving problems and
: by extention using the right tools to solve a particular problem. I think C and
: C++ have their place in developing low level systems (real time systems,
: compilers...).
I'd probably restrict the domain much more to only portions of
the aforementioned systems which need the speed that C & C++
provide (assuming they can beat other better alternatives in
those fields).
: >>There is nothing that forces you to use the features you don't understand nor
: >>can master. Once you understand and master the language (any language),
: >>you will call for more features, since you will think the language is too
: >>simple.
: Perhaps the problem is that those "features you don't understand nor
: can master" are the best way that language can do a particular task.
With C & C++ it's more like these "features" are always looming
above our heads. For instance the whole pointer fiasco in C.
When is the user required to manually manipulate pointers?
In numerous languages (like Haskell) pointers are never needed,
and you can happily manipulate trees and other traditionally
"pointer-dependent" data structures with greater ease than
you could in languages which require pointers. In other languages
the use of the aforementioned pointers are only required when
you need certain data structures like trees (ie: Ada). In
C however, you need pointers for tasks which do not require
them -- modifying arguments to functions!
This is a clear example of complexity that is not needed, but
which is forced upon the user regardless. Now a portion of
your thinking is devoted to juggling the pointers of the
function you are writing, and remembering to manually dereference,
and realizing that any blunder at this point could easily lead
to an error requiring hours of debugging time.
The situation is even nastier when you already wrote a function,
but want its parameters to be modified, or vice versa. Then
you have to go and modify every reference to the variable
for a task which in other languages requires a mere alteration
of the parameter list in the declaration and invocation.
Again there is no excuse for this kind of mess, and it is a prime
example of the "needless arcana" of which a previous poster
spoke.
: >I want power, flexibility, and safety--without having to deal directly with
: >any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
: >Travis
: Have you ever looked at Modula-3?
[Snip of Modula-3 features]
I for one am happy that all was not lost on Pascal. It's nice to see
languages like Modula-3, Ada, and Oberon which inherited the
Pascal legacy of clarity, elegance, and simplicity, but not lack
of functionality. While I'm a functional language person myself,
if I couldn't have functional languages usurp C/C++'s dominance,
I believe that one of the above languages would make very
worthy alternatives.
--
Cya,
Ahmed
Brains for dinner, brains for lunch
Brains for breakfast, brains for brunch
Brains at every single meal
Why can't we have some guts?
"Brain Eaters" by the Misfits
········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
> In numerous languages (like Haskell) pointers are never needed,
> and you can happily manipulate trees and other traditionally
> "pointer-dependent" data structures with greater ease than
> you could in languages which require pointers. In other languages
> the use of the aforementioned pointers are only required when
> you need certain data structures like trees (ie: Ada). In
> C however, you need pointers for tasks which do not require
> them -- modifying arguments to functions!
In C++, however, you don't need pointers for that task. Why pick
on C's deficiencies in an article that isn't even being posted
to a C newsgroup? This article is posted to comp.lang.c++ and
comp.lang.lisp; neither of those newsgroups deals with C.
* ········@Bayou.UH.EDU
| In C however, you need pointers for tasks which do not require them --
| modifying arguments to functions!
the very existence of a "better" mechanism to do this in C++ (references)
suggest that multiple return values really do make a lot of sense, despite
all the hostile arguments from certain camps when you suggest this. that a
widely used tool like `perl' also supports them as a matter of course, and
to its users delight, is perhaps indicative of a fundamental flaw in the
argument that functions in programming languages should only return one
value, as opposed to functions in mathematics, which already differ greatly
from "our" functions.
incidentally, I happen to dislike the approaches to faking the return of
multiple values that don't actually return multiple values: structs in C,
lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
references (mere syntactic sugar for pointers) in C++, etc.
my favorite example is getting the current time under Unix and in C:
`gettimeofday' takes two pointers to structures you have to declare and
possibly allocate memory for, fills them in for you, and then you get to
retriev the values from them. the function returns four integers in this
very complicated way: seconds since the epoch, microseconds into the
current second, time zone as the number of minutes west of Greenwich, and
the type of daylight savings time to apply. let's also not forget that
`gettimeofday' includes an error return value to indicate only one kind of
error: "an argument address referenced invalid memory", or a stray pointer.
to decode this time into your current timezone, you need to decode it with
the function `localtime', which, unsurprisingly, takes a pointer to the
first return value from `gettimeofday' and returns a pointer to statically
allocated memory that contains the values you need in a structure. you
need to make certain that you copy all of these values to your own space
before some other function clobbers it. `localtime' returns 11 values,
most of which you don't need. (and then, of course, the day of the month
is a number in the range 1-31, but the month is a number in the range 0-11
and the year is 1900 less than the actual year, but that's another can of
worms.) all this to achieve the effect of multiple return values! to
summarize: `gettimeofday' requires pointers to preallocated memory to
return multiple values, and has an error return value to barf on the
address of that memory, while `localtime' returns a pointer to a static
memory area overwritten by each call. this epitomizes the Unix interface
as I see it -- Unix doesn't give its programmers the time of day.
#\Erik
--
my other car is a cdr
Erik Naggum (····@naggum.no) wrote:
: * ········@Bayou.UH.EDU
: | In C however, you need pointers for tasks which do not require them --
: | modifying arguments to functions!
: the very existence of a "better" mechanism to do this in C++ (references)
: suggest that multiple return values really do make a lot of sense, despite
: all the hostile arguments from certain camps when you suggest this.
Multiple returns make plenty of sense.
: that a
: widely used tool like `perl' also supports them as a matter of course, and
: to its users delight, is perhaps indicative of a fundamental flaw in the
: argument that functions in programming languages should only return one
: value, as opposed to functions in mathematics, which already differ greatly
: from "our" functions.
Frankly I'm all for the return of multiple values from functions.
: incidentally, I happen to dislike the approaches to faking the return of
: multiple values that don't actually return multiple values: structs in C,
: lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
: references (mere syntactic sugar for pointers) in C++, etc.
Well I like to be able to simply return the values without
faking also, but if the "faking" is transparent then I won't
mind. For instance, Haskell doesn't allow multiple returns
from functions but it does consider the tuple to be a basic
data type and therefore multiple values can be encapsulated
in a tuple and easily used. For instance:
(x, y, z) = f a b c
Here, f is returning one value, a tuple, but you can place
variables inside the tuple and they will get the value of
each corresponding element. Tuples are also homogenous, so
even though this is "faking", it's virtually invisible and
is even better than the real thing since you can store
the entire return in one variable and later pick out the
components with great ease and elegance.
[Snip -- long but excellent example of the convolutions you can
go through to simulate multiple return values]
: all this to achieve the effect of multiple return values! to
: summarize: `gettimeofday' requires pointers to preallocated memory to
: return multiple values, and has an error return value to barf on the
: address of that memory, while `localtime' returns a pointer to a static
: memory area overwritten by each call. this epitomizes the Unix interface
: as I see it -- Unix doesn't give its programmers the time of day.
All I can say is I couldn't agree more. Great example and a
great point.
: #\Erik
: --
: my other car is a cdr
--
Cya,
Ahmed
········@bayou.uh.edu (········@Bayou.UH.EDU) wrote:
: Erik Naggum (····@naggum.no) wrote:
: : * ········@Bayou.UH.EDU
: : | In C however, you need pointers for tasks which do not require them --
: : | modifying arguments to functions!
: each corresponding element. Tuples are also homogenous, so
^^^^^^^^^^
Hetereogenous is what I meant to say. Apologies all.
[Snip]
: : #\Erik
: : --
: : my other car is a cdr
: --
: Cya,
: Ahmed
--
Cya,
Ahmed
I had an operation, a statement of our times
They tied my balls together, what's inside is not alive
"Operation" by the Circle Jerks
With a mighty <················@naggum.no>,
····@naggum.no wibbled into the void...
[beautiful critique of C/C++ kludges for returning multiple values]
> to summarize: `gettimeofday' requires pointers to preallocated memory to
> return multiple values, and has an error return value to barf on the
> address of that memory, while `localtime' returns a pointer to a static
> memory area overwritten by each call. this epitomizes the Unix interface
> as I see it -- Unix doesn't give its programmers the time of day.
This problem isn't even unique to Unix, but I don't want to spoil such
a wonderful punchline with mere pedantry. ;-)
If you'll permit me, I'd like to save this in a page in my homepage,
as I can forsee a time when it'll be useful to refer a C++ programmer
to it. You'll get _full_ credit for it, of course.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
>* Erik Naggum <····@naggum.no> writes:
>| incidentally, I happen to dislike the approaches to faking the return of
>| multiple values that don't actually return multiple values: structs in C,
>| lists in Scheme,
>
>* Chris Bitmead
>| I don't see the problem of returning lists as in Scheme.
>
>that's just like saying you don't see the problem of returning structures
>in C, isn't it? returning a compound structure is very different from
>returning multiple values, and specifically so in the many cases where only
>the first value will be used.
I fail to see the big difference. Sure, having a standard way of doing
it allows the compiler to make more optimisations. (The more library
functions in a language that are standardised the better you can
optimize. Nothing unique about multiple return values).
Just to illustrate, here is an example the Scheme multiple return
value standard proposal, implemented as lists. (It's probably a naive
and flawed implementation), but you get the idea about how little
difference there is.
(define values list)
(define (call-with-values val func) (apply func (val)))
e.g.
(call-with-values (lambda () (values 6 7)) *)
=>42
>when multiple return values require special care in the compiler, be that
>with some heavily optimized forms of lists, or register-allocated vectors
>or whatever, it is silly to argue that they aren't special and could just
>as well be represented by some ordinary data type.
>
>| There is a proposed standard for multiple return values in scheme. It
>| can be implemented as syntactic sugar for returning lists.
>
>I really hope it can be implemented more efficiently, too.
>
>#\Erik
>--
>if you think big enough, you never have to do it
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
"Simply drag your mother in law's mobile phone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
* Erik Naggum
| that's just like saying you don't see the problem of returning structures
| in C, isn't it? returning a compound structure is very different from
| returning multiple values, and specifically so in the many cases where only
| the first value will be used.
* Chris Bitmead
| I fail to see the big difference. Sure, having a standard way of doing
| it allows the compiler to make more optimisations. (The more library
| functions in a language that are standardised the better you can
| optimize. Nothing unique about multiple return values.)
|
| Just to illustrate, here is an example the Scheme multiple return value
| standard proposal, implemented as lists. (It's probably a naive and
| flawed implementation), but you get the idea about how little difference
| there is.
sigh. let me illustrate what I mean with "in the many cases where only the
first value will be used" since you (and others) continue to talk about
operations on _all_ the returned values. in Common Lisp, `floor' of one
argument returns two values, the largest integer smaller than the argument,
and the "rest". normally, you don't need the second value.
in Common Lisp, (+ (floor 17.42) 3) evaluates to 20. if I read your Scheme
proposal right, you need to know that the function can return multiple
values and the expression becomes (+ (first-value (floor 17.42)) 3), where
`first-value' is just another name for `car'. it is _this_ aspect of
multiple values that requires special handling in the compiler, and which,
if you fake them with lists or whatever, you _still_ must recognize as a
special property of the first of the returned values that does not apply to
the first element of a returned list.
a multiple value return mechanism that does not cons is _very_ valuable.
one that conses and costs a hell of a lot more than normal value returns
(e.g., in always having to fetch the first value explicitly) is just too
painful to use.
#\Erik
--
if you think big enough, you never have to do it
From: William D Clinger
Subject: Multiple values in R5RS Scheme
Date:
Message-ID: <330DF03C.3ABA@ccs.neu.edu>
This message was composed in response to a thread whose subject
was "What is wrong with OO ?". I have changed the subject line,
removed comp.lang.c++ from the list of newsgroups, and added
comp.lang.scheme (in case its residents need new fuel).
The code posted by Chris Bitmead was not a correct implementation
of R5RS multiple return values, which requires (VALUES X) to be
equivalent to X, and requires (CALL-WITH-VALUES * -) to evaluate
to -1.
It is true that an inefficient version of the R5RS multiple value
facility can be implemented in R4RS Scheme using lists, but the
code is somewhat more complex. Furthermore an implementation
in R4RS Scheme wouldn't be able to perform full error checking.
Erik Naggum (····@naggum.no) wrote:
> in Common Lisp, (+ (floor 17.42) 3) evaluates to 20. if I read your Scheme
> proposal right, you need to know that the function can return multiple
> values and the expression becomes (+ (first-value (floor 17.42)) 3), where
> `first-value' is just another name for `car'.
If FLOOR were to return two values, and FIRST-VALUE were a procedure,
then both
(+ (floor 17.42) 3)
and (+ (FIRST-VALUE (FLOOR 17.42)) 3)
would be errors because both contain a call to FLOOR in which the
continuation demands exactly 1 argument.
This is a matter of philosphy. The Scheme community considered
a semantics in which the continuation passed to FLOOR would
accept 1 or more return values, but some felt that Common Lisp's
implicit ignoring of extra return values would lead to bugs in
which a return value that should not be ignored would be.
#flame on
In fact, the Scheme community went so far as to adopt a semantics
in which
(begin (floor 17.42) 3)
would be an error if FLOOR were to return 2 values. I think this
is incredibly silly. I would be unhappy with any implementation
of R5RS Scheme that does not provide the option of ignoring such
"errors".
#flame off
Erik continued:
> a multiple value return mechanism that does not cons is _very_ valuable.
This is an endorsement of the R5RS mechanism, which does not
require consing.
Will
William D Clinger <····@ccs.neu.edu> writes:
...
>
> #flame on
>
> In fact, the Scheme community went so far as to adopt a semantics
> in which
>
> (begin (floor 17.42) 3)
>
> would be an error if FLOOR were to return 2 values. I think this
> is incredibly silly. I would be unhappy with any implementation
> of R5RS Scheme that does not provide the option of ignoring such
> "errors".
>
> #flame off
>
> Erik continued:
> > a multiple value return mechanism that does not cons is _very_ valuable.
>
> This is an endorsement of the R5RS mechanism, which does not
> require consing.
>
> Will
(declaim (extension:flame-on))
Congratulations to the Scheme community :) It took them 13 years to
adopt as a standard what was there and obviously useful (and non
consing) in Common Lisp in 1984. Of course, in the process the
semantics had to be changed. :)
In the year 2010 R6RS will probably contain a "standard" version of
'format' or maybe of keywords parameters. :)
(declaim (extension:flame-off))
--
Marco Antoniotti - Resistente Umano
===============================================================================