Re: idea: on the issue of C and language extensions
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- Date: Fri, 30 Nov 2007 23:30:03 +1000
"santosh" <santosh.k83@xxxxxxxxx> wrote in message
news:fiopji$ftu$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
cr88192 wrote:
I am representing a different approach.
we can actually take weight OFF the standards committee.
how:
by allowing an auxilary "second route" for defining extension
features; this route would be based mostly on something like a mailing
list (or maybe, even here on usenet), and maybe having a few people in
control of defining and adding features (so, people argue about and
formalize ideas in an "open" manner, and a few people take these ideas
and specify them).
this is a lot more formal and controlled than simply having each
compiler go off and do their own thing, or rip off other
implementations, yet far lighter weight and informal than forcing
involvement of a traditional standards committee to formally weight
and consider every possible proposal.
The question is how many of the "major" implementors like GCC, Intel,
IBM, MSVC, Comeau are actually going to participate in this informal
group, and even more doubtfully, reach anything close to a consensus on
any proposed extensions.
mostly, I had just figured said goup would "standardize" on many of the
extensions they have done already...
anyways, one doesn't really need "big players" for something like this...
A group composed only of hobbyists and one-man-shows like you and jacob
is probably going to be ignored by the larger C community.
possibly, who knows...
Also establishing a sort of steering committee is going to be a
difficult task. If the "major" players do decide to get involved it is
very probably quickly going to get stuck in precisely the diplomatic
and technical quagmire that the WG14 is in currently.
I never really said it would be "steering" anyways.
the point is more to enumerate possibilities and organize thoughts for said
small and specialized implementations, not to try to drive the community or
the big implementations.
after all, if the big implementations decide on something, their userbases
use what they have defined, and for them a system like this is unecessary...
The key problem would be in reaching an agreement on these extensions.
Each implementor is very likely to disagree with at least one other
implementor and is likely to go ahead on their own anyway.
When parts of the Standard released by such a major organisation like
ISO are still to be implemented, I find it difficult to believe that
the community is going to sucessfully rally around an a purely informal
group.
The OSS development model may not apply for the C vendor community.
I don't expect this to be anything like how the ISO will operate.
it will not "drive" implementations, and may well be completely ignored by
any large compiler vendors, and that is really, of no real concern. many of
these implementations already have many of these features anyways, the most
drastic would then be the hope that they add a header to list what features
are present, and even this is purely optional. that is the plan...
after all, there is no need to 'force' any of this to be implemented, it
will all be primarily informative, and optional...
more so, I would recommend specifying a good deal of existing practice
as part of this process, in part as a way of "unifying" some tendency
for divergent solutions to the same problem.
Existing practises currently vary between implementors. Formulating a
Standardised subset is going to mean that one or more group will have
to make compromises.
How has the MS's "safe" C library been with GCC? Or GCC's extensions
with MSVC?
who knows...
note above, this is not really my concern...
after all, we could standardize both MSVCs and GCCs practices, mostly
implying that it would be good if further (presumably mostly small-scale)
implementations follow along.
it is just that I feel, having a single unified and massive "standard"
for "everything under the sun" is the wrong approach here (it both
puts too much weight on the standard, and hinders the creation of
useful domain-specific and experimental implementations).
I agree. It's just that I doubt a "massive" standard for C (including
optional portions) is going to work at all. A lot of influential people
in the C community seem to be expressing a strong desire to keep C
simple and compact, while most major vendors seem to have their focus
on C++. The C subset of their C/C++ implementations it seems, is simply
being maintained. Of course this might just be my perception or
pessimism.
wrong expression I guess...
ok, I just think the monolithic-standard approach may not be the best.
it leaves too much room for fragmentation, and as things are now, about all
that is left for hobbyist and domain-specific implementations is to try to
immitate the larger implementations, and is often left with little direction
concerning more far-reaching extensions...
a slightly more minimalistic language, and a large semi-formal set of
extensions, would seem a better approach here.
Certainly the first part would work (witness the enormous prevalence of
the C95 standard), but the end result of the semi-formal set of
extensions might be no better, for the end-user, than the current state
of relying on de facto third party libraries like GLib, APR, Boehm etc.
yes, but this will go further than is possible with libraries, since this
will have some influence on syntactic matters as well...
this is mostly a goal difference as well. I don't intend to change how apps
or other traditional software are developed, more the fringe cases of custom
domain-specific compilers (some of the areas more controlled by masses of
customized scripting languages and domain-specific languages, where C holds
a little less sway, but at the same time isn't terribly applicable...).
aka: the lands of chaos where battles rage between the likes of Scheme,
Lisp, Smalltalk, Forth, ...
it was in these lands I operated before eventually writing a C compiler, to
do some things not possible with many of these other languages (but it is
not to say that C proper is in every real way agreeable...).
however, this does not mean someone from these domains thinks about
programming language usage in exactly the same way as the larger developer
community. the languages are used and exist in a very different form, and
things are small-scale, fluid, and chaotic.
one can just try to set biases where they are...
of course, all this does mean:
if you want fully portable code, you can only use the core standard.
but, at the same time, it can allow moving beyond the core standard
while still retaining a sense of "portability" (at least between
implementations implementing the specific needed featureset).
Interface portability, possibly. But different is such a program taking
advantage of multiple such features going to be (in terms of cost of
porting and developing), than the current method of using popular third
party libs like wxWidgets etc.
Certainly the success of the Boost effort in C++ land indicates that it
is possible, but I somehow think that it might be much harder to
replicate it within the C community.
as noted, the concern is more about language extensions, than libraries.
after all, a library doesn't need anything special, and works easily with
multiple compilers.
a syntax extension inherently depends on the compiler though.
.
- References:
- idea: on the issue of C and language extensions
- From: cr88192
- Re: idea: on the issue of C and language extensions
- From: santosh
- Re: idea: on the issue of C and language extensions
- From: cr88192
- Re: idea: on the issue of C and language extensions
- From: santosh
- idea: on the issue of C and language extensions
- Prev by Date: Re: idea: on the issue of C and language extensions
- Next by Date: Re: isodigit
- Previous by thread: Re: idea: on the issue of C and language extensions
- Next by thread: Re: idea: on the issue of C and language extensions
- Index(es):
Relevant Pages
|
