caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jacques Carette <carette@mcmaster.ca>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] compiler bug?
Date: Sat, 20 May 2006 05:10:08 +1000	[thread overview]
Message-ID: <1148065808.15638.56.camel@rosella.wigram> (raw)
In-Reply-To: <446DF6C0.4090000@mcmaster.ca>

On Fri, 2006-05-19 at 12:48 -0400, Jacques Carette wrote:
> skaller wrote:
> 
> >>>What about high level optimisations?
> >>>
> >>>Felix supports this:
> >>>
> >>>	reduce revrev[t] (x:list[t]): rev (rev x) => x;
> >>>      
> >>>
> >>Haskell (GHC to be precise) allows that too. But is syntactic 
> >>term-rewriting, in other words it is *untyped*.

> >It's well typed. x:list[t] means x is of type list[t].
> >  
> >
> The *result* is well-typed.  What is the 'type' of the rule (ie the 
> 'function' reduce) ?  

> reduce acts on the programming language syntax, 
> not on semantic values.

Yes, but so what?

Originally you said it was *untyped*.
As if it were like a macro which rewrites all terms

	rev (rev x)

to

	x

but this is not the case.

The thing is Felix ALSO has macros which are indeed untyped:

	macro fun f(x) = x + x;

so f x is replaced by x + x everywhere the f is in scope.

So when you later said

"Ocaml is great because it is statically typed.  MetaOCaml is wonderful 
because it is statically typed.  Adding an untyped layer to a typed 
language seems like a definite step backwards (i.e. a hack).. "

I think you're missing the point: I'd agree with that
comment and also agree it applied to Felix macros,
because they are indeed manipulations of untyped terms.
Macro processing is done first, before typing.

But 'reduce' is done after typing, it manipulates
typed terms: it isn't adding an *untyped* layer
to the system, on the contrary the semantics implied
are actually *beyond* ordinary static typing. We have
learned:

	rev ^ 2 = id (revrev)

and this property of 'rev' is a constraint on its semantics
(but of course not a complete specification).

What one might say is that the mechanism is somewhat
ad hoc rather than being systematic.

The problem here, if any, you yourself pointed out
in private email some time ago -- there's no assurance
the rules are actually reductions: one or more such
rules may well diverge.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2006-05-19 19:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 23:14 Dan Koppel
2006-05-17 23:33 ` [Caml-list] " John Carr
2006-05-18 17:15 ` Xavier Leroy
2006-05-18 17:34   ` Jacques Carette
2006-05-18 17:46     ` Xavier Leroy
2006-05-18 19:31       ` Jacques Carette
2006-05-18 20:07         ` David Brown
2006-05-18 20:15           ` Jacques Carette
2006-05-18 20:20           ` Alain Frisch
2006-05-18 18:19     ` skaller
2006-05-18 18:53       ` Jacques Carette
2006-05-19  1:47         ` skaller
2006-05-19  2:17           ` Brian Hurt
2006-05-19  3:11             ` skaller
2006-05-19 16:48           ` Jacques Carette
2006-05-19 19:10             ` skaller [this message]
2012-08-06 10:04 [Caml-list] Compiler bug? Dmitry Bely
2012-08-06 10:11 ` Alain Frisch
2012-08-06 10:20   ` Dmitry Bely
2012-08-06 10:34     ` Alain Frisch
2012-08-06 11:03       ` Dmitry Bely
2012-08-06 11:32         ` Alain Frisch
2012-08-06 12:16           ` Dmitry Bely
2012-08-07  1:35           ` Cedric Cellier
2012-08-08 16:03           ` Dmitry Bely
2012-08-08 18:03             ` Alain Frisch
2012-08-08 18:22               ` Jesper Louis Andersen
2012-08-08 18:40                 ` Dmitry Bely
2012-08-08 19:29                   ` Fabrice Le Fessant
2012-08-08 23:34                 ` Anil Madhavapeddy
2012-08-09  0:53                 ` Francois Berenger

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=1148065808.15638.56.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=carette@mcmaster.ca \
    /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).