From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 31F907ED7A for ; Sat, 22 Sep 2012 14:02:07 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of bobzhang1988@gmail.com) identity=pra; client-ip=209.85.216.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="bobzhang1988@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of bobzhang1988@gmail.com designates 209.85.216.182 as permitted sender) identity=mailfrom; client-ip=209.85.216.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="bobzhang1988@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qc0-f182.google.com) identity=helo; client-ip=209.85.216.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="postmaster@mail-qc0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4CAIWoXVDRVdi2k2dsb2JhbABFi2qyOAgjAQEBAQkJCwkUBCOCIAEBAQMBEgIJIwEbDw0BAQMMBgULDQkWDwkDAgECARERAQUBHBMBBQIBAR6HUAEDCQYLmhAJA4wlgnWEeAoZJw1ZiHQBBQyLJIYWA5VlgRWNLj+EI4E+ X-IronPort-AV: E=Sophos;i="4.80,467,1344204000"; d="scan'208,217";a="174216667" Received: from mail-qc0-f182.google.com ([209.85.216.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Sep 2012 14:02:06 +0200 Received: by qcsg15 with SMTP id g15so331261qcs.27 for ; Sat, 22 Sep 2012 05:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=PdzVjlChOWGHQiwgN0fjjnhATUPtB4hpvjNRiVUQxDs=; b=O7nLYdpqhC8GbTiC0jUHn/pjumkQv8WhV4Vh2/nh3VpYmhW4K0xI+DQakld4/bK3C6 HmyxycfkXql+47v3xUEzAg7jPxNiNTkqiTtKmsdVH2iDNUa7McYeh34r8XrGsxGSvGsm DTapGhlo6c6pZj/rrDHhrXucAVPEnIEcdleFRpbSQtf/lxax7ZNFrazEh5UffFl6tdG4 rjyBQJgnNFAwhZAgaFQPjnPici6IPhWisGiNQB+lM6NA6WA1sPtf2PTGjbnnCouBlJ9X 7Jb/Mr57e+jJoLJme1QsxGPStxo86wtgV9dxVbas9UhvNAe/WRT2ozcJ5wSM3w7mxLKc hMdw== Received: by 10.224.31.202 with SMTP id z10mr18703889qac.86.1348315325399; Sat, 22 Sep 2012 05:02:05 -0700 (PDT) Received: from Hongbos-MacBook-Air.local ([66.250.143.158]) by mx.google.com with ESMTPS id bh14sm16525124qab.2.2012.09.22.05.02.04 (version=SSLv3 cipher=OTHER); Sat, 22 Sep 2012 05:02:04 -0700 (PDT) Message-ID: <505DA8BB.1080009@gmail.com> Date: Sat, 22 Sep 2012 08:02:03 -0400 From: Hongbo Zhang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: oleg@okmij.org CC: caml-list@inria.fr References: <20120922075008.24778.qmail@www1.g3.pair.com> In-Reply-To: <20120922075008.24778.qmail@www1.g3.pair.com> Content-Type: multipart/alternative; boundary="------------050905090007010803030900" Subject: [Caml-list] Re: Call for collaboration on the future of camlp4 This is a multi-part message in MIME format. --------------050905090007010803030900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/22/12 3:50 AM, oleg@okmij.org wrote: >> Yes, it's [MetaOCaml] a run-time optimizer with type safe assurance. It can do >> partial evaluation to generate some optimized code. > Let me stress once again how narrow this view is. MetaOCaml goes well > beyond partial evaluation. For example, MetaOCaml, as a general code > generation framework, was used to derive optimal (in the number of > multiplications) FFT kernels. Partial evaluation will not give you > that. > > Code generation is a very promising technique in High-Performance > computing. Most of the tools used in practice -- FFTW, ATLAS, SPIRAL > -- are all off-line tools. They generate a large number of candidate > codes and choose the best performing. What's important is to quickly > generate a large number of very tedious programs. Assurance of > correctness are important: a programmer, especially a domain expert, > will not want to even look at the generated code let alone debug it. > I see MetaOCaml target the same area. > To my limited knowledge, FFTW used techniques more like Camlp4. Again: type safety(without dependent types) is far from correctness, actually, the type error bugs are the easiest to fix. In practice, you always need to debug the generated code if something goes wrong. One thing people complains about template c++ code is that it's really hard to debug. >> I agree it would be useful to have a native eval, but this requires >> non-trivial changes to the compiler which I don't expect it will be >> realized in a short term. > The assessment is mistaken. MetaOCaml v3.09 did have a native > back-end. I know quite well what changes were required. Those changes > are no longer needed since dynamic linking has since become part of > OCaml proper. Actually, I am one of the curious programmers who tried MetaOCaml and played with it. Don't get me wrong, I would be happy to see MetaOCaml pushed into OCaml. As I said before, it's orthogonal to P4, it's great if we could dynamically generate type safe code, and we can make use of meta-ocaml as well ;-) But the assumption is /*that we have a native meta-ocaml without patching the compiler */ >> If you take a look at the history of Template Haskell, they finally >> step back from type checking everything to give up type checking some >> quasi-quotations. > This is a mistaken impression. While Template Haskell as a whole will > remain untyped for a long time -- after all, Template Haskell can > generate data and type class _declarations_, whose typing is far from > clear -- there is a definite push towards MetaOCaml-like type safety > for expressions. > http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal > > see especially > Part B: Add new MetaML-style constructs for strongly-typed metaprogramming. > > If this is implemented, TH becomes quite like MetaML. There are two problems here, first you object language is not only ocaml, second, yes, we want /*everything to be first class, everything*/, the most expressive system. >> We don't want to sacrifice too much experssivity for type safety, this >> is especially important in macros. In common lisp, there is also a >> kind of macros called "Anaphoric macros" which you will find painful >> to do in Scheme. > That is not a very good argument since R5RS macros in Scheme were > intentionally limited in their expressivity. The macro system was > designed to be just enough expressive for the special forms > introduced in the Report. (Later on the system was found to be quite > more expressive than its designers have anticipated.) > > The anaphoric macros are easily expressible in the system of our JFP > 2011 paper (staging with a very limited delimited control). No > subversions of hygiene are needed. That depends on how you define 'easily expressible' ;-) Let's discuss in private, btw, it's a bit unfair that you just picked some points and ignored others without context. Thanks for your message. > --------------050905090007010803030900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 9/22/12 3:50 AM, oleg@okmij.org wrote:
Yes, it's [MetaOCaml] a run-time optimizer with type safe assurance. It can do
partial evaluation to generate some optimized code. 

Let me stress once again how narrow this view is. MetaOCaml goes well
beyond partial evaluation. For example, MetaOCaml, as a general code
generation framework, was used to derive optimal (in the number of
multiplications) FFT kernels. Partial evaluation will not give you
that.

Code generation is a very promising technique in High-Performance
computing. Most of the tools used in practice -- FFTW, ATLAS, SPIRAL
-- are all off-line tools. They generate a large number of candidate
codes and choose the best performing. What's important is to quickly
generate a large number of very tedious programs. Assurance of
correctness are important: a programmer, especially a domain expert,
will not want to even look at the generated code let alone debug it.
I see MetaOCaml target the same area.
To my limited knowledge, FFTW used techniques more like Camlp4.
Again: type safety(without dependent types) is far from correctness,
actually, the type error bugs are the easiest to fix. In practice,
you always need to debug the generated code if something goes wrong.
One thing people complains about template c++ code is that it's really
hard to debug.

I agree it would be useful to have a native eval, but this requires
non-trivial changes to the compiler which I don't expect it will be
realized in a short term.

The assessment is mistaken. MetaOCaml v3.09 did have a native
back-end. I know quite well what changes were required. Those changes
are no longer needed since dynamic linking has since become part of
OCaml proper.
Actually, I am one of the curious programmers who tried MetaOCaml and played
with it. Don't get me wrong, I would be happy to see MetaOCaml pushed into OCaml.
As I said before, it's orthogonal to P4, it's great if we could dynamically generate
type safe code, and we can make use of meta-ocaml as well ;-)
But the assumption is that we have a native meta-ocaml without patching the compiler 

      

        
If you take a look at the history of Template Haskell, they finally
step back from type checking everything to give up type checking some
quasi-quotations. 


      

      
This is a mistaken impression. While Template Haskell as a whole will
remain untyped for a long time -- after all, Template Haskell can
generate data and type class _declarations_, whose typing is far from
clear -- there is a definite push towards MetaOCaml-like type safety
for expressions. 
  http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal

see especially
  Part B: Add new MetaML-style constructs for strongly-typed metaprogramming.

If this is implemented, TH becomes quite like MetaML.


    

    There are two problems here, first you object language is not only
    ocaml,

    second, yes, we want everything to be first class, everything,
    the most 

    expressive system.

    

      

      

        
We don't want to sacrifice too much experssivity for type safety, this
is especially important in macros. In common lisp, there is also a
kind of macros called "Anaphoric macros" which you will find painful
to do in Scheme.


      

      
That is not a very good argument since R5RS macros in Scheme were
intentionally limited in their expressivity. The macro system was
designed to be just enough expressive for the special forms
introduced in the Report. (Later on the system was found to be quite
more expressive than its designers have anticipated.)

The anaphoric macros are easily expressible in the system of our JFP
2011 paper (staging with a very limited delimited control). No
subversions of hygiene are needed.


    

    That depends on how you define 'easily expressible' ;-)

    Let's discuss in private, btw, it's a bit unfair that you just
    picked

    some points and ignored others without context.

    

    Thanks for your message.

    

      



    

    

  


--------------050905090007010803030900--