Home > Archive > Fortran > March 2008 > Intelligent macros .vs. BITS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Intelligent macros .vs. BITS
|
|
| Simulate 2008-03-20, 10:13 pm |
| 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?
| |
| Dan Nagle 2008-03-20, 10:13 pm |
| Hello,
On 2008-03-20 21:02:21 -0400, Simulate <li.simula@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.
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 2008-03-20, 10:13 pm |
| Dan Nagle wrote:
(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 2008-03-21, 4:37 am |
| But generic programming is the overwhelming direction in programing at
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 2008-03-21, 4:37 am |
| Simulate <li.simula@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.
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 2008-03-21, 7:20 pm |
| On Mar 21, 1:11=A0am, nos...@see.signature (Richard Maine) wrote:
> 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.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgement come=
s from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain
| |
| jamesgiles@att.net 2008-03-21, 7:20 pm |
| On Mar 21, 12:11=A0am, nos...@see.signature (Richard Maine) wrote:
> Simulate <li.sim...@gmail.com> wrote:
>
> 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 2008-03-21, 7:20 pm |
| > If Fortran had skipped inheritance and gone straight for generic
> programming we'd now have a language that could attract new users. =A0It
> would have capabilities that are hard to match with other languages
Yes, I strongly agree with the "attract new users".
| |
| Arjen Markus 2008-03-21, 7:20 pm |
| On 21 mrt, 15:50, GaryScott <garylsc...@sbcglobal.net> wrote:
> On Mar 21, 1:11=A0am, nos...@see.signature (Richard Maine) wrote:
>
> <snip>
[color=darkred]
>
> I'd much prefer incorporation of a full fledged existing language like
> Rexx or (argh) <Perl | Python | Ruby (pick one). =A0I 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.
>
>
>
>
>
mes from experience;[color=darkred]
oorspronkelijk bericht niet weergeven -[color=darkred]
>
> - Tekst uit oorspronkelijk bericht weergeven -
You forgot Tcl and several others in that list :)
Regards,
Arjen
| |
| GaryScott 2008-03-21, 7:20 pm |
| On Mar 21, 10:33=A0am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 21 mrt, 15:50, GaryScott <garylsc...@sbcglobal.net> wrote:
>
<snip>
>
<SNIP>
> 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 2008-03-21, 7:20 pm |
| GaryScott wrote:
> On Mar 21, 10:33 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> <snip>
> <SNIP>
>
> I think I'd have included Expect before I'd ever include Tcl.
But Expect is just an extension to Tcl :)
--Mark
| |
| Gary Scott 2008-03-21, 10:13 pm |
| Mark Stucky wrote:
> GaryScott wrote:
>
>
>
> But Expect is just an extension to Tcl :)
:) 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
| |
|
| "Dan Nagle" <dannagle@verizon.net> wrote in message news:2008032021135911272-dannagle@verizonnet...
> On 2008-03-20 21:02:21 -0400, Simulate <li.simula@gmail.com> said:
>
>
> 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.
| |
|
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:4YydnW8d2e7_k37anZ2dnUVZ_sKqnZ2d@co
mcast.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.
|
|
|
|
|