Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

imperative syntax ambiguity

1 view
Skip to first unread message

Geoffrey Irving

unread,
May 5, 2011, 3:03:24 AM5/5/11
to Dylan Simon, duck...@googlegroups.com
As part of the shift to imperative execution, I need to add support
for bare expressions at the top level. This creates the following
ambiguity:

f :: t

can be either the expression (f :: t) or the start of a function
declaration. One way to resolve this would be to treat f :: t as a
function type specification if it's followed by something of the form
f = ..., and as an expression otherwise. The only difference with the
current code is that stuff like

f :: Int
g = 3
f = 3

would get through the parser. Currently, it fails at parse time
because f :: t must be followed by the definition of f. Of course,
even if that got through the parser it would currently fail at type
inference time because f doesn't have a type when f :: Int gets
evaluated.

Time for sleep.

Geoffrey

Dylan Simon

unread,
May 5, 2011, 10:26:37 AM5/5/11
to duck...@googlegroups.com
From Geoffrey Irving <irv...@naml.us>, Thu, May 05, 2011 at 12:03:24AM -0700:

I'm not convinced we need to support top-level statements. In the main
module, clearly they add no value. In other modules, they may be ill-advised,
but the same effect can be achieved with top-level assignments "_ = f" anyway.

Geoffrey Irving

unread,
May 5, 2011, 10:15:27 PM5/5/11
to duck...@googlegroups.com

I'd been assuming that main would vanish entirely, a la perl or python. _ = f certainly works, but it'd be odd if we allowed just f inside functions but not outside. It also hides whether the return type is unit or not.

Geoffrey

Reply all
Reply to author
Forward
0 new messages