Can you get sml-mode to highlight type mismatch terms?

All,

Here's a little wishlist item for those minds more capable than
mine...

I often run into type mismatch errors in deeply nested type terms (see
example below, from some typical broken combinator-based parser
code). I would *love* to have xemacs sml-mode just highlight in red
that I messed up and am trying to pass a DECL_INFO list instead of a
simple DECL_INFO. These messages are just too painful and tedious to
parse and compare by hand! One bright red highlighted term would be
worth a thousand words :-)

The general case would likely be hard, but I'd think that a simple
error message parser with a comparison or unification algorithm would
be able to identify obvious conflicts. The usual errors I see in my
development are of the form shown below, with occasional problems due
to value restriction (can't bind a concrete to a 'Z type).

While I've seen references to stand-alone type error slicing and
various little toy tools, I'm wondering if there is a way to integrate
a simple error message scanner/highlighter into xemacs sml-mode.

Regards,

- Kenn


vparse.sml:1758.12-1761.53 Error: operator and operand don't agree
[tycon mismatch]
operator domain: (VSTREAM
-> (((designator * sym_decl) list * (DECL_INFO *
TYPEDEF))
* VSTREAM) list)
* (VSTREAM
-> (((designator * sym_decl) list
* (DECL_INFO * TYPEDEF)) * VSTREAM) list)
operand: (VSTREAM
-> (((designator * sym_decl) list * (DECL_INFO *
TYPEDEF))
* VSTREAM) list)
* (VSTREAM
-> (((designator * sym_decl) list
* (DECL_INFO list * TYPEDEF)) * VSTREAM)
list)
in expression:
f <$> p_integer_type_definition <exp> <|>
(f <$> p_floating_type_definition <exp>) <|>
p_enumeration_type_definition di <|> p_physical_type_definition
di

....
> error message parser with a comparison or unification algorithm ...
> in expression:
> f <$> p_integer_type_definition <exp> <|>
> (f <$> p_floating_type_definition <exp>) <|>
> p_enumeration_type_definition di <|> p_physical_type_definition

I am interested! Tell me in greater detail what you expect to be error-
highlighted. (I think I follow but I want to be certain.)

Why an 'error message parser'?

On Oct 3, 5:57 am, dben...@eecs.wsu.edu wrote:
> ...

> I am interested! Tell me in greater detail what you expect to be error-
> highlighted. (I think I follow but I want to be certain.)
>
> Why an 'error message parser'?

My thinking is this: I'd like to quickly see what I did wrong instead
of manually performing a term-by-term comparison on a pair of type
signatures. I'd see three obvious solutions (though there are
certainly more):

1) make the compiler message more useful, pointing out the DECL_INFO
list vs DECL_INFO as the source of the problem immediately, then
showing the full mismatch message. I had assumed that this would be
difficult, although on reflection, it might not be. It would also be
compiler-specific.

2) integrate a full type error slicer with sml-mode. This seems very
difficult because you would have to make sure the slicer was fully
synchronized with the emacs comint shell and the state of the inferior
sml-process.

3) quickly hack up an emacs extension that (maybe on request, maybe
always) would parse the buffer for [tycon mismatch] error indications,
then do the same term-by term comparison (or more generally,
unification) that I do, then highlight the words "DECL_INFO list" and
"DECL_INFO" in the error message. Of course, showing me the problem in
the original source would be even better, but I think this implies
solution (2). Clearly, this is not a general solution and will not
necessarily provide useful feedback in all cases, but it seems like
the easiest way to get the most return for the effort.

Regards,

- Kenn

> ... although on reflection, it might not be. It would also be
> compiler-specific.
> ... then highlight the words "DECL_INFO list" and
> "DECL_INFO" in the error message.
....
> Regards,
>
> - Kenn

I believe I fully understand now. Yes, this is certainly feasible for
the SML/NJ error messages, at least most of the time.

It is also a most useful idea! While I'll not attempt to put this into
emacs, I am working (slowly) on yaed (yet another editor) called Ped
(for Program editor). I already capture error messages which are then
diplayed as post-its near the offending text, with a box around the
offending text. Since I have the error message, it ought to be fairly
simple to equip Ped with the highlighting you suggest.

Thanks,
David

kennheinrich@sympatico.ca wrote:
[...]
> I often run into type mismatch errors in deeply nested type terms (see
> example below, from some typical broken combinator-based parser
> code). I would *love* to have xemacs sml-mode just highlight in red
> that I messed up and am trying to pass a DECL_INFO list instead of a
> simple DECL_INFO. These messages are just too painful and tedious to
> parse and compare by hand! One bright red highlighted term would be
> worth a thousand words :-)
[...]

The bg-build-mode I wrote (mostly for working with MLton) can
highlight expressions referred to in error messages. See here:

http://mlton.org/EmacsBgBuildMode

Message highlighting doesn't yet work as well as I would like. In
particular, it sometimes highlights too large an area, because
movement (by expressions) in SML mode doesn't work properly (or I'm
just not using the right commands/approch). Patches are welcome!

-Vesa Karvonen

> Here's a little wishlist item for those minds more capable than
> mine...

> I often run into type mismatch errors in deeply nested type terms (see
> example below, from some typical broken combinator-based parser
> code). I would *love* to have xemacs sml-mode just highlight in red
> that I messed up and am trying to pass a DECL_INFO list instead of a
> simple DECL_INFO. These messages are just too painful and tedious to
> parse and compare by hand! One bright red highlighted term would be
> worth a thousand words :-)

> The general case would likely be hard, but I'd think that a simple
> error message parser with a comparison or unification algorithm would
> be able to identify obvious conflicts. The usual errors I see in my
> development are of the form shown below, with occasional problems due
> to value restriction (can't bind a concrete to a 'Z type).

> While I've seen references to stand-alone type error slicing and
> various little toy tools, I'm wondering if there is a way to integrate
> a simple error message scanner/highlighter into xemacs sml-mode.

The patch below to sml-proc.el does just that: when visiting such an error
with C-x ` (or by clicking on it), the differences between the two types
are highlighted.

This presumes you're using a *very* recent version of Emacs (i.e. built from
the CVS trunk). If you don't want to build your own Emacs, then you can try
it with Emacs-22 together with the CVS version of smerge-mode.el which you
can download from

http://cvs.savannah.gnu.org/viewvc/*...EAD&root=emacs

This has been *very* lightly tested, and I'd like to add it to the next
version of sml-mode, so any feedback is welcome.


Stefan


Index: sml-proc.el
================================================== =================
--- sml-proc.el (revision 2721)
+++ sml-proc.el (working copy)
@@ -308,6 +308,29 @@
(progn (call-interactively 'run-sml)
(get-buffer-process (current-buffer)))))

+(defun inferior-sml-next-error-hook ()
+ ;; Try to recognize SML/NJ type error message and to highlight finely the
+ ;; difference between the two types (in case they're large, it's not
+ ;; always obvious to spot it).
+ (save-current-buffer
+ (when (and (derived-mode-p 'sml-mode 'inferior-sml-mode)
+ (boundp 'next-error-last-buffer)
+ (bufferp next-error-last-buffer)
+ (set-buffer next-error-last-buffer)
+ (derived-mode-p 'inferior-sml-mode)
+ ;; The position of `point' is not guaranteed :-(
+ (looking-at ".*\n operator domain: "))
+ (save-excursion
+ (let ((b1 (match-end 0))
+ e1 b2 e2)
+ (when (re-search-forward "\n in expression:\n" nil t)
+ (setq e2 (match-beginning 0))
+ (when (re-search-backward "\n operand: " b1 t)
+ (setq e1 (match-beginning 0))
+ (setq b2 (match-end 0))
+ (smerge-refine-subst b1 e1 b2 e2
+ '((face . smerge-refined-change))))))))))
+
(define-derived-mode inferior-sml-mode comint-mode "Inferior-SML"
"Major mode for interacting with an inferior ML process.

@@ -354,7 +377,8 @@
TAB file name completion, as in shell-mode, etc.."
(setq comint-prompt-regexp sml-prompt-regexp)
(sml-mode-variables)
-
+ ;; We have to install it globally, 'cause it's run in the *source* buffer :-(
+ (add-hook 'next-error-hook 'inferior-sml-next-error-hook)
(set (make-local-variable 'font-lock-defaults)
inferior-sml-font-lock-defaults)
;; For sequencing through error messages:

kennheinrich@sympatico.ca wrote:
[...]
> 1) make the compiler message more useful, pointing out the DECL_INFO
> list vs DECL_INFO as the source of the problem immediately, then
> showing the full mismatch message. I had assumed that this would be
> difficult, although on reflection, it might not be. It would also be
> compiler-specific.

MLton does something like that. See the section "Type error messages"
on the page http://mlton.org/TypeChecking .

-Vesa Karvonen