[Haskell-cafe] Re: Ambiguous type variable woes

[Gleb Alexeyev]

Jacques Carette wrote:

-- This does not however help at all!  The only way I have found of 
'fixing' this requires annotating the code itself, which I most 
definitely do not want to do because I specifically want the code to be 
polymorphic in that way.  But GHC 6.8.2 does not want to let me do this.


What are my options?


If my guess is correct (sorry if it's not), you want the code to be 
polymorhic so that you don't have to write the shape of the stack twice. 
Then the way out is to annotate the type of 'empty':


test1 = first . p 2 . p 3 $ (empty :: ((), Void))

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] RE: [Haskell] GHC 6.10 and OpenGL

[Simon Peyton-Jones]

| It's sad to see the OpenGL binding being dropped from GHC binary
| installers starting from 6.10. Though this issue has been brought up
| and discussed before, I'm sure a lot of people who based their work on
| OpenGL would share the same sympathy.

The plan (which we have perhaps not articulated as clearly as we should) is 
this:

- We are trying to make the GHC release contain as few libraries as possible
- Instead, you get the batteries for GHC (ie the libraries) from the Haskell 
Platform
http://www.haskell.org/haskellwiki/Haskell_Platform

This lets GHC HQ get out of the library business, and makes it easier to 
upgrade libraries independently from GHC.  But it does mean that GHC without 
the batteries is a feeble thing.  You really want to wait until the HP comes 
out.

The HP will be released in source form, to be installed by cabal-install, of 
course. But I believe that the intention is that there should be a Windows 
installer for it too.

Things I am less clear about
 - When will the first HP release compatible with GHC 6.10 appear?
 - How do users get cabal-install in the first place?  Is there
a windows installer for it?
 - Where can one find an up-to-date list of what packages are in HP?
 - Is there anyone who is actually planning to do the work of making
a windows installer for the HP?  The HP home page lists only
Duncan and Don.

I think it'd be good if it was easy to answer these questions from the HP home 
page.

Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Request for code review: slice-1.0.0, TestSupport

[Owen Smith]

Hi all,

Thanks for your welcome and helpful comments. I've banged out a first
attempt at a Haskell library and was curious if anybody would have
time or interest in looking it over it for style, design, stuff that's
just wrong, or (most likely) stuff that's been done better elsewhere.
I'm willing to trade some labor in kind, if there's any odd jobs that
can be done by a relative newbie (e.g. maybe setting up a Windows box
for OpenGL build testing with GHC 6.10??).

The library, slice, is an emulation of Python's list slicing mechanism:

http://www.owendsmith.com/slice-1.0.0.tar.gz

It uses a triple of Maybes to specify the range, so it's unwieldly in
terms of syntax, but the functionality should be there. Mostly,
besides gaining experience with writing a library, I wanted to have
functionality that skips through a list the way Python slices can, and
didn't see a particularly clean way of doing that particular kind of
list dicing in Data.List or elsewhere. (In particular, looking towards
an application where I'll need to split a list into odd-positioned
elements and even-positioned-elements.) I'm doubtful if this is worth
publishing as a real package, but maybe someone besides myself will
see something in it worth keeping.

One thing I did play with was hooking my unit tests into the Cabal
build system for my package; if I've read earlier posts correctly this
has not been done frequently or systematically, so if that's the case,
maybe this can be a contribution towards better testing support. The
scripts in the TestSupport module follow a pattern I've used elsewhere
in other languages: stomp through the Test directory hierarchy, find
all source files that start with Test, and run them on the fly using
runhaskell. This works beautifully if you happen to have runhaskell
installed and on your system path, but woe to you if you don't--and
I'm not sure how to properly capture that as a dependency in Cabal.
I'm also wondering if there's any existing Cabal support to configure
a proper location for this (I couldn't find it). And if that weren't
enough--if similar mechanisms to runhaskell exist for other compilers
that I should try to build into this somehow.

Thanks!
-- O
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ambiguous type variable woes

[Andrea Vezzosi]

If you want to defer the choice of 's' you've to make it appear in the type
signature of test1, so you've to introduce an artificial parameter even if
we're interested only in its type. e.g.:
data Proxy (s :: * - * - *)  -- useful because we can't have an argument
of type 's' directly, since it's higher-kinded,
  -- and to document that we're using a
phantom argument
proxy :: Proxy s
proxy = undefined

test1 :: Stack s = Proxy s - Integer
test1 pr = first . p 2 . p 3 $ empty `asTypeOf` toStack pr
   where toStack :: Proxy s - s a b
testTuple = test1 (proxy :: Proxy (,))

enabling LANGUAGE ScopedTypeVars you can rewrite test1 in a more direct
fashion:

test1 :: forall s. Stack s = Proxy s - Integer
test1 _ = fist . p 2 . p 3 $ (empty :: s () Void)


On Mon, Nov 24, 2008 at 5:09 AM, Jacques Carette [EMAIL PROTECTED]wrote:

 I was trying to create a typeclass for an abstract Stack class, and ran
 into some problems.  The following 'works' fine:

 {-# OPTIONS_GHC -XEmptyDataDecls -XFlexibleContexts
 -fno-monomorphism-restriction #-}
 module Stack where

 data Void

 class Stack s where
   push_ :: s a r - b - s b (s a r)
   empty :: s () Void
   top   :: s a (s b r) - (a, s b r)
   first :: s a r - a

 instance Stack (,) where
   push_ s a = (a,s)
   empty = ((),undefined::Void)
   top   = id
   first = fst

 p = flip push_
 test0 = top  . p 2 . p 3 $ empty

 -- But the following doesn't - I get an Ambiguous type variable `s' in the
 contraint `Stack s' arising from the use of `first':
 test1 = first . p 2 . p 3 $ empty
 -- sure, that makes sense, it somehow needs to know what flavour of Stack
 to use even though (or perhaps because) the answer is independent of it.
 -- So I listen to the probable fix and add a type signature:
 test1 :: Stack (,) = Integer

 -- This does not however help at all!  The only way I have found of
 'fixing' this requires annotating the code itself, which I most definitely
 do not want to do because I specifically want the code to be polymorphic in
 that way.  But GHC 6.8.2 does not want to let me do this.

 What are my options?

 Jacques
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Problem getting code from AFP08 parallel tutorial to run in parallel

[Olivier Boudry]

Hi all,

I'm reading the following tutorial:
http://research.microsoft.com/~simonpj/papers/parallel/AFP08-notes.pdf
A Tutorial on Parallel and Concurrent
Programming in Haskell and have problems getting the expected speed
improvement from running two tasks in parallel. With any version of
the code present in pages 1-7 of the tutorial I keep getting the CPU
stick to 50%.

I did not forget to compile the code with `-threaded` and run it with
`+RTS -N2` and it runs on a dual core machine on which I already used
the Control.Parallel.Strategies.parMap function and got 100% CPU
usage.

The first version of the parallel function in the tutorial (page 6) is:

parSumFibEuler :: Int − Int − Int
parSumFibEuler a b
  = f 'par' (f + e)
  where
f = fib a
e = sumEuler b

In the tutorial, swapping f and e on the 3rd line does the job, but in
my case it doesn't change anything.

C:\Temp\haskellghc --make -threaded SumEulerP6.hs
[1 of 1] Compiling Main ( SumEulerP6.hs, SumEulerP6.o )
Linking SumEulerP6.exe ...

C:\Temp\haskellSumEulerP6 +RTS -N1
sum: 119201850
time: 36.890625 seconds

C:\Temp\haskellSumEulerP6 +RTS -N2
sum: 119201850
time: 36.859375 seconds

Next page of the tutorial the tasks are explicitly sequenced so the
code does not depend on the ordering of the two `+` operands:

parSumFibEuler :: Int - Int - Int
parSumFibEuler a b
  = f `par` (e `pseq` (f + e))
where
  f = fib a
  e = sumEuler b

With once again a disappointing result:

C:\Temp\haskellghc --make -threaded SumEulerP7.hs
[1 of 1] Compiling Main ( SumEulerP7.hs, SumEulerP7.o )
Linking SumEulerP7.exe ...

C:\Temp\haskellSumEulerP7 +RTS -N1
sum: 119201850
time: 36.875 seconds

C:\Temp\haskellSumEulerP7 +RTS -N2
sum: 119201850
time: 36.75 seconds

I tried this on a Windows XP Dell Dual Core with GHC 6.10.1 and on a
iMac Dual Core with GHC 6.8.3 and got the same result on both. I'm
probably missing something really stupid but I'm lacking the parallel
thinking skills to understand how to look at the problem and resolve
it.

Any pointers?

Thanks,

Olivier.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: howto tuple fold to do n-ary cross product?

[Larry Evans]

On 11/24/08 00:40, Andrea Vezzosi wrote:
It's more natural to consider the cross product of no sets to be [[]] so 
your crossr becomes:


crossr [] = [[]]
crossr (x:xs) = concat (map (\h -map (\t - h:t) (crossr tail)) hd)

which we can rewrite with list comprehensions for conciseness:

crossr [] = [[]]
crossr (x:xs) = [ a:as |  a - x,  as - crossr xs ]

then look at the definition of foldr:
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)

and, considering (foldr f z) == crossr, you should derive the definition 
of f and z.


THANK YOU Andrea (and Luke) for prompting me to a solution:

  crossf::[[a]] - [[a]]

  crossf lls = foldr
(\hd tail - concat (map (\h -map (\t - h:t) tail) hd))
[[]]
lls

The reason I'm interested in this is that the cross product problem
came up in the boost newsgroup:

  http://thread.gmane.org/gmane.comp.lib.boost.devel/182797/focus=182915

I believe programming the solution in a truly functional language might
help a boost mpl programmer to see a solution in mpl.  I expect there's
some counterpart to haskell's map, concat, and foldr in mpl and so
the mpl solution would be similar to the above crossf solution.

-kind regards to both of you,

 Larry

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] SOEGraphics in GHC?

[Dmitri O.Kondratiev]

Please help, to locate in GHC distribution SOEGraphics library from
Paul Hudak, book The Haskell School of Expression
(http://www.haskell.org/soe/ )

Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: howto tuple fold to do n-ary cross product?

[apfelmus]

Luke Palmer wrote:
 Larry Evans wrote:

 contains a cross function which calculates the cross product
 of two lists.  That attached does the same but then
 used cross on 3 lists.  Naturally, I thought use of
 fold could generalize that to n lists; however,
 I'm getting error:
 
 The type of the function will not involve tuples, since they can be
 arbitrary length (dynamic-length tuples are not supported in Haskell;
 we use lists for that).
 
 cross :: [[a]] - [[a]]
 
 

This is the  sequence  function from Control.Monad.

  cross :: [[a]] - [[a]]
  cross = sequence

   cross [[1,2],[3,4]]
  [[1,3],[1,4],[2,3],[2,4]]



Regards,
apfelmus

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] SOEGraphics in GHC?

[David Leimbach]

Did you try clicking the links on that page you referenced?
There's one labelled software.

http://www.haskell.org/soe/software1.htm

Which shows source code links for SOE.

Dave

2008/11/24 Dmitri O.Kondratiev [EMAIL PROTECTED]

 Please help, to locate in GHC distribution SOEGraphics library from
 Paul Hudak, book The Haskell School of Expression
 (http://www.haskell.org/soe/ )

 Thanks!

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem getting code from AFP08 parallel tutorial to run in parallel

[Don Stewart]

Which version of GHC are you using?

This particular example triggers a boundary condition in ghc 6.10
where, with only one spark, GHC doesn't fire up the extra cpu. Try it
with 6.8.x to see that in action.

Simon Marlow may be able to comment more.

-- Don

olivier.boudry:
 Hi all,
 
 I'm reading the following tutorial:
 http://research.microsoft.com/~simonpj/papers/parallel/AFP08-notes.pdf
 A Tutorial on Parallel and Concurrent
 Programming in Haskell and have problems getting the expected speed
 improvement from running two tasks in parallel. With any version of
 the code present in pages 1-7 of the tutorial I keep getting the CPU
 stick to 50%.
 
 I did not forget to compile the code with `-threaded` and run it with
 `+RTS -N2` and it runs on a dual core machine on which I already used
 the Control.Parallel.Strategies.parMap function and got 100% CPU
 usage.
 
 The first version of the parallel function in the tutorial (page 6) is:
 
 parSumFibEuler :: Int − Int − Int
 parSumFibEuler a b
   = f 'par' (f + e)
   where
 f = fib a
 e = sumEuler b
 
 In the tutorial, swapping f and e on the 3rd line does the job, but in
 my case it doesn't change anything.
 
 C:\Temp\haskellghc --make -threaded SumEulerP6.hs
 [1 of 1] Compiling Main ( SumEulerP6.hs, SumEulerP6.o )
 Linking SumEulerP6.exe ...
 
 C:\Temp\haskellSumEulerP6 +RTS -N1
 sum: 119201850
 time: 36.890625 seconds
 
 C:\Temp\haskellSumEulerP6 +RTS -N2
 sum: 119201850
 time: 36.859375 seconds
 
 Next page of the tutorial the tasks are explicitly sequenced so the
 code does not depend on the ordering of the two `+` operands:
 
 parSumFibEuler :: Int - Int - Int
 parSumFibEuler a b
   = f `par` (e `pseq` (f + e))
 where
   f = fib a
   e = sumEuler b
 
 With once again a disappointing result:
 
 C:\Temp\haskellghc --make -threaded SumEulerP7.hs
 [1 of 1] Compiling Main ( SumEulerP7.hs, SumEulerP7.o )
 Linking SumEulerP7.exe ...
 
 C:\Temp\haskellSumEulerP7 +RTS -N1
 sum: 119201850
 time: 36.875 seconds
 
 C:\Temp\haskellSumEulerP7 +RTS -N2
 sum: 119201850
 time: 36.75 seconds
 
 I tried this on a Windows XP Dell Dual Core with GHC 6.10.1 and on a
 iMac Dual Core with GHC 6.8.3 and got the same result on both. I'm
 probably missing something really stupid but I'm lacking the parallel
 thinking skills to understand how to look at the problem and resolve
 it.
 
 Any pointers?
 
 Thanks,
 
 Olivier.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Don Stewart]

simonpj:
 
 | It's sad to see the OpenGL binding being dropped from GHC binary
 | installers starting from 6.10. Though this issue has been brought up
 | and discussed before, I'm sure a lot of people who based their work on
 | OpenGL would share the same sympathy.
 
 The plan (which we have perhaps not articulated as clearly as we should) is 
 this:
 
 - We are trying to make the GHC release contain as few libraries as possible
 - Instead, you get the batteries for GHC (ie the libraries) from the 
 Haskell Platform
 http://www.haskell.org/haskellwiki/Haskell_Platform
 
 This lets GHC HQ get out of the library business, and makes it easier to 
 upgrade libraries independently from GHC.  But it does mean that GHC without 
 the batteries is a feeble thing.  You really want to wait until the HP comes 
 out.
 
 The HP will be released in source form, to be installed by cabal-install, of 
 course. But I believe that the intention is that there should be a Windows 
 installer for it too.
 
 Things I am less clear about
  - When will the first HP release compatible with GHC 6.10 appear?

Next few weeks.

  - How do users get cabal-install in the first place?  Is there
 a windows installer for it?

Via binaries for their platform (e.g. windows .exe's).

  - Where can one find an up-to-date list of what packages are in HP?

The definitive version,

http://code.haskell.org/haskell-platform/haskell-platform.cabal

There's also a bug tracker.

  - Is there anyone who is actually planning to do the work of making
 a windows installer for the HP?  The HP home page lists only
 Duncan and Don.

We need a Windows platform champion, as we do for other distros, who's
in the business of making native packages for that key system.

Neil?

 I think it'd be good if it was easy to answer these questions from the HP 
 home page.
 

Yes!

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] SOEGraphics in GHC?

[sam lee]

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HGL
or
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/soegtk


2008/11/24 Dmitri O.Kondratiev [EMAIL PROTECTED]:
 Please help, to locate in GHC distribution SOEGraphics library from
 Paul Hudak, book The Haskell School of Expression
 (http://www.haskell.org/soe/ )

 Thanks!

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] monads with take-out options

[Greg Meredith]

Haskellians,
Some monads come with take-out options, e.g.

   - List
   - Set

In the sense that if unit : A - List A is given by unit a = [a], then
taking the head of a list can be used to retrieve values from inside the
monad.

Some monads do not come with take-out options, IO being a notorious example.

Some monads, like Maybe, sit on the fence about take-out. They'll provide it
when it's available.

Now, are there references for a theory of monads and take-out options? For
example, it seems that all sensible notions of containers have take-out. Can
we make the leap and define a container as a monad with a notion of
take-out? Has this been done? Are there reasons for not doing? Can we say
what conditions are necessary to ensure a notion of take-out?

Best wishes,

--greg

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Jason Dagit]

2008/11/24 Greg Meredith [EMAIL PROTECTED]

 Haskellians,
 Some monads come with take-out options, e.g.

- List
- Set

 In the sense that if unit : A - List A is given by unit a = [a], then
 taking the head of a list can be used to retrieve values from inside the
 monad.

 Some monads do not come with take-out options, IO being a notorious
 example.


I think the take-out option for IO is usually called 'main'. :)

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Jonathan Cast]

On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
 Haskellians,

 Some monads come with take-out options, e.g.
   * List
   * Set
 In the sense that if unit : A - List A is given by unit a = [a], then
 taking the head of a list can be used to retrieve values from inside
 the monad.

 Some monads do not come with take-out options, IO being a notorious
 example.

 Some monads, like Maybe, sit on the fence about take-out. They'll
 provide it when it's available.

It might be pointed out that List and Set are also in this region.  In
fact, Maybe is better, in this regard, since you know, if fromJust
succeeds, that it will only have once value to return.  head might find
one value to return, no values, or even multiple values.

A better example of a monad that always has a left inverse to return is
((,) w), where w is a monoid.  In this case,

snd . return = id :: a - a

as desired (we always have the left inverses

join . return = id :: m a - m a

where join a = a = id).

 Now, are there references for a theory of monads and take-out options?
 For example, it seems that all sensible notions of containers have
 take-out.

Sounds reasonable.  Foldable gives you something:

  foldr const undefined

will pull out the last value visited by foldr, and agrees with head at [].

 Can we make the leap and define a container as a monad with a notion
 of take-out?

If you want.  I'd rather define a container to be Traversable; it
doesn't exclude anything interesting (that I'm aware of), and is mostly
more powerful.

 Has this been done?

Are you familiar at all with Foldable
(http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%3AFoldable)
 and Traversable 
(http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable)

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Garbage collection as a dual of laziness?

[John Meacham]

A way this analogy breaks down is that lazyness evaluates precisely what
is needed, and no more. The set of values evaluated by lazyness is
exactly equivalent to the set of values needed.

Garbage collectors are conservative by nature, the values collected by
the garbage collector are some subset of the values that will not be
needed in the future, which particular subset that is depends on details
of the garbage collector and the optimizer.

Also, there is no real direct way to observe _when_ values have been garbage
collected (without resorting to weak pointers or implementation details)
so it is questionable what a correspondence will give you practically in
terms of reasoning ability. Whether the garbage was 'collected' right
away or when needed, as long as you don't run out of memory the program
is oblivious to it.

John



-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Windows vs. Linux x64

[Bartosz Wójcik]

Hi Everybody,

while working on my resent project I've noticed that my code seems to be 
faster under Windows than under Linux x64.
More exactly this was an AI game evaluator that ran on given parameters. There 
was no IO performed. I've run 3 lots of test on both systems and stored some 
figures. It was physicaly the same PC.

1st lot
WinXP 
total time = 27.18 secs (1359 ticks @ 20 ms) 
total alloc = 5,788,242,604 bytes (excludes profiling overheads)
Linux 
total time  =   34.44 secs   (1722 ticks @ 20 ms)
total alloc = 11,897,757,176 bytes  (excludes profiling overheads)

2nd lot
WinXP
total time = 63.96 secs (3198 ticks @ 20 ms) 
total alloc = 13,205,507,148 bytes (excludes profiling overheads)
Linux
total time  =   80.76 secs   (4038 ticks @ 20 ms)
total alloc = 27,258,694,888 bytes  (excludes profiling overheads)

3rd lot
WinXP
total time = 207.10 secs (10355 ticks @ 20 ms) 
total alloc = 44,982,716,780 bytes (excludes profiling overheads)
Linux
total time = 267.58 secs (13379 ticks @ 20 ms) 
total alloc = 92,307,482,416 bytes (excludes profiling overheads)

I've used the same compile and runtime options for both. I've tried to run 
with -H option, but this didn't improve anything. 
Is this common behaviour? Does anybody know what can be the reason?

regards,
Bartek


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Windows vs. Linux x64

[Don Stewart]

bartek:
 Hi Everybody,
 
 while working on my resent project I've noticed that my code seems to be 
 faster under Windows than under Linux x64.
 More exactly this was an AI game evaluator that ran on given parameters. 
 There 
 was no IO performed. I've run 3 lots of test on both systems and stored some 
 figures. It was physicaly the same PC.
 
 1st lot
 WinXP 
 total time = 27.18 secs (1359 ticks @ 20 ms) 
 total alloc = 5,788,242,604 bytes (excludes profiling overheads)
 Linux 
 total time  =   34.44 secs   (1722 ticks @ 20 ms)
 total alloc = 11,897,757,176 bytes  (excludes profiling overheads)
 
 2nd lot
 WinXP
 total time = 63.96 secs (3198 ticks @ 20 ms) 
 total alloc = 13,205,507,148 bytes (excludes profiling overheads)
 Linux
 total time  =   80.76 secs   (4038 ticks @ 20 ms)
 total alloc = 27,258,694,888 bytes  (excludes profiling overheads)
 
 3rd lot
 WinXP
 total time = 207.10 secs (10355 ticks @ 20 ms) 
 total alloc = 44,982,716,780 bytes (excludes profiling overheads)
 Linux
 total time = 267.58 secs (13379 ticks @ 20 ms) 
 total alloc = 92,307,482,416 bytes (excludes profiling overheads)
 
 I've used the same compile and runtime options for both. I've tried to run 
 with -H option, but this didn't improve anything. 
 Is this common behaviour? Does anybody know what can be the reason?

Is Windows running in 32 bit? What gcc versions are you using on each system?

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Greg Meredith]

Jonathan,
Nice! Thanks. In addition to implementations, do we have more mathematical
accounts? Let me expose more of my motives.

   - i am interested in a first-principles notion of data. Neither lambda
   nor π-calculus come with a criterion for determining which terms represent
   data and which programs. You can shoe-horn in such notions -- and it is
   clear that practical programming relies on such a separation -- but along
   come nice abstractions like generic programming and the boundary starts
   moving again. (Note, also that one of the reasons i mention π-calculus is
   because when you start shipping data between processes you'd like to know
   that this term really is data and not some nasty little program...) One step
   towards a first-principles characterization of data (as separate from
   program) is a first-principles characterization of containers.
  - Along these lines Barry Jay's pattern-matching calculus is an
  intriguing step towards such a characterization. This also links up with
  Foldable and Traversable.
  - i also looked at variants of Wischik's fusion calculus in which
  Abramsky's proof expressions characterize the notion of shippable data.
  (Part of the intuition here is that shippable data really ought to have a
  terminating access property for access to some interior region.
The linear
  types for proof expressions guarantee such a property for all well-typed
  terms.)
   - There is a real tension between nominal strategies and structural
   strategies for accessing data. This is very stark when one starts adding
   notions of data to the  π-calculus -- which is entirely nominal in
   characterization. Moreover, accessing some piece of data by path is natural,
   obvious and programmatically extensible. Accessing something by name is
   fast. These two ideas come together if one's nominal technology (think
   Gabbay-Pitt's freshness widgetry) comes with a notion of names that have
   structure.*
   - Finally, i think the notion of take-out option has something to do with
   being able to demarcate regions. In this sense i think there is a very deep
   connection with  Oleg's investigations of delimited continuations and --
   forgive the leap -- Linda tuple spaces.

As i've tried to indicate, in much the same way that monad is a very, very
general abstraction, i believe that there are suitably general abstractions
that account for a broad range of phenomena and still usefully separate a
notion of data from a notion of program. The category theoretic account of
monad plays a very central role in exposing the generality of the
abstraction (while Haskell's presentation has played a very central role in
understanding the utility of such a general abstractin). A similarly
axiomatic account of the separation of program from data could have
applicability and utility we haven't even dreamed of yet.

Best wishes,

--greg

* i simply cannot resist re-counting an insight that i got from Walter
Fontana, Harvard Systems Biology, when we worked together. In some sense the
dividing line between alchemy and chemistry is the periodic table. Before
the development of the periodic table a good deal of human investigation of
material properties could be seen as falling under the rubric alchemy. After
it, chemistry. If you stare at the periodic table you see that the element
names do not matter. They are merely convenient ways of referring to the
positional information of the table. From a position in the table you can
account for and predict all kind of properties of elements (notice that all
the noble gases line up on the right!). Positions in the table -- kinds of
element -- can be seen as 'names with structure', the structure of which
determines the properties of instances of said kind. i believe that a
first-principles account of the separation of program and data could have as
big an impact on our understanding of the properties of computation as the
development of the periodic table had on our understanding of material
properties.

On Mon, Nov 24, 2008 at 2:30 PM, Jonathan Cast [EMAIL PROTECTED]wrote:

 On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
  Haskellians,

  Some monads come with take-out options, e.g.
* List
* Set
  In the sense that if unit : A - List A is given by unit a = [a], then
  taking the head of a list can be used to retrieve values from inside
  the monad.

  Some monads do not come with take-out options, IO being a notorious
  example.

  Some monads, like Maybe, sit on the fence about take-out. They'll
  provide it when it's available.

 It might be pointed out that List and Set are also in this region.  In
 fact, Maybe is better, in this regard, since you know, if fromJust
 succeeds, that it will only have once value to return.  head might find
 one value to return, no values, or even multiple values.

 A better example of a monad that always has a left inverse to return is
 ((,) w), where w is a 

Re: [Haskell-cafe] Windows vs. Linux x64

[John Meacham]

Is the windows 32 or 64 bit, a while ago, ghc had trouble producing
efficient binaries for 64 bit intel systems. Something about the
interaction between gcc and the C it produced created some pessimal
assembly output. I do not know how much this is still an issue though.
You could try compiling 32 bit binaries under linux and running them on
the same machine (they will work on the 64 bit system) and compare the
results.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[John Meacham]

On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote:
 Now, are there references for a theory of monads and take-out options? For
 example, it seems that all sensible notions of containers have take-out. Can
 we make the leap and define a container as a monad with a notion of
 take-out? Has this been done? Are there reasons for not doing? Can we say
 what conditions are necessary to ensure a notion of take-out?

Yes, you are describing 'co-monads'. 

here is an example that a quick web search brought up, and there was a
paper on them and their properties published a while ago
http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html

the duals in that version are

extract - return
duplicate - join
extend  - flip (=) (more or less)

John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: cabal install HaXml installs wrong version unless I specify the version number

[Duncan Coutts]

On Mon, 2008-11-24 at 15:16 +0100, Thomas Hartman wrote:
 I have run into another issue with cabal packaging, which seems
 related to the issues discussed above. (see attached tar file for
 complete example of failure scenario)
 
 If I have a cabal package that depends on two other packages
   -- package xml-parsec requires HaXml == 1.19.4 (the latest)
   -- package HAppS-Server requires HaXml == 1.13.3 (the default)
 
 ghc --make testDepConflict.hs
   works fine.

Yes, it happens to work.

 But I can't install via cabal without, I guess, breaking out the
 conflict into a separate cabal package.

But cabal does not have enough information to know that it is going to
work, and in many similar situations it'll fail. So it errs on the side
of caution.

The potential problem is that types defined in the two different
versions of HaXml get used together in your package. Obviously that's
not happening in your example but consider the case of different
packages using different versions of the bytestring package and you
would see type errors where different versions of the bytestring type
get equated.

Specifically the cabal install solver tries to find a solution that uses
at most one version of each package. So that's why it declares that
those two packages conflict.

There's not a lot more we can do without having more information. For
example if we know that the two packages you're using do not re-export
any types from the HaXml package, and we could somehow declare and
enforce such private build dependencies then that would be more
information and the solver could allow private versions of a package to
be different.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage/Cabal/Haddock question

[David Waern]

2008/11/21 Robert Greayer [EMAIL PROTECTED]:
 How does Hackage run 'haddock' on uploaded packages?  I had assumed it 
 directly runs the cabal 'haddock' target, e.g.

 runhaskell Setup.hs haddock

 but it appears to perhaps be more complex than that.

 Some backrgound --

 haddock doesn't seem to like quasiquotation - running haddock on a source 
 tree that includes quasiquotations eventually results in:

 haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing

 (eliminating the code that contains [$xxx|] constructs gets rid of the 
 error.)

It's true that haddock can't handle qasi-quotation. I've filed a bug ticket:

  http://trac.haskell.org/haddock/ticket/66

David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Windows vs. Linux x64

[Don Stewart]

john:
 Is the windows 32 or 64 bit, a while ago, ghc had trouble producing
 efficient binaries for 64 bit intel systems. Something about the
 interaction between gcc and the C it produced created some pessimal
 assembly output. I do not know how much this is still an issue though.
 You could try compiling 32 bit binaries under linux and running them on
 the same machine (they will work on the 64 bit system) and compare the
 results.
 

I get better code on x86_64/linux than on x86/linux, fwiw, thanks to my
trusty gcc version 4.3.2.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Claus Reinke]

  - i am interested in a first-principles notion of data. Neither lambda
  nor π-calculus come with a criterion for determining which terms represent
  data and which programs. You can shoe-horn in such notions -- and it is
  clear that practical programming relies on such a separation -- but along
  come nice abstractions like generic programming and the boundary starts
  moving again. (Note, also that one of the reasons i mention π-calculus is
  because when you start shipping data between processes you'd like to know
  that this term really is data and not some nasty little program...)


I wouldn't call the usual representations of data in lambda shoe-horned
(but perhaps you meant the criterion for distinguishing programs from
data, not the notion of data?). Exposing data structures as nothing but
placeholders for the contexts operating on their components, by making
the structure components parameters to yet-to-be-determined continuations,
seems to be as reduced to first-principles as one can get.

It is also close to the old saying that data are just dumb programs
(does anyone know who originated that phrase?) - when storage
was tight, programmers couldn't always afford to fill it with dead
code, so they encoded data in (the state of executing) their routines.
When data was separated from real program code, associating data
with the code needed to interpret it was still common. When high-level
languages came along, treating programs as data (via reflective meta-
programming, not higher order functions) remained desirable in some
communities. Procedural abstraction was investigated as an alternative
to abstract data types. Shipping an interpreter to run stored code was
sometimes used to reduce memory footprint.

If your interest is in security of mobile code, I doubt that you want to
distinguish programs and data - non-program data which, when
interpreted by otherwise safe-looking code, does nasty things, isn't
much safer than code that does non-safe things directly. Unless you
rule out code which may, depending on the data it operates on, do
unwanted things, which is tricky without restricting expressiveness.

More likely, you want to distinguish different kinds/types of
programs/data, in terms of what using them together can do (in
terms of pi-calculus, you're interested in typing process communication,
restricting access to certain resources, or limiting communication
to certain protocols). In the presence of suitably expressive type
systems, procedural data abstractions need not be any less safe
than dead bits interpreted by a separate program. Or if reasoning
by suitable observational equivalences tells you that a piece of code
can't do anything unsafe, does it matter whether that piece is
program or data?

That may be too simplistic for your purposes, but I thought I'd put
in a word for the representation of data structures in lambda.

Claus

Ps. there have been lots of variation of pi-calculus, including
   some targetting more direct programming styles, such as
   the blue calculus (pi-calculus in direct style, Boudol et al).
   But I suspect you are aware of all that.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] build tools and Cabal

[John Lato]

Hello,

Cabal allows specifying arguments for tools it recognizes on the
command line, e.g.

runhaskell Setup.hs configure --c2hs-option=some_option

Unfortunately, I can't find a way to make this work with .cabal (or
.buildinfo) files, except for the specific cases of ghc, hugs, and
nhc98 options.  Am I missing something?  If not, could this be added
easily?  It would be very helpful as I'm trying to work around the
broken cpp Apple provides.

Thanks,
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage/Cabal/Haddock question

[Thomas Hartman]

I've noticed that many of the packages I upload to haddock don't build
documentation properly, although the documentation builds fine locally
when I run cabal haddock.

For example:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppSHelpers

is fine in my local environment.

I am not using quasiquotation. This also seems to be affecting many of
the other happs bundles.

thomas.

2008/11/21 Robert Greayer [EMAIL PROTECTED]:
 How does Hackage run 'haddock' on uploaded packages?  I had assumed it 
 directly runs the cabal 'haddock' target, e.g.

 runhaskell Setup.hs haddock

 but it appears to perhaps be more complex than that.

 Some backrgound --

 haddock doesn't seem to like quasiquotation - running haddock on a source 
 tree that includes quasiquotations eventually results in:

 haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing

 (eliminating the code that contains [$xxx|] constructs gets rid of the 
 error.)

 so runhaskell Setup.hs haddock ends up not generating any documentation.  I 
 worked around this problem by using a 'UserHook' and adding in an extra path 
 element to the source path prior to running haddock via Cabal:

 main = defaultMainWithHooks (simpleUserHooks {
 preHaddock = \_ _ - return (Just $ emptyBuildInfo { hsSourceDirs = 
 [noqqsrc]},[]) })

 The additional directory contains an alternate version of modules that don't 
 contain quasiquotation (just types and stubs), which seems to hide the 
 versions that do.  This works fine locally, but not on hackage (still get the 
 same behavior in the build failure log).  Of course, I'd prefer not to have 
 to do this at all, so if anyone knows a way around the problem (or if its 
 purely my problem -- I'm doing something wrong), I'd appreciate hearing about 
 it.

 I'm using GHC 6.10.1, and have tried setup haddock with both the 
 shipped-with-ghc version of haddock and the latest version.

 Thanks,
 rcg



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Request for code review: slice-1.0.0, TestSupport

[wren ng thornton]

Owen Smith wrote:

Hi all,

Thanks for your welcome and helpful comments. I've banged out a first
attempt at a Haskell library and was curious if anybody would have
time or interest in looking it over it for style, design, stuff that's
just wrong, or (most likely) stuff that's been done better elsewhere.
I'm willing to trade some labor in kind, if there's any odd jobs that
can be done by a relative newbie (e.g. maybe setting up a Windows box
for OpenGL build testing with GHC 6.10??).

The library, slice, is an emulation of Python's list slicing mechanism:

http://www.owendsmith.com/slice-1.0.0.tar.gz

It uses a triple of Maybes to specify the range, so it's unwieldly in
terms of syntax, but the functionality should be there.


This begs the question, why not use Haskell's enumeration syntax 
directly? That is, is there a specific reason you're using SliceParams 
instead of taking a list of indices as input? If you do the latter then 
Haskell already provides the [1,3..42] syntactic sugar (albeit, the 
second argument is the second element of the list with the step size 
inferred, rather than giving the step size explicitly).


Upsides of lists of indices:
* You can do Perl-style slicing where you can take the elements in 
whatever order you like, not just regular stepping orders. This is a 
two-edged sword, but it does make things much more concise than needing 
to manually stitch together a bunch of regular-step slices.


* You can allow a step size of 0 in order to get an infinite list of the 
element at that index. (Of course, you can do this with the current 
implementation by just allowing it.)


* You can piggyback on Haskell's syntactic sugar for regular step sequences.

* Negative indices are easy: let l = length xs in xs `slice` map (\i - 
if i  0 then l+i else i) indices  -- with some extra polish for 
boundary conditions.


* It can potentially be generalized to operate over any indexable 
collection. (Maybe more tricky than it's worth, if you want to guarantee 
efficiency.)



Downsides:
* Handling Perlish slicing is trickier since you may need to jump 
arbitrarily far back into the part of the list you've already seen. It's 
especially tricky if you don't want to hold onto the whole list when you 
don't need it.


* Constructing a list of indices from the [x,y..z] expression adds 
memory overhead if you don't do list fusion. (FWIW, using list fusion 
isn't too hard, heck you've basically rewritten a specialized case of it.)




Implementation-wise, you should use Data.List.Extras.LazyLength[1] for 
dealing with those guards. When you just want to guarantee a list's 
length is above or below some bound, getting the actual full length 
always wastes time and generally wastes space as well (by not being 
least-strict).


Similarly, if you do in fact need to get the full length of a list, you 
should bind it to a local variable so you needn't calculate it over and 
over. Also you can use case expressions (with a function like `compare`) 
to replace many of the guards more efficiently.


In the same vein, the `slices` function can be made much more efficient 
if you actually do a round-robin, instead of traversing the list 
repeatedly for each slice. Round-robining is much easier than doing 
slicing right anyways.


Finally, you may want to use Data.DList[2] in sliceRec, instead of 
constructing the list backwards and then reversing it. Difference lists 
have a constant-time append function, so you can eliminate the reversal 
thus saving O(m) time where m is the length of the list returned.


[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/list-extras

[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist


Mostly,
besides gaining experience with writing a library, I wanted to have
functionality that skips through a list the way Python slices can, and
didn't see a particularly clean way of doing that particular kind of
list dicing in Data.List or elsewhere.


A naive implementation of the arbitrary-indexing Perlish slicer:

 xs `slice` indices = map (xs !!) indices

Of course, this implementation is quite slow since it traverses the list 
from the beginning for each index. A smarter version would use something 
like a list zipper[3] so that the traversal time is bounded by the step 
size. In fact, difference lists can be thought of as a special case of 
zippers for lists.[4]


[3] http://en.wikibooks.org/wiki/Haskell/Zippers

[4] Where special means you only ever expand it down, and never move 
backwards. Difference lists can be generalized to other datastructures 
in the same way zippers can, though it seems much less common to do so.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Brandon S. Allbery KF8NH]

On 2008 Nov 24, at 17:06, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out  
options? For example, it seems that all sensible notions of  
containers have take-out. Can we make the leap and define a  
container as a monad with a notion of take-out? Has this been done?  
Are there reasons for not doing? Can we say what conditions are  
necessary to ensure a notion of take-out?


Doesn't ST kinda fall outside the pale?  (Well, it is a container of  
sorts, but a very different from Maybe or [].)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Greg Meredith]

Brandon,
i see your point, but how do we sharpen that intuition to a formal
characterization?

Best wishes,

--greg

On Mon, Nov 24, 2008 at 10:45 PM, Brandon S. Allbery KF8NH 
[EMAIL PROTECTED] wrote:

 On 2008 Nov 24, at 17:06, Greg Meredith wrote:

 Now, are there references for a theory of monads and take-out options? For
 example, it seems that all sensible notions of containers have take-out. Can
 we make the leap and define a container as a monad with a notion of
 take-out? Has this been done? Are there reasons for not doing? Can we say
 what conditions are necessary to ensure a notion of take-out?


 Doesn't ST kinda fall outside the pale?  (Well, it is a container of sorts,
 but a very different from Maybe or [].)

 --
 brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
 system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
 electrical and computer engineering, carnegie mellon universityKF8NH





-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monads with take-out options

[Greg Meredith]

Claus,
Thanks for your thoughtful response. Let me note that fully abstract
semantics for PCF -- a total toy, mind you, just lambda + bools + naturals
-- took some 25 years from characterization of the problem to a solution.
That would seem to indicate shoe-horning, in my book ;-). Moreover, when i
look at proposals to revisit Church versus Parigot encodings for data
structures (ala Oliveira's thesis), i think we are still at the very
beginnings of an understanding of how data fits into algebraic accounts of
computation (such as lambda and π-calculi).

Obviously, we've come a long way. The relationship between types and
pattern-matching, for example, is now heavily exploited and generally a good
thing. But, do we really understand what's at work here -- or is this just
another 'shut up and calculate' situation, like we have in certain areas of
physics. Frankly, i think we are really just starting to understand what
types are and how they relate to programs. This really begs fundamental
questions. Can we give a compelling type-theoretic account of the separation
of program from data?

The existence of such an account has all kinds of implications, too. For
example, the current classification of notions of quantity (number) is
entirely one of history and accident.

   - Naturals
   - Rationals
   - Constructible
   - Algebraic
   - Transcendental
   - Reals
   - Complex
   - Infinitessimal
   - ...

Can we give a type theoretic reconstruction of these notions (of traditional
data types) that would unify -- or heaven forbid -- redraw the usual
distinctions along lines that make more sense in terms of applications that
provide value to users? Conway's ideas of numbers as games is remarkably
unifying and captures all numbers in a single elegant data type. Can this
(or something like it) be further rationally partitioned to provide better
notions of numeric type? Is there a point where such an activity hits a wall
and what we thought was data (real numbers; sequences of naturals; ...) are
just too close to programs to be well served by data-centric treatments?

Best wishes,

--greg

2008/11/24 Claus Reinke [EMAIL PROTECTED]

  - i am interested in a first-principles notion of data. Neither lambda
  nor π-calculus come with a criterion for determining which terms
 represent
  data and which programs. You can shoe-horn in such notions -- and it is
  clear that practical programming relies on such a separation -- but along
  come nice abstractions like generic programming and the boundary starts
  moving again. (Note, also that one of the reasons i mention π-calculus is
  because when you start shipping data between processes you'd like to know
  that this term really is data and not some nasty little program...)


 I wouldn't call the usual representations of data in lambda shoe-horned
 (but perhaps you meant the criterion for distinguishing programs from
 data, not the notion of data?). Exposing data structures as nothing but
 placeholders for the contexts operating on their components, by making
 the structure components parameters to yet-to-be-determined continuations,
 seems to be as reduced to first-principles as one can get.

 It is also close to the old saying that data are just dumb programs
 (does anyone know who originated that phrase?) - when storage
 was tight, programmers couldn't always afford to fill it with dead
 code, so they encoded data in (the state of executing) their routines.
 When data was separated from real program code, associating data
 with the code needed to interpret it was still common. When high-level
 languages came along, treating programs as data (via reflective meta-
 programming, not higher order functions) remained desirable in some
 communities. Procedural abstraction was investigated as an alternative
 to abstract data types. Shipping an interpreter to run stored code was
 sometimes used to reduce memory footprint.

 If your interest is in security of mobile code, I doubt that you want to
 distinguish programs and data - non-program data which, when
 interpreted by otherwise safe-looking code, does nasty things, isn't
 much safer than code that does non-safe things directly. Unless you
 rule out code which may, depending on the data it operates on, do
 unwanted things, which is tricky without restricting expressiveness.

 More likely, you want to distinguish different kinds/types of
 programs/data, in terms of what using them together can do (in
 terms of pi-calculus, you're interested in typing process communication,
 restricting access to certain resources, or limiting communication
 to certain protocols). In the presence of suitably expressive type
 systems, procedural data abstractions need not be any less safe
 than dead bits interpreted by a separate program. Or if reasoning
 by suitable observational equivalences tells you that a piece of code
 can't do anything unsafe, does it matter whether that piece is
 program or data?

 That may be too simplistic for your