Syntax for output-only arrows?

[Ross Paterson]

On Tue, Jun 08, 2004 at 03:02:37PM -0700, John Meacham wrote:
> On Tue, Jun 08, 2004 at 03:47:04AM +0300, Lauri Alanko wrote:
> > When I use arrows, I find that many of my primitives are of type (a () b)
> > (for some arrow type a): they produce a value but don't take any input.
> > E.g. deterministic parsers are like this.
> > 
> > The syntactic sugar for arrows is lovely, but I find it a bit tedious
> > writing "foo -< ()" all the time. The syntax allows the output of arrows
> > to be ignored, why not input too?
> > 
> > Would it cause unreasonable parsing problems simply to allow a simple
> > expression of an arrow type to be a legal command inside a proc
> > expression, with an implicit -< () input? Or are there other reasons
> > against it?
> > 
> > I for one find it extremely convenient that I can write "purely
> > imperative" code with a simple syntax like do { foo; bar; baz }. I'd
> > like similar simplicity when dealing with arrows, too.
> 
> ooh. I second this motion. if it is possible that is. 

Eek -- users!

It's certainly doable in GHC, which parses commands as expressions anyway.
Presumably it would scan the expression for arrow stuff and apply this
transformation if none were found.  But it feels hacky -- currently you
can tell what kind of command you have by looking at the outer syntax
-- this change could be confusing for readers too.  It may also make
errors harder to diagnose: this form will have to be recognized before
type checking, without using type info, and so may lead to confusing
type errors.

Also, it's ambiguous: is

	if b then e1 else e2

to be interpreted as

	(if b then e1 else e2) -< ()
or as
	if b then (e1 -< ()) else (e2 -< ())

(These have different meanings for some arrows.)  You could add more
rules to clarify, but it's awkward.  And what's special about ()?