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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id AE1368002D for ; Wed, 12 Oct 2016 09:20:47 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=oleg@okmij.org; spf=Pass smtp.mailfrom=oleg@okmij.org; spf=None smtp.helo=postmaster@mail1.g3.pair.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oleg@okmij.org) identity=pra; client-ip=66.39.3.114; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of oleg@okmij.org designates 66.39.3.114 as permitted sender) identity=mailfrom; client-ip=66.39.3.114; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail1.g3.pair.com) identity=helo; client-ip=66.39.3.114; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="postmaster@mail1.g3.pair.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AlM8xehBzxENuicROZ/1GUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP74r8bcNUDSrc9gkEXOFd2CrakV0ayK6uuxBSQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09?= =?us-ascii?q?fr2zQd+IyZjunLHus7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJce?= =?us-ascii?q?kFjUlhJFaUggqurpzopM0roGxsvKcm889eXL/ScaUiVqAeDTJjOW0v4Mzt8xXO?= =?us-ascii?q?CUOO+HQ0U2gbn1xPGQeWwgv9W8LWtib1/r563CSVFcr1SLE2HzO44PE4G1fTlC?= =?us-ascii?q?4bOmthoynsgctqgfcDrQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgDL4/1Xh3IDJ0JcHAEBBAEBCgEBG?= =?us-ascii?q?BgHgwUBAQEBAXR8jTOXU5NlggwmhXoCggEMOBQBAQEBAQEBAQEBARIBAQEKCwk?= =?us-ascii?q?JGS+CMhiCGAICAjo/GyE0BUqIYg7DEAEBAQcBAQEBJIY8hFaCY4UUgi8FjzSKT?= =?us-ascii?q?oIvg3iJSwuBbk59hlOFaYVxhwiDfx6BBIJzEQuBYmOIZAEBAQ?= X-IPAS-Result: =?us-ascii?q?A0AMAgDL4/1Xh3IDJ0JcHAEBBAEBCgEBGBgHgwUBAQEBAXR?= =?us-ascii?q?8jTOXU5NlggwmhXoCggEMOBQBAQEBAQEBAQEBARIBAQEKCwkJGS+CMhiCGAICA?= =?us-ascii?q?jo/GyE0BUqIYg7DEAEBAQcBAQEBJIY8hFaCY4UUgi8FjzSKToIvg3iJSwuBbk5?= =?us-ascii?q?9hlOFaYVxhwiDfx6BBIJzEQuBYmOIZAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,333,1473112800"; d="scan'208";a="196471352" Received: from mail1.g3.pair.com ([66.39.3.114]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2016 09:20:46 +0200 Received: from Magus.localnet (fortigate.sf.ecei.tohoku.ac.jp [130.34.188.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.g3.pair.com (Postfix) with ESMTPSA id 69F1F3FBB54; Wed, 12 Oct 2016 03:20:43 -0400 (EDT) Date: Wed, 12 Oct 2016 16:25:47 +0900 From: Oleg To: oliver@first.in-berlin.de, ivg@ieee.org Cc: caml-list@inria.fr Message-ID: <20161012072547.GA1673@Magus.localnet> Mail-Followup-To: Oleg , oliver@first.in-berlin.de, ivg@ieee.org, caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <380FF407-4857-4363-971F-1567AD43A0BC@ieee.org> User-Agent: Mutt/1.6.1 (2016-04-27) Subject: Re: [Caml-list] First-Class Types?! Currently MetaOCaml does not allow struct ... end and sig ... end to appear within brackets. If it did, it becomes legitimate to talk about splices not only within expressions but also type definitions, etc. So, the notion of first-class types arises quite naturally once we considered staging. We have tried to contemplate this question and what good might first-class types do. One immediate benefit would be specializing functor applications and reducing/removing overhead of using functors. When we thought about it further, it turns out we can do essentially the same in existing (Meta)OCaml. Hence the problem: we couldn't come up with a compelling example why we would need to extend staging to type expressions. You can read more details in the PEPM 2016 paper http://okmij.org/ftp/meta-programming/StagingNG.pdf