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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8A235820A1 for ; Tue, 13 Aug 2013 13:23:07 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rossberg@mpi-sws.org) identity=pra; client-ip=139.19.1.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rossberg@mpi-sws.org designates 139.19.1.49 as permitted sender) identity=mailfrom; client-ip=139.19.1.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@hera.mpi-klsb.mpg.de) identity=helo; client-ip=139.19.1.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="postmaster@hera.mpi-klsb.mpg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8CAPQVClKLEwExgGdsb2JhbABbDsJYgR8WDgEBCwcECQkUBSOCJAEBAQMBOAgBATYBAQ8LDgoJFg8JAwIBAgEjBR0GDQEHAQGIBgaaFosMhEcBBY1oBo55gUMHhBGUEIl/jgZAgWY X-IPAS-Result: Ah8CAPQVClKLEwExgGdsb2JhbABbDsJYgR8WDgEBCwcECQkUBSOCJAEBAQMBOAgBATYBAQ8LDgoJFg8JAwIBAgEjBR0GDQEHAQGIBgaaFosMhEcBBY1oBo55gUMHhBGUEIl/jgZAgWY X-IronPort-AV: E=Sophos;i="4.89,868,1367964000"; d="scan'208";a="29246441" Received: from hera.mpi-klsb.mpg.de ([139.19.1.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 13 Aug 2013 13:23:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PJ7dGlfp9UMnbxwkbsmS3ucleGEbWRGJYZT++U3w0dc=; b=qW9dKk762YCT1D5+PUbCmJCXaxKcvOzEyGph53NCj6VosrhzgIFvMPmuyrsvoi7DgkHeAIOD6kcziOfxp2sH/R6xV0O0sUpKhDganLAlOhE+EVonQ/CbC55vQvVGZrsPDRrc9kRgQIpYCzf62Tzs95q0A4GgU+Qs98hWYBnSiUs=; Received: from srv-00-126.mpi-klsb.mpg.de ([139.19.1.29]:41093 helo=zak.mpi-klsb.mpg.de) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtp (Exim 4.72) id 1V9Cgn-0002ya-55; Tue, 13 Aug 2013 13:23:03 +0200 Received: from [74.125.57.233] (port=39464 helo=bozo.muc.corp.google.com) by zak.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1V9Cgm-0002Fc-KT; Tue, 13 Aug 2013 13:23:00 +0200 Message-ID: <520A1713.7030708@mpi-sws.org> Date: Tue, 13 Aug 2013 13:22:59 +0200 From: Andreas Rossberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Leo White CC: David Sheets , Caml List References: <1407E74D-EDC8-4638-8917-4CAC80B4C682@mpi-sws.org> <9D61A8E2-D0B4-452A-B372-401E499423AE@mpi-sws.org> <86bo549sv9.fsf@cam.ac.uk> <5208C0A7.2040906@mpi-sws.org> <86haevnnr5.fsf@cam.ac.uk> <5208D1EF.5050302@mpi-sws.org> <86bo53njmc.fsf@cam.ac.uk> <5208EE0D.3000507@mpi-sws.org> <867gfrndl0.fsf@cam.ac.uk> <52090871.8090400@mpi-sws.org> <861u5yoo0o.fsf@cam.ac.uk> In-Reply-To: <861u5yoo0o.fsf@cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MPI-Local-Sender: true Subject: Re: [Caml-list] First-class Functor Forgetting for Free On 08/12/2013 06:46 PM, Leo White wrote: >> Your row variables will inevitably be higher-order, AFAICS. > > I don't think they will be. To be higher order wouldn't they need to > have parameters? I don't see how they could end up with parameters. Their instantiation would _contain_ type constructors, which makes them higher-order. Whether that would be a problem or not I'm not sure (probably not as long as these row variables cannot be used in any other context). It definitely is an extension over the kind of polymorphism OCaml currently supports. >> I disagree completely. Packages wrap modules, so package types _are_ module types. The point of package types is to >> embed module types into the core type system, not to create a parallel module type system. I think it would be a real >> bad idea to invent a separate typing mechanism for this purpose, since that is bound to create complexity, friction, and >> confusion. > > I also disagree completely. Packages wrap modules, so package types > _wrap_ module types. The core type system provides mechanisms that are > not available in the module type system. We should not rule out using > these mechanisms with package types to make then easier to use. > > Embeding module types into the core type system should mean allowing the > mechanisms provided by the core type system to operate on module types, > not just allowing the core type system to treat module types as > black-boxes that can be passed around and given back to the module > system. I don't follow that line of reasoning. The primary reason why we have a two-layered language is that most of the core typing mechanisms simply _don't work_ for modules. Packages are a clean way of escaping the stratification without mixing up the layers and running into a wealth of potential problems. It's unfortunate enough that programmers need to understand 2 separate sublanguages and type systems. Extending that to 2 + 1/2 and blurring the boundary with rather subtle and limited mechanisms would seem to have a negative net effect on language usability. I'd argue that less is more here (as is often the case in language design). Best, /Andreas