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 4F7887ED7A for ; Sat, 22 Sep 2012 09:50:11 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oleg@okmij.org) identity=pra; client-ip=66.39.3.115; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of oleg@okmij.org designates 66.39.3.115 as permitted sender) identity=mailfrom; client-ip=66.39.3.115; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; 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@www1.g3.pair.com) identity=helo; client-ip=66.39.3.115; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="postmaster@www1.g3.pair.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAHVrXVBCJwNzX2dsb2JhbABFvkIfUYIgAQEEAR1ODgUWNFUUFIgEBgu5PYswgnaDIAOVZAGBFZF0gVo X-IronPort-AV: E=Sophos;i="4.80,467,1344204000"; d="scan'208";a="174202858" Received: from www1.g3.pair.com ([66.39.3.115]) by mail1-smtp-roc.national.inria.fr with SMTP; 22 Sep 2012 09:50:10 +0200 Received: (qmail 24779 invoked by uid 9370); 22 Sep 2012 07:50:08 -0000 Date: 22 Sep 2012 07:50:08 -0000 Message-ID: <20120922075008.24778.qmail@www1.g3.pair.com> From: oleg@okmij.org To: bobzhang1988@gmail.com CC: caml-list@inria.fr In-reply-to: <505B091A.7080806@gmail.com> X-Validation-by: oleg@okmij.org Subject: [Caml-list] Re: Call for collaboration on the future of camlp4 > 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. > 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. > 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. > 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.