caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Martin Chabr <martin_chabr@yahoo.de>
To: skaller <skaller@users.sourceforge.net>
Cc: caml-list@yquem.inria.fr
Subject: Ant:  [Caml-list] how to implement generic operators
Date: Mon, 24 Oct 2005 20:26:54 +0200 (CEST)	[thread overview]
Message-ID: <20051024182654.24834.qmail@web26808.mail.ukl.yahoo.com> (raw)
In-Reply-To: <1130131250.28443.79.camel@rosella>

I am not an expert and I am not a compiler or language
designer. I only use languages and I can only tell you
how I feel when I use one language or move to another
one.

I did some Prolog and some Python programming before I
moved to OCaml. In both Prolog and Python you can use
lists with mixed types as you suggest. I thing the
problem is not mixing types in a list, but what you
want to do with the data afterwards. Operators do
restrict data types.

I was surprised at first when I found out how OCaml
restricts lists. I was even more surprised when I
learned about the distinction between the integer and
floating operators (+ and * vs +. and *. etc.): Then I
learned about some problems with type inference in
Standard ML which uses overloaded operators. You have
to declare the types more in Standard ML than in
OCaml.

Now I got used to it and appreciate the clarity: types
in mixed expressions must always be converted to be
compatible with each other. No automatic conversion
where you wonder what will happen.

C# had collections of mixed types as well in the 1.x
version. Now, in the version 2.0 they have generics
and strong type checking and everybody seems to like
it, not having to do any type detection and casting.

Martin

--- skaller <skaller@users.sourceforge.net> wrote:

> I am looking for some ideas on how to implement
> generic
> operators.
> 
> To explain what I mean by that: consider some
> operations
> such as: fold, map, iter. In Ocaml these are
> polymorphic.
> 
> A generic iter would be something like:
> 
> 	iter f [1; 2.0; "hello"] 
> 
> -->
> 
> 	f 1; f 2.0; f "hello"
> 
> Now, within Ocaml itself this doesn't make sense.
> However
> my question relates to how to *implement* such an
> operation
> in a compiler. In that case, the list above is a
> list
> of *terms* not values -- so there is no typing
> problem,
> provided the reduction rules ground at compile time.
> 
> Now for the problem: there are a LOT of such
> operators.
> Here is another example:
> 
> 	compose [f; g; h; k]
> 
> and another 
> 
> 	ravel [f; g; h; k]
> 
> which converts a product of functions to a function
> of products.
> 
> I want the USER to be able to define these
> operations,
> and provide only a minimal set of combinators in the
> compiler.
> 
> Obviously, one of the key combinators is fold, since
> all of
> the above operations suffer from the problem that
> whilst
> the user can .. as in Ocaml .. easily define a
> binary version
> of the operator .. there is no way in the target
> language
> to handle *lists* of arguments: the compiler itself
> can do
> so easily by using Ocaml lists of terms, but the
> user
> cannot modify the compiler to add new combinators.
> 
> To make the problem concrete: suppose I would like
> to avoid:
> 
> 	Compose of term list
> 	Ravel of term list
> 	.....
> 
> each of which uses much the same reduction rules: it
> expands
> to some tree or using more basic binary primitives
> .. 
> I would clearly need some representation like:
> 
> 	Assoc of op * term list
> 
> and then some kind of fold which works for all
> different binary op,
> where now 'op' is defined by the user.
> 
> So crudely the question is: what is the
> representation of 'op'
> required so the generic fold can create a wide class
> of
> generic n-ary operations from binary ones?
> 
> Note the data for op will be obtained by parsing in
> the input
> program, so cannot consist of just a fixed list of
> variants.
> 
> Crudely .. I am looking for a way to declare a
> function
> which instead of having 'two' arguments, can have n.
> All the arguments must be the same KIND so their
> terms
> have the same type, but the arguments obviously will
> not
> have the same type.
> 
> Hope this makes sense .. I have a feeling MetaOcaml
> can do this already.
> 
> -- 
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de


  reply	other threads:[~2005-10-24 18:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-24  5:20 skaller
2005-10-24 18:26 ` Martin Chabr [this message]
2005-10-25  1:09   ` Ant: [Caml-list] " skaller
2005-10-25  1:56   ` skaller
2005-10-24 19:27 ` Jacques Carette
2005-10-25  1:43   ` skaller
2005-10-25 15:52     ` Jacques Carette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051024182654.24834.qmail@web26808.mail.ukl.yahoo.com \
    --to=martin_chabr@yahoo.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=skaller@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).