Home > Archive > Fortran > November 2007 > C String Prefix Operator Idea (Was: gfortran diagnostics and so on)
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 |
C String Prefix Operator Idea (Was: gfortran diagnostics and so on)
|
|
| Craig Dedo 2007-11-23, 7:09 pm |
| <jamesgiles@att.net> wrote in message
news:bb15322e-3371-4423-9d2f-797f81189860@r60g2000hsc.googlegroups.com...
> On Nov 23, 10:42 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>
> These all suffer from a weakness that's shared with
> processing the escapes by default: the method is only
> applicable to literals. A better solution would be
> to have a prefix operator that processes escapes.
Good idea. I wish I had thought of that.
In addition to the other advantages that you list, anyone can implement this
idea right now. There is no need to wait for a compiler vendor to provide the
functionality. Just write the function to implement the C language substitution
rules and then use the defined-operator feature. Of course, it would be a
user-defined operator rather than an intrinsic operator, but that should not be
much of an inconvenience; defined unary operators have the highest precedence
anyway (Fortran 2003, 7.3, Table 7.7).
Someone should implement this and then post it in this newsgroup. Perhaps I
could do it, time permitting.
> "Character literal \n without embedded new line."
> .c. "Character result \n with embedded new line."
>
> This has the added bonus of moving the indication to
> the left so it's more easily visible. Since it's an
> operator you can apply it to string variables, expressions
> and so on. So you can write:
>
> .c. ("abc" // '' // "n" // mystring)
>
> If that's your taste. You could write a different
> operator to apply other escapes that some people find
> preferable:
>
> .e. "abc ^m^j" // mystring
>
> String literals should be just that: literals. Their
> value and their appearance should be one-to-one.
>
> --
> J. Giles
--
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: <cdedo@wi.rr.com> or <craig@ctdedo.com>
| |
| James Van Buskirk 2007-11-24, 4:29 am |
| "Craig Dedo" <cdedo@wi.rr.com> wrote in message
news:47472586$0$4966$4c368faf@roadrunner
.com...
> In addition to the other advantages that you list, anyone can implement
> this idea right now. There is no need to wait for a compiler vendor to
> provide the functionality. Just write the function to implement the C
> language substitution rules and then use the defined-operator feature. Of
> course, it would be a user-defined operator rather than an intrinsic
> operator, but that should not be much of an inconvenience; defined unary
> operators have the highest precedence anyway (Fortran 2003, 7.3, Table
> 7.7).
> Someone should implement this and then post it in this newsgroup.
> Perhaps I could do it, time permitting.
Well, not quite. Having high priority is normally undesirable I
think, but of course we could always use parentheses. Let's see...
we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
'\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
"'" to achar(39), '\"' to achar(34), '\' to achar(92), '\?' to achar(63)
and all that, but also '\1' to achar(1), '\12' to achar(10) and
'\123' to achar(83). Also, achar(92)//achar(10) translates to ''.
Microsoft says that '\c' should translate to 'c' but gfortran would
translate it to '\c'.
http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx
Translate '\x12' obviously to achar(18), but does that mean
'\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
to not be unambiguously defined.
A problem with a user-defined function is the translation of
'\"' and "'". These can't both be trapped in the same string
without compiler assistance. In a C program most of the
escape sequences are '\n' which is irrelevant in record-oriented
Fortran I/O. Also, do you want to trim the output of the
function to take into account the string contraction? Easily
done with a specification function, but it would stop the
function from being elemental. Do you want to append the
achar(0) at the end as well? Probably not, because I don't
think existing implementations do so.
Even C compilers implement these escape sequences differently.
Therefore anyone who uses them in C has to be ready to change
his escape sequences around as the program is ported to different
compilers. Changing them to invocations of ACHAR is then just
as normal as would be the case in changing C compilers.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Craig Dedo 2007-11-24, 7:10 pm |
| "James Van Buskirk" <not_valid@comcast.net> wrote in message
news:Dq2dnca0_tpIQNranZ2dnUVZ_jKdnZ2d@co
mcast.com...
> "Craig Dedo" <cdedo@wi.rr.com> wrote in message
> news:47472586$0$4966$4c368faf@roadrunner
.com...
>
>
>
> Well, not quite. Having high priority is normally undesirable I
> think, but of course we could always use parentheses. Let's see...
Thanks for pointing out the complications, but I believe that all or nearly
all of them are already covered by the C 99 Standard, ISO/IEC 9899:1999,
especially section 6.4.4.4.
> we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
> '\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
> "'" to achar(39), '\"' to achar(34), '\' to achar(92), '\?' to achar(63)
> and all that, but also '\1' to achar(1), '\12' to achar(10) and
> '\123' to achar(83). Also, achar(92)//achar(10) translates to ''.
All of these are covered by C99, 6.4.4.4.
> Microsoft says that '\c' should translate to 'c' but gfortran would
> translate it to '\c'.
> http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx
This behavior is Microsoft specific and is labelled as such on the web page
you reference. It is most definitely non-standard. See C99, 6.4.4.4, par. 8
and note 64. In fact, note 64 requires an error condition if there is any
escape sequence that is not covered by any of the specifically authorized
translations.
> Translate '\x12' obviously to achar(18), but does that mean
> '\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
> to not be unambiguously defined.
These are covered by C99, 6.4.4.4, especially par. 1, 5, 6, 7, and 9.
> A problem with a user-defined function is the translation of
> '\"' and "'". These can't both be trapped in the same string
> without compiler assistance. In a C program most of the
> escape sequences are '\n' which is irrelevant in record-oriented
> Fortran I/O. Also, do you want to trim the output of the
> function to take into account the string contraction? Easily
> done with a specification function, but it would stop the
> function from being elemental.
I had not thought about the elemental issue before, but making it elemental
seems reasonable. It would add useful functionality at next to no cost. Blank
padding at the end is not a big deal in Fortran.
> Do you want to append the
> achar(0) at the end as well? Probably not, because I don't
> think existing implementations do so.
I was not planning to add a null character at the end. FWIW, the CVF
extension does add a null character at the end, according to the documentation.
I have not looked at such strings in the debugger, but, in my experience, DEC,
CVF, HP, and Intel documentation is highly accurate.
> Even C compilers implement these escape sequences differently.
> Therefore anyone who uses them in C has to be ready to change
> his escape sequences around as the program is ported to different
> compilers. Changing them to invocations of ACHAR is then just
> as normal as would be the case in changing C compilers.
If I did it, I would follow the C99 standard rigorously and not worry about
compiler-specific deviations from C99. That is the only way to keep the
implementation effort to a reasonable amount.
--
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: <cdedo@wi.rr.com> or <craig@ctdedo.com>
| |
| Craig Dedo 2007-11-24, 7:10 pm |
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:S7ydnVZGcPbCzdXanZ2dnUVZ_jOdnZ2d@co
mcast.com...
>
> As a side note, Java has unicode escapes of the form \uXXXX
> where XXXX is four hex digits. These escapes are processed
> earlier than string escapes, such that a line like:
>
> s="some string\u000a";
>
> will fail with an unterminated string, though
>
> s="another string\u0022;
>
> will work fine.
>
<snip>
>
> -- glen
This feature is actually part of C++ 98 (ISO/IEC 14882:1998) and C99
(ISO/IEC 9899:1999) also. Both standards allow four and eight digit hex codes
to specify ISO 10646 (aka Unicode) characters of the form:
\unnnn and
\Unnnnnnnn
The lowercase version designates one hex quad while the uppercase version
designates two hex quads.
References: C++ 98, 2.2 and C99 6.4.3
--
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: <cdedo@wi.rr.com> or <craig@ctdedo.com>
| |
| James Van Buskirk 2007-11-24, 7:10 pm |
| "Craig Dedo" <cdedo@wi.rr.com> wrote in message
news:47483745$0$24334$4c368faf@roadrunne
r.com...
> If I did it, I would follow the C99 standard rigorously and not worry
> about compiler-specific deviations from C99. That is the only way to keep
> the implementation effort to a reasonable amount.
It occurred to me that a non-intrinsic implementation could not function
in the context of an initialization expression.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Wade Ward 2007-11-26, 4:25 am |
|
"Craig Dedo" <cdedo@wi.rr.com> wrote in message
news:47483745$0$24334$4c368faf@roadrunne
r.com...
> "James Van Buskirk" <not_valid@comcast.net> wrote in message
>
> If I did it, I would follow the C99 standard rigorously and not worry
> about compiler-specific deviations from C99. That is the only way to keep
> the implementation effort to a reasonable amount.
This sounds good on paper, but might be less good in practice.
You'd be wrong to think C99 were popular in the C crowd. I like it, but I'm
very much the exception. Furthermore, I'm not in the C crowd.
--
wade ward
wade@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| Craig Dedo 2007-11-26, 7:17 pm |
| "Wade Ward" <wade@zaxfuuq.net> wrote in message
news:1196059417_6705@sp12lax.superfeed.net...
>
> "Craig Dedo" <cdedo@wi.rr.com> wrote in message
> news:47483745$0$24334$4c368faf@roadrunne
r.com...
>
> This sounds good on paper, but might be less good in practice.
>
> You'd be wrong to think C99 were popular in the C crowd. I like it, but I'm
> very much the exception. Furthermore, I'm not in the C crowd.
> --
> wade ward
>
> wade@zaxfuuq.net
> 435 -838-7760
I believe that your reasoning is faulty on a number of points.
1. In my experience, doing C language programming professionally for over
10 years in commercial environments with real profit-and-loss responsibility,
the software developers take the relevant language standards very seriously.
This includes the ISO C and C++ standards. If the compiler does not support a
particular feature that is in a standard, the expectation is that the developer
of the compiler is actively working to develop that feature for a future
version.
Of course, I am well aware that some C and C++ developers have the attitude
that whatever Emperor Bill decrees is the standard. I can't do anything about
that except to point out to such people that the ISO is the world's official
standards body.
BTW, if you want a real entertainment, #include all of the header files
defined in the C99 standard and use some of those features in the "Hello,
World!" program and try to compile it with MS VC++. Almost certainly, it will
fail, due to the use of unsupported features. Let's see, C99 has been out for
nearly 8 years now. Why is that?
2. I would write such a function for Fortran programmers, not C
programmers. The purpose would be to provide a way to allow the processing of C
language escape sequences while still preserving the integrity of the semantic
interpretation of Fortran character expressions.
C and C++ language bigots do not use Fortran, except under duress.
Professional software developers respect the standards and conventions of the
languages, operating systems, and other tools that they work with. Respect for
such standards and conventions is part of being a professional. Even if a
professional software developer has a strong preference for C or C++, he or she
will respect the standards and conventions of Fortran when programming in
Fortran.
3. If I developed such a function, I would need an objective, impartial
reference framework. The current ISO standard is the best such reference.
4. Technically speaking, any compiler deviations from the provisions of the
C99 standard are non-standard. They cannot be standard-conforming extensions.
This is because the C99 standard requires the compiler to generate an exception
condition if it encounters any escape sequence that is not defined in the C99
standard. I pointed this out in an earlier message in this thread. There is no
flexibility regarding additional escape sequences beyond those defined in the
C99 standard.
--
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: <cdedo@wi.rr.com> or <craig@ctdedo.com>
| |
| Wade Ward 2007-11-27, 7:18 pm |
|
"Craig Dedo" <cdedo@wi.rr.com> wrote in message
news:474adb8d$0$8593$4c368faf@roadrunner
.com...
> "Wade Ward" <wade@zaxfuuq.net> wrote in message
> news:1196059417_6705@sp12lax.superfeed.net...
[color=darkred]
> I believe that your reasoning is faulty on a number of points.
>
> 1. In my experience, doing C language programming professionally for
> over 10 years in commercial environments with real profit-and-loss
> responsibility, the software developers take the relevant language
> standards very seriously. This includes the ISO C and C++ standards. If
> the compiler does not support a particular feature that is in a standard,
> the expectation is that the developer of the compiler is actively working
> to develop that feature for a future version.
That's good to hear.
> Of course, I am well aware that some C and C++ developers have the
> attitude that whatever Emperor Bill decrees is the standard. I can't do
> anything about that except to point out to such people that the ISO is the
> world's official standards body.
> 2. I would write such a function for Fortran programmers, not C
> programmers. The purpose would be to provide a way to allow the
> processing of C language escape sequences while still preserving the
> integrity of the semantic interpretation of Fortran character expressions.
>
> C and C++ language bigots do not use Fortran, except under duress.
> Professional software developers respect the standards and conventions of
> the languages, operating systems, and other tools that they work with.
> Respect for such standards and conventions is part of being a
> professional. Even if a professional software developer has a strong
> preference for C or C++, he or she will respect the standards and
> conventions of Fortran when programming in Fortran.
You question my reasoning. In the above 3 paragraphs I question your facts.
While it is true that the meteoric success and influence of MS drove C++
throughout the eighties, I don't think that Bill's opinion 2007 counts
anymore than mine. First of all, he's retired, and I just can't imagine him
thinking about international comp sci standards. That would be like George
Bush ruminating about the Constitution in the year 2012. Clearly, they
regard these respective documents as toilet paper.
I have no idea what goes on in the c++ world. These people are acutely
aware of their proximity to MS, and I believe they have erected a
sufficiently high wall to have their standrad reflect what is good for their
syntax as opposed to the usual vendor. If I actually laid eyes on their
standard, I could comment further.
With C and MS, my point is that C doesn't talk to MS, not the other way
around. Mention MS in clc and don your asbestos suit....
>
> 3. If I developed such a function, I would need an objective,
> impartial reference framework. The current ISO standard is the best such
> reference.
>
> 4. Technically speaking, any compiler deviations from the provisions
> of the C99 standard are non-standard. They cannot be standard-conforming
> extensions. This is because the C99 standard requires the compiler to
> generate an exception condition if it encounters any escape sequence that
> is not defined in the C99 standard. I pointed this out in an earlier
> message in this thread. There is no flexibility regarding additional
> escape sequences beyond those defined in the C99 standard.
I didn't read this earlier, but now I see your point. Like anything with a
history in C, there's what the current standard says and then an
encyclopedia of past practice. For my own self, what I thought I didn't
know about backslash whatever was in point of fact an underdeveloped
distinction between source and execution sets.
[re-ordered for thematic reasons]
> BTW, if you want a real entertainment, #include all of the header files
> defined in the C99 standard and use some of those features in the "Hello,
> World!" program and try to compile it with MS VC++. Almost certainly, it
> will fail, due to the use of unsupported features. Let's see, C99 has
> been out for nearly 8 years now. Why is that?
Richard Heathfield recently posted a link for the five vendors whose
product had tested as fully-compliant for C-99. I remember thinking that
they would be the usual suspects, inculding Sun and Dinkumware, but
excluding MS. Would anyone expect MS to have a reasonable C99 product?
Well I would, having given myself to the dark empire at a young age, but I
am, like I say, usually in the minority. Most folks including the C vendor
I use, Bloodshed, have enough C compliance to do interoperation where I
think it matters, places like complex.h and boolean types. I'm still
puzzled how the difference between C89 and C99 could show up in printf, but
it does. (Could have something to do with escape sequences, so I guess I'm
on topic.) C's printf function however is variadic, not a candidate for
interop and therefore more boring C in c.l.f.
--
wade ward
wade@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
|
|
|
|
|