Skip to content

Imperative block syntax, function definition syntax #11

Description

@pboyer

There is a case to be made for [Imperative] attributes for function definitions, e.g.:

[Imperative]
def : Number boolToNum( val : bool ) {
  if ( val ) { return = 1;} else { return = 0; }
}

This could also clearly be inferred.

This is an assigned imperative block, with proposed dependency capture vars:

val = true;
a = [Imperative]( val ){
  if ( val ) { return = 1;} else { return = 0; }
}
// a == 1

An assigned imperative block is thus a lot like an immediately evaluated anonymous function, in proposed syntax:

a = ([Imperative] lambda : Number ( val : bool ){ if ( val ) { return = 1;} else { return = 0; } )( false )
// a == 1

However, this form actually is more powerful, as the type declaration allows for replication to be performed:

a = ([Imperative] lambda : Number ( val : bool ){ if ( val ) { return = 1;} else { return = 0; } )( {false, true} )
// a == { 0, 1 }

IOW, the user can specify whether the the captured variables should be interpreted as a compound or singular value.

Perhaps, we can modify the Imperative block capture list to include a type annotation:

a = [Imperative]( val : bool ){ if ( val ) { return = 1;} else { return = 0; }

@lukechurch

Activity

  1. ke-yu commented on Jun 30, 2016

    @ke-yu
    Contributor

    I'd suggest that function doesn't have return type, or always be var[]..[], or the return type is just for annotation, instead of doing type coercion for return value.

  2. lukechurch commented on Jun 30, 2016

    @lukechurch
    Contributor

    @pboyer I think considering applying [Imperative] to other things than 'bare blocks' is a good idea. Where it's reasonable, it's really just an annotation on the structure that adjusts the semantics.

    I'm very cautious about the UX impact of inference. It makes code terse to write, but difficult to read and can cause unexpected behaviour changes. What happens if the first statement of a function isn't imperative? Do you switch the whole function to imperative because of a single statement?

    In general in user studies elsewhere we've seen that inference only works well when it's very local, predictable and has good tool support to help the user reason about what is going on.

    I like the direction the anonymous functions are going in, but find the examples a little hard to read above and I'm not overly keen on introducing the word lambda :) I think the () are getting over-used for too many different things as a syntactic construct.

  3. lukechurch commented on Jun 30, 2016

    @lukechurch
    Contributor

    @ke-yu Functions having return types is UX helpful - it helps people know what they're going to get back from the function.

    If the function type is an annotation only and gets ignored at runtime, now you potentially a function that says one thing and actually does another. That seems like it leads to confusions.

  4. lukechurch commented on Jun 30, 2016

    @lukechurch
    Contributor

    BTW @pboyer Do feel free to assign things like this to me if you're asking me a question - or drop me a note. I didn't reply for such a long time because the notification got lost in the noise of my inbox. Sorry about that.

  5. pboyer commented on Jun 30, 2016

    @pboyer
    ContributorAuthor

    @lukechurch I just put your name on it if you had any thoughts. Task assignment seems so formal...

    The syntax for lambda was more speculative than anything. I simply wanted to demonstrate that such a syntax is more powerful than imperative blocks (without having type annotations on captured variables). It's a bit odd though, as that means putting a type annotation on an already defined variable...

  6. ke-yu commented on Jul 1, 2016

    @ke-yu
    Contributor

    @pboyer lambda could be more general

    a = ( val : bool ){ [Imperative] {if ( val ) { return = 1;} else { return = 0; }}
    
  7. pboyer commented on Oct 26, 2016

    @pboyer
    ContributorAuthor
    [Imperative] 
    def foo(){
    
    }
    

    could be compiled to

    def foo() {
      return [ Imperative ] {
    
      }
    }
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions