From: skaller <sk...@us...> - 2004-07-29 22:15:28
|
On Fri, 2004-07-30 at 07:10, Nicolas Cannasse wrote: > > I'll clarify my thinking then : > What kind of modifications are needed to support - for example - purely > functional enums ? > > Theses : > > val iter : ('a -> unit) -> 'a t -> unit > val iter2 : ('a -> 'b -> unit) -> 'a t -> 'b t -> unit > val fold : ('a -> 'b -> 'b) -> 'b -> 'a t -> 'b > val fold2 : ('a -> 'b -> 'c -> 'c) -> 'c -> 'a t -> 'b t -> 'c > val iteri : (int -> 'a -> unit) -> 'a t -> unit > val iter2i : (int -> 'a -> 'b -> unit) -> 'a t -> 'b t -> unit > val foldi : (int -> 'a -> 'b -> 'b) -> 'b -> 'a t -> 'b > val fold2i : (int -> 'a -> 'b -> 'c -> 'c) -> 'c -> 'a t -> 'b t -> 'c > val map : ('a -> 'b) -> 'a t -> 'b t > val mapi : (int -> 'a -> 'b) -> 'a t -> 'b t > val filter : ('a -> bool) -> 'a t -> 'a t > val filter_map : ('a -> 'b option) -> 'a t -> 'b t > val append : 'a t -> 'a t -> 'a t > val concat : 'a t t -> 'a t Given the style of interface I would have to agree with these. > val empty : unit -> 'a t > val from : (unit -> 'a) -> 'a t > val init : int -> (int -> 'a) -> 'a t but not these. Empty is suspect -- in theory empty() is a special case of count() which is a special case of fold() -- and therefore would be *defined* to exhaust the enumeration destructively. Since that's a questionable interpretation of the intent, leave empty() out for the moment. Similarly, from() and init() both imply destructive generators are acceptable, which is debatable. In addition, one can argue constructors should always be split out from the purely categorical abstraction defining a concept -- clearly we must have constructors (such as 'from_list') but lets package them separately so we can actually agree on something and make progress :) -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |