Reading cookies

Re: type-safe net/rpc?

Re: Something from Alef - the become statement

On Feb 14, 3:18 pm, "Thomas Bushnell, BSG" <tbushn...@...>
wrote:
> I think this is very interesting.
>
> It is called "tail call optimization", and is hardly an Alef invention. You
> can just spell it "return", and get the same effect; the compiler can
> simply detect the fact of the tail call and do the optimization.

No it's not an Alef invention.  I actually like being explicit, as you
say below .

Sometimes you want to be able to get a stack trace, and other times
you want the TCO to happen.  You can let other people argue about
whether it's good to be implicit or explicit about this .

>
> The advantage of "become" is that it *requires *the compiler to do the tail
> call optimization, but that can be done as well by making it a requirement
> of the language that "return" do so. Scheme has shown that this can be done
> to great effect, and that when programmers are *guaranteed *that the tail
> call optimization will happen, possibilities of considerable power show up.
>

Actually require is like return in the cases where it could not be
tail call optimized.

> You also give some things up. For example, if you wish to target the JVM,
> it is all but impossible to do it efficiently, because the JVM imposes
> rules about stack frames which make it impossible. (You can do it with
> trampolines, but at a considerable efficiency cost.)

Clojure has a special syntax to recur to the same function as the only
non-stack consuming looping construct, but it can only do looping, not
CPS style computation.

>
> I think it would be interesting to see what happens if something like this
> were done in Go, but experience shows that if you make it an optional thing
> the compiler *might *do (which is what GCC does, for example), then you
> don't get much benefit from it as a programmer; and if you make it a rule
> which the compiler *must *do, then programmers depend on it, and you can't
> remove the requirement without turning working code into broken code. So
> it's a Pretty Big Decision.
>

I agree it's a big decision, I'm just interested if anyone sees value
in this, the way it was done in Alef.

> Thomas
>
>
>
>
>
>
>
> On Tue, Feb 14, 2012 at 2:58 PM, David Leimbach <leim...@...> wrote:
> > Was thinking a little about Alef today.  Seemed like a pretty darned
> > nice language really that I hardly knew, and one of the things I
> > thought was rather novel about it was the "become" statement.
>
> > From the Alef User's Guide found here:
> >http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ug
>
> > "The become statement transfers control in one of two ways. If its
> > operand evaluates to anything other than a function, become behaves as
> > a return statement yielding the result of the evaluation. When the
> > operand is a function returning exactly the same type as the current
> > function, the current function is replaced by the operand function and
> > control is transferred to the beginning of that function. There is a
> > crucial difference between a subroutine call and this form of function
> > invocation: the former creates a new subroutine context on the stack
> > before transferring control; the latter replaces the current function
> > context with the new context and transfers control. When a function
> > invokes itself or when several functions invoke each other via mutual
> > recursion using become, the computation runs in constant space. When
> > used in this form, the become statement is useful for implementing
> > functional style programs.
> > "
>
> > I think this could be an interesting addition to Go, especially around
> > interface types.  It could enable some kinds of CPS style programming
> > that isn't really easily achieved in C or C++ without setjmp/longjmp
> > or ucontext stuff.
>
> > Anyone else think this is interesting?

Re: Re: Something from Alef - the become statement

Re: Re: Go I/O not failsafe?

On Wed, Feb 15, 2012 at 1:54 AM, Mike Coleman <tutufan@...> wrote:
> Just to clarify, by "novice" programmers, I don't really mean CS101
> students.  I'm talking about scientists/accountants/many sysadmins/
> etc--people who don't care about programming per se, but who are just
> trying to solve a problem.

Go is not the language for people that can't handle doing error checking.
If you can't handle checking for an error then it's unlikely you'll
take in to account integer overflows, avoid race conditions, safely
concurrently access memory and resources , deal with mutable state,
deadlocks, livelocks and all the other things that come with using a
systems language.
Non-programmer scientists/accountants/sysadmins will likely have more
luck with python, their code will be small, slow, single threaded and
unreliable anyway.

> Here is my definition of "failsafe".  If I run the standard "hello
> world" program in a language like so
>
>    $ ./helloworld > /dev/full
>
> it should bomb, with both an error message complaining about a failed
> write, and an error status.

This seems like a fairly leak definition of "failsafe", there are
plenty of other ways for code to fail badly that doesn't involve any
I/O or any errors. These are generally called "bugs" and occur when a
program acts in a way the programmer didn't expect. They often lead to
silent data corruption and are often quite hard to find.

Missing error checks are easy to find in comparison, they are so easy
that a program can be written to find them. So it seems silly to spend
any time worrying about them.

--

-- 
=====================
http://jessta.id.au

Re: Something from Alef - the become statement

On Feb 14, 3:47 pm, Evan Shaw <eds...@...> wrote:
> It's an interesting idea, but I think I would rarely use this feature
> in practice. I'll default to being opposed to adding it.

On deeper reflection I'm beginning to agree with you.

In trying to explore this further a bit I'm having some trouble coming
up with a good way for this to work out with respect to panic/recover.

func OpenCPS(name string, onError func(Error), next func(*File))  {
    file, err := os.Open(string)
    if file != nil {
        become next(file)
    }
    else if err != nil {
        become onError(err)
    }
}

A couple things look a bit weird here.

1. Become doesn't feel like it would work very well the way Go
currently works with return statements. With the version of Go I have
installed, Go would complain if I used "return" where "become" is
here.  Become would have to be the last statement of the function to
avoid that and that seems to mean that I'd need to capture both the
function in some external var as well as the arguments to it that are
appropriate.  It would be a function of interface{} with an
interface{} var.  Messy.

2. What happens with Panic/Recover when one becomes another function?

This could get really hairy really fast I reckon.

Go really doesn't need to be a functional language anyway .

Dave

Re: Something from Alef - the become statement

On Feb 14, 4:59 pm, "Thomas Bushnell, BSG" <tbushn...@...>
wrote:
> On Tue, Feb 14, 2012 at 4:57 PM, David Leimbach <leim...@...> wrote:
>
> > Sometimes you want to be able to get a stack trace, and other times
> > you want the TCO to happen.  You can let other people argue about
> > whether it's good to be implicit or explicit about this .
>
> Most Scheme systems deal with this by tracing function invocations, which
> (it turns out) is usually even more valuable than a stack trace. They
> maintain a (variably sized) buffer which you can use to hold as many as you
> want.
>

It's like a built-in Writer Monad!

> Thomas

Blog post about new go tool

Re: Reading cookies

Re: Blog post about new go tool