Re: Allow ambiguous types (with warning) by default

[Sumit Sahrawat, Maths & Computing, IIT (BHU)]

We could have a LANGUAGE pragma that makes the language easier for
beginners.
Provided it would not change anything major, otherwise it will be hard to
decide how much to simplify the language.
We can restrict it to only enabling some other extensions, one of which
could be AllowAmbiguousTypes.

On 6 December 2015 at 04:51, David Kraeutmann  wrote:

> I'm strongly against this, for a multitude of reasons. There's already a
> mechanism for doing what you want -- type defaulting. See also
> https://ghc.haskell.org/trac/ghc/ticket/8171 .
>
> On 12/5/2015 11:38 PM, David Feuer wrote:
> > The ambiguity check produces errors that are quite surprising to the
> > uninitiated. When the check is suppressed, the errors at use sites are
> > typically much easier to grasp. On the other hand, there's obviously a
> lot
> > of value to catching mistakes as soon as possible. Would it be possible
> to
> > turn that into a warning by default?
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Regards

Sumit Sahrawat
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remote GHCi

[Sumit Sahrawat, Maths & Computing, IIT (BHU)]

Hi Simon,

IHaskell  makes use of
dynCompileExpr to evaluate code provided by the user, so that the result
can be sent to the frontend to be displayed.

I don't think we can make it work without using dynCompileExpr, Andrew
would have more to say about this.

On 17 November 2015 at 16:10, Alan & Kim Zimmerman 
wrote:

> This fits in directly with what I am trying to do for the
> haskell-ide-engine, where the intention is to expose ghci via an
> asynchronous process with communication via message passing.
>
> A bonus would be to have two separate interfaces, one for REPL interaction
> for the user, the other to be able to query properties of the loaded code.
>
> I am currently investigating exposing Behavior and RunTerm from haskeline
> to create a message passing backend instead.
>
> Alan
> On 17 Nov 2015 12:11 PM, "Simon Marlow"  wrote:
>
>> Hi folks - I've been thinking about changing the way we run interpreted
>> code so that it would be run in a separate process.  It turns out this has
>> quite a few benefits, and would let us kill some of the really awkward
>> hacks we have in GHC to work around problems that arise because we're
>> running interpreted code and the compiler on the same runtime.
>>
>> I summarised the idea here:
>> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
>>
>> I'd be interested to hear if anyone has any thoughts around this,
>> particularly if doing this would make your life difficult in some way. Are
>> people relying on dynCompileExpr for anything?
>>
>> Cheers,
>> Simon
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Regards

Sumit Sahrawat
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remote GHCi

[Sumit Sahrawat, Maths & Computing, IIT (BHU)]

The use-case which I've worked on deals with widget messages. Widgets are
stored inside the kernel, and can recieve signals from user code, frontend
events etc.

To capture messages sent by the user code, the messages are queued in a
TChan inside the interpreter environment. Messages from this TChan are
extracted into the kernel using dynCompileExpr and fromDynamic, and
processed as required.

The user input code is executed in the interpreter context, but we also
need to gather information some more information from the context, which is
why dynCompileExpr is crucial there.

On 17 November 2015 at 19:59, Richard Eisenberg  wrote:

> How does this interact with typechecker plugins? I assume they would still
> happen in GHC's process.
>
> I've also been thinking about designing and implementing a mechanisms
> where programmers could specify custom pretty-printers for their types, and
> GHC would use these pretty-printers in error messages. This action would
> also probably need to be in the same process.
>
> Would either of these ideas be affected? My guess is "no", because we
> should be able to be selective in what gets farmed out to the second
> process and what stays locally.
>
> Richard
>
> On Nov 17, 2015, at 5:10 AM, Simon Marlow  wrote:
>
> > Hi folks - I've been thinking about changing the way we run interpreted
> code so that it would be run in a separate process.  It turns out this has
> quite a few benefits, and would let us kill some of the really awkward
> hacks we have in GHC to work around problems that arise because we're
> running interpreted code and the compiler on the same runtime.
> >
> > I summarised the idea here:
> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
> >
> > I'd be interested to hear if anyone has any thoughts around this,
> particularly if doing this would make your life difficult in some way. Are
> people relying on dynCompileExpr for anything?
> >
> > Cheers,
> > Simon
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards

Sumit Sahrawat
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] A GC'd heap using weak pointers

[Sumit Sahrawat, Maths & Computing, IIT (BHU)]

This would be well recieved on ghc-devs mailing list. Adding to cc.

On 6 October 2015 at 15:55, Thomas Koster  wrote:

> Good afternoon list,
>
> I am implementing a simple, interpreted language that needs a garbage-
> collected heap for storage. Like most discussions on memory management,
> I use the term "heap" by analogy - the actual data structure is not
> necessarily a true heap.
>
> My Heap type is basically a map of "addresses" (Int) to values. Values
> may themselves contain addresses, perhaps recursively to each other
> (like letrec). The extra field in Heap stores the next unused address,
> used to allocate fresh slots, as you can see in "heapAlloc".
>
> > type Address = Int
> > data Value = ...things with Addresses...
> > data Heap = Heap !Address (Map Address Value)
> >
> > heapAlloc :: Heap -> (Address, Heap)
> > heapAlloc (Heap nextFreeAddr binds) =
> >   (nextFreeAddr, Heap (succ nextFreeAddr) binds)
>
> There is also a stack of roots and an expression under evaluation.
>
> > type Stack = [...things with Addresses...]
> > data Expr = ...things with Addresses...
>
> The function I need to write is:
>
> > heapGC :: [Address] -> Heap -> Heap
> > heapGC roots heap = ...collect unreachable values from heap...
>
> Rather than re-invent this particularly complex wheel, I am wondering
> if I could use GHC weak pointers and have the GHC runtime collect values
> in my heap for me. Something like this:
>
> > type Address = Int
> > data Reference = Reference Address
> > data Value = ...things with References...
> > data Heap = Heap !Address (Map Address (Weak Value))
> >
> > heapAlloc :: Heap -> (Reference, Heap)
> > heapAlloc (Heap nextFreeAddr binds) =
> >   (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds)
> >
> > heapStore :: Reference -> Value -> Heap -> IO Heap
> > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do
> >   weakVal <- mkWeak ref val Nothing
> >   return $ Heap nextFreeAddr (Map.insert addr weakVal binds)
>
> Note the new type, Reference. This replaces Address everywhere except
> in the heap's internal structure, which continues to use Address.
> Reference values are opaque, unique and obtained from the heap using
> heapAlloc.
>
> The idea is that only two things should cause Values to stay alive:
> 1. reachable holders of Reference (by GHC's definition of "reachable"),
> 2. ordinary Haskell closures arising from stepping the interpreter.
> "Being in the Heap" should not be enough to keep a Value alive. Then,
> my heapGC function should only have to prune dead addresses from the
> map.
>
> I am having trouble getting a proof-of-concept working (I am unable to
> observe any finalizers running, ever), but before I get into that, is
> this idea sound? Has somebody else implemented this in a library
> already?
>
> Thanks,
> Thomas Koster
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Regards

Sumit Sahrawat
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs