[Grace-core] Polymorphism over unit

[Andrew P. Black]

I think that this is a consequence of us distinguishing syntactically (rather than by type) between value-returning statements and non-value returning statements.

At the last workshop, we discussed (but I don't recall if we decided anything about) having non-value returning methods return "None".  (We decided that the best name to use was "Nothing", but then rejected that on the grounds that one could never explain to a student that they should have written "Nothing" where in fact they had written nothing.)

This doesn't help, though, because the whole point of "none" is that it should be an error to assign it: it is NOT a value.

So I see two solutions to your problem.  The first is to go back on our decision to distinguish syntactically between value-returning statements and non-value returning statements.  The second is not to write code that is polymorphic over whether None or a value is returned, but instead to have two versions of the code, one for use in a value context, and one for use in a statement context.

It seems clear to me that THE LANGUAGE would get simpler if we eliminated this distinction (for example, made everything return self if nothing more explicit is retruned).  You are telling us that THE LIBRARIES would get simpler too.  Unfortunately, student programs would not get simpler, because students would use assignments in expression context.  Error messages would not get simpler.   Which are most important for our audience?

	Andrew


On 28 Nov 2011, at 18:20, Michael Homer wrote:

> Hi,
> I am trying to write code that is polymorphic over whether
> Unit(/Void/...) is returned or not. It's specifically for the pattern
> matching implementation, but it could come up elsewhere as well.
> 
> The issue arises when returning the result of applying an arbitrary
> block, or some other signal value. When the block returns a normal
> value, that works fine and has a well-defined disjunctive type R | S.
> Testing the result for equality with the signal value then isn't a
> problem. If the block happens to return Unit, there is a problem,
> because the Unit value can't be assigned anywhere, or be an argument
> to another method.
> 
> Concretely:
>  method match(value) case(block<A,ReturnType>) -> ReturnType |
> MatchFailed { ... return block.apply(value) ... return MatchFailed }
>  def m1 = match(-1)case { print "A negative number!" }
>  if (MatchFailed == m1) then { ... }
> The assignment statement fails, either statically or at runtime, and
> there's no way around it. The unit value also can't be encapsulated in
> another object to return for the same reason. What's the solution
> here?
> -Michael
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core