Intelligent macros .vs. BITS
Simulate
important feature. However, why the 2008 standard remove the
"Intelligent macros" item?
Dan Nagle
The short answer is that macro preprocessing
was seen as a backward technology. That is,
all macro preprocessing was seen as backward.
See, for instance, PL/1.
Something closer to Ada-style generic programming
was seen as "more modern" programming. Yet that was
rejected as being too costly to implement.
YMMV
The even shorter answer is that
that's the way the votes were counted. ;-)
Also, WG5 (who make these decisions) tries
to work by consensus. There was simply a minority
(I was one) who would never accept macro preprocessing.
The convenor decided the votes were strong enough
to remove a feature nobody thought was essential.
--
Cheers!
Dan Nagle
glen herrmannsfeldt
(snip)
> The short answer is that macro preprocessing
> was seen as a backward technology. That is,
> all macro preprocessing was seen as backward.
Java has no macro facility for the same reason.
For conditional compilation they guarantee that
code in an
if(false) { }
group won't be compiled. The statements to have to
be legal, unlike those in a C
#if 0
#endif
block.
> See, for instance, PL/1.
The PL/I macro processor is probably more featured than
it needs to be. Symbol replacement and conditional compilation,
the two main features of the C preprocessor, are likely the most
used and most useful.
-- glen
Simulate
present time. It may be later to add this feature in Fortran even now.
However, is the feature only wait to next standard in 2016?
Richard Maine
> But generic programming is the overwhelming direction in programing at
> present time.
In some ways, that's a pretty big argument *AGAINST* doing it. Trying to
run after the latest fad ends up with just a mess after a few
generations of such fads; that is not a way to go for the long term.
As it happens, I do think that there is a lot of benefit to generic
program. But *NOT* just because that's the current fad that we should
try to jump on.
However, even among strong supporters of generic programming, there is
major debate as to whether a macro feature is a good way to do it.
Perhaps it is a good way. I'll defer judgement. But I will note that
doing a good job of something like generic programming requires a lot of
careful thought and design work - not just throwing in the first idea
that comes to someone's mind. If you want to know why "intelligent
macros" aren't in the current proposed language, perhaps that is one of
the answers (along with the answers already mentioned, such as that it
didn't get enough votes). Maybe some people thought it too important to
throw in a half-baked job that would get in the way of doing it better
later. I'm not expressing an opinion on whether the proposal was
half-baked or not. I'm just elaborating on whay the fact that something
is considered important might be reason to take the time to come up with
a good proposal.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
GaryScott
> Simulate <li.sim...@gmail.com> wrote:
<snip>
> If you want to know why "intelligent
> macros" aren't in the current proposed language, perhaps that is one of
> the answers (along with the answers already mentioned, such as that it
> didn't get enough votes). Maybe some people thought it too important to
> throw in a half-baked job that would get in the way of doing it better
> later. I'm not expressing an opinion on whether the proposal was
> half-baked or not. I'm just elaborating on whay the fact that something
> is considered important might be reason to take the time to come up with
> a good proposal.
I'd much prefer incorporation of a full fledged existing language like
Rexx or (argh) <Perl | Python | Ruby (pick one). I don't think its
necessary to invent something completely new, which will likely be
"less intelligent" for some time to come than any of these I've
listed.
james...@att.net
> Simulate <li.sim...@gmail.com> wrote:
> > But generic programming is the overwhelming direction in programing at
> > present time.
>
> In some ways, that's a pretty big argument *AGAINST* doing it. Trying to
> run after the latest fad ends up with just a mess after a few
> generations of such fads; that is not a way to go for the long term.
Kind of ironic isn't it? Generic programming was older and more
mature than the fad of inheritance based code when that fad was chosen
to be added to Fortran. Not only that, it's a simpler feature to
describe, implement, teach, use, read, verify, and maintain than
inheritance based code. Inheritance based code can almost
mechanically be converted to generic code, since the capabilities of
the latter are a superset of what inheritance can do. Unlike
inheritance, generic programming doesn't introduce a wholly new form
of dependency. So generic code doesn't become monolithic like
inheritance based code always does. In fact, programmers find that it
encourages modularity.
If Fortran had skipped inheritance and gone straight for generic
programming we'd now have a language that could attract new users. It
would have capabilities that are hard to match with other languages
(most those with generic abilities also have inheritance to stumble
over). Rather than playing "me too" with the rest of the world, we'd
now have a leader.
To be sure, macros are not the best way to do generic programming
(though simple ones would be *very* useful for other things). And the
macro-like Ada implementation of generic is not all that good either.
The "typeful" language Haskell might be a better model.
I tend to agree that Fortran already has something like three kinds of
polymorphism already (counting TRANSFER like tricks) and adding
another, even a superior one, would be cumbersome because of the need
to maintain backward compatibility ("backward" being an appropriate
word here). I will, in a few months, again propose my own possible
such feature. I was interrupted before when the committee
unexpectedly took a "final and binding" vote on what new features to
consider for f2008. I don't think any will listen.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Simulate
> programming we'd now have a language that could attract new users. It
> would have capabilities that are hard to match with other languages
Yes, I strongly agree with the "attract new users".
Arjen Markus
>
> - Tekst uit oorspronkelijk bericht weergeven -
You forgot Tcl and several others in that list :)
Regards,
Arjen
GaryScott
> On 21 mrt, 15:50, GaryScott <garylsc...@sbcglobal.net> wrote:
>
> > I'd much prefer incorporation of a full fledged existing language like
> > Rexx or (argh) <Perl | Python | Ruby (pick one). I don't think its
> > necessary to invent something completely new, which will likely be
> > "less intelligent" for some time to come than any of these I've
> > listed.
>
> You forgot Tcl and several others in that list :)
I think I'd have included Expect before I'd ever include Tcl.
>
> Regards,
>
> Arjen- Hide quoted text -
>
> - Show quoted text -
Mark Stucky
But Expect is just an extension to Tcl :)
--Mark
Gary Scott
:) I thought it was the biggest piece of crap I'd ever had to maintain.
Clearly "designed" by amateurs.
>
> --Mark
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
robin
news:4YydnW8d2e7_k37a...@comcast.com...
> The PL/I macro processor is probably more featured than
> it needs to be. Symbol replacement and conditional compilation,
> the two main features of the C preprocessor, are likely the most
> used and most useful.
The macro facility of PL/I has many uses:
1. generating constants at compile time;
2. insertion of debugging code;
3. replacement of names;
4. inline of code;
5. unrolling of loops;
6. language translation;
to mention a few.
To see some extensive uses, see Barnes' book.
robin
> On 2008-03-20 21:02:21 -0400, Simulate <li.s...@gmail.com> said:
>
> > I have no much knowledge on BITS. I think Intelligent macros is very
> > important feature. However, why the 2008 standard remove the
> > "Intelligent macros" item?
>
> The short answer is that macro preprocessing
> was seen as a backward technology. That is,
> all macro preprocessing was seen as backward.
> See, for instance, PL/1.
The macro facility of PL/I has many uses:
1. generating constants at compile time;
2. insertion of debugging code;
3. replacement of names;
4. inline of code;
5. language translation;
to mention a few.
Craig Dedo
news:1ie4imi.13a7g9c12hk3foN%nos...@see.signature...
I would like to throw out a thought question:
What is the best way to implement generic programming and generic
procedures? What are the trade-offs involved in various approaches? What
languages use the best approaches? What improvements could be made in those
approaches? What languages do it badly and what are the shortcomings of those
approaches?
I'm looking not only for ease and robustness of implementation, but also
robustness and ease of use in using the generic programming feature for
developing applications in Fortran.
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
Craig Powers
>
> I would like to throw out a thought question:
>
> What is the best way to implement generic programming and generic
> procedures? What are the trade-offs involved in various approaches?
> What languages use the best approaches? What improvements could be made
> in those approaches? What languages do it badly and what are the
> shortcomings of those approaches?
>
> I'm looking not only for ease and robustness of implementation, but
> also robustness and ease of use in using the generic programming feature
> for developing applications in Fortran.
My main experience with using generic programming is templates in C++.
Unfortunately, I haven't used them extensively enough to comment on
their major shortcomings, nor have I used other forms of generic
programming enough to comment on the relative advantages and
disadvantages of C++. However, if you were to ask that question in a
C++ newsgroup (e.g. comp.lang.c++.moderated) you would probably get some
very good answers about the plusses and minuses of C++ itself, and you
might even get some good comparitive info from anyone who has used
another language with generic programming features.
Gerry Ford
"Craig Powers" <eni...@hal-pc.org> wrote in message
news:47f16d7d$0$1732$a726...@news.hal-pc.org...
http://www.stlport.org/resources/StepanovUSA.html
The above is an informative link and below is an excerpt.
Question:
Could you explain to a modest C++ programmer what Generic Programming is,
what is the relation of Generic Programming with C++ and STL, and how did
you come to use Generic Programming in a C++ context?
Answer:
Generic programming is a programming method that is based in finding the
most abstract representations of efficient algorithms. That is, you start
with an algorithm and find the most general set of requirements that allows
it to perform and to perform efficiently. The amazing thing is that many
different algorithms need the same set of requirements and there are
multiple implementations of these requirements. The analogous fact in
mathematics is that many different theorems depend on the same set of axioms
and there are many different models of the same axioms. Abstraction works!
Generic programming assumes that there are some fundamental laws that govern
the behavior of software components and that it is possible to design
interoperable modules based on these laws. It is also possible to use the
laws to guide our software design. STL is an example of generic programming.
C++ is a language in which I was able to produce a convincing example.
When I first read this a couple weeks ago, I wondered what this looks like
in fortran:
template <class StrictWeakOrdered>
inline StrictWeakOrdered& max(StrictWeakOrdered& x,
StrictWeakOrdered& y) {
return x < y ? y : x;
}
and
template <class StrictWeakOrdered>
inline const StrictWeakOrdered& max(const StrictWeakOrdered& x,
const StrictWeakOrdered& y) {
return x < y ? y : x;
}
--
"I am waiting for them to prove that God is really American."
~~ Lawrence Ferlinghetti
Arjen Markus
That is an easy one:
max(x,y)
Well, this Fortran equivalent is a trifle less powerful than the C++
one,
but that does not mean it is not basically true :).
Regards,
Arjen
Gerry Ford
"Arjen Markus" <arjen....@wldelft.nl> wrote in message
news:d9078f0f-d62f-4d3b...@e23g2000prf.googlegroups.com...
>
> That is an easy one:
>
> max(x,y)
>
> Well, this Fortran equivalent is a trifle less powerful than the C++
> one,
> but that does not mean it is not basically true :).
Stepanov thought it was important that one of the above was & and the other
was const &. The distinction is lost on me.
My problem with c++ is that when you take out Microsoft and C, I'm not left
with much. The template syntax is, e.g., beyond me.
I like Stepanov's emphasis on algorithms.
--
"That this social order with its pauperism, famines, prisons, gallows,
armies, and wars is necessary to society; that still greater disaster
would ensue if this organization were destroyed; all this is said only
by those who profit by this organization, while those who suffer from it
- and they are ten times as numerous - think and say quite the contrary."
~~ Leo Tolstoy
Arjen Markus
> "Arjen Markus" <arjen.mar...@wldelft.nl> wrote in message
>
> news:d9078f0f-d62f-4d3b...@e23g2000prf.googlegroups.com...
>
>
>
> > On 1 apr, 06:20, "Gerry Ford" <ge...@nowhere.ford> wrote:
> >> When I first read this a couple weeks ago, I wondered what this looks
> >> like
> >> in fortran:
>
> >> template <class StrictWeakOrdered>
> >> inline StrictWeakOrdered& max(StrictWeakOrdered& x,
> >> StrictWeakOrdered& y) {
> >> return x < y ? y : x;
>
> >> }
>
> >> and
> >> template <class StrictWeakOrdered>
> >> inline const StrictWeakOrdered& max(const StrictWeakOrdered& x,
> >> const StrictWeakOrdered& y) {
> >> return x < y ? y : x;
>
> >> }
>
> > That is an easy one:
>
> > max(x,y)
>
> > Well, this Fortran equivalent is a trifle less powerful than the C++
> > one,
> > but that does not mean it is not basically true :).
>
> Stepanov thought it was important that one of the above was & and the other
> was const &. The distinction is lost on me.
>
> My problem with c++ is that when you take out Microsoft and C, I'm not left
> with much. The template syntax is, e.g., beyond me.
>
> I like Stepanov's emphasis on algorithms.
I was in a somewhat frivolous mood when I wrote my answer, but indeed
Fortran
has had generic features at least since FORTRAN 77.
There are two important aspects to generic programming:
1. Notational: C++'s templates are one form, smart macros are another
2. Conceptual: creating a sort of meta-algorithm to solve a whole
class
of problems, not just a particular one (albeit one with lots of
parameters)
I like the description of the conceptual aspect, I think it captures
the
essence of what you want to achieve.
The notational aspect is just as important, but the two templates you
gave are
very idiosyncratic to C++: it has to do with passing values/objects by
reference
or by value (note: in C you _always_ pass by value, but sometimes you
pass
the address by value, resulting more or less effectively in a pass by
reference,
but it is up to you to use the asterisk in the right places).
As for generic design of algorithms: in my opinion, reverse
communication,
though it may not seem modern or even have a awkward reputation, is a
very
flexible solution on the client side to this:
You only have to fill in a few blanks in whatever way you find
necessary
and there you go.
A solution with callbacks is much more restrictive. The interface for
each callback is fixed. And it does not do much more to hide the
details,
you still need to fill the blanks.
But with the right design, either can do the job.
Regards,
Arjen
Craig Powers
> "Arjen Markus" <arjen....@wldelft.nl> wrote in message
> news:d9078f0f-d62f-4d3b...@e23g2000prf.googlegroups.com...
>> On 1 apr, 06:20, "Gerry Ford" <ge...@nowhere.ford> wrote:
>
>>> When I first read this a couple weeks ago, I wondered what this looks
>>> like
>>> in fortran:
>>>
>>> template <class StrictWeakOrdered>
>>> inline StrictWeakOrdered& max(StrictWeakOrdered& x,
>>> StrictWeakOrdered& y) {
>>> return x < y ? y : x;
>>>
>>> }
>>>
>>> and
>>> template <class StrictWeakOrdered>
>>> inline const StrictWeakOrdered& max(const StrictWeakOrdered& x,
>>> const StrictWeakOrdered& y) {
>>> return x < y ? y : x;
>>>
>>> }
>
>> That is an easy one:
>>
>> max(x,y)
>>
>> Well, this Fortran equivalent is a trifle less powerful than the C++
>> one,
>> but that does not mean it is not basically true :).
>
> Stepanov thought it was important that one of the above was & and the other
> was const &. The distinction is lost on me.
The distinction is that the former requires mutable parameters and
provides a mutable result, while the latter allows const parameters (at
the cost of only producing a const result).
You could write code like this with the former:
max(x, y) = max(x, y) + 10;
As a result, whichever of x or y contained the larger value gets 10
added to it.
(setting aside whether that would be appropriate -- keeping in mind even
if, at first blush, it appears to be a bad idea, there may be other
contexts where it is extremely useful for writing concise code)
James Giles
...
> You could write code like this with the former:
> max(x, y) = max(x, y) + 10;
>
> As a result, whichever of x or y contained the larger value gets 10
> added to it.
>
> (setting aside whether that would be appropriate -- keeping in mind
> even if, at first blush, it appears to be a bad idea, there may be
> other contexts where it is extremely useful for writing concise code)
Given that conciseness is never by itself a measure of code quality,
but both legibility and correctness are, it would still seem to be a
bad idea. Certainly any tool which does such a thing should
have that characteristic of its behavior encoded into its name in
some unmistakable way. Other precautions might also be relevant.