I am doing a presentation on OCaml, I want to put if there is a standard comittee or not. I searched the internet far and wide and I couldn't get an answer for that, so I am asking for help here.
OCaml does not follow any national or international standard. The language is whatever the Gallium (formerly Cristal) group at INRIA want it to be.
The OCaml language does not have any standard, as there is only one implementation of it, namely OCaml itself. Some other experimental versions of OCaml exist (OCaml Java, one version that used to run on .NET) but as far as I know, none of them is considered serious enough (as of now) to be an alternative implementation. The Standard ML language has been standardized (as the name implies!), and implementations of it exist (SML/NJ, AliceML, MoscowML), but OCaml is not SML.
However, several industrial users of OCaml need agreement on the future directions of the language. A structure exists for that purpose, which is called the Caml Consortium http://caml.inria.fr/consortium/; future improvements on the language itself and its implementation may be discussed there. Technical discussions take place on a private list called caml-devel.
If you're talking about an official standard like those produced by ISO, there's no indication of one. Computer languages are handled within ISO (and, to be honest, that's the most important standards body; all national bodies like ANSI and AS) tend to just feed into ISO) with technical committee 1, working group 22 (JTC1/SWG22).
A list of the standards issued for JTC1/SWG22 can be found here and there's not a peep about OCaml.
Although there are some interesting snippets in there, such as Fortran being worked on as late as 2010, and Ruby in there but no Python.
That's not to say there may not be some standardisation effort outside of ISO or the national bodies, but it may be seen as less serious.
Related
When the C++ committee publish a new feature that will be part of the standard library in the next standard of the language, do they also release some source code or some kind of guidance on how to implement that feature?
Let's take unique_ptr as an example. The language committee just defines an interface for that class template and let the compiler vendor implement it as it wants? How exactly does this process of implementation of the standard library features occur?
Can anyone implement parts of the standard library for a platform that doesn't have support for them yet? Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that? Where should I look for information? If I decide to open source my project, can I do that? Will I need to follow exactly what the standard says, or I can write a non-compliant version?
Usually,
every new library feature goes through a proposal.
If the proposal makes it to the C++ committee's Library Evolution Working Group, it goes through a series of iterations (a "tough ground" as I am aware).
It undergoes a series of refinement process as described here
Should it require a (TS) Technical Specification (since C++11), it goes there to be baked. Take for example, the #include <filesystem> was in a Filesystem TS prior to C++17.
One thing I believe the committee likes, is an implementation experience.
More information can be found on the ISOCpp site
Well, as to the implementation:
There are quite a number of "library features" that cannot be implemented purely as a library. they require compiler support. And in these case, compilers provides "intrinsic" that you could hook on to. Take for example, clang provides intrinsics for certain type_traits
Most library features have some implementation experience, mostly from the Boost libraries.
You could actually look into the source code for the default standard library that ships with your compiler:
libc++ for Clang
libstdc++ for GCC
Sadly most of the implementations use a whole bunch of underscores. Mostly because they are reserved for use by the "Standard Library".
Can anyone implement parts of the standard library for a platform that doesn't have support for it yet?
Yes, you can, so far your compiler supports that platform, and the platform or Operating System provides usable API. For example. std::cout, elements of std::ifstream, and so much more requires platform specific support.
Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that?
You can look into the code of others and start from there. We learn from giants. Some Open Source Examples:
ETL
StandardCPlusPlus
uClib++
How could I do that? Where should I look for information?
You could check the paper that introduced the feature into the C++ library. For example, std::optional has a stand-alone implementation here which was used as a reference implementation during the proposal stages.
You could check the standard library, and do a laborious study. :-)
Search the internet. :-)
Or write it from scratch as specified by the standard
Will I need to follow exactly what the standard say or I can write a non-compliant version?
There's is no compulsion to follow what the C++ standard library specifies. That would be your "own" library.
Formally, no. As with all standards out there, C++ Standard sets the rules, and does not gives implementation. However, from the practical standpoint, it is nearly impossible to introduce a new feature into Standard Library without proposed implementation, so you often can find those attached to proposals.
As for your questions on "can you write non-compliant version", you can do whatever you want. Adoption might depend on your compliance, or might not - a super-widely adopted MSVC is known to violate C++ standard.
Typically, a new feature is not standardized, unless the committee has some solid evidence that it can be implemented, and will be useful. This very often consists of a prototype implementation in boost, a GNU library, or one of the commercial compiler vendors.
The standard itself does not contain any implementation guidance - it is purely a specification. The compiler vendors (or their subcontractors) choose how to implement that specification.
In the specific case of unique_ptr, it was adopted into the standard from boost::unique_ptr - and you can still use the latter. If you have a compiler that will compile for your microcontroller, it is almost certain that it will be able to build enough of boost to make unique_ptr work.
There is nothing stopping you from writing a non-conforming implementation (apart from the trivial point that if you sold it as being standards-conforming, and it wasn't you might get your local equivalent of Trading Standards come knocking.)
The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.
Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.
You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).
I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.
If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.
Separate from frontend implementers' experiences, are there formal standards that syntactic extensions to the C++ grammar are required to meet? That is, are proposed extensions subjected to any form of mechanical analysis before being accepted?
I ask because I have read that the two most widely used C++ compilers, g++ and clang, both use hand written, recursive descent parsers. Does that mean that as the grammar evolves, it needs to remain LL(1) (or maybe LL(n)) with the proviso that certain implementation tricks are allowed / assumed / expected?
The C++ standard defines a language; it does not restrict what that language might become in the future. (The C standard does contain a section called "future directions", but that is more a warning to users of features which have been deprecated, and which identifiers might be reserved in the future, rather than being a limitation on future standards.)
That said, the standards process is basically conservative, since the committee includes representatives of the major compilers as well as major user groups, none of whom are likely to accept changes which make the language even harder to parse.
As far as I know, there is no mechanical validation of proposed changes. But there is a lot of manual analysis by people with a lot of experience and expertise. Moreover, proposed changes are generally accompanied by proof-of-concept implementations to demonstrate their viability and utility.
When the C++ committee publish a new feature that will be part of the standard library in the next standard of the language, do they also release some source code or some kind of guidance on how to implement that feature?
Let's take unique_ptr as an example. The language committee just defines an interface for that class template and let the compiler vendor implement it as it wants? How exactly does this process of implementation of the standard library features occur?
Can anyone implement parts of the standard library for a platform that doesn't have support for them yet? Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that? Where should I look for information? If I decide to open source my project, can I do that? Will I need to follow exactly what the standard says, or I can write a non-compliant version?
Usually,
every new library feature goes through a proposal.
If the proposal makes it to the C++ committee's Library Evolution Working Group, it goes through a series of iterations (a "tough ground" as I am aware).
It undergoes a series of refinement process as described here
Should it require a (TS) Technical Specification (since C++11), it goes there to be baked. Take for example, the #include <filesystem> was in a Filesystem TS prior to C++17.
One thing I believe the committee likes, is an implementation experience.
More information can be found on the ISOCpp site
Well, as to the implementation:
There are quite a number of "library features" that cannot be implemented purely as a library. they require compiler support. And in these case, compilers provides "intrinsic" that you could hook on to. Take for example, clang provides intrinsics for certain type_traits
Most library features have some implementation experience, mostly from the Boost libraries.
You could actually look into the source code for the default standard library that ships with your compiler:
libc++ for Clang
libstdc++ for GCC
Sadly most of the implementations use a whole bunch of underscores. Mostly because they are reserved for use by the "Standard Library".
Can anyone implement parts of the standard library for a platform that doesn't have support for it yet?
Yes, you can, so far your compiler supports that platform, and the platform or Operating System provides usable API. For example. std::cout, elements of std::ifstream, and so much more requires platform specific support.
Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that?
You can look into the code of others and start from there. We learn from giants. Some Open Source Examples:
ETL
StandardCPlusPlus
uClib++
How could I do that? Where should I look for information?
You could check the paper that introduced the feature into the C++ library. For example, std::optional has a stand-alone implementation here which was used as a reference implementation during the proposal stages.
You could check the standard library, and do a laborious study. :-)
Search the internet. :-)
Or write it from scratch as specified by the standard
Will I need to follow exactly what the standard say or I can write a non-compliant version?
There's is no compulsion to follow what the C++ standard library specifies. That would be your "own" library.
Formally, no. As with all standards out there, C++ Standard sets the rules, and does not gives implementation. However, from the practical standpoint, it is nearly impossible to introduce a new feature into Standard Library without proposed implementation, so you often can find those attached to proposals.
As for your questions on "can you write non-compliant version", you can do whatever you want. Adoption might depend on your compliance, or might not - a super-widely adopted MSVC is known to violate C++ standard.
Typically, a new feature is not standardized, unless the committee has some solid evidence that it can be implemented, and will be useful. This very often consists of a prototype implementation in boost, a GNU library, or one of the commercial compiler vendors.
The standard itself does not contain any implementation guidance - it is purely a specification. The compiler vendors (or their subcontractors) choose how to implement that specification.
In the specific case of unique_ptr, it was adopted into the standard from boost::unique_ptr - and you can still use the latter. If you have a compiler that will compile for your microcontroller, it is almost certain that it will be able to build enough of boost to make unique_ptr work.
There is nothing stopping you from writing a non-conforming implementation (apart from the trivial point that if you sold it as being standards-conforming, and it wasn't you might get your local equivalent of Trading Standards come knocking.)
The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.
Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.
You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).
I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.
If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.
After a quick search in draft N4296, I could not find any example of a name in the C++ Standard Library for which two possible spellings exists (BrE vs. AmE).
While this may even be intentional, I can imagine that at some point, if a graphics library will be standardized (and there seems to be some effort going in this direction), the choice between "colour" and "color" will have to be made.
Are there normative regulations or perhaps even informal criteria that are being used to decide which spelling to pick for names in the C++ Standard Library?
I'd expect that, if there were an official guideline, we should be able to find it in the Standard Library Guidelines on the committee's web site. Since there are a number of items regarding naming conventions and none of them mentions American versus British English, I can only conclude that such a decision has not been made yet.
As others have commented, there is prose and at least one function name in the standard that uses the American spelling so my bet would be that it would be preferred in case of doubt. From what I can tell, this is also what most other libraries do. The Boost Library Requirements and Guidelines, by the way, don't have anything to say about this issue either.
After having an answer here wrong, because I wasn't up to date on the C standard, I started to look for some place that gives a description of whats in the C and C++ standards.
I do not want the complete standards, of which I found links in Where do I find the current C or C++ standard documents?, or intimate technical discussions. Instead I would like something that briefly describes the standard, with references to the actual standard if I want to check it more thoroughly, and maybe saying which standard the feature was introduced in.
Is there such a resource available?
EDIT: A little background to the question: I have been programming C for over 20 years now, and when I learnt it not much was standardized. And what was in the official standard was not widely implemented. Through the years I have become good enough C programmer that my friends and colleges come to me for help when they have problems.
However, when I learned C I was told that things like memory layout for multi-dimensional arrays was implementation specific, and when I saw a question about that subject I said that it wasn't standardized only to be told I was wrong. But even knowing this, I have a hard time finding any place saying that it's in the standard, and it's even harder to find in which standard it was first introduced.
If there was some place saying "Memory layout of multi-dimensional arrays was standardized in C9x, in section Y of the standard document" It would have been easy to find and give this to the person asking the question. I am not intrested in what the actual layout is, just that it has been standardized, and where to look if I really want a definitive answer about it.
This of course goes for other things. Like knowing that header file "<yyy.h>" is mandated by standard "C90", and where in the standard I should look for the rationale and contents of it. It is very difficult to find these things when they are spread out, having it collected in one place would make it much easier to find.
Anything that's not the standard will either be not definitive, or be simplified in such a way as to be far less than useful. And anything definitive or really useful will basically be the standard.
I know of no resource that covers every section of the C standard (or even a sizable number of them) in a simplified way and I would doubt its usefulness. You generally have a specific issue you need solved and, in that case, you would search for that specific issue - the vast majority of people don't need the standard, especially when they have a resource like SO at their fingertips.
If you're a language implementer or enjoy examining the dark corners of the language in excruciating detail, then yes, get the standard, it's invaluable. If you're just using the language day-to-day (even as an expert), you can get by without it, with just a bit of googling (a).
(a) Make sure one of the search terms is site:stackoverflow.com :-)
I found http://en.cppreference.com/w/cpp is now becoming pretty good! (always much more complete)
There is so much material in the standard there is just no way to briefly describe it. I don't think your question is really answerable as written. If you want a reference for the standard library though, Josuttis' book http://www.amazon.com/Standard-Library-Tutorial-Reference/dp/0201379260/ref=sr_1_1?ie=UTF8&qid=1320994652&sr=8-1 is always a fantastic reference.
I'm guessing you already are familiar with the older standards and want to brush up on the newer less-used stuff.
Here is a good read for C99. It covers changes and has notes to the actual standard. Also some stuff on C++ in there.
Wikipedia is great for C++11. Great for basics, but doesn't go into full detail.
If you fully understand the language then you can generally infer the standard. For strange corner-cases you're going to have to refer to the standard.
I think some of the other people answering this question are right: one seldom needs the ultimately authoritative ISO standard document, unless you are writing a compiler or something like that. For me, I find that the main books on the two languages by the language creators are sufficient for almost all my needs. They are:
The C Programming Language by Brian Kernighan and Dennis Ritchie
The C++ Programming Language by Bjarne Stroustrup
Look for the latest editions of each, although a quick search on Amazon shows neither updated for the latest incarnations of the languages (C99 and C++11). You might need to supplement with online sources, or perhaps look at A C Primer Plus and Professional C++.