Hi Max,
I don't have anything in a public repository at this time. I have been
exploring a series of designs in this space trying to see if any could be
applied to a system like GHC's bytecode interpreter, but up to now I've been
working mostly with cooperatively jitting x86-64 assembly to x86-64 a
2009/6/18 Edward Kmett :
> What is interesting is in a lazy setting, if you are tracing a bytecode
> representation that knows about allocation and thunks, you can do some
> additional optimizations in here. If on every path to a side exit or the end
> of the loop you find that the thunk is evaluat
I have been exploring a weak form of runtime strictness analysis in a
tracing JIT project of my own in the spirit of TraceMonkey. Basically a
tracing JIT doesn't compile blocks of code but instead once a tracing point
has been passed often enough, it starts a trace from that point logging the
serie
Paul,
Did you mean to say that const is strict in its first param and
lazy in its second (since const _|_ y = _|_)? Also, can you explain
your notation, how does a -> {S} -> b ->{L} a indicate the
strictness? Why not just {S} a -> {L} b -> a?
I'm sorry for the confusion. Indeed, const, as
Paul,
In trying to follow your email I got a bit confused by your notation -
const :: a -> b -> a const x y = x could read a -> {S} -> b -
>{L} a
Here, we have annotated the function-space constructor (->) with
information about whether the corresponding function is strict or
lazy
Ryan,
Also, partial application + seq throws a wrench in things: [...]
You're absolutely right. I did not take into account the effects of
seq in my previous post. However, this is exactly the subject of a
paper I presented at TFP, two weeks ago. A revised version of the
paper will be av
Also, partial application + seq throws a wrench in things:
seq (const undefined) ()
== ()
/= seq undefined ()
but
seq (const undefined ()) ()
== undefined
== seq undefined ()
So const is only strict in its first argument when fully applied; I
think any strictness annotation would have t
Stefan,
Thank you for the detailed response! In trying to follow your email I got a
bit confused by your notation -
const :: a -> b -> a
const x y = x
could read
a -> {S} -> b ->{L} a
> Here, we have annotated the function-space constructor (->) with
> information about whether the corres
Dear Paul,
This thread as well as your blog post is very interesting. Hopefully I
can add something more or less valuable to it.
On your blog, you mention that your scheme for run-time strictness
analysis doesn't work out because it'll have you force a function
first before you can find o
Thanks for replies everyone. :) I had not heard of Rice's theorem but it's
not too surprising.
A couple thoughts I had:
1. In general determining whether a function is strict is undecideable. But
a conservative approximation can certainly be guaranteed to terminate. And
what is stopping us from hav
I was recently trying to figure out if there was a way, at runtime, to do
better strictness analysis for polymorphic HOFs, for which the strictness of
some arguments might depend on the strictness of the strictness of function
types that are passed as arguments [1]. As an example, consider foldl.
On Sun, Jun 14, 2009 at 5:42 PM, Paul Chiusano wrote:
>
> Note that I'm not suggesting Haskell should do anything like this. I'm
> playing around with the ideas because I'm interesting in creating a lazy
> language and I was hoping to have strictness analysis be very predictable
> and uniform, som
On Sun, Jun 14, 2009 at 8:18 PM, Eugene Kirpichov wrote:
> The idea looks cool, but perfect strictness analysis is not possible,
> t.i. the problem of determining whether f _|_ = _|_ is undecidable,
> since it is a non-trivial property of f (there exist f's for which it
> is true, and ones for whi
2009/6/15 Paul Chiusano :
> Hello,
> I was recently trying to figure out if there was a way, at runtime, to do
> better strictness analysis for polymorphic HOFs, for which the strictness of
> some arguments might depend on the strictness of the strictness of function
> types that are passed as argu
Hello,
I was recently trying to figure out if there was a way, at runtime, to do
better strictness analysis for polymorphic HOFs, for which the strictness of
some arguments might depend on the strictness of the strictness of function
types that are passed as arguments [1]. As an example, consider f
15 matches
Mail list logo
