[Caml-list] What are "Language extensions"?

[Caml-list] What are "Language extensions"?

[Lauri Alanko]

In the O'Caml reference manual, the actual language specification is
split into two parts, "The Objective Caml language" and "Language
extensions". I'm curious as to what this division indicates about the
status of different features of the language. The manual itself
doesn't help much, since the extensions chapter only opens with:

	This chapter describes language extensions and convenience
	features that are implemented in Objective Caml, but not
	described in the Objective Caml reference manual.

In other words, "this chapter is for the stuff that isn't in the
previous chapter". Not very informative.

What, then, does it mean for something to be an extension instead of a
part of the "basic" language? Is it about backwards compatibility
(e.g. the basic language is guaranteed to work with every 3.x
release)? Or about forward compatibility (e.g. some extensions might
not be supported in a future 3.x release)? Or about stability? Will
some of the extensions eventually be incorporated into the "basic"
language?

The structure of the manual clearly implies that I as a programmer
should take into account that a feature is an "extension". I just
have no idea what I should do with that knowledge.


Lauri

Re: [Caml-list] What are "Language extensions"?

[Mike Lin]

My strong impression is that many of the "language extensions" are
each an INRIA student's thesis :)

On Fri, Mar 25, 2011 at 9:12 PM, Lauri Alanko <la@iki.fi> wrote:
> In the O'Caml reference manual, the actual language specification is
> split into two parts, "The Objective Caml language" and "Language
> extensions". I'm curious as to what this division indicates about the
> status of different features of the language. The manual itself
> doesn't help much, since the extensions chapter only opens with:
>
>        This chapter describes language extensions and convenience
>        features that are implemented in Objective Caml, but not
>        described in the Objective Caml reference manual.
>
> In other words, "this chapter is for the stuff that isn't in the
> previous chapter". Not very informative.
>
> What, then, does it mean for something to be an extension instead of a
> part of the "basic" language? Is it about backwards compatibility
> (e.g. the basic language is guaranteed to work with every 3.x
> release)? Or about forward compatibility (e.g. some extensions might
> not be supported in a future 3.x release)? Or about stability? Will
> some of the extensions eventually be incorporated into the "basic"
> language?
>
> The structure of the manual clearly implies that I as a programmer
> should take into account that a feature is an "extension". I just
> have no idea what I should do with that knowledge.
>
>
> Lauri
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] What are "Language extensions"?

[Steven Shaw]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

Perhaps it doesn't mean much when there's only one implementation of
Objective Caml. However, if a second implementation came along then I guess
it may only implement the core language without extensions (and still be
considered a valid "Objective Caml").

[-- Attachment #2: Type: text/html, Size: 275 bytes --]

Re: [Caml-list] What are "Language extensions"?

[Martin Jambon]

On 03/25/11 21:30, Steven Shaw wrote:
> Perhaps it doesn't mean much when there's only one implementation of
> Objective Caml. However, if a second implementation came along then I
> guess it may only implement the core language without extensions (and
> still be considered a valid "Objective Caml").

The "language extensions" section of the manual describes features that
are perfectly usable but may be gone in the next release of the official
Objective Caml distribution (compilers etc.).

For example, there used to be a special syntax for pattern matching
against streams (Stream module). It was removed but can still be used by
preprocessing .ml files with camlp4 or camlp5.

Currently the least esoteric features that are commonly used among these
"language extensions" are in my opinion:

- assert
- integer literals for int32 and int64
- lazy expressions (but not lazy patterns)
- char range patterns
- local open (new in 3.12)
- record notations (new in 3.12)

It is easy to see workarounds if these features were to disappear from
the official implementation because they are mostly syntax. Not so sure
about the other extensions.


Martin

Re: [Caml-list] What are "Language extensions"?

[Xavier Leroy]

On 03/26/2011 02:12 AM, Lauri Alanko wrote:

> In the O'Caml reference manual, the actual language specification is
> split into two parts, "The Objective Caml language" and "Language
> extensions". I'm curious as to what this division indicates about the
> status of different features of the language.

Don't put too much meaning in this distinction.  Basically, the
"language extensions" chapter describes most of the features that were
added since OCaml 1.00 back in 1995 (!), or that were present in 1.00
but considered a bit experimental then.

This said, only one of those extensions went away in the past (stream
pattern matching, as Martin Jambon recalled), and I don't see any of
the remaining extensions going away in the short to medium term.

However, some of those extensions are a little less "future-proof"
than the core of the language and are more likely to change in
slightly incompatible ways.  A prime example is recursive modules,
whose type-checking has changed a couple of times in the past (because
it walks a fine line between unsoundness and undecidability), breaking
some Caml code that uses recursive modules.

Perhaps, one day, the most stable "extensions" should be moved from
the "language extensions" chapter to the "Objective Caml language"
chapter, but this is just a matter of presentation.

Hope this clarifies the issue.

- Xavier Leroy