[Caml-list] Filename.temp_dir_name

[Caml-list] Filename.temp_dir_name

[Sébastien Hinderer]

Dear all,

In Ocaml 4.02.0, filename.mli says that temp_dir_name is deprecated
since 3.09.1 and that get_temp_dir_name should be used instead, but this
function does not seem to be deined in e.g.the sources of
ocaml-3.10.0+beta.

Any hint?

Thanks,
Sébastien.

RE: [Caml-list] Filename.temp_dir_name

[David Allsopp]

Sébastien Hinderer wrote:
> Dear all,
> 
> In Ocaml 4.02.0, filename.mli says that temp_dir_name is deprecated since
> 3.09.1 and that get_temp_dir_name should be used instead, but this
> function does not seem to be deined in e.g.the sources of ocaml-
> 3.10.0+beta.

You've not quite read the sources correctly - the function temp_dir_name was *introduced* in 3.09.1 (that's the @since) and deprecated in 4.00.0 when get_temp_dir_name was introduced (deprecated functions became a bit more visible in 4.02 because of the new [@@deprecated] attribute - although warning 3 existed, I think that was only language features beforehand).

If you need to write code for 4.x which is also backwards compatible, you'll need to introduce a compatibility layer - ExtLib/Batteries contain examples of how to do this (especially the Unix modules in Batteries, which have to allow for different constructors in different version of OCaml sum types).

Essentially, you'll create something like CompatibilityLayer.ml which your build system will generate as:

module Filename = Filename

for OCaml >= 4.00.0, and:

module Filename = struct
  include Filename

  let get_temp_dir_name = (* ... code for get_temp_dir_name *)

  (* ... any other 4.00.0 functions back-ported *)
end

for OCaml < 4.00.0. Then in each of your actual source files you'll simply add

open CompatibilityLayer

at the top. See also the bytes package in findlib >= 1.5 (doing the same thing for the OCaml 4.02 Bytes module).

HTH,


David 

Re: [Caml-list] Filename.temp_dir_name

[Sébastien Hinderer]

Dear David,

Many thanks for your response.



David Allsopp (2014/10/23 12:50 +0000):
> If you need to write code for 4.x which is also backwards compatible,
> you'll need to introduce a compatibility layer - ExtLib/Batteries
> contain examples of how to do this (especially the Unix modules in
> Batteries, which have to allow for different constructors in different
> version of OCaml sum types).
>

 
> Essentially, you'll create something like CompatibilityLayer.ml which your build system will generate as:
> 
> module Filename = Filename
> 
> for OCaml >= 4.00.0, and:
> 
> module Filename = struct
>   include Filename
> 
>   let get_temp_dir_name = (* ... code for get_temp_dir_name *)
> 
>   (* ... any other 4.00.0 functions back-ported *)
> end
> 
> for OCaml < 4.00.0. Then in each of your actual source files you'll simply add
> 
> open CompatibilityLayer
> 
> at the top. See also the bytes package in findlib >= 1.5 (doing the same thing for the OCaml 4.02 Bytes module).

Thanks for the pointers. I had a look to the different projects you
mentionned but so far I couldn't find where in the sources the
compatibility layer was defined / generated.

I mean, I understand the principle of what you explain but I'd be happy
to see a concrete example illustrating how the buildsystem generates the
appropriate files depending on the compiler version.

Would it be possible for you to show me more precisely where this is
done, plese?

Thanks,
Sébastien.

> 
> HTH,
> 
> 
> David 
> 

RE: [Caml-list] Filename.temp_dir_name

[David Allsopp]

Sébastien Hinderer wrote:
> David Allsopp (2014/10/23 12:50 +0000):

<snip>

> Thanks for the pointers. I had a look to the different projects you
> mentionned but so far I couldn't find where in the sources the
> compatibility layer was defined / generated.
> 
> I mean, I understand the principle of what you explain but I'd be happy to
> see a concrete example illustrating how the buildsystem generates the
> appropriate files depending on the compiler version.
> 
> Would it be possible for you to show me more precisely where this is done,
> plese?

In batteries[1], see src/batUnix.mliv type [open_flag] which has lines prefixed ##. There is the program build/prefilter.ml and then a suffix rule (search for .mliv.mli) in Makefile which generates batUnix.mli.

In findlib[2], see configure (search for "# bytes?"). It detects whether bytes.cmi exists in the compiler's lib directory (`ocamlc -where`/bytes.cmi). Based on that it therefore determines whether it will generate a dummy META file from the files site-lib-src/bytes or whether it will compile its compatibility library in src/bytes.


David

[1] http://forge.ocamlcore.org/frs/?group_id=17
[2] http://download.camlcity.org/download/findlib-1.5.5.tar.gz

Re: [Caml-list] Filename.temp_dir_name

[Sébastien Hinderer]

Dear David,

Many thanks for your prompt and helpful response.

> In batteries[1], see src/batUnix.mliv type [open_flag] which has lines
> prefixed ##. There is the program build/prefilter.ml and then a suffix
> rule (search for .mliv.mli) in Makefile which generates batUnix.mli.

Ah yes, seen, thanks. So this is a line-based approach actually.
I'm wondering whether code has already been written implement a
block-based approach, i.e. an aproach where one can make several lines
compiler-version dependent at once?

> In findlib[2], see configure (search for "# bytes?"). It detects
> whether bytes.cmi exists in the compiler's lib directory (`ocamlc
> -where`/bytes.cmi). Based on that it therefore determines whether it
> will generate a dummy META file from the files site-lib-src/bytes or
> whether it will compile its compatibility library in src/bytes.

Seen also, thanks.

I guess it would also be okay,in a tool, to use that same test and to
just rpovide the bytes module if it does not exist, rather than
installing a package...

Thanks!
Sébastien.

Re: [Caml-list] Filename.temp_dir_name

[Gabriel Scherer]

There is the cppo tool of Martin Jambon which is a "serious"
preprocessor for OCaml -- by opposition to prefilter.ml which started
as a sed script and is growing in uncontrolled (but rather reasonable)
ways.
  http://mjambon.com/cppo.html

On Wed, Oct 29, 2014 at 4:29 PM, Sébastien Hinderer
<Sebastien.Hinderer@ens-lyon.org> wrote:
> Dear David,
>
> Many thanks for your prompt and helpful response.
>
>> In batteries[1], see src/batUnix.mliv type [open_flag] which has lines
>> prefixed ##. There is the program build/prefilter.ml and then a suffix
>> rule (search for .mliv.mli) in Makefile which generates batUnix.mli.
>
> Ah yes, seen, thanks. So this is a line-based approach actually.
> I'm wondering whether code has already been written implement a
> block-based approach, i.e. an aproach where one can make several lines
> compiler-version dependent at once?
>
>> In findlib[2], see configure (search for "# bytes?"). It detects
>> whether bytes.cmi exists in the compiler's lib directory (`ocamlc
>> -where`/bytes.cmi). Based on that it therefore determines whether it
>> will generate a dummy META file from the files site-lib-src/bytes or
>> whether it will compile its compatibility library in src/bytes.
>
> Seen also, thanks.
>
> I guess it would also be okay,in a tool, to use that same test and to
> just rpovide the bytes module if it does not exist, rather than
> installing a package...
>
> Thanks!
> Sébastien.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Filename.temp_dir_name

[Sylvain Pogodalla]

Dear all,

Sébastien Hinderer writes:
 > Ah yes, seen, thanks. So this is a line-based approach actually.
 > I'm wondering whether code has already been written implement a
 > block-based approach, i.e. an aproach where one can make several lines
 > compiler-version dependent at once?

The IFDEF instruction of campl4 (and the corresponding -D flag) may
also be useful for that purpose.

Sylvain

Re: [Caml-list] Filename.temp_dir_name

[Daniel Bünzli]

Le jeudi, 30 octobre 2014 à 10:22, Sylvain Pogodalla a écrit :
> The IFDEF instruction of campl4 (and the corresponding -D flag) may
> also be useful for that purpose.

Rather than using ugly pre-processing tools and make unreadable #idef'd sources you can simply gather version specific functionality in different modules with the same name and choose the right one at configure time.  

Best,

Daniel

Re: [Caml-list] Filename.temp_dir_name

[Sébastien Hinderer]

Excellent point, many thanks Sylvain!
Sébstien.

RE: [Caml-list] Filename.temp_dir_name

[David Allsopp]

Daniel Bünzli wrote:
> Le jeudi, 30 octobre 2014 à 10:22, Sylvain Pogodalla a écrit :
> > The IFDEF instruction of campl4 (and the corresponding -D flag) may
> > also be useful for that purpose.
> 
> Rather than using ugly pre-processing tools and make unreadable #idef'd
> sources you can simply gather version specific functionality in different
> modules with the same name and choose the right one at configure time.

That would involve vast amounts of code duplication (certainly for the unix case in batteries) and would make the sources considerably less readable as you'd lose the obvious source-based knowledge of where the differences are!


David

Re: [Caml-list] Filename.temp_dir_name

[Daniel Bünzli]

Le jeudi, 30 octobre 2014 à 10:49, David Allsopp a écrit :
> That would involve vast amounts of code duplication (certainly for the unix case in batteries)

Depends on the use case and the way you organize things (can't speak for batteries though).  
  
> and would make the sources considerably less readable as you'd lose the obvious source-based knowledge of where the differences are!

Disagree, that's because you don't believe in abstraction. You are not interested in knowing the difference between one version or the other. You are interested in having the same semantics in both versions and that semantics should be defined at the module API level. By #ifdefing you didn't take the time to actually think about what you really want.

Best,

Daniel