langley@bigbird.rtp.dg.com (Mark L Langley) (03/05/90)
Ron Guilmette replies to article <4800087@m.cs.uiuc.edu> nelson@m.cs.uiuc.edu > > void bill (int b = printf ("default")) {}; > >(That is to say that we can assume that if length is not supplied, then the > passed data is actually a string.) > >But it gets upset since "data" is not yet defined/in that scope. Is there > a way to get around this??? // No. A default value expression for a formal parameter can be any kind of // expression (including function calls) and it can be arbitrarily complex, // but the expression has to be valid IN THE CONTEXT where it appears (just // like all other expressions). ... // Ron Guilmette (rfg@ics.uci.edu) Ah, not so... but I concur insomuch as I think it *should* be true... It is not *IN THE CONTEXT*, as rfg asserts, rather it must be legal outside of any local context. In other words, Cfront gathers up the context at a global scope and uses only that global context. Sad but true consider this... extern "C" { extern printf(...); }; void bar(int x=i+j) { printf("%d\n", x); } main() { int i=20, j=30; bar(); } "default.c", line 3: error: i undefined "default.c", line 3: error: j undefined "default.c", line 3: error: + of void* 3 errors I intend to propose this as a change in ANSI C++, and have already proposed it to AT&T in private correspondance. Mark Langley langley@dg-rtp.dg.com
jak@cs.brown.edu (Jak Kirman) (03/07/90)
langley@bigbird.rtp.dg.com (Mark L Langley) suggests that the following should be legal: > > void bar(int x=i+j) { > printf("%d\n", x); > } > > main() { > int i=20, j=30; > bar(); > } > ...I intend to propose this as a change in ANSI C++, and have already > proposed it to AT&T in private correspondance... Surely you can't be serious about this? You are proposing dynamic scoping for C++. C and C++ have always been lexically scoped, and the problems with dynamic scoping are so great that languages like Lisp, which used to be dynamically scoped, are moving away from it. Consider: - How can you guarantee that any i and j will be in scope when bar is called? You would have to look at the context of every call to bar to decide this. - How do you decide which i and j should be used? You have to scan up the stack at run-time -- a very expensive proposition. - How can you do any reasoning on your program when you have no idea which i and j are going to be used? Jak ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ARPA/BITNET : jak@cs.brown.edu Tel : (401) 863 7664 Snail : 86 Benevolent St, Providence, 02906 RI. Tel : (401) 272 6149 "You'll have to forgive me. I have a memory like a... like a... what are those things you drain rice in?" -- Douglas Adams, "Dirk Gently's..."
shankar@hpclscu.HP.COM (Shankar Unni) (03/10/90)
> > void bar(int x=i+j) { > > printf("%d\n", x); > > } > > main() { > > int i=20, j=30; > > bar(); > > } > > ...I intend to propose this as a change in ANSI C++, and have already > > proposed it to AT&T in private correspondance... > > Surely you can't be serious about this? You are proposing dynamic > scoping for C++. C and C++ have always been lexically scoped, and the > problems with dynamic scoping are so great that languages like Lisp, > which used to be dynamically scoped, are moving away from it. > Hello, "thunks"!! (Who called them that? Hoare?) > - How do you decide which i and j should be used? You have to scan up > the stack at run-time -- a very expensive proposition. Does anyone remember the famous "call-by-name" in Algol 6*? Just as an example (at undergrad school), I tried calculating the Ackermann function (I tried "ackermann(3,4)" for a decent data point) using both call-by-name (the default!) and call-by-value, and got: Call by value : 6 seconds (OK, so it was a slow machine :-/) Call by name : >1200 seconds (The job was killed by the sysadmin) Mark, are you still serious about your proposal? I suggest a re-reading of some elementary (and preferably slightly old) principles-of-programming-languages text (Pratt, or the collection of papers by Dahl, Dijkstra, and Hoare) for a description of call-by-name, and what has to be done to implement it. ----- Shankar Unni E-Mail: shankar@hpda.hp.com Hewlett-Packard California Language Lab.
rfg@ics.uci.edu (Ronald Guilmette) (03/10/90)
In article <820@xyzzy.UUCP> langley@bigbird.rtp.dg.com (Mark L Langley) writes: > > >Ron Guilmette replies to article <4800087@m.cs.uiuc.edu> nelson@m.cs.uiuc.edu > >> >> void bill (int b = printf ("default")) {}; >> >>(That is to say that we can assume that if length is not supplied, then the > > passed data is actually a string.) >> >>But it gets upset since "data" is not yet defined/in that scope. Is there >> a way to get around this??? > >// No. A default value expression for a formal parameter can be any kind of >// expression (including function calls) and it can be arbitrarily complex, >// but the expression has to be valid IN THE CONTEXT where it appears (just >// like all other expressions). > ... >// Ron Guilmette (rfg@ics.uci.edu) > > >Ah, not so... but I concur insomuch as I think it *should* be true... > >It is not *IN THE CONTEXT*, as rfg asserts, rather it must be legal outside >of any local context. In other words, Cfront gathers up the context at a >global scope and uses only that global context. Sad but true consider this... > > extern "C" { extern printf(...); }; > > void bar(int x=i+j) { > printf("%d\n", x); > } > > main() { > int i=20, j=30; > bar(); > } > "default.c", line 3: error: i undefined > "default.c", line 3: error: j undefined > "default.c", line 3: error: + of void* > 3 errors Mark, you have obviously misconstrued what I said. You are considering the context in which the default value expression actually comes into play (i.e. at a call point). The point at which a default expression comes into play is obviously different from the point in the text where it actually appears. >I intend to propose this as a change in ANSI C++, and have already >proposed it to AT&T in private correspondance. If you are suggesting that the default expressions be semantically evaluated in the context(s) in which they come into play, think again. The difficulty of implementing such a treatment far outweighs the usefulness of having such a treatment. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.