lazy evaluation and immuntability in golang

[will]

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

[Jan Mercl]

On Tue, Apr 29, 2014 at 12:31 PM, will <wma...@gmail.com> 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

[chris dollin]

On 29 April 2014 11:31, will <wma...@gmail.com> 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

[will]

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)

[Jesse McNelis]

On 29/04/2014 9:03 pm, "will" <wma...@gmail.com> 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.

[will]

Was looking at only two aspects not the full feature of the language

[Hai Thanh Nguyen]

Go simply sucks when talking about features, the beauty of Go comes from simplitcity.

[Benjamin Measures]

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.

[Scott Pakin]

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

[simon place]

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