Syntax for output-only arrows?
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. Lauri Alanko la@iki.fi
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. -- John Meacham - ⑆repetae.net⑆john⑈
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 ()?
participants (3)
-
John Meacham -
Lauri Alanko -
Ross Paterson