Re: Announcement: Beta of Leksah IDE available

J__rgen Nicklisch-Franken <jnf <at> arcor.de> wrote:

> So I please the members of the community to pause for a moment and try
> out Leksah with a benevolent attitude.
>
I did (the previous version, tbh), and couldn't find anything to
seriously bicker about... a few problems regarding metadata generation,
but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be
able to close the toolbar by pressing on one of its buttons that
incidentally looks just like the one to close a file.

Completition already rocks, the interface is nicely configurable
(although I resorted to editing config and session files instead of
using gui commands[1]), project management worked out fine (after I
figured out that I had to manually configure leksah to pass --user to
cabal), all in all it's an impressive piece of code that radiates later
uberness instead of lacking features. Last, but not least, it's _fast_,
_waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are
concerned, it's also complete.

The one thing that keeps me from switching to it, right now, is the
editor not being a vi. While gtksourceview might be, in theory,
a usable editor, my muscle memory tells me otherwise. It'd be like
switching to autoconf for C development instead of just copying over my
beloved OMakefile.

Providing refactoring support would make it irresistible... maybe it's
time to add a plugin layer, so that things like vacuum or a wrapper
around hp2ps can register themselves with leksah, without giving up
their identity as stand-alone projects. Plugability is the one feature

Re: TMVar's are great but fail under ghc 6.10.1 windows

Alberto G. Corona  wrote:
> however, It happens that fails in my windows box with ghc 6.10.1  , single
> core
> 
> here is the code and the results:
> 
> -----------begin code:
> module Main where
> 
> import Control.Concurrent.STM
> 
> import Control.Concurrent
> import System.IO.Unsafe
> import GHC.Conc
> 
> 
> 
> mtxs=  unsafePerformIO $ mapM newTMVarIO $ take 5 $ repeat  0
> 
> proc i= atomically $ do
>  unsafeIOToSTM $ putStr $ "init of process "++ show i++"\n"

As Sterling points out, unsafeIOToSTM is really unsafe. A fundamental
restriction is that the IO action used with unsafeIOToSTM may not block.
However, putStr may block.

It's actually possible to do the logging without blocking:

>>> cut here >>>
module Main where

Re: Looking for practical examples of Zippers

G'day all.

Quoting Gü?nther Schmidt <gue.schmidt <at> web.de>:

> my quest for data structures continues. Lately I came across "Zippers".
>
> Can anybody point be to some useful examples?

This is a good example, currently in use in GHC:

   http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html

Cheers,
Andrew Bromage

Re: Is there a way to see the equation reduction?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: ANNOUNCE: vacuum-cairo: a cairo frontend to vacuum for live Haskell data visualization

On 2009 Mar 31, at 13:52, Sebastian Fischer wrote:
> On Mar 31, 2009, at 7:15 PM, Brandon S. Allbery KF8NH wrote:
>>> cabal: cannot configure vacuum-cairo-0.3.1. It requires svgcairo - 
>>> any
>>> There is no available version of svgcairo that satisfies -any
>>
>> This is looking for the Haskell svgcairo package, in other words  
>> the Haskell binding for the libsvg-cairo package that you have  
>> installed.
>
> Where do I get this? (It's not on Hackage) Is it usually installed  
> with Gtk2Hs?

Yes, if the libsvg-cairo library is found when you run configure for  
gtk2hs, it will be built.  So if you built gtk2hs before installing  
libsvg-cairo, rebuild and reinstall gtk2hs.

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Looking for practical examples of Zippers

Cristiano Paris wrote:
> On Tue, Mar 31, 2009 at 10:13 PM, Dan Weston <westondan <at> imageworks.com> wrote:
>>> What I've learned: Zippers are "structured collections[1] with a
>>> focus". Through a Zipper you can O(1) change the value of the focused
>>> element: that's the fundamental property. In addition, you can change
>>> the focus through a series of "moving" functions.

>> To clarify: there is no magic that turns a data structure into O(1) access,
>> just as a CPS transformation is not a magic bullet for speeding up programs.
>> Only the move functions (changing focus to some subset of "adjacent"
>> substructures) are O(1). Update functions need not be O(1). And amortized
>> random access time via a zipper is never less than amortized random access
>> of the optimal equivalent un-zippered data structure.
> 
> That's true. But, correct me if I'm wrong, updates on the focus site are O(1).

Yes. It's just that shifting the focus to the site from scratch does not
 take constant time, obviously.

Regards,
apfelmus

--
http://apfelmus.nfshost.com

Re: Is there a way to see the equation reduction?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: uvector package appendU: memory leak?

Manlio Perillo wrote:
> By the way, about insertWith/alter; from IntMap documentation:
> 
> insertWithKey: O(min(n,W)
> alter: O(log n)
> 
> So, alter is more efficient than insertWithKey?
> And what is that `W` ?

As Claus says it's the maximum (value of Int; number of keys). It's in 
an easily overlooked comment at the top of the IntMap page, last I checked.

As for which is faster, it depends. The O(min(n,W)) stuff is effectively 
linear because n can't exceed W (what would you use for the key?), but 
it's a smart linear that rivals O(log n). Because the values of n are so 
small, what really matters here are the constant factors not the 
asymptotic complexity. Also it depends a lot on what operations you 
really need.

If you're interested in the details, I highly recommend Okasaki&Gill's 
paper[1] where they introduce IntMap. It's eminently readable and gives 
comparative numbers to other datastructures for all the basic operations.

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5452

--

-- 
Live well,
~wren

Re: Re: Looking for practical examples of Zippers

Gü?nther Schmidt wrote:
> Thanks Don,
> 
> I followed some examples but have not yet seen anything that would show 
> me how, for instance, turn a nested Map like
> 
> Map Int (Map Int (Map String Double)
> 
> into a "zipped" version.

You can't. Or rather, you can't unless you have access to the 
implementation of the datastructure itself; and Data.Map doesn't provide 
enough details to do it.

One of the problems with trying to make a zipper for Data.Map is that it 
maintains a number of invariants on structure which would be tricky to 
fix up if someone changes things at the focused point. (Not impossible, 
but certainly tricky.)

Another tricky thing for this particular example is answering the 
question of what you want to call the "focus". Usually zippered 
datastructures are functors, so given F X we can pick one X to be the 
focus and then unzip the F around it. You can treat Map X Y as a functor 
(Map X) applied to Y. Here we'd get a zipper of (Map X) with amortized 
access time to the other Ys at neighboring Xs, which is nice but maybe 
not worth the overhead since we already have O(log n) access from the root.

But (Map X) Y misses half the point of Map: we can't change the Xs. We'd 
prefer something like Map as a functor on (X,Y), but if we took (X,Y) as 
the focus, then what should happen if someone changes the X? Changing X 
changes our position in the unzipped Map X Y, so we'd have to do some 
tricky things in order to refocus and maintain the balancing invariants 
of Map. Which is to say that Map isn't really a functor on (X,Y) so we 
can't rely on the structural properties of functors like we're used to 
when making zippers.

--

-- 
Live well,
~wren

Re: about the Godel Numbering for untyped lambda calculus

John Tromp wrote:
>> I am reading the book "The lambda calculus: Its syntax and Semantics" in the
>> chapter about Godel Numbering but I am confused in some points.
>>
>> We know for Church Numerals, we have Cn = \fx.f^n(x) for some n>=0,
>> i.e. C0= \fx.x and C
>> 1 = \fx.fx.
>>
>> >From the above definition, I could guess the purpose of this kind of
>> encoding is trying to encode numeral via terms.
>>
>> How about the Godel Numbering? From definition we know people say #M is the
>> godel number of M and we also have [M] = C#M to enjoy the second fixed point
>> theorem : for all F there exists X s.t. F[X] = X.
>>
>> What the mapping function # is standing for? How could I use it? What the #M
>> will be? How to make use of the Godel Numbering?
>>
>> Thank you very much!
> 
> My Wikipedia page on Binary Lambda Calculus.
> 
>   http://en.wikipedia.org/wiki/Binary_lambda_calculus
> 
> shows a simple encoding of lc terms as bitstrings, which in
> turn are in 1-1 correspondence with the natural numbers.
> 
> It also shows how to represent bitstrings as lambda terms,
> and gives an interpreter that extracts any closed term M
> from its encoding #M.
> 
> It also give several examples of how all that is applicable
> to program size complexity.

Also don't forget Jot[1]

[1] http://barker.linguistics.fas.nyu.edu/Stuff/Iota/

--

-- 
Live well,
~wren