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