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 07A467FDEE for ; Thu, 2 Jun 2016 21:18:44 +0200 (CEST) IronPort-PHdr: 9a23:R1YY2hSHy1GHzewkyXFudOpU/dpsv+yvbD5Q0YIujvd0So/mwa64YhON2/xhgRfzUJnB7Loc0qyN4/GmBD1LuM3d+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8yVPlQD3WHhKZpJbzyI7izp/vEMhoVjLqtjgjDomVBvP9ps+GVzOFiIlAz97MrjtLRq8iBXpu5zv5UYCfayLOwESukSBz0jNyUx5db3nRjFVwqGoHUGGC1CmRNNB03B7Qrmdpb3qCrz8ORnjnq0J8rzGPofUC6v87tmDFfKgSweKjMiuimDgcVqgb5HrTqkrBl22JLZeseePawtLevmYdoGSD8ZDY5qXCtbD9bkYg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=carette@mcmaster.ca; spf=None smtp.mailfrom=carette@mcmaster.ca; spf=None smtp.helo=postmaster@FHSHC4H16-1.csu.mcmaster.ca Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=pra; client-ip=130.113.22.3; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=mailfrom; client-ip=130.113.22.3; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@FHSHC4H16-1.csu.mcmaster.ca) identity=helo; client-ip=130.113.22.3; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="postmaster@FHSHC4H16-1.csu.mcmaster.ca"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvAgCHhVBXgAMWcYJegm0hggW8O4YSAiOBDzsRAQEBAQEBAQERAQELCwkJISQLQRIBgVyCDBCBCwELAR5WJgEEG4gnAaFdoUePNoMqgi4Fjh2KFAYBgS6OWod7hTiPTDSEDoNshn8BfgEBAQ X-IPAS-Result: A0DvAgCHhVBXgAMWcYJegm0hggW8O4YSAiOBDzsRAQEBAQEBAQERAQELCwkJISQLQRIBgVyCDBCBCwELAR5WJgEEG4gnAaFdoUePNoMqgi4Fjh2KFAYBgS6OWod7hTiPTDSEDoNshn8BfgEBAQ X-IronPort-AV: E=Sophos;i="5.26,407,1459807200"; d="scan'208,217";a="179943810" Received: from fhshc4h16-1.csu.mcmaster.ca ([130.113.22.3]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 02 Jun 2016 21:18:42 +0200 Received: from FHSDB2D11-2.csu.mcmaster.ca ([fe80::2924:2ca:3cbc:4521]) by FHSHC4H16-1.csu.mcmaster.ca ([2002:8271:1603::8271:1603]) with mapi id 14.03.0279.002; Thu, 2 Jun 2016 15:18:41 -0400 From: "Carette, Jacques" To: "caml-list@inria.fr" Thread-Topic: Option to fully expand types in error messages? Thread-Index: AdG9A5GLssEk6Qd8TUiu0LqSgShZcw== Date: Thu, 2 Jun 2016 19:18:39 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.113.22.227] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22366.005 x-tm-as-result: No--34.481400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Caml-list] Option to fully expand types in error messages?

In writing some code which uses a lot of monads with underlying type= s which use constraints, even simple errors can lead to extremely hard to r= ead error messages. The main reason is that the two types given in errors are partially expanded, to different= levels. This frequently means that the part where the type checker d= etects a mismatch is (extremely) opaque to human eyes.

In that case, it would actually be preferable to fully expand the types.&nb= sp; Yes, that will produce wallpaper. But at least the mismatch shoul= d be considerably easier to catch.

Does this already exist, or should I submit a feature request?

Jacques

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 E6F7F7FDEE for ; Thu, 2 Jun 2016 21:45:46 +0200 (CEST) IronPort-PHdr: 9a23:ueIFKBf6TPSWqfDa2zG4NtmBlGMj4u6mDksu8pMizoh2WeGdxc6zZR7h7PlgxGXEQZ/co6odzbGG4ua9CCdZusrJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbviqtuOMk4R32b1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S5WeWwMnwZUDkyNzhjxR4r8qWGy4uF0wiSGIcDeSLsxUC++4r0tQxa+2wkdMDts32jdkM19iOpgqxKsvRFli9rbaYuPNfd6OLjWfd4ASHBpUcNYVigHCYS5OdhcR9EdNPpV+tGu72AFqgGzUEz1XLvi Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f182.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; 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@mail-io0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DTAACRjFBXerbfVdFehQ0Gry2LFYF5hhICgSwHOBQBAQEBAQEBAREBAQkLCwkfMYIwghYBAQQSER0BGx0BAwwGBQsNAgImAgIiAREBBQEcBhMbB4dyAQMXo1uBMT4xizuBaoJYBYdyChknDVKDTQEBAQEGAQEBARsCBhBxhSaETYdBglkBBJg3gVaMSoFph3uFOI4NEh6BDx6CMIIQIDKKfAEBAQ X-IPAS-Result: A0DTAACRjFBXerbfVdFehQ0Gry2LFYF5hhICgSwHOBQBAQEBAQEBAREBAQkLCwkfMYIwghYBAQQSER0BGx0BAwwGBQsNAgImAgIiAREBBQEcBhMbB4dyAQMXo1uBMT4xizuBaoJYBYdyChknDVKDTQEBAQEGAQEBARsCBhBxhSaETYdBglkBBJg3gVaMSoFph3uFOI4NEh6BDx6CMIIQIDKKfAEBAQ X-IronPort-AV: E=Sophos;i="5.26,407,1459807200"; d="scan'208";a="220871098" Received: from mail-io0-f182.google.com ([209.85.223.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 02 Jun 2016 21:45:23 +0200 Received: by mail-io0-f182.google.com with SMTP id t40so56163962ioi.0 for ; Thu, 02 Jun 2016 12:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/x46S7tm/CNFuNdv7tIZ248kV7sP8t5SMVCZdP4Dgl4=; b=CfqYaYNrYfKX53w8mSQANAuf4HVQsRtruBAzLyAjcSpEoJ3WjMAPj+fehqCXRO+K2B CR3AvIArOp4wkwaX6FNVZzN9usDeCA53Ae3e5ekZE6924POQFIGiX6WTNgRCCgWFv6iK owEXkPKeXHpdvXb0Wms/9exvQ1qHIsV05unOpRP8ocOKqGbxDaxawGOaPVl9+NxgFsTH L3CpuXBkWqdiEFoSAQDLa1hvtHS3iSZHmCdqLAO3qUrfXjnM7yuYrMN+8Nj7qyW32VNh HcTeamObraHeclSxKmpmDxcbXFZ47D+qSfqeVug5yCzwmrxWynWekOEqWiZ/Z8TeeIsV uhWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/x46S7tm/CNFuNdv7tIZ248kV7sP8t5SMVCZdP4Dgl4=; b=aKv2tvxyXrsWpi/2LiNlbcWkGsHAfkTnwNMzTh+cI1LmPvC1jSjKTrYoaUJ1Hiyg+/ CdgE0fc1R5vXczutVOVrh+hG05C5D/uF1TobfpUX6MEj0RseIn5we1kEwC+WYiRIQzl+ 8UIvOFLrzx0AjmlFEuiA9uSkPeKNJ5NeP2rCJ/e5xoF+E3lRElA3mb9LZtYCxXY/xzmA UZZVAv/WpJFqJ4f4nFHy0X6ichO4jMAMorA7fID9lM7s9XDq5HAUltNkme5L2fLMXhOz E/bWLQjRLNKeS636SeSgLNWBL2YzHleGFw4I7mSUDN9Lp+aJgVsA4vqZ0l+GSWNTpgQT ofkA== X-Gm-Message-State: ALyK8tKxyNaiGY6AT0YsT0w+l7t2xz7BgZW/ut10YDIq2lzTL6k8tVYlZ4WcOhCxnhh4idMJbONjl3EhDBdPOg== X-Received: by 10.107.169.67 with SMTP id s64mr549287ioe.19.1464896722055; Thu, 02 Jun 2016 12:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.89.195 with HTTP; Thu, 2 Jun 2016 12:44:42 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Thu, 2 Jun 2016 15:44:42 -0400 Message-ID: To: "Carette, Jacques" Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Option to fully expand types in error messages? This does not exist to my knowledge. I think that in a bug report, it would be interesting if you could include some reproducible code and an example of the error messages that are not readable. I would expect that a better solution exists, that expands enough of the paths to clarify the error, without expanding constraints that are not related to the type error. One thing you might try to play with is the -short-paths options, that tries to print shorter types (but is also possibly less predictable); it can expand more if that can result in showing a shorter path, so for types that are synonyms of existing paths plus constraints it might result in constraint expansion. (I suspect it will not solve your problem, but that it may be of interest to other people with unclear type error messages.) On Thu, Jun 2, 2016 at 3:18 PM, Carette, Jacques wrote: > In writing some code which uses a lot of monads with underlying types which > use constraints, even simple errors can lead to extremely hard to read error > messages. The main reason is that the two types given in errors are > partially expanded, to different levels. This frequently means that the > part where the type checker detects a mismatch is (extremely) opaque to > human eyes. > > In that case, it would actually be preferable to fully expand the types. > Yes, that will produce wallpaper. But at least the mismatch should be > considerably easier to catch. > > Does this already exist, or should I submit a feature request? > > Jacques 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 574E87FDEE for ; Thu, 2 Jun 2016 21:50:48 +0200 (CEST) IronPort-PHdr: 9a23:6OhzYR8FcB7Jz/9uRHKM819IXTAuvvDOBiVQ1KB80+0cTK2v8tzYMVDF4r011RmSDdSdtqMP0rGK+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuSt+U0pX8jrvus7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjMD39DwrRTIUSeI43IdVC1WzksJUED560TVV53rsyb+/tF22CSAMNe+Gb89Uy6j4qMtUxTohT0KLRY29WjWjop7i6cN8zy7oBkq8ofOZ4fdEft4ZaDMNYcLQGtHRcVAfy5IBI6nc5ECAvZHNuFd+dqu72ASpAezUFH/TNjkzSVF0zqrhKA= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout3.mail.janestreet.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; 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@mxout3.mail.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout3.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUAwC6jVBXduXIaSZehBB9BqlHhQyLb4F5IoVwAoEsBzoSAQEBAQEBAQERAQoWCVCCMIIWAQEEEhEdAQEsCwEPCwsNAgIJHQICIQESAQUBChIGEwgKCQeHcwMXAwujSIExPjGKVGeEQQEBBYg7AwqEHwEBAQEBAQEBAgEBAQEBAQEBFwgQcYUmhE2CQ4R+glkBhkUMkTczhgCGJ4F5gWlOhy2FOIdkhikSHoEPJAGCKYIQUop8AQEB X-IPAS-Result: A0AUAwC6jVBXduXIaSZehBB9BqlHhQyLb4F5IoVwAoEsBzoSAQEBAQEBAQERAQoWCVCCMIIWAQEEEhEdAQEsCwEPCwsNAgIJHQICIQESAQUBChIGEwgKCQeHcwMXAwujSIExPjGKVGeEQQEBBYg7AwqEHwEBAQEBAQEBAgEBAQEBAQEBFwgQcYUmhE2CQ4R+glkBhkUMkTczhgCGJ4F5gWlOhy2FOIdkhikSHoEPJAGCKYIQUop8AQEB X-IronPort-AV: E=Sophos;i="5.26,407,1459807200"; d="scan'208";a="179946813" Received: from mxout3.mail.janestreet.com ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 21:50:28 +0200 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout3.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1b8YdP-0006uv-FQ for caml-list@inria.fr; Thu, 02 Jun 2016 15:50:27 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BXUI4D-AAACoJ-Nb; 2016-06-02 15:50:27.430513-04:00 Received: from mail-vk0-f71.google.com ([209.85.213.71]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1b8YdP-0002Tt-BK for caml-list@inria.fr; Thu, 02 Jun 2016 15:50:27 -0400 Received: by mail-vk0-f71.google.com with SMTP id t7so153445064vkf.2 for ; Thu, 02 Jun 2016 12:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xaeMWjj4EO2deeD3sS/F+n+W+VrcFrjJjtL1cuuwKWA=; b=C2brBFcf0qZFUqAkjyqvUftPmatO3TcAKTwMAEhOpnjMjS9ZTHslFqUUUo3CsGAoKU BBkSNB2NvBhYQAQgk3YYCaohS0REd8mm+FT6B6kzmGLFMtuuZlcuLJnGksbbzAAlzWcN aDnbvqDpGZBiqrI3sJlmq7xN26CyOpAlwvljQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xaeMWjj4EO2deeD3sS/F+n+W+VrcFrjJjtL1cuuwKWA=; b=OaQLJYONA9VuDTamA5oeAhdvu5aC/QJpqEr42TIpzdDOV0vYMMod4ExsEkPoQEJcRq FZ+iZEGJS3PHZwLM5zrYiBTh9e0RKbJUNHM0PG+cb0vzvABLAljFWzUa9s8puUMiBJLD 3gkAwU7IAyFRDgOGY3zPDm6Ynu67IaB+UGjRQsnlH2gCBzNeYdX93RINziTzBEGnkyKs TQcnUO/qB1YDm6mQlN78tcozF3ZhZW9dScV1f2jfeCTU4f24TQJKc6gqebYZhf/tLeUQ C9mngLZH+7MfutcZwOYihHmEstmuTj8FypW4UaqTjbzzYEcNOv0U7jCZkm2lPZ4iEEaK cGJA== X-Gm-Message-State: ALyK8tKIWFmEIyYcbjJ10MuxTIkAUZEbnzX73UJvmule4jDwhukONsrG2FadcJJ7jvF2zmoKREXE5GwisyR8CGhOyWTm9bBsA1Go1hjxamYQkozhKXIq7cSiSaiEVUWG+SZtElWujhw3t7z/QwDJsKY+4SpJSv7VrM9w/QqhtD8= X-Received: by 10.129.86.139 with SMTP id k133mr7023359ywb.96.1464897027045; Thu, 02 Jun 2016 12:50:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.86.139 with SMTP id k133mr7023351ywb.96.1464897026837; Thu, 02 Jun 2016 12:50:26 -0700 (PDT) Received: by 10.37.217.75 with HTTP; Thu, 2 Jun 2016 12:50:26 -0700 (PDT) In-Reply-To: References:

Date: Thu, 2 Jun 2016 15:50:26 -0400 Message-ID: From:Yaron Minsky To:Gabriel Scherer Cc:"Carette, Jacques" , "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Option to fully expand types in error messages? Have you tired using the short-paths flag? This doesn't completely expand the types, but it does a good job of picking the "right" type: the heuristic is (roughly) to pick the type alias with the fewest number of dots, and amongst those, pick the one defined most recently. It tends to make type errors quite a lot better, but I admit I'm not sure it would help in the case you describe. y On Thu, Jun 2, 2016 at 3:44 PM, Gabriel Scherer wrote: > This does not exist to my knowledge. I think that in a bug report, it > would be interesting if you could include some reproducible code and > an example of the error messages that are not readable. I would expect > that a better solution exists, that expands enough of the paths to > clarify the error, without expanding constraints that are not related > to the type error. > > One thing you might try to play with is the -short-paths options, that > tries to print shorter types (but is also possibly less predictable); > it can expand more if that can result in showing a shorter path, so > for types that are synonyms of existing paths plus constraints it > might result in constraint expansion. (I suspect it will not solve > your problem, but that it may be of interest to other people with > unclear type error messages.) > > On Thu, Jun 2, 2016 at 3:18 PM, Carette, Jacques wrote: >> In writing some code which uses a lot of monads with underlying types which >> use constraints, even simple errors can lead to extremely hard to read error >> messages. The main reason is that the two types given in errors are >> partially expanded, to different levels. This frequently means that the >> part where the type checker detects a mismatch is (extremely) opaque to >> human eyes. >> >> In that case, it would actually be preferable to fully expand the types. >> Yes, that will produce wallpaper. But at least the mismatch should be >> considerably easier to catch. >> >> Does this already exist, or should I submit a feature request? >> >> Jacques > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs 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 19F8A7FDEE for ; Thu, 2 Jun 2016 23:59:32 +0200 (CEST) IronPort-PHdr: 9a23:rvJsJhdOABz9S+0f5or4FFTIlGMj4u6mDksu8pMizoh2WeGdxc+4bB7h7PlgxGXEQZ/co6odzbGG4ua+ACdYu96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDjvcOKKF0SzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IeezAcq85Vb1VCig9eyBwvZWz9EqLcQza13IGVWNetxtOGAvUpEXrW5b3qSjrnuh03iSBIdf7QKxyUjOnueMjZxbikiYKM3YC+2HakMFqxPZUqRi7phF7hZXfYIyPOeBWcabUfNdcTm1ECJV/TStEV8mXZpECE/YMea56poLkulYV51PqDgC2Cf/zxxdNjXr/xrE3yaIqGFeVj0QbA9sSvSGM/53OP6AIXLXwlfGQwA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=carette@mcmaster.ca; spf=None smtp.mailfrom=carette@mcmaster.ca; spf=None smtp.helo=postmaster@FHSHC2D11-2.csu.mcmaster.ca Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=pra; client-ip=130.113.22.2; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=mailfrom; client-ip=130.113.22.2; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@FHSHC2D11-2.csu.mcmaster.ca) identity=helo; client-ip=130.113.22.2; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="postmaster@FHSHC2D11-2.csu.mcmaster.ca"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DbAgAtq1BXfgIWcYJegw6CBbpCgXmGEgKBNjoSAQEBAQEBAQERAQELCwkJIS9BEgGBXIIWAQEEOj8QAgEIDhQUEDIlAQEEAQ0NiCcBwnYBAQEBAQUBAQEBAQEBAQEeinSEQoMqgi4FmDEGAY9yAY1Ij0wlBYIxHIFLhg2EXgF+AQEB X-IPAS-Result: A0DbAgAtq1BXfgIWcYJegw6CBbpCgXmGEgKBNjoSAQEBAQEBAQERAQELCwkJIS9BEgGBXIIWAQEEOj8QAgEIDhQUEDIlAQEEAQ0NiCcBwnYBAQEBAQUBAQEBAQEBAQEeinSEQoMqgi4FmDEGAY9yAY1Ij0wlBYIxHIFLhg2EXgF+AQEB X-IronPort-AV: E=Sophos;i="5.26,408,1459807200"; d="scan'208";a="220883578" Received: from fhshc2d11-2.csu.mcmaster.ca ([130.113.22.2]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 02 Jun 2016 23:59:31 +0200 Received: from FHSDB2D11-2.csu.mcmaster.ca ([fe80::2924:2ca:3cbc:4521]) by FHSHC2D11-2.csu.mcmaster.ca ([2002:8271:1602::8271:1602]) with mapi id 14.03.0279.002; Thu, 2 Jun 2016 17:59:29 -0400 From: "Carette, Jacques" To: Yaron Minsky , Gabriel Scherer CC: "caml-list@inria.fr" Thread-Topic: [Caml-list] Option to fully expand types in error messages? Thread-Index: AdG9A5GLssEk6Qd8TUiu0LqSgShZcwAJSpkAAAAzQwD//+CiRg== Date: Thu, 2 Jun 2016 21:59:28 +0000 Message-ID: References:

, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.113.22.227] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22366.005 x-tm-as-result: No--31.039900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [Caml-list] Option to fully expand types in error messages? I will try the ``short-paths'' flag and report back. We're also trying to = produce a reasonably-sized self-contained example. (I did not know about short-paths, so that is definitely worth a try) Jacques= 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 A4F887FDEE for ; Fri, 3 Jun 2016 01:59:19 +0200 (CEST) IronPort-PHdr: 9a23:vNBpWBaZtUnu8TEFfg+jygT/LSx+4OfEezUN459isYplN5qZpcW6bnLW6fgltlLVR4KTs6sC0LqH9f65EjRaqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7H0pcSYO18ArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6t73AFT2gN2jFBGQXZ8ByyCpz4qCbmqudV3SKfNNbqQKpyUj30vIlxTxq9qi4MLiM06yn4g9Zqja1GrVr1qBVl2Y/bfYy9MfNifuXbdNwdVGMEQ4BYXGpDGtXvPMM0E+MdMLMA/MHGrFwUoE77XFH0CQ== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=garrigue@math.nagoya-u.ac.jp; spf=None smtp.mailfrom=garrigue@math.nagoya-u.ac.jp; spf=None smtp.helo=postmaster@mailhost.math.nagoya-u.ac.jp Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtAAATyFBXfQWCBoVehQ26SoF5hhICgWwUAQEBAQEBAQERAQELFgdQgjCCFgEBBEADATUBAQ4LGBwSVwaIQbBDhSgHAokPg1sBAQEBAQEEAQEBAQEBAQEWAQiIHoJWhECDLIIujl2JYI4ggWmHe4U4j0wehDNfinwBAQE X-IPAS-Result: A0CtAAATyFBXfQWCBoVehQ26SoF5hhICgWwUAQEBAQEBAQERAQELFgdQgjCCFgEBBEADATUBAQ4LGBwSVwaIQbBDhSgHAokPg1sBAQEBAQEEAQEBAQEBAQEWAQiIHoJWhECDLIIujl2JYI4ggWmHe4U4j0wehDNfinwBAQE X-IronPort-AV: E=Sophos;i="5.26,409,1459807200"; d="scan'208";a="179962161" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Jun 2016 01:59:13 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 4A94763EB for ; Fri, 3 Jun 2016 08:59:11 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (rabbit-172.math.nagoya-u.ac.jp [172.16.254.254]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 9802F24E3; Fri, 3 Jun 2016 08:59:10 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=73f7Q03mOtM0szaW0oD9aXaa+gc=; b=siZnb1hhFzdZ1FU2D/DT11iTFlSP N/EQ+4cAeo3VTg4hRSXrT/3xVF8CgkGSU/d9L9Um2GnsfDlZ2XMapShdvt0QiHWQ 51/cL4B/yzFJpV38KHM88mkw9sRiPmDobW/BoS70Apvk6w5ICDqCB/Unp3kWtLZe vyzBbR2HVQRO0wk= DomainKey-Signature: a=rsa-sha1; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=yKnTzdnjeeRjDAp+KpPnvZ6gG6swwNy1s0defBfUlrQ0lYuKDODgRj0r+ZUgUUTabcNEj07SWyO7b07+80XSXVIZtXMYTEglUJ62Xt6nDOWfeoQhDtil5NZTL6CgLLxHTyfmT5hNC2+wILfqi4QbF/oWExPqXcnaIs78uj1KCa8=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 918936BEA; Fri, 3 Jun 2016 08:56:15 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Jacques Garrigue In-Reply-To: Date: Fri, 3 Jun 2016 08:59:20 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jacques Carette X-Mailer: Apple Mail (2.3124) Subject: Re: [Caml-list] Option to fully expand types in error messages? On 2016/06/03 04:18, "Carette, Jacques" wrote: >=20 > In writing some code which uses a lot of monads with underlying types whi= ch use constraints, even simple errors can lead to extremely hard to read e= rror messages. The main reason is that the two types given in errors are p= artially expanded, to different levels. This frequently means that the par= t where the type checker detects a mismatch is (extremely) opaque to human = eyes. >=20 > In that case, it would actually be preferable to fully expand the types. = Yes, that will produce wallpaper. But at least the mismatch should be con= siderably easier to catch. >=20 > Does this already exist, or should I submit a feature request? >=20 > Jacques In the error message, types are expanded just enough to get down to the con= flict. If the conflict is not visible at that point, this is probably a scoping er= ror (and there should be an extra line stating that); otherwise this should be seen as a bug. As Yaron pointed, -short-paths can help by at least giving a normal form fo= r paths (which may not be the expansion, but should be unique in the error = context). But it will not expand a type if the expansion is not a type cons= tructor, or if the parameters are different. Jacques= 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 139C27FE36 for ; Fri, 3 Jun 2016 17:42:26 +0200 (CEST) IronPort-PHdr: 9a23:hKp4Dh2VtOqh6N+PsmDT+DRfVm0co7zxezQtwd8ZsegfKfad9pjvdHbS+e9qxAeQG96LurQa0KGG4ujJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6DyZrsnLDjs7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+lxDIVBaC/TMzW38MkxVVDkCR4xjgRJb+rybSs+Nh2G+cNMLxXLlxRHKr5OFpUEm7pj0AMmtz22jNh9BsgeYTghuqvgFy2MScNIqcLvdiYq71eNgfTHFdU9wXXCUXUdD0VJcGE+dUZbUQlIL6vVZb6ELmXQQ= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=carette@mcmaster.ca; spf=None smtp.mailfrom=carette@mcmaster.ca; spf=None smtp.helo=postmaster@FHSHC4H16-2.csu.mcmaster.ca Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=pra; client-ip=130.113.22.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=mailfrom; client-ip=130.113.22.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@FHSHC4H16-2.csu.mcmaster.ca) identity=helo; client-ip=130.113.22.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="postmaster@FHSHC4H16-2.csu.mcmaster.ca"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C1AACgpFFXfgQWcYJbDoMAgQJ9BrpUgXkahXgCgTc4FAEBAQEBAQEBEQEBCwsJCSEvgjCCFQEBAQQnRwsQAgEIEQQBAQEKJAIwHQgBAQQOBQgGiCEBwm0BAQEBAQEBAQEBAQEBAQEBAQEBAQEODop0hEIVJ4Jugi4FmD8GAYMsgWltigpOhy2FOI9SHoNpO26JEwF+AQEB X-IPAS-Result: A0C1AACgpFFXfgQWcYJbDoMAgQJ9BrpUgXkahXgCgTc4FAEBAQEBAQEBEQEBCwsJCSEvgjCCFQEBAQQnRwsQAgEIEQQBAQEKJAIwHQgBAQQOBQgGiCEBwm0BAQEBAQEBAQEBAQEBAQEBAQEBAQEODop0hEIVJ4Jugi4FmD8GAYMsgWltigpOhy2FOI9SHoNpO26JEwF+AQEB X-IronPort-AV: E=Sophos;i="5.26,412,1459807200"; d="ml'?scan'208";a="221017562" Received: from fhshc4h16-2.csu.mcmaster.ca ([130.113.22.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 03 Jun 2016 17:42:24 +0200 Received: from FHSDB2D11-2.csu.mcmaster.ca ([fe80::2924:2ca:3cbc:4521]) by FHSHC4H16-2.csu.mcmaster.ca ([2002:8271:1604::8271:1604]) with mapi id 14.03.0279.002; Fri, 3 Jun 2016 11:42:22 -0400 From: "Carette, Jacques" To: Jacques Garrigue CC: OCaML List Mailing Thread-Topic: [Caml-list] Option to fully expand types in error messages? Thread-Index: AdG9A5GLssEk6Qd8TUiu0LqSgShZcwASLzMAABhpMFM= Date: Fri, 3 Jun 2016 15:42:22 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.113.22.227] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22370.000 x-tm-as-result: No--44.024500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_F7B18907EEED5244A3608C61DF32A4E410D5B39AFHSDB2D112csumc_" MIME-Version: 1.0 Subject: RE: [Caml-list] Option to fully expand types in error messages? --_002_F7B18907EEED5244A3608C61DF32A4E410D5B39AFHSDB2D112csumc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So here is an actual example. The error I get is ocamlc -short-paths -c reproduce.ml=20 File "reproduce.ml", line 148, characters 21-25: Error: Signature mismatch: ... Values do not match: val traverseexercise : 'a container PseudoCode.abstract -> ('a PseudoCode.abstract -> 'b PseudoCode.abstract -> ('c * 'b) PseudoCode.abstract) -> 'b PseudoCode.abstract -> 'd container -> ('d container -> 'c container PseudoCode.abstract -> 'e) -> 'e is not included in val traverseexercise : loopdata container PseudoCode.abstract -> (loopdata PseudoCode.abstract -> loopdata PseudoCode.abstract -> (loopdata * loopdata) PseudoCode.abstract) -> loopdata PseudoCode.abstract -> (< answer : 'a; state : 'b; .. >, loopdata) PseudoCode.cmonad File "reproduce.ml", line 111, characters 6-206: Expected declaration File "reproduce.ml", line 125, characters 8-24: Actual declaration I can't tell from the above error what the actual cause is. The full code = is attached. [This code is quite reduced already. It is kept at this size= to show in more detail the kinds of errors we're seeing.] Any 'hint' from OCaml as to the precise nature of the non-match would sure = be appreciated. Jacques ________________________________________ From: Jacques Garrigue [garrigue@math.nagoya-u.ac.jp] Sent: June 2, 2016 19:59 To: Carette, Jacques Cc: OCaML List Mailing Subject: Re: [Caml-list] Option to fully expand types in error messages? On 2016/06/03 04:18, "Carette, Jacques" wrote: > > In writing some code which uses a lot of monads with underlying types whi= ch use constraints, even simple errors can lead to extremely hard to read e= rror messages. The main reason is that the two types given in errors are p= artially expanded, to different levels. This frequently means that the par= t where the type checker detects a mismatch is (extremely) opaque to human = eyes. > > In that case, it would actually be preferable to fully expand the types. = Yes, that will produce wallpaper. But at least the mismatch should be con= siderably easier to catch. > > Does this already exist, or should I submit a feature request? > > Jacques In the error message, types are expanded just enough to get down to the con= flict. If the conflict is not visible at that point, this is probably a scoping er= ror (and there should be an extra line stating that); otherwise this should be seen as a bug. As Yaron pointed, -short-paths can help by at least giving a normal form fo= r paths (which may not be the expansion, but should be unique in the error = context). But it will not expand a type if the expansion is not a type cons= tructor, or if the parameters are different. Jacques --_002_F7B18907EEED5244A3608C61DF32A4E410D5B39AFHSDB2D112csumc_ Content-Type: application/octet-stream; name="reproduce.ml" Content-Description: reproduce.ml Content-Disposition: attachment; filename="reproduce.ml"; size=4358; creation-date="Fri, 03 Jun 2016 15:42:00 GMT"; modification-date="Fri, 03 Jun 2016 15:42:00 GMT" Content-Transfer-Encoding: base64 dHlwZSAoJ3AsJ3YpIG1vbmFkID0gJ3MgLT4gKCdzIC0+ICd2IC0+ICd3KSAt PiAndw0KICBjb25zdHJhaW50ICdwID0gPHN0YXRlIDogJ3M7IGFuc3dlciA6 ICd3OyAuLj4NCg0KbGV0IHJldCAoYSA6J3YpIDogKCdwLCd2KSBtb25hZCA9 IGZ1biBzIGsgLT4gayBzIGENCg0KbGV0IChsZXQhKSAobSA6ICgncCwndikg bW9uYWQpIChmIDogJ3YgLT4gKCdwLCd1KSBtb25hZCkgOiAoJ3AsJ3UpIG1v bmFkDQogID0gZnVuIHMgayAtPiBtIHMgKGZ1biBzJyBiIC0+IGYgYiBzJyBr KQ0KDQpsZXQgazAgXyB2ID0gdg0KDQptb2R1bGUgdHlwZSBUID0gc2lnDQog IHR5cGUgJ2IgYWJzdHJhY3QNCg0KICB0eXBlICgncGMsJ3ApIGNtb25hZF9j b25zdHJhaW50ID0gdW5pdA0KICAgIGNvbnN0cmFpbnQNCiAgICAgICdwID0g PHN0YXRlIDogJ3MgbGlzdDsgYW5zd2VyIDogJ3cgYWJzdHJhY3Q+DQogICAg Y29uc3RyYWludA0KICAgICAgJ3BjID0gPGFuc3dlciA6ICd3OyBzdGF0ZSA6 ICdzOyAuLj4NCg0KICB0eXBlICgncGMsJ3YpIGNtb25hZCA9ICgncCwgJ3Yg YWJzdHJhY3QpIG1vbmFkDQogICAgY29uc3RyYWludCBfID0gKCdwYywncCkg Y21vbmFkX2NvbnN0cmFpbnQNCg0KICB2YWwgZ2VucmVjbG9vcCA6DQogICAg KCgnYiAtPiAnYykgYWJzdHJhY3QgLT4NCiAgICAnYiBhYnN0cmFjdCAtPiAn ZCAtPiAoJ2UgLT4gJ2MgYWJzdHJhY3QgLT4gJ2MgYWJzdHJhY3QpIC0+ICdj IGFic3RyYWN0KSAtPg0KICAgICdiIGFic3RyYWN0IC0+ICdkIC0+ICgnZCAt PiAnYyBhYnN0cmFjdCAtPiAnZykgLT4gJ2cNCiAgdmFsIGFwcGx5TSA6DQog ICAgKCdiIC0+ICdjKSBhYnN0cmFjdCAtPiAnYiBhYnN0cmFjdCAtPiAnZCAt PiAoJ2QgLT4gJ2MgYWJzdHJhY3QgLT4gJ2UpIC0+ICdlDQogIG1vZHVsZSBQ YWlyIDoNCiAgICBzaWcNCiAgICAgIHZhbCB1bnBhaXIgOiAoJ2IgKiAnYykg YWJzdHJhY3QgLT4gJ2IgYWJzdHJhY3QgKiAnYyBhYnN0cmFjdA0KICAgIGVu ZA0KICBtb2R1bGUgSWR4IDoNCiAgICBzaWcNCiAgICAgIHZhbCB6ZXJvIDog aW50IGFic3RyYWN0DQogICAgICB2YWwgc3VjYyA6IGludCBhYnN0cmFjdCAt PiBpbnQgYWJzdHJhY3QNCiAgICBlbmQNCiAgbW9kdWxlIFR1cGxlIDoNCiAg ICBzaWcNCiAgICAgIHZhbCB0dXAyIDogJ2IgYWJzdHJhY3QgLT4gJ2MgYWJz dHJhY3QgLT4gKCdiICogJ2MpIGFic3RyYWN0DQogICAgZW5kDQogIG1vZHVs ZSBDTGlzdCA6DQogICAgc2lnDQogICAgICB2YWwgbmlsIDogJ2IgbGlzdCBh YnN0cmFjdA0KICAgICAgdmFsIGNvbnMgOiAnYiBhYnN0cmFjdCAtPiAnYiBs aXN0IGFic3RyYWN0IC0+ICdiIGxpc3QgYWJzdHJhY3QNCiAgICAgIHZhbCBt YXRjaExpc3RNIDoNCiAgICAgICAgJ2IgbGlzdCBhYnN0cmFjdCAtPg0KICAg ICAgICAoJ3AsICdjKSBjbW9uYWQgLT4NCiAgICAgICAgKCdiIGFic3RyYWN0 IC0+ICdiIGxpc3QgYWJzdHJhY3QgLT4gKCdwLCAnYykgY21vbmFkKSAtPg0K ICAgICAgICAoJ3AsICdjKSBjbW9uYWQNCiAgICBlbmQNCmVuZA0KDQptb2R1 bGUgUHNldWRvQ29kZSA9IHN0cnVjdA0KDQogIHR5cGUgJ2IgYWJzdHJhY3Qg PSB1bml0IC0+ICdiDQoNCiAgdHlwZSAoJ3BjLCdwKSBjbW9uYWRfY29uc3Ry YWludCA9IHVuaXQNCiAgICBjb25zdHJhaW50DQogICAgICAncCA9IDxzdGF0 ZSA6ICdzIGxpc3Q7IGFuc3dlciA6ICd3IGFic3RyYWN0Pg0KICAgIGNvbnN0 cmFpbnQNCiAgICAgICdwYyA9IDxhbnN3ZXIgOiAndzsgc3RhdGUgOiAnczsg Li4+DQoNCiAgdHlwZSAoJ3BjLCd2KSBjbW9uYWQgPSAoJ3AsICd2IGFic3Ry YWN0KSBtb25hZA0KICAgIGNvbnN0cmFpbnQgXyA9ICgncGMsJ3ApIGNtb25h ZF9jb25zdHJhaW50DQogIGxldCBnZW5yZWNsb29wIGdlbiBydGFyZyA9IGZ1 biBzIGsgLT4gayBzDQogICAgKGZ1biAoKSAtPiBsZXQgcmVjIGxvb3AgaiA9 IGdlbiAoZnVuICgpIC0+IGxvb3ApIChmdW4gKCkgLT4gaikgcyBrMCAoKSBp bg0KICAgIGxvb3AgKHJ0YXJnICgpKSkNCiAgbGV0IGFwcGx5ICBmIHggPSBm dW4gKCkgLT4gKGYgKCkpICh4ICgpKQ0KICBsZXQgYXBwbHlNICBmIHggPSBy ZXQgKGFwcGx5IGYgeCkNCiAgbW9kdWxlIFBhaXIgPSBzdHJ1Y3QNCiAgKCog VG8gYmUgYWJsZSB0byBkZWNvbnN0cnVjdCBwYWlycyBpbiBtb25hZGljIGNv ZGU6DQogICAgcGVyZm9ybSAoYSxiKSA8LS0gcmV0ICh1bnBhaXIgcHYpICop DQogICAgbGV0IHVucGFpciB4ID0gKChmdW4gKCkgLT4gZnN0ICh4ICgpKSks IGZ1biAoKSAtPiBzbmQgKHggKCkpKQ0KICAgIGxldCBmc3QgeCA9IChmdW4g KCkgLT4gZnN0ICh4ICgpKSkNCiAgICBsZXQgc25kIHggPSAoZnVuICgpIC0+ IHNuZCAoeCAoKSkpDQogIGVuZA0KDQogIG1vZHVsZSBJZHggPSBzdHJ1Y3QN CiAgICBsZXQgemVybyA9IGZ1biAoKSAtPiAwDQogICAgbGV0IHN1Y2MgYSA9 IGZ1biAoKSAtPiAoYSAoKSkgKyAxDQogIGVuZA0KICBtb2R1bGUgVHVwbGUg PSBzdHJ1Y3QNCiAgICBsZXQgdHVwMiBhIGIgPSBmdW4gKCkgLT4gKCAoYSAo KSksIChiICgpKSApDQogIGVuZA0KICBtb2R1bGUgQ0xpc3QgPSBzdHJ1Y3QN CiAgICBsZXQgbmlsID0gZnVuICgpIC0+IFtdDQogICAgbGV0IGNvbnMgYSBi ID0gZnVuICgpIC0+IChhICgpKSA6OiAoYiAoKSkNCiAgICBsZXQgbWF0Y2hM aXN0TSBsIGVtcHR5IG5vbmVtcHR5ID0gZnVuIHMgayAtPiAoZnVuICgpIC0+ DQogICAgICBtYXRjaCBsICgpIHdpdGgNCiAgICAgICAgfCBbXSAgIC0+IGVt cHR5IHMgayAoKQ0KICAgICAgICB8IGg6OnQgLT4gbm9uZW1wdHkgKGZ1biAo KSAtPiBoKSAoZnVuICgpIC0+IHQpIHMgayAoKSkNCiAgZW5kDQplbmQNCg0K bW9kdWxlIHR5cGUgVmFsdWUgPSBzaWcNCiAgdHlwZSB2YWx1ZQ0KZW5kDQoN Cm1vZHVsZSBJbnRWID0gc3RydWN0DQogIHR5cGUgdmFsdWUgPSBpbnQNCmVu ZA0KDQptb2R1bGUgVHJhdmVyc2UgKENPREU6IFQpID0gc3RydWN0DQogIG9w ZW4gQ09ERQ0KDQogIG1vZHVsZSBDb250YWluZXJMaWIgKFY6VmFsdWUpIChM OlZhbHVlKSA9IHN0cnVjdA0KICAgIG1vZHVsZSB0eXBlIFNpZyA9IHNpZw0K ICAgICAgdHlwZSB2YWx1ZSA9IFYudmFsdWUNCiAgICAgIHR5cGUgJ2EgY29u dGFpbmVyDQogICAgICB0eXBlIGVsdGRlc2MNCiAgICAgIHR5cGUgbG9vcGRh dGEgPSBMLnZhbHVlDQogICAgICB2YWwgdHJhdmVyc2VleGVyY2lzZSA6DQog ICAgICAgIHZhbHVlIGNvbnRhaW5lciBhYnN0cmFjdCAtPg0KICAgICAgICAo ZWx0ZGVzYyBhYnN0cmFjdCAtPiBsb29wZGF0YSBhYnN0cmFjdCAtPiAodmFs dWUgKiBsb29wZGF0YSkgYWJzdHJhY3QpIC0+DQogICAgICAgIGxvb3BkYXRh IGFic3RyYWN0IC0+DQooKiAgICAgICAgICgnYSwgdmFsdWUgY29udGFpbmVy KSBjbW9uYWQgKikNCiAgICAgICAgKCdhLCB2YWx1ZSkgY21vbmFkDQogICAg ZW5kDQogIGVuZA0KDQogIG1vZHVsZSBMaXN0Q29udGFpbmVyTGliIChWIDog VmFsdWUpIChMIDogVmFsdWUpID0gc3RydWN0DQogICAgdHlwZSB2YWx1ZSA9 IFYudmFsdWUNCiAgICB0eXBlICdhIGNvbnRhaW5lciA9ICdhIGxpc3QNCiAg ICB0eXBlIGVsdGRlc2MgPSB2YWx1ZQ0KICAgIHR5cGUgbG9vcGRhdGEgPSBM LnZhbHVlDQoNCiAgICBsZXQgdHJhdmVyc2VleGVyY2lzZSBsc3QgZiBkYXRh ICA9DQogICAgICBsZXQgZ2VuIHNlbGYgdHVwID0NCiAgICAgIGxldCAobHN0 LCBpKSA9IFBhaXIudW5wYWlyIHR1cCBpbg0KICAgICAgQ0xpc3QubWF0Y2hM aXN0TSBsc3QNCiAgICAgICAgKHJldCBDTGlzdC5uaWwpDQogICAgICAgIChm dW4gaCB0IC0+DQogICAgICAgIGxldCAodiwgaTIpID0gUGFpci51bnBhaXIg KGYgKGgpIGkpIGluDQogICAgICAgIGxldCEgciA9IChhcHBseU0gc2VsZiAo VHVwbGUudHVwMiB0IGkyKSkgaW4NCiAgICAgICAgcmV0IChDTGlzdC5jb25z IHYgcikpDQogICAgICBpbiBnZW5yZWNsb29wIGdlbiAoVHVwbGUudHVwMiBs c3QgZGF0YSkNCiAgZW5kDQoNCiAgbW9kdWxlIEV4IChDb250YWluZXIgOiBD b250YWluZXJMaWIgKEludFYpIChJbnRWKS5TaWcpID0gc3RydWN0DQogICAg bGV0IHRyYXZlcnNlZXhlcmNpc2UgY29udGFpbmVyID0NCiAgICAgIGxldCBi b2R5ID0gZnVuIF8gbiAtPiBUdXBsZS50dXAyIG4gKElkeC5zdWNjIG4pIGlu DQogICAgICBDb250YWluZXIudHJhdmVyc2VleGVyY2lzZSBjb250YWluZXIg Ym9keSBJZHguemVybw0KICBlbmQNCg0KZW5kDQoNCm1vZHVsZSBUZXN0ID0g c3RydWN0DQogIG1vZHVsZSBUQyA9IFRyYXZlcnNlKFBzZXVkb0NvZGUpDQog IG1vZHVsZSBMQ0lJID0gVEMuTGlzdENvbnRhaW5lckxpYiAoSW50VikgKElu dFYpDQogIG1vZHVsZSBMVCA9IFRDLkV4IChMQ0lJKQ0KZW5kDQo= --_002_F7B18907EEED5244A3608C61DF32A4E410D5B39AFHSDB2D112csumc_-- 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 097D17FE36 for ; Fri, 3 Jun 2016 17:50:19 +0200 (CEST) IronPort-PHdr: 9a23:L6wmQBLlNzTq4W0wkNmcpTZWNBhigK39O0sv0rFitYgVKv7xwZ3uMQTl6Ol3ixeRBMOAu6MC1bGd4vqocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC3oLpjKvjodX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm0vb2rgHORhej4X4VU2Ne0kYZQluN0BavFLz4qCbmquc5kAuTNtTrQKt+EWCp5r1mVAPloCIMMjci7GzNzMd52vF1uhWk8i122YnSKKSUMuF9b+uJbNYbQ3FCT+5TXipMGZ+mYoYTSeEGOLAL/MHGu1ISoE7mVkGXD+T1x2oN2yb7 Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout3.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; 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@mxout3.mail.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout3.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQAOplFXc+XIaSZchBB9BqlOKotfhH2BeSKFcAKBMAc4FAEBAQEBAQEBEQEKFglQgjCCFQEBAQMBEhEEGQEBLAsBBAsJAgsGBAEBAQ0dAgIiEgEFAQoKCAYTEhCHcwMPCAMLlAyPQoExPjGKVGeEQQEBBYg/A4QpAQEBAQEBAQEBAQEBAQEBAQEBAQEBFAgQhheETYRtglSCWQGGRgyRd4YDiCGBaU6HLYU4jhMSHoEPDw+CMIIQUooSAQEB X-IPAS-Result: A0D1AQAOplFXc+XIaSZchBB9BqlOKotfhH2BeSKFcAKBMAc4FAEBAQEBAQEBEQEKFglQgjCCFQEBAQMBEhEEGQEBLAsBBAsJAgsGBAEBAQ0dAgIiEgEFAQoKCAYTEhCHcwMPCAMLlAyPQoExPjGKVGeEQQEBBYg/A4QpAQEBAQEBAQEBAQEBAQEBAQEBAQEBFAgQhheETYRtglSCWQGGRgyRd4YDiCGBaU6HLYU4jhMSHoEPDw+CMIIQUooSAQEB X-IronPort-AV: E=Sophos;i="5.26,412,1459807200"; d="scan'208,217";a="221019246" Received: from mxout3.mail.janestreet.com ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2016 17:50:17 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout3.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1b8rMW-0000JM-JN for caml-list@inria.fr; Fri, 03 Jun 2016 11:50:16 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BXUac4-AAAE2F-Ri; 2016-06-03 11:50:16.562402-04:00 Received: from mail-qg0-f70.google.com ([209.85.192.70]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1b8rMW-0003Ct-Fo for caml-list@inria.fr; Fri, 03 Jun 2016 11:50:16 -0400 Received: by mail-qg0-f70.google.com with SMTP id p34so51654729qgp.3 for ; Fri, 03 Jun 2016 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FZsvebllC8rDm+pZSlropTslcoBnQoay7NtftmpvXUc=; b=ExH1Ts/z1bXdN5nU6NKzu5aXdg04Vgy+0cwYNdAjMDuoDIUiLh44oFRjg6oCqwohfT kH15b0BfO3rYs4QcMfsI8ymuLgd3fMTVgCacRL8EfJmDSY7AS+cmQX13uRNLd6z2sVKI O+WjbA30jq8zuLGukts5gEA5p9NhZBRgEibrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FZsvebllC8rDm+pZSlropTslcoBnQoay7NtftmpvXUc=; b=AANoFJQMxO5ZhxwZ3cYMujip1O+ZOesmMHjnbDbWb+XVfZuHLzGFze/79WY0O8bo9m ods60UVc1/htxKzLkrpuMJbYK0Z1MBgMLswV/KoUYJT5fd7BxbcsdCQN4rHp3JUNoYgt q4K0RU/c+97mYgxChf3xxtnInk+rtclSSeukfIdfbw+nupTVWt+tMbZqz9ksg9NAkyxg DxfY/ddDRI5kFHfS+EwdwRHIO6E9P90p+SnXSEhirBAQoa4fTDbjtH4TBiQXPftmstxz 3xSFv5YMVSlGW1zS8r4XqRpKfjTX9xJi33t3nIwas72KoIAFnkL4/ibSPLcyr5AJAVRu +O4A== X-Gm-Message-State: ALyK8tI3we/enGCwa5N2RhhwxbO6BMlsWCUBkFvAieZuBkgwdOfZuI/rGgdcM7uTY3D6yNGrF7K20wuGEez1RrjB4WZozaoQH5YRya6Q60nI+jXY35sekIfOn8Hfr/IEVnjY4mXiobutQIdW40dOqHlqon8y1Q0sRjwc1zx4sJU= X-Received: by 10.129.128.199 with SMTP id q190mr3028298ywf.319.1464969016212; Fri, 03 Jun 2016 08:50:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.128.199 with SMTP id q190mr3028287ywf.319.1464969016020; Fri, 03 Jun 2016 08:50:16 -0700 (PDT) Received: by 10.37.217.75 with HTTP; Fri, 3 Jun 2016 08:50:15 -0700 (PDT) In-Reply-To: References:

Date: Fri, 3 Jun 2016 11:50:15 -0400 Message-ID: From:Yaron Minsky To:"Carette, Jacques" Cc:Jacques Garrigue , OCaML List Mailing Content-Type: multipart/alternative; boundary=94eb2c033810cec70b053461ade6 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Option to fully expand types in error messages? --94eb2c033810cec70b053461ade6 Content-Type: text/plain; charset=UTF-8 Diffs are often useful in visualizing such things. not sure how helpful it is in this case, but it does at least make it a bit clearer what's lined up. This was generated with our patdiff tool. @@@@@@@@@@ -1,7 +1,7 @@@@@@@@@@ val traverseexercise :-| *'a* container PseudoCode.abstract ->-| (*'a* PseudoCode.abstract ->-| *'b* PseudoCode.abstract -> (*'c* * *'b*) PseudoCode.abstract) ->-| *'b* PseudoCode.abstract* ->*-|* 'd container* ->-| (*'d* *container* *-*> *'c container* PseudoCode.*abstract -> 'e) -> 'e*+| loopdata container PseudoCode.abstract ->+| (loopdata PseudoCode.abstract ->+| loopdata PseudoCode.abstract ->+| (loopdata * loopdata) PseudoCode.abstract) ->+| loopdata PseudoCode.abstract ->+| (< answer : 'a; state : 'b; .. >, loopdata) PseudoCode.cmonad On Fri, Jun 3, 2016 at 11:42 AM, Carette, Jacques wrote: > So here is an actual example. The error I get is > ocamlc -short-paths -c reproduce.ml > File "reproduce.ml", line 148, characters 21-25: > Error: Signature mismatch: > ... > Values do not match: > val traverseexercise : > 'a container PseudoCode.abstract -> > ('a PseudoCode.abstract -> > 'b PseudoCode.abstract -> ('c * 'b) PseudoCode.abstract) -> > 'b PseudoCode.abstract -> > 'd container -> > ('d container -> 'c container PseudoCode.abstract -> 'e) -> 'e > is not included in > val traverseexercise : > loopdata container PseudoCode.abstract -> > (loopdata PseudoCode.abstract -> > loopdata PseudoCode.abstract -> > (loopdata * loopdata) PseudoCode.abstract) -> > loopdata PseudoCode.abstract -> > (< answer : 'a; state : 'b; .. >, loopdata) PseudoCode.cmonad > File "reproduce.ml", line 111, characters 6-206: Expected > declaration > File "reproduce.ml", line 125, characters 8-24: Actual declaration > > I can't tell from the above error what the actual cause is. The full code > is attached. [This code is quite reduced already. It is kept at this size > to show in more detail the kinds of errors we're seeing.] > > Any 'hint' from OCaml as to the precise nature of the non-match would sure > be appreciated. > > Jacques > > ________________________________________ > From: Jacques Garrigue [garrigue@math.nagoya-u.ac.jp] > Sent: June 2, 2016 19:59 > To: Carette, Jacques > Cc: OCaML List Mailing > Subject: Re: [Caml-list] Option to fully expand types in error messages? > > On 2016/06/03 04:18, "Carette, Jacques" wrote: > > > > In writing some code which uses a lot of monads with underlying types > which use constraints, even simple errors can lead to extremely hard to > read error messages. The main reason is that the two types given in errors > are partially expanded, to different levels. This frequently means that > the part where the type checker detects a mismatch is (extremely) opaque to > human eyes. > > > > In that case, it would actually be preferable to fully expand the > types. Yes, that will produce wallpaper. But at least the mismatch should > be considerably easier to catch. > > > > Does this already exist, or should I submit a feature request? > > > > Jacques > > In the error message, types are expanded just enough to get down to the > conflict. > If the conflict is not visible at that point, this is probably a scoping > error (and there should be an extra line stating that); > otherwise this should be seen as a bug. > As Yaron pointed, -short-paths can help by at least giving a normal form > for paths (which may not be the expansion, but should be unique in the > error context). But it will not expand a type if the expansion is not a > type constructor, or if the parameters are different. > > Jacques > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --94eb2c033810cec70b053461ade6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Diffs are often useful in visualizing such things. =C2=A0n= ot sure how helpful it is in this case, but it does at least make it a bit = clearer what's lined up.=C2=A0 This was generated with our patdiff tool= .

@@@@@@@@@@ -1,7 +1,7 @@@@@@@@@@
           val traverseexercise :
-|           'a container PseudoCode.abstract ->
-|           ('a PseudoCode.abstract ->
-|            'b PseudoCode.abstract -> ('c * 'b) PseudoCode.abstract) ->
-|           'b PseudoCode.abstract ->
-|           'd container ->
-|           ('d container -<=
/span>> 'c container PseudoCode.abstract -> 'e) -&g=
t; 'e
+|           loopdata cont=
ainer PseudoCode.abstract ->
+|           (loopdata Pse=
udoCode.abstract ->
+|            loopdata Pse=
udoCode.abstract ->
+|            (loopdata * =
loopdata) PseudoCode.abstract) -&=
gt;
+|           loopdata Pseu=
doCode.abstract ->
+|           (< answer : 'a; state : 'b; .. >, loopdata) PseudoCode.<=
span style=3D"color:rgb(0,136,0)">cmonad

On Fri, Jun 3, 2016 at 11:4= 2 AM, Carette, Jacques <carette@mcmaster.ca> wrote:
So here is an actual example.=C2=A0 The error I= get is
ocamlc -short-paths -c reproduce.ml
File "reproduce.ml", line 148, characters 21-25:
Error: Signature mismatch:
=C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0Values do not match:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0val traverseexercise :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'a container PseudoCode.abstra= ct ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0('a PseudoCode.abstract -><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'b PseudoCode.abstract -> = ('c * 'b) PseudoCode.abstract) ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'b PseudoCode.abstract -> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'd container ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0('d container -> 'c con= tainer PseudoCode.abstract -> 'e) -> 'e
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not included in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0val traverseexercise :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loopdata container PseudoCode.abst= ract ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(loopdata PseudoCode.abstract ->= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loopdata PseudoCode.abstract ->= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (loopdata * loopdata) PseudoCode.= abstract) ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loopdata PseudoCode.abstract ->=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(< answer : 'a; state : = 9;b; .. >, loopdata) PseudoCode.cmonad
=C2=A0 =C2=A0 =C2=A0 =C2=A0File "reproduce.ml", line 111, charact= ers 6-206: Expected declaration
=C2=A0 =C2=A0 =C2=A0 =C2=A0File "reproduce.ml", line 125, charact= ers 8-24: Actual declaration

I can't tell from the above error what the actual cause is.=C2=A0 The f= ull code is attached.=C2=A0 [This code is quite reduced already.=C2=A0 It i= s kept at this size to show in more detail the kinds of errors we're se= eing.]

Any 'hint' from OCaml as to the precise nature of the non-match wou= ld sure be appreciated.

Jacques

________________________________________
From: Jacques Garrigue [gar= rigue@math.nagoya-u.ac.jp]
Sent: June 2, 2016 19:59
To: Carette, Jacques
Cc: OCaML List Mailing
Subject: Re: [Caml-list] Option to fully expand types in error messages?

On 2016/06/03 04:18, "Carette, Jacques" wrote:
>
> In writing some code which uses a lot of monads with underlying types = which use constraints, even simple errors can lead to extremely hard to rea= d error messages.=C2=A0 The main reason is that the two types given in erro= rs are partially expanded, to different levels.=C2=A0 This frequently means= that the part where the type checker detects a mismatch is (extremely) opa= que to human eyes.
>
> In that case, it would actually be preferable to fully expand the type= s.=C2=A0 Yes, that will produce wallpaper.=C2=A0 But at least the mismatch = should be considerably easier to catch.
>
> Does this already exist, or should I submit a feature request?
>
> Jacques

In the error message, types are expanded just enough to get down to the con= flict.
If the conflict is not visible at that point, this is probably a scoping er= ror (and there should be an extra line stating that);
otherwise this should be seen as a bug.
As Yaron pointed, -short-paths can help by at least giving a normal form fo= r paths (which may not be the expansion, but should be unique in the error = context). But it will not expand a type if the expansion is not a type cons= tructor, or if the parameters are different.

Jacques

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--94eb2c033810cec70b053461ade6-- 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 B9B3C7FE36 for ; Sat, 4 Jun 2016 08:27:17 +0200 (CEST) IronPort-PHdr: 9a23:C+pyfhahlO3flKk5UIoYqtX/LSx+4OfEezUN459isYplN5qZpcW6bnLW6fgltlLVR4KTs6sC0LqH9f68Ej1Qqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7H0pcGYMlUArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6t73AFT2gN2jFBGQXZ8ByyCpz4qCbmqudV3SKfNNbqQKpyUj30vIlxTxq9qi4MLiM06yn4g9Zqja1GrVr1qBVl2Y/bfYy9MfNifuXbdNwdVGMEQ4BYXGpDGtXvPMM0E+MdMLMA/MHGrFwUoE77XFH0CQ== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=garrigue@math.nagoya-u.ac.jp; spf=None smtp.mailfrom=garrigue@math.nagoya-u.ac.jp; spf=None smtp.helo=postmaster@mailhost.math.nagoya-u.ac.jp Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0AADPc1JXfQWCBoVehBB9umaBehqFeAKBZhQBAQEBAQEBAREBAQsWB1CCMIIVAQEBBCcTBgMBKgsBAQ4LEQQBAQEcEk8IBhMbiBOwN4UoBwKIcYNbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwEIiB4Igk6EQIMsgi6OXolvhgOII4FpTocuhTiPWB6EM1+JYwEBAQ X-IPAS-Result: A0C0AADPc1JXfQWCBoVehBB9umaBehqFeAKBZhQBAQEBAQEBAREBAQsWB1CCMIIVAQEBBCcTBgMBKgsBAQ4LEQQBAQEcEk8IBhMbiBOwN4UoBwKIcYNbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwEIiB4Igk6EQIMsgi6OXolvhgOII4FpTocuhTiPWB6EM1+JYwEBAQ X-IronPort-AV: E=Sophos;i="5.26,415,1459807200"; d="scan'208";a="180113650" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 04 Jun 2016 08:27:15 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 2E5866425 for ; Sat, 4 Jun 2016 15:27:13 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (rabbit-172.math.nagoya-u.ac.jp [172.16.254.254]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id BD4EC24DF; Sat, 4 Jun 2016 15:27:12 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=48aP8sFzccSQIs6fWoOmuTOMeaM=; b=GHXArNg8eAjmPNZQXEBv8oTVBMRn 96nMN4JRKQ7FvHIMvt6LJ487DNotF6+i7GLg7WzAGe13tAvlAgpR90Ub08fsLn56 mcIOZ24MjEPb6bAQa46lNzXdqQLJizE8NvoFFDII7ESQo2maS0C3QUiR2QnArrat 38b8U4X+xJxXWaw= DomainKey-Signature: a=rsa-sha1; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=gctaHoKaiZRib0G6lViMkCHMr4kGNOq6TA9Ycivt5d/I23588Za2yx+ELBYKUFtoUgZsIIgvYEM0uDwrclahqzk5GUsILKKfETDXxh9sa+p5yzu11nvjDkhq2aGSRY1ApaFYAwhFwmZiEXOC49+3pYHgMdnP5GFAyxJDVGYHalU=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 110D56E90; Sat, 4 Jun 2016 15:24:16 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jacques Garrigue In-Reply-To: Date: Sat, 4 Jun 2016 15:27:23 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: <1F323615-4222-44E1-8188-EC829A45652A@math.nagoya-u.ac.jp> References:

To: Jacques Carette X-Mailer: Apple Mail (2.3124) Subject: Re: [Caml-list] Option to fully expand types in error messages? I see. This is a problem with mismatching signatures. This is much less well supported than unification errors (internally, the f= unction called is moregeneral, which does not rely on unification). This has already been much improved by tracking the mismatching item better= , and -short-paths helps also by normalizing some types, but we should also= track mismatches inside type schemes. As you suggest, another solution would be full expansion. This is a bad idea with objects, but may make sense for programs not using = recursive types. Note however that there is no function doing this kind of expansion inside = the compiler... Jacques On 2016/06/04 00:42, "Carette, Jacques" wrote: >=20 > So here is an actual example. The error I get is > ocamlc -short-paths -c reproduce.ml=20 > File "reproduce.ml", line 148, characters 21-25: > Error: Signature mismatch: > ... > Values do not match: > val traverseexercise : > 'a container PseudoCode.abstract -> > ('a PseudoCode.abstract -> > 'b PseudoCode.abstract -> ('c * 'b) PseudoCode.abstract) -> > 'b PseudoCode.abstract -> > 'd container -> > ('d container -> 'c container PseudoCode.abstract -> 'e) -> 'e > is not included in > val traverseexercise : > loopdata container PseudoCode.abstract -> > (loopdata PseudoCode.abstract -> > loopdata PseudoCode.abstract -> > (loopdata * loopdata) PseudoCode.abstract) -> > loopdata PseudoCode.abstract -> > (< answer : 'a; state : 'b; .. >, loopdata) PseudoCode.cmonad > File "reproduce.ml", line 111, characters 6-206: Expected declarati= on > File "reproduce.ml", line 125, characters 8-24: Actual declaration >=20 > I can't tell from the above error what the actual cause is. The full cod= e is attached. [This code is quite reduced already. It is kept at this si= ze to show in more detail the kinds of errors we're seeing.] >=20 > Any 'hint' from OCaml as to the precise nature of the non-match would sur= e be appreciated. >=20 > Jacques >=20 > ________________________________________ > From: Jacques Garrigue [garrigue@math.nagoya-u.ac.jp] > Sent: June 2, 2016 19:59 > To: Carette, Jacques > Cc: OCaML List Mailing > Subject: Re: [Caml-list] Option to fully expand types in error messages? >=20 > On 2016/06/03 04:18, "Carette, Jacques" wrote: >>=20 >> In writing some code which uses a lot of monads with underlying types wh= ich use constraints, even simple errors can lead to extremely hard to read = error messages. The main reason is that the two types given in errors are = partially expanded, to different levels. This frequently means that the pa= rt where the type checker detects a mismatch is (extremely) opaque to human= eyes. >>=20 >> In that case, it would actually be preferable to fully expand the types.= Yes, that will produce wallpaper. But at least the mismatch should be co= nsiderably easier to catch. >>=20 >> Does this already exist, or should I submit a feature request? >>=20 >> Jacques >=20 > In the error message, types are expanded just enough to get down to the c= onflict. > If the conflict is not visible at that point, this is probably a scoping = error (and there should be an extra line stating that); > otherwise this should be seen as a bug. > As Yaron pointed, -short-paths can help by at least giving a normal form = for paths (which may not be the expansion, but should be unique in the erro= r context). But it will not expand a type if the expansion is not a type co= nstructor, or if the parameters are different. >=20 > Jacques