FAQ
Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use it
    when needed)
    - immutability (i.e creating a variable that is immutable) e.g. int,
    double, long?


regards,

Will

--
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

  • Jan Mercl at Apr 29, 2014 at 10:43 am

    On Tue, Apr 29, 2014 at 12:31 PM, will wrote:
    Does golang support the following:

    Lazy evaluation (define a variable, load it in memory and only use it when
    needed)
    Not directly. Lazy evaluation is possible by calling functions in
    place where a lazy evaluated operand would be in other languages. And
    if a closure is involved, I guess it's easy to use this way. More
    complex scenarios can include a sync.Once somewhere to avoid
    re-evaluation.
    immutability (i.e creating a variable that is immutable) e.g. int, double,
    long?
    Not directly. You can write a package like (untested code):

    package foo

    import "bar"

    type Bar struct {
               b bar.Bar
    }

    func (b *Bar) Bar() { return b.b}

    func NewImmutableBar(b bar.Bar) { return &Bar{b} }

    type Baz ...

    ----

    But you will probably not find too many examples of such approach.
    Within a package an immutability is usually achieved through
    discipline only. Exported stuff can hide internals just by not
    exporting things (eg. type Exported{ Visible T; hidden U}).

    -j

    --
    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.
  • Chris dollin at Apr 29, 2014 at 10:45 am

    On 29 April 2014 11:31, will wrote:
    Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)
    Yes and no. It depends on how much work your're prepared to do before
    one stops saying it's "supported".

    It's not there as an automatic pervasive property of the language
    (unlike Haskell). Mixing lazy evaluation with an avowedly imperative
    language is likely to be ... complicated.

        - immutability (i.e creating a variable that is immutable) e.g. int,
        double, long?


    Yes and no. It depends on how much work your're prepared to do before
    one stops saying it's "supported".

    To make a variable immutable, (a) make it unexported, and (b) don't
    assign to it in its declaring package.

    Or don't use a variable; use a const, for those types and initialising
    expressions that permit it.

    Are you trying to solve a programming problem or just characterise
    the language?

    Chris

    --
    Chris "allusive" Dollin

    --
    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.
  • Will at Apr 29, 2014 at 11:03 am
    Hi Chris,

    Thanks for the feedback.

    At this stage its looking at the characteristic of the language (looking at
    the equivalent how certain things can be done in go which are done say in
    scala or haskell)
    On Tuesday, 29 April 2014 12:45:55 UTC+2, chris dollin wrote:
    On 29 April 2014 11:31, will <wma...@gmail.com <javascript:>> wrote:


    Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)
    Yes and no. It depends on how much work your're prepared to do before
    one stops saying it's "supported".

    It's not there as an automatic pervasive property of the language
    (unlike Haskell). Mixing lazy evaluation with an avowedly imperative
    language is likely to be ... complicated.

    - immutability (i.e creating a variable that is immutable) e.g. int,
    double, long?


    Yes and no. It depends on how much work your're prepared to do before
    one stops saying it's "supported".

    To make a variable immutable, (a) make it unexported, and (b) don't
    assign to it in its declaring package.

    Or don't use a variable; use a const, for those types and initialising
    expressions that permit it.

    Are you trying to solve a programming problem or just characterise
    the language?

    Chris

    --
    Chris "allusive" Dollin
    --
    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.
  • Jesse McNelis at Apr 29, 2014 at 11:06 am

    On 29/04/2014 9:03 pm, "will" wrote:
    At this stage its looking at the characteristic of the language (looking
    at the equivalent how certain things can be done in go which are done say
    in scala or haskell)
    >

    Haskell and Scala are very different languages to Go. Comparing them on a
    feature by feature basis won't be useful.

    --
    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.
  • Will at Apr 29, 2014 at 11:26 am
    Was looking at only two aspects not the full feature of the language
    On Tuesday, 29 April 2014 13:06:48 UTC+2, Jesse McNelis wrote:

    On 29/04/2014 9:03 pm, "will" <wma...@gmail.com <javascript:>> wrote:
    At this stage its looking at the characteristic of the language (looking
    at the equivalent how certain things can be done in go which are done say
    in scala or haskell)
    Haskell and Scala are very different languages to Go. Comparing them on a
    feature by feature basis won't be useful.
    --
    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.
  • Hai Thanh Nguyen at Apr 29, 2014 at 12:05 pm
    Go simply sucks when talking about features, the beauty of Go comes from
    simplitcity.
    On Tuesday, April 29, 2014 5:31:07 PM UTC+7, will wrote:


    Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)
    - immutability (i.e creating a variable that is immutable) e.g. int,
    double, long?


    regards,

    Will
    --
    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.
  • Benjamin Measures at Apr 29, 2014 at 1:24 pm

    On Tuesday, 29 April 2014 13:05:49 UTC+1, Hai Thanh Nguyen wrote:
    Go simply sucks when talking about features, the beauty of Go comes from
    simplitcity.
    I'd emphasise orthogonality of features. Simplistically, the lack of
    features is a feature.

    --
    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.
  • Scott Pakin at May 1, 2014 at 7:43 pm

    On Tuesday, April 29, 2014 4:31:07 AM UTC-6, will wrote:
    Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)

    I once tried to write a lazy-evaluation package in Go based on channels.
      The basic idea was to use goroutines and channels to represent lazy
    computations. A lazy function would first write a probe message into an
    unbuffered channel, then perform its computation, and finally write the
    result into a (typically different) channel. Consequently, the function
    would block until a consumer requested its value by reading from the
    unbuffered channel.

    This split-phase operation was a bit clunky to abstract into a
    general-purpose package so I gave up working on it. Still, it does
    indicate that lazy evaluation can be implemented in Go—not as pervasively
    as in Haskell but not much worse than Scheme's delay and force primitives.

    — Scott

    --
    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.
  • Simon place at May 1, 2014 at 8:36 pm
    - Lazy evaluation (define a variable, load it in memory and only use it
        when needed)

    for me

    On Thursday, 1 May 2014 20:43:34 UTC+1, Scott Pakin wrote:
    On Tuesday, April 29, 2014 4:31:07 AM UTC-6, will wrote:

    Does golang support the following:

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)

    I once tried to write a lazy-evaluation package in Go based on channels.
    The basic idea was to use goroutines and channels to represent lazy
    computations. A lazy function would first write a probe message into an
    unbuffered channel, then perform its computation, and finally write the
    result into a (typically different) channel. Consequently, the function
    would block until a consumer requested its value by reading from the
    unbuffered channel.

    This split-phase operation was a bit clunky to abstract into a
    general-purpose package so I gave up working on it. Still, it does
    indicate that lazy evaluation can be implemented in Go—not as pervasively
    as in Haskell but not much worse than Scheme's delay and force primitives.

    — Scott
    --
    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.
  • Simon place at May 1, 2014 at 8:44 pm

    - Lazy evaluation (define a variable, load it in memory and only use
    it when needed)
    for me lazy is;

              define var, and how to calculate it, but dont actually until/if
    needed (transparently)

    this is not built-in, so you code this using accessor (get/set) methods.

    and you do immutability by not having a 'set' accessor.


    --
    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
postedApr 29, '14 at 10:31a
activeMay 1, '14 at 8:44p
posts11
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase