FAQ
Dear Gophers, what do you think about sketched below construct?

func () (rv int, err error) {

     watch (err != nil) {

         // switch over err, print err, whatever

         return rv, err
     }

     // ......
     result, err := callfunc() // watched err
     // ......

     return
}

// Watch statements
//
// "Watch" statements specify the conditional execution a Block of code
// according to the value of a boolean expression. The expression is
// checked every time any variable used in said expression has
// been assigned to in a preceding simple statement.
//
// WatchStmt = "watch" Expression Block

// One may think about 'watch' implicitly evaluating right
// before "invisible semicolon" that ends the preceding statement:
// E.g.
// watch (var != nil)
// ...
// Statement_not_assigning_to_var // ; "invisible semicolon"
// ...
// Statement_assigning_to_var // ; "invisible semicolon"
// // "invisibly perform a watch"
// // ; "invisible semicolon"
//


--
Wojciech S. Czarnecki
        ^oo^ OHIR-RIPE

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Jan 15, 2015 at 4:11 pm

    On Thu, Jan 15, 2015 at 5:02 AM, Wojciech S. Czarnecki wrote:
    Dear Gophers, what do you think about sketched below construct?

    func () (rv int, err error) {

    watch (err != nil) {

    // switch over err, print err, whatever

    return rv, err
    }

    // ......
    result, err := callfunc() // watched err
    // ......

    return
    }

    // Watch statements
    //
    // "Watch" statements specify the conditional execution a Block of code
    // according to the value of a boolean expression. The expression is
    // checked every time any variable used in said expression has
    // been assigned to in a preceding simple statement.
    //
    // WatchStmt = "watch" Expression Block

    // One may think about 'watch' implicitly evaluating right
    // before "invisible semicolon" that ends the preceding statement:
    // E.g.
    // watch (var != nil)
    // ...
    // Statement_not_assigning_to_var // ; "invisible semicolon"
    // ...
    // Statement_assigning_to_var // ; "invisible semicolon"
    // // "invisibly perform a watch"
    // // ; "invisible semicolon"
    //

    Besides the obvious issue of spooky action at a distance, there is a
    question of what should happen if the variable is changed in nested
    function.

    func F() (err error) {
      watch (err != nil) {
       return error.New("watch")
      }
      defer func() {
       err = error.New("defer")
       return err
      }()
      return
    }

    Now what happens? If the answer is not reasonably obvious, then there
    is something wrong with the construct.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 15, 2015 at 5:13 pm
    Dnia 2015-01-15, o godz. 08:10:59
    Ian Lance Taylor <iant@golang.org> napisał(a):

    Besides the obvious issue of spooky action at a distance
    This is a valid concern. And strong argument against the 'watch'
    construct. Though I got "the watch" idea while pondering on
    current "too many ; err != nil" threads and proposed patterns.
    Some of them much convulted.
    what should happen if the variable is changed in nested function.
    I meant _preceding_*simple*_statement_, i.e. an Assignment. Nothing more.
    So nothing should happen. Compiler will not put the watch check, as nested
    function definition (and a deffered call to) are not simple statements.
    // been assigned to in a preceding simple statement.
    _______________________________________^^^^^^__________
    func F() (err error) {
    watch (err != nil) {
    return error.New("watch")
    }
    defer func() {
    err = error.New("defer")
    return err
    }()
    return
    }

    Now what happens? If the answer is not reasonably obvious, then there
    is something wrong with the construct.
    Good example.

    For me the answer is obvious: neither anonymous func definition is a
    simple statement nor the call to it assigns to the being watched variable is.
    So there is no place for an "invisible watch check".

    As to whether deffered anonymous functions should be allowed to have inner
    watchers: I sincerely do not know. Though likely it would be good for
    consistency.
    Ian
    --
    Wojciech S. Czarnecki
            ^oo^ OHIR-RIPE

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • DV at Jan 15, 2015 at 5:47 pm
    The proposed patterns *are* indeed convoluted, yes. Not too sound too
    offensive, but I think 99% of the github.com "let's-make-errors-better"
    projects are convoluted and completely unnecessary as well.

    Here, this can be enlightening:
    http://blog.golang.org/errors-are-values

    Errors are really *not* that difficult in Go, nor are they verbose, nor do
    we need 9 different special packages to make them "more usable", IMO.
    On Thursday, January 15, 2015 at 10:13:15 AM UTC-7, ohir wrote:

    Dnia 2015-01-15, o godz. 08:10:59
    Ian Lance Taylor <ia...@golang.org <javascript:>> napisał(a):

    Besides the obvious issue of spooky action at a distance
    This is a valid concern. And strong argument against the 'watch'
    construct. Though I got "the watch" idea while pondering on
    current "too many ; err != nil" threads and proposed patterns.
    Some of them much convulted.
    what should happen if the variable is changed in nested function.
    I meant _preceding_*simple*_statement_, i.e. an Assignment. Nothing more.
    So nothing should happen. Compiler will not put the watch check, as nested
    function definition (and a deffered call to) are not simple statements.
    // been assigned to in a preceding simple statement.
    _______________________________________^^^^^^__________
    func F() (err error) {
    watch (err != nil) {
    return error.New("watch")
    }
    defer func() {
    err = error.New("defer")
    return err
    }()
    return
    }

    Now what happens? If the answer is not reasonably obvious, then there
    is something wrong with the construct.
    Good example.

    For me the answer is obvious: neither anonymous func definition is a
    simple statement nor the call to it assigns to the being watched variable
    is.
    So there is no place for an "invisible watch check".

    As to whether deffered anonymous functions should be allowed to have inner
    watchers: I sincerely do not know. Though likely it would be good for
    consistency.
    Ian
    --
    Wojciech S. Czarnecki
    ^oo^ OHIR-RIPE
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • DV at Jan 15, 2015 at 5:48 pm
    The proposed patterns *are* indeed convoluted, yes. Not too sound too
    offensive, but I think 99% of the github.com "let's-make-errors-better"
    projects are convoluted and completely unnecessary as well.

    Here, this can be enlightening:
    http://blog.golang.org/errors-are-values

    Errors are really *not* that difficult in Go, nor are they verbose, nor do
    we need 9 different special packages to make them "more usable", IMO.
    On Thursday, January 15, 2015 at 10:13:15 AM UTC-7, ohir wrote:

    Dnia 2015-01-15, o godz. 08:10:59
    Ian Lance Taylor <ia...@golang.org <javascript:>> napisał(a):

    Besides the obvious issue of spooky action at a distance
    This is a valid concern. And strong argument against the 'watch'
    construct. Though I got "the watch" idea while pondering on
    current "too many ; err != nil" threads and proposed patterns.
    Some of them much convulted.
    what should happen if the variable is changed in nested function.
    I meant _preceding_*simple*_statement_, i.e. an Assignment. Nothing more.
    So nothing should happen. Compiler will not put the watch check, as nested
    function definition (and a deffered call to) are not simple statements.
    // been assigned to in a preceding simple statement.
    _______________________________________^^^^^^__________
    func F() (err error) {
    watch (err != nil) {
    return error.New("watch")
    }
    defer func() {
    err = error.New("defer")
    return err
    }()
    return
    }

    Now what happens? If the answer is not reasonably obvious, then there
    is something wrong with the construct.
    Good example.

    For me the answer is obvious: neither anonymous func definition is a
    simple statement nor the call to it assigns to the being watched variable
    is.
    So there is no place for an "invisible watch check".

    As to whether deffered anonymous functions should be allowed to have inner
    watchers: I sincerely do not know. Though likely it would be good for
    consistency.
    Ian
    --
    Wojciech S. Czarnecki
    ^oo^ OHIR-RIPE
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Anlhord at Jan 15, 2015 at 4:17 pm
    what's the advantage compared to
    https://github.com/goerr/goerr/tree/master/test/err0
    On Thursday, January 15, 2015 at 2:02:49 PM UTC+1, ohir wrote:

    Dear Gophers, what do you think about sketched below construct?

    func () (rv int, err error) {

    watch (err != nil) {

    // switch over err, print err, whatever

    return rv, err
    }

    // ......
    result, err := callfunc() // watched err
    // ......

    return
    }

    // Watch statements
    //
    // "Watch" statements specify the conditional execution a Block of code
    // according to the value of a boolean expression. The expression is
    // checked every time any variable used in said expression has
    // been assigned to in a preceding simple statement.
    //
    // WatchStmt = "watch" Expression Block

    // One may think about 'watch' implicitly evaluating right
    // before "invisible semicolon" that ends the preceding statement:
    // E.g.
    // watch (var != nil)
    // ...
    // Statement_not_assigning_to_var // ; "invisible semicolon"
    // ...
    // Statement_assigning_to_var // ; "invisible semicolon"
    // // "invisibly perform a watch"
    // // ; "invisible semicolon"
    //


    --
    Wojciech S. Czarnecki
    ^oo^ OHIR-RIPE
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 15, 2015 at 5:17 pm
    Dnia 2015-01-15, o godz. 08:17:11
    anlhord@gmail.com napisał(a):
    I do not know if there is any advantage over an avaliable package.
    The 'watch' construct is curently a pure idea to discuss.
    Not even a proposal.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Klaus Post at Jan 16, 2015 at 12:11 pm
    Hi!

    Other than the already mentioned issues, what would happen if:

    func Foo() error {
       var int i
       watch(i != 0) {
         return error.New("watch")
       }
       Bar(&i)
    }

    func Bar(i *int) {
       [...]
       *i = 1
       [..]
    }

    Would Bar just terminate mid-function?
    Should watches follow pointers? If not, what if a function takes the
    pointer to a watched variable and changes it?
    What if a pointer to a watched expression is stored in a struct that is
    returned or handed to another function?

    /Klaus
    On Thursday, 15 January 2015 14:02:49 UTC+1, ohir wrote:

    Dear Gophers, what do you think about sketched below construct?

    func () (rv int, err error) {

    watch (err != nil) {

    // switch over err, print err, whatever

    return rv, err
    }

    // ......
    result, err := callfunc() // watched err
    // ......

    return
    }

    // Watch statements
    //
    // "Watch" statements specify the conditional execution a Block of code
    // according to the value of a boolean expression. The expression is
    // checked every time any variable used in said expression has
    // been assigned to in a preceding simple statement.
    //
    // WatchStmt = "watch" Expression Block

    // One may think about 'watch' implicitly evaluating right
    // before "invisible semicolon" that ends the preceding statement:
    // E.g.
    // watch (var != nil)
    // ...
    // Statement_not_assigning_to_var // ; "invisible semicolon"
    // ...
    // Statement_assigning_to_var // ; "invisible semicolon"
    // // "invisibly perform a watch"
    // // ; "invisible semicolon"
    //


    --
    Wojciech S. Czarnecki
    ^oo^ OHIR-RIPE
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 16, 2015 at 11:57 pm
    Dnia 2015-01-16, o godz. 04:11:04
    Klaus Post <klauspost@gmail.com> napisał(a):
    Other than the already mentioned issues, what would happen if:
    [cut]
    Should watches follow pointers? If not, what if a function takes the
    pointer to a watched variable and changes it?
    What if a pointer to a watched expression is stored in a struct that is
    returned or handed to another function?
    Watch is by definition restricted to _simple_ statements_.

    See http://golang.org/ref/spec#Statements

    Of which watchable are: IncDecStmt|Assignment|SendStmt
    /Klaus
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 17, 2015 at 12:28 am
    Dnia 2015-01-16, o godz. 04:11:04
    Klaus Post <klauspost@gmail.com> napisał(a):

    I think I should elaborate more:
    Should watches follow pointers? If not, what if a function takes the
    pointer to a watched variable and changes it?
    Watch does not go deep in any sense. It does NOT wrap a variable memory
    in some kind of magic code. It is purely procedural. It kicks in
    on an assignment in current scope. It works as on example:


    func x () {

    watch ( v != 0 ) { // compiler: aha! note v as watched and
         got_v_zero() // make "subfunc w1 (v) {
                        // if v != 0 {
                        // got_v_zero();
                        // return;
                        // } }" }

         dosmth(&v) // no simple statement, no watch
         v := 1 // an assignment, v on the left, assigned to
                        // compiler: aha! v is under watch so lets
                        // call watcher subfunc for v =>
                        // "; w1(v) ;"
                        // <= control returns here from w1 call
         vv := v // vv is not being watched of course
                        // ...
    }
    What if a pointer to a watched expression is stored in a struct that is
    returned or handed to another function?
    All those questions are exactly of my own before I settled on _simple_
    statements. To get reasoning (and implementation) straight.

    --
    Wojciech S. Czarnecki
            ^oo^ OHIR-RIPE

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nico at Jan 16, 2015 at 1:07 pm
    I'd say that this proposal is equivalent to what in other languages are
    called exceptions.

    The proposed notation:

    func () (rv int, err error) {
          watch (err != nil) {
              // switch over err, print err, whatever
              return rv, err
          }

          // ......
          result, err := callfunc() // watched err
          // ......

          return
    }

    could be re-written using the traditional notation as:

    func () (rv int, err error) {
          try {
              // ......
              result, err := callfunc() // watched err
              // ......
              return
          } catch err {
              // switch over err, print err, whatever
              return rv, err
          }
    }



    Exceptions were intentionally excluded from Go. See this FAQ entry:

          http://golang.org/doc/faq#exceptions

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 16, 2015 at 11:39 pm
    Dnia 2015-01-16, o godz. 13:07:11
    Nico <nicolas.riesco@gmail.com> napisał(a):
    I'd say that this proposal is equivalent to what in other languages are
    called exceptions.
    Nope. Watch does not break normal control flow as exceptions do.
    Also, there is nothing in the spec to say a watch must be used to
    check an error condition. It is meant to keep any otherwise repetitive
    conditional check/action in a single place. Watch is purely procedural.

    E.g.

    func x () {
        // ...
        watch ( inxd.ext_flags == urgent ) {
      process_urgent_data(inxd)
      // no return, so the control
      // flows to the next statement in the scope
        }
        // ...
        inxd, _ := pull_something() // here the inxd will be checked
         // then control returns here ->
        process_normal_data(inxd) //
        // ... // many other inxd assignments
         // to check
    }

    Anyway, Ian's "action at a distance" argument still stands. This is
    a single common trait the Watch statement and exceptions have.

    --
    Wojciech S. Czarnecki
            ^oo^ OHIR-RIPE

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Paul Hankin at Jan 17, 2015 at 7:25 am
    func P(n int) bool {
       i := 1
       watch n % i == 0 {
         return false
       }
       watch i * i < n {
         goto a
       }
       a: i++
       return true
    }

    Is this program legal? I think the answer is that it's ambiguous in
    multiple ways (I count 5) given the definitions so far, and we'd end up
    with a relatively long amount of text in the language reference describing
    how this construct works in combination with the rest of the language.

    I'd much rather use a simple language that I understand and pay the cost of
    a few extra (explicit) if-statements.

    --
    Paul
    On Thursday, 15 January 2015 22:02:49 UTC+9, ohir wrote:

    Dear Gophers, what do you think about sketched below construct?

    func () (rv int, err error) {

    watch (err != nil) {

    // switch over err, print err, whatever

    return rv, err
    }

    // ......
    result, err := callfunc() // watched err
    // ......

    return
    }

    // Watch statements
    //
    // "Watch" statements specify the conditional execution a Block of code
    // according to the value of a boolean expression. The expression is
    // checked every time any variable used in said expression has
    // been assigned to in a preceding simple statement.
    //
    // WatchStmt = "watch" Expression Block

    // One may think about 'watch' implicitly evaluating right
    // before "invisible semicolon" that ends the preceding statement:
    // E.g.
    // watch (var != nil)
    // ...
    // Statement_not_assigning_to_var // ; "invisible semicolon"
    // ...
    // Statement_assigning_to_var // ; "invisible semicolon"
    // // "invisibly perform a watch"
    // // ; "invisible semicolon"
    //


    --
    Wojciech S. Czarnecki
    ^oo^ OHIR-RIPE
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wojciech S. Czarnecki at Jan 17, 2015 at 9:54 am
    Dnia 2015-01-16, o godz. 23:25:46
    Paul Hankin <paul.hankin@gmail.com> napisał(a):
    it's ambiguous in multiple ways
    [...]
    I'd much rather use a simple language that I understand
    and pay the cost of a few extra (explicit) if-statements.
    You are right.

    Legibility of the go language is too precious to be abused.
    Putting an if Expr {} does cost a few keystrokes and a few seconds
    to reason, reasoning about whether 'watch' will be called may cost
    hours.

    The 'watch' construct is oficially deceased. EOT.

    Thank you all for the comments.

    --
    Wojciech S. Czarnecki
            ^oo^ OHIR-RIPE

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 15, '15 at 1:02p
activeJan 17, '15 at 9:54a
posts14
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase