ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] properties of symbols

[Henri DF <hen...@ep...>]

thanks for the pointer. i (naively) thought that anything which "takes 
away 
polymorphism" could only improve efficiency, and that this would extend to 
functors. 

[OT] i wonder when there is ever a case for functors then..

henri



> > > It looks interesting, although I didn't need theses before.
> > > Some comments :
> > > - polymorphic is better than functors (more usable and better perfs as
> > > Martin said)
> >
> > polymorphic code better performing than functors? sounds odd...
> >
> > henri
> 
> I don't think there is optimisations made from the type-specialization of
> functors. More than that, each functor application is creating an additional
> indirection.
> You can have a look at this thread for more informations :
> 
> http://caml.inria.fr/archives/200307/msg00244.html
> 
> Regards,
> Nicolas Cannasse
> 
> 

Re: [Ocaml-lib-devel] properties of symbols

[Nicolas C. <war...@fr...>]

> > It looks interesting, although I didn't need theses before.
> > Some comments :
> > - polymorphic is better than functors (more usable and better perfs as
> > Martin said)
>
> polymorphic code better performing than functors? sounds odd...
>
> henri

I don't think there is optimisations made from the type-specialization of
functors. More than that, each functor application is creating an additional
indirection.
You can have a look at this thread for more informations :

http://caml.inria.fr/archives/200307/msg00244.html

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] properties of symbols

[Henri DF <hen...@ep...>]

> It looks interesting, although I didn't need theses before.
> Some comments :
> - polymorphic is better than functors (more usable and better perfs as
> Martin said)
 
polymorphic code better performing than functors? sounds odd...

henri

> - there should be a way to retreive all the objects from a table and all the
> properties from an object
> - properties should be "closures" over objects so we doesn't need 2
> arguments on put/get
> - better would be to have a recursive data structure so properties can
> themself be objects :-)
> 
> Regards,
> Nicolas Cannasse
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
> 

[Ocaml-lib-devel] IO oo wrappers

[Nicolas C. <war...@fr...>]

Here's some OO wrappers proposal for IO module.

As Yamagata Yoriyuki suggested, theses can be useful in order to provide
ExtLib IO compatibility without the need to add a dependency to IO module
(that's one - the only ? - nice thing with objects, since their type are not
module-bounds). If success, I'm planing also to add this for Enums.

Regards,
Nicolas Cannasse

(** MLI **)

class ['a,'b] o_input : ('a,'b) input ->
  object

 method read : 'a
 method nread : int -> 'b
 method pos : int
 method available : int option
 method close : unit

  end

class ['a,'b,'c] o_output : ('a,'b,'c) output ->
  object

 method write : 'a -> unit
 method nwrite : 'b -> unit
 method pos : int
 method flush : unit
 method close : 'c

  end

val from_in : ('a,'b) #o_input -> ('a,'b) input
val from_out : ('a,'b,'c) #o_output -> ('a,'b,'c) output

(** ML **)

class ['a,'b] o_input (ch:('a,'b) input) =
  object

 method read = read ch
 method nread n = nread ch n
 method pos = pos_in ch
 method available = available ch
 method close = close_in ch

  end

class ['a,'b,'c] o_output (ch:('a,'b,'c) output) =
  object

 method write x = write ch x
 method nwrite x = nwrite ch x
 method pos = pos_out ch
 method flush = flush ch
 method close = close_out ch

  end

let from_in ch =
 create_in
  ~read:(fun () -> ch#read)
  ~nread:ch#nread
  ~pos:(fun () -> ch#pos)
  ~available:(fun () -> ch#available)
  ~close:(fun () -> ch#close)

let from_out ch =
 create_out
  ~write:ch#write
  ~nwrite:ch#nwrite
  ~pos:(fun () -> ch#pos)
  ~flush:(fun () -> ch#flush)
  ~close:(fun () -> ch#close)

Re: [Ocaml-lib-devel] properties of symbols

[Nicolas C. <war...@fr...>]

> Hi,
>
> under Lisp there are to very useful functions `put' and
> `get'. Emacs, C-h f put RET ->
>
> put is a built-in function.
> (put SYMBOL PROPNAME VALUE)
>
> Store SYMBOL's PROPNAME property with value VALUE.
> It can be retrieved with `(get SYMBOL PROPNAME)'.
>
> Eg:
>
> (put 'car 'ccm 1500)
> (put 'car 'color 'silver)
> (put 'car 'owner "Joe")
>
> (get 'car 'owner)
> => "Joe"
>
> This functionality is something different than hashtabels.
> A Hashtable has a type ('a,'b) Hashtbl.t and 'b is fix.
>
> With static typed OCaml it's tricky to implement put and get, but it's
> possible. I needed something like this and Alain Frisch referred me to
this
> old mail
[...]

It looks interesting, although I didn't need theses before.
Some comments :
- polymorphic is better than functors (more usable and better perfs as
Martin said)
- there should be a way to retreive all the objects from a table and all the
properties from an object
- properties should be "closures" over objects so we doesn't need 2
arguments on put/get
- better would be to have a recursive data structure so properties can
themself be objects :-)

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Towards release 1.1

[Nicolas C. <war...@fr...>]

> Hi list,
>
> Here's a todo list proposal before releasing 1.1 :
> - writing documentation of newest modules : IO , Base64 and PMap
> - adding Ocaml DBI (only the common abstract interfaces, no driver) : I'm
> waiting for OCaml DBI 's author Richard Johns answer.
> Everybody is of course welcome in contributing documentation, comments, or
> code before next release.

Today :
- added Base64 IO support (for mapping an IO with a Base64 encoding) and
documentation
- committed dbi.ml and dbi.ml , common DB interfaces for OCamlDBI.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] properties of symbols

[Martin J. <mar...@em...>]

On Sun, 25 Apr 2004, Martin Jambon wrote:

> On Sat, 24 Apr 2004, Christoph Bauer wrote:
>
> > Hi,
> >
> > > That's really cool!
> > >
> > > Since I don't like to use functors, I translated it into a functor-free
> > > version.
> > > The difference is that you need to create the symbol_table using
> > > Symbols.make_table.
> >
> > And who will call Symbols.make_table?  And then you cannot mix string-Symbols
> > and Variant-symbols in the same program. Please explain the advantages of your
> > modifications.
>
> Sorry, there are a few things that I misunderstood in your implementation.
> Correct me if I am wrong:
> 1) only one global table is created for storing symbols of any type

Of course a fresh table is created with every functor application.
Sorry.

Re: [Ocaml-lib-devel] properties of symbols

[Martin J. <mar...@em...>]

On Sat, 24 Apr 2004, Christoph Bauer wrote:

> Hi,
>
> > That's really cool!
> >
> > Since I don't like to use functors, I translated it into a functor-free
> > version.
> > The difference is that you need to create the symbol_table using
> > Symbols.make_table.
>
> And who will call Symbols.make_table?  And then you cannot mix string-Symbols
> and Variant-symbols in the same program. Please explain the advantages of your
> modifications.

Sorry, there are a few things that I misunderstood in your implementation.
Correct me if I am wrong:
1) only one global table is created for storing symbols of any type
2) but you need to apply the functor for each type of symbol

What I posted is not supposed to better than your work, and I did not
spend much time to do it, I was just trying to see how it was working.
What I thought when I posted my message was:
1) it is generally a good practice to be able to isolate data, i.e. avoid
global variables
2) functor application is not beginner-friendly, where "beginner" means
actually "a lot of people"
3) each table will store only one type of symbol, which looks satisfying
to me, but maybe this where I missed something.

That's all.

Good night (it's late here),

Martin

Re: [Ocaml-lib-devel] properties of symbols

[Christoph B. <c_...@in...>]

Hi,

> That's really cool!
>
> Since I don't like to use functors, I translated it into a functor-free
> version.
> The difference is that you need to create the symbol_table using
> Symbols.make_table.

Sorry about my complains, your modifications are fine, of course.

Regards,
Christoph Bauer

-- 
beginfig(1)u=3cm;draw fullcircle scaled 2u;x0=x1=y1=x2=y3=0;-y0=y2=x3=1u;
filldraw z0..{left}z1{left}..z2{curl 1}..z3..z0..cycle;def t(expr p)=fullcircle
scaled .25u shifted(0,p*u);enddef;unfill t(.5);fill t(-.5);endfig;bye

Re: [Ocaml-lib-devel] properties of symbols

[Christoph B. <c_...@in...>]

Hi,

> That's really cool!
>
> Since I don't like to use functors, I translated it into a functor-free
> version.
> The difference is that you need to create the symbol_table using
> Symbols.make_table.

And who will call Symbols.make_table?  And then you cannot mix string-Symbols
and Variant-symbols in the same program. Please explain the advantages of your
modifications.

Regards,
Christoph Bauer


-- 
beginfig(1)u=3cm;draw fullcircle scaled 2u;x0=x1=y1=x2=y3=0;-y0=y2=x3=1u;
filldraw z0..{left}z1{left}..z2{curl 1}..z3..z0..cycle;def t(expr p)=fullcircle
scaled .25u shifted(0,p*u);enddef;unfill t(.5);fill t(-.5);endfig;bye

Re: [Ocaml-lib-devel] properties of symbols

[Martin J. <mar...@em...>]

On Sat, 24 Apr 2004, Henri DF wrote:

>
> > That's really cool!
> >
> > Since I don't like to use functors, I translated it into a functor-free
> > version.
>
> is there any loss of efficiency in doing so?

Probably.
The best would be to have both.
I would use the functorized version for writing libraries or very
optimized code, and the polymorphic version the rest of the time
(let's say 90%).

How is it possible to do this without coding twice?


Martin

Re: [Ocaml-lib-devel] properties of symbols

[Henri DF <hen...@ep...>]

> That's really cool!
> 
> Since I don't like to use functors, I translated it into a functor-free
> version.

is there any loss of efficiency in doing so?

henri

> The difference is that you need to create the symbol_table using
> Symbols.make_table.
> 
> What does the ExtLib team think?
> 
> 
> Martin
> 

Re: [Ocaml-lib-devel] properties of symbols

[Remi V. <rem...@la...>]

Martin Jambon <mar...@em...> writes:

> That's really cool!
>
> Since I don't like to use functors, I translated it into a functor-free
> version.
> The difference is that you need to create the symbol_table using
> Symbols.make_table.
>
> What does the ExtLib team think?

It is not thread safe. This should be noted somewhere. Otherwise, it
seem interesting.

[...]


-- 
Rémi Vanicat

Re: [Ocaml-lib-devel] properties of symbols

[Martin J. <mar...@em...>]

That's really cool!

Since I don't like to use functors, I translated it into a functor-free
version.
The difference is that you need to create the symbol_table using
Symbols.make_table.

What does the ExtLib team think?


Martin

[Ocaml-lib-devel] properties of symbols

[Christoph B. <c_...@in...>]

Hi,

under Lisp there are to very useful functions `put' and
`get'. Emacs, C-h f put RET ->

put is a built-in function.
(put SYMBOL PROPNAME VALUE)

Store SYMBOL's PROPNAME property with value VALUE.
It can be retrieved with `(get SYMBOL PROPNAME)'.

Eg:

(put 'car 'ccm 1500)
(put 'car 'color 'silver)
(put 'car 'owner "Joe")

(get 'car 'owner)
=> "Joe"

This functionality is something different than hashtabels.
A Hashtable has a type ('a,'b) Hashtbl.t and 'b is fix.

With static typed OCaml it's tricky to implement put and get, but it's
possible. I needed something like this and Alain Frisch referred me to this
old mail 

  http://caml.inria.fr/archives/200105/msg00175.html

This message describes a cute idea how to implement properties in OCaml.

The shown  implementation has two bugs and is slow for symbols
with a lot of properties. I fixed theses issues and here is my
code. Differences are

  * there is no `prop := None' bug (maybe others)
  * it uses a hashtable to find the unit->unit functions (should be much faster)
  * Symbols can be created from strings, variants, ints, ...
  * properties can have trigger-functions, one for get and one for put. These
    function will be called on each reading or modifying of the property. 
    This is maybe more than someone wants, but it's cheap to implement.

I think ExtLib is the right place to provide such a module.

Regards,
Christoph Bauer

(* symbols.mli *)

(** Symbols with properties of various types. *)

module type KEY_TYPE = sig type t end
(** 

  KEYTYPE abstracts from the concret type of a symbol.
  
*)



module Make :
  functor (Key_type : KEY_TYPE) ->
    sig
      type 'a property 
      type symbol 
      val make : Key_type.t -> symbol
	(** [make key] creates a symbol. *)
      val key_of_symbol : symbol -> Key_type.t
	(** [key_of_symbol symbol] returns the key of a symbol. *)

      val make_property :
        ?put_trigger:(symbol -> 'a -> unit) ->
        ?get_trigger:(symbol -> 'a -> unit) -> unit -> 'a property
	(** [make_property ?put_tigger ?get_trigger ()] creates a new property.
	     [put symbol this_property] calls the [put_trigger] (if specified) 
	  and [get symbol this_property] calls the [get_trigger]. *)

      val put : symbol -> 'a property -> 'a -> unit
	(** [put symbol prop value] puts a property with value [value] to a symbol.
	  [put] calls the put_trigger for property.
	*)
      val get : symbol -> 'a property -> 'a
	(** [get symbol property] returns the value of the property of the symbol.  
	  [get] calls the get_trigger for property.
	*)
    end


(** [StringSymbol = Make(String)] *)
module StringSymbol :
  sig
    type 'a property 
    type symbol 
    val symbol_table : (String.t, symbol) Hashtbl.t
    val make : String.t -> symbol
    val key_of_symbol : symbol -> String.t
    val make_property :
      ?put_trigger:(symbol -> 'a -> unit) ->
      ?get_trigger:(symbol -> 'a -> unit) -> unit -> 'a property
    val put : symbol -> 'a property -> 'a -> unit
    val get : symbol -> 'a property -> 'a
  end

(* symbols.ml *)

module type KEY_TYPE =
sig
  type t
end

	    
let some_of = 
  function 
      Some x -> x
    | None -> invalid_arg "some_of"

module Make(Key_type: KEY_TYPE) =
  struct
    type 'a  property = {
      id : int;
      mutable value : 'a option;
      get_trigger : (symbol -> 'a ->  unit) option; (* maybe mutable ? *)
      put_trigger : (symbol -> 'a -> unit) option; (* maybe mutable ? *)
    }
    and symbol = {
      name : Key_type.t;
      mutable properties : (int, unit->unit) Hashtbl.t;
    }
	
    let symbol_table = Hashtbl.create 127
    let make name = 
      try Hashtbl.find symbol_table name 
      with Not_found ->
	let s = { name = name; properties = Hashtbl.create 13 } in
	  Hashtbl.add symbol_table name s;
	  s
	    
    let key_of_symbol symbol = symbol.name
				    
    let pcounter = ref ~-1
    let make_property ?put_trigger ?get_trigger () =  (* not thread safe *)
      incr pcounter;
      { 
	id = !pcounter; 
	value = None;
	get_trigger = get_trigger;
	put_trigger = put_trigger;
      }
	
    let put symbol prop value =
      Hashtbl.add symbol.properties prop.id (fun () -> prop.value <- Some value);
      match prop.put_trigger with
	  Some g -> g symbol value
	| None -> ()

	    
    let get symbol prop =
      let f = Hashtbl.find symbol.properties prop.id in
	f ();
	(match prop.get_trigger with
	     Some g -> g symbol (some_of prop.value);
	   | None -> ());
	some_of prop.value
  end

module StringSymbol = Make(String)


(* symbol_test.ml *)

module Symbol = Symbol.StringSymbol

let () = 
  let symbol = Symbol.make "hello" in
  let string_property = Symbol.make_property 
			  ~get_trigger:  (fun s v -> print_endline ("get on `" ^ Symbol.key_of_symbol s ^ "' returns `" ^ v ^ "'")) () 
  and int_property = Symbol.make_property
		       ~put_trigger: (fun s v -> print_endline ("put `" ^ string_of_int v ^ "' to `" ^ Symbol.key_of_symbol s ^ "'")) () 
  and bool_property = Symbol.make_property () in
    Symbol.put symbol string_property "test";
    Symbol.put symbol int_property 42;
    Symbol.put symbol bool_property true;
    let s = Symbol.get symbol string_property
    and i = Symbol.get symbol int_property
    and b = Symbol.get symbol bool_property in
      print_endline 
	("s=" ^ s ^ "\n" 
	 ^ "i=" ^ string_of_int i ^ "\n"
	 ^ "b=" ^ if b then "true" else "false")



-- 
beginfig(1)u=3cm;draw fullcircle scaled 2u;x0=x1=y1=x2=y3=0;-y0=y2=x3=1u;
filldraw z0..{left}z1{left}..z2{curl 1}..z3..z0..cycle;def t(expr p)=fullcircle
scaled .25u shifted(0,p*u);enddef;unfill t(.5);fill t(-.5);endfig;bye

Re: [Ocaml-lib-devel] Base64 + Hashtbl.count

[Nicolas C. <war...@fr...>]

> Today I committed previously posted Base64 module , with just two
functions
> encode and decode, that can be extended later. I also added
ExtHashtbl.count
> that is returning the number of elements in an hashtbl.

Looks like the function have been added and named Hashtbl.length on the
Ocaml CVS.
I'll then rename it length.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Towards release 1.1

[Nicolas C. <war...@fr...>]

Hi list,

Here's a todo list proposal before releasing 1.1 :
- writing documentation of newest modules : IO , Base64 and PMap
- adding Ocaml DBI (only the common abstract interfaces, no driver) : I'm
waiting for OCaml DBI 's author Richard Johns answer.
Everybody is of course welcome in contributing documentation, comments, or
code before next release.

Best Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Base64 + Hashtbl.count

[Nicolas C. <war...@fr...>]

Hi list,

Today I committed previously posted Base64 module , with just two functions
encode and decode, that can be extended later. I also added ExtHashtbl.count
that is returning the number of elements in an hashtbl.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] ('a, 'b list ref) Hashtbl.t

[Martin J. <mar...@em...>]

Hi everyone,

Today I wrote an interface for the manipulation of hash tables with unique
copy of each key. This is just using a ('a, 'b list ref) Hashtbl.t.
I think it is especially useful for using hash tables as a clustering
engine. Since I use this kind of things all the time, at least I will use
it. If ExtLib people think it is useful, take it.
It is all based on the standard Hashtbl module.
The module is called Hashtbl2 and can be found here:

  http://martin.jambon.free.fr/ocaml.html

Ocamldoc doc:

  http://martin.jambon.free.fr/hashtbl2/Hashtbl2.html


Martin

Re: [Ocaml-lib-devel] Hashtbl.length and Hashtbl.size

[Martin J. <mar...@em...>]

On Wed, 14 Apr 2004, Nicolas Cannasse wrote:

> about "array_length" I'm not satisfied either with "allocated_size" nor
> "array_length" since the last one is giving information on how hashtbl are
> implemented, which is never a good idea in an abstract interface.

Hashtbl must provide hash tables or I will not use it anymore. It has to
rely on an array-like structure. So what's wrong?

Martin

Re: [Ocaml-lib-devel] Hashtbl.length and Hashtbl.size

[Nicolas C. <war...@fr...>]

> > I propose the following :
> >
> > "count" for the number of inserted elements (wrt Enum)
> > "allocated_size" (or something else) for the size of the underlying
array.
>
> Why not cardinal and array_length?
>
> cardinal vs. count: we don't trigger an iterative algorithm; cardinal is
>                     more neutral
> array_length: hash tables are always supposed to be based on arrays,
>               right?

let me dismiss "cardinal" : we have already List.length , Enum.count,
IO.available ... users might be confused if we had one more way of counting
: IMHO  "count" and "length" are the only choices, but "length" is more
appropriate for flat data structures such as List or Arrays.

about "array_length" I'm not satisfied either with "allocated_size" nor
"array_length" since the last one is giving information on how hashtbl are
implemented, which is never a good idea in an abstract interface.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Re: Hashtbl.length and Hashtbl.size

[Alan P. <ap...@re...>]

In article <016201c42242$194dc6d0$ef01a8c0@warp>, Nicolas Cannasse wrote:
> 
> "count" for the number of inserted elements (wrt Enum)
> "allocated_size" (or something else) for the size of the underlying array.

What about "bucket_count" for the number of buckets?

Re: [Ocaml-lib-devel] Hashtbl.length and Hashtbl.size

[Martin J. <mar...@em...>]

On Wed, 14 Apr 2004, Nicolas Cannasse wrote:

> I propose the following :
>
> "count" for the number of inserted elements (wrt Enum)
> "allocated_size" (or something else) for the size of the underlying array.

Why not cardinal and array_length?

cardinal vs. count: we don't trigger an iterative algorithm; cardinal is
                    more neutral
array_length: hash tables are always supposed to be based on arrays,
              right?

Martin

Re: [Ocaml-lib-devel] Hashtbl.length and Hashtbl.size

[Nicolas C. <war...@fr...>]

> Hi,
>
> I am sometimes missing a function that returns the size of a hash table:
> 1. length of the underlying array
> 2. number of elements.
>
> let length tbl = Array.length tbl.data
> let size tbl = tbl.size
>
> The purpose of the length function is to return a good guess for the size
> of a table that we want to fill with more or less the same number of
> elements than an existing table.
>
> Did I miss anything?

They are actually useful, and I think we could add them to the ExtHashtbl
module.
However, I'm not sure about the naming : one could mistake size and length.

I propose the following :

"count" for the number of inserted elements (wrt Enum)
"allocated_size" (or something else) for the size of the underlying array.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Hashtbl.length and Hashtbl.size

[Martin J. <mar...@em...>]

Hi,

I am sometimes missing a function that returns the size of a hash table:
1. length of the underlying array
2. number of elements.

let length tbl = Array.length tbl.data
let size tbl = tbl.size

The purpose of the length function is to return a good guess for the size
of a table that we want to fill with more or less the same number of
elements than an existing table.

Did I miss anything?

Martin