Dobes solution to (one of the) problems with closure capture might work.
Given this:
var x = 1;
val y = x + 1;
++x;
println$ y;
the problem is y (by specificaton) could be either 1 or 2, depending on whether
y
is eagerly evaluated (treated like a variable) or laz
When you say that "all hell breaks loose" if the target frame is not
active, what do you mean? Some kind of runtime error?
I thought the work with monads and option types was there to avoid this
kind of problem.
Maybe I've been overly brainwashed by the "goto haters" out there but I
don't think
On Fri, Aug 17, 2012 at 7:31 PM, john skaller wrote:
>
> On 18/08/2012, at 6:19 AM, Dobes Vandermeer wrote:
> >
> > What are you saying, is that your internal representation makes it
> difficult or impossible. However, this isn't the only representation
> available, so really what you are saying
On Fri, Aug 17, 2012 at 8:21 PM, john skaller wrote:
>
> On 18/08/2012, at 6:33 AM, Dobes Vandermeer wrote:
> >
> > Does the spec guarantee that a procedure without noinline will be
> inlined, that its vals will be passed by value?
>
> Nope. Don't use vals if you want eager evaluation. That's wha
On 20/08/2012, at 3:07 PM, Dobes Vandermeer wrote:
> When you say that "all hell breaks loose" if the target frame is not active,
> what do you mean? Some kind of runtime error?
On my sample, an infinite loop happened.
I'm not sure how to stop this. It can probably be done.
Normally its safe
On 20/08/2012, at 3:24 PM, Dobes Vandermeer wrote:
>
> let ?x = expr in
>
> where you cannot refer to x until after it is initialised.
>
> RIght - just treat every var ... and val ... as if it is opening a new let
> starting at that point and continuing to the end of the block it is in
On Sun, Aug 19, 2012 at 12:37 AM, john skaller <
skal...@users.sourceforge.net> wrote:
> Dobes solution to (one of the) problems with closure capture might work.
>
> Given this:
>
> var x = 1;
> val y = x + 1;
> ++x;
> println$ y;
>
> the problem is y (by specificat
On 20/08/2012, at 3:46 PM, Dobes Vandermeer wrote:
>
> A "value" would be the result of a computation - thus eager evaluation.
> Instead you are treating the val as the computation itself, potentially
> deferred.
>
> This means that in fact a val is not a value, but a function that takes no
On 20/08/2012, at 3:46 PM, Dobes Vandermeer wrote:
>
> The keyword "fun" is used to define functions, it may be suitable for this as
> well. If you allow one to define a type of function that takes no parameter
> and doesn't require any parameter (not even unit) to be passed:
>
> fun x => y
On 20/08/2012, at 4:30 PM, Dobes Vandermeer wrote:
>
> There's a kind of program transformation called "static single assignment"
> (SSA) that views each assignment to a local variable (var) as a new name.
Indeed. Felix does that. I previously described it, in terms
of unravelling and re-ravell
10 matches
Mail list logo
