Re: [Haskell] Global Variables and IO initializers: A proposal and semantics

[Jules Bean]

On 12 Oct 2004, at 23:33, John Meacham wrote:
  and via the FFI  just a
 foreign import "&global_var" :: Ptr Int
  note that we do not need any foregin code, just an object which
allocates the space in the bss for global_var, the fact we can access
and work with such space from haskell, but have no way to allocate it
is quite telling that there is something missing in the language.
Yes, that's weird, isn't it?


The basic idea is that your entire program behaves as if in a giant
'mdo' block, ordered in module dependency order.

I wondered if something like that could work, but I wasn't sure that 
mdo allowed recursion in its let-bindings...

Jules
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] lazy constructors

[Serge D. Mechveliani]

Dear Haskellers,

I try to organize a `lazy' output in my program, so that the 
data are accumulated, step by step in a pair
 (String, String)
(a contrived simplified example).
And the first component is a `story' to be printed out in a `lazy'
manner, the first steps need to print without waiting for the whole
data field to be ready. 

If the program returns  String,  then I can arrange this.
But with  (String, String),  I do not know how to do.
And in the real progam, it is a more complex labeled record, carried
along through the program.
Probably, the obstackle is in the very Haskell language.
Consider a simple example:

---
bottomStr :: String
bottomStr = let xs = xs in xs

bottomSPair :: (String, String)
bottomSPair = let p = p in p

bound = 10^8  :: Int   -- some large number

f1, f2, g1, g2 :: Char

f1 = head ('a' :  (if last [1 .. bound] > 0 then "b" else "c"))

f2 = head ('a' : bottomStr)

g1 = head $ fst $ addToSPair 'a'
 (if  last [1 .. bound] > 0  then ("b", "") else ("c", ""))

g2 = head $ fst $ addToSPair 'a' bottomSPair

addToSPair :: Char -> (String, String) -> (String, String)
addToSPairc   (xs, ys) =  (c:xs,   ys)

main = putStr  [ f1,  '\n' ]
  -- f2
  -- g1, g2
---

g1 is similar to f1,  g2 similar to f2.

f1 and f2 are evaluated immediately to 'a';

g1 evaluates to 'a' after a long computation;
g2 evaluates to  Fail: <>

As g2 is similar to f2, should it have a value 'a' ?
In
   head $ fst $ addToSPair 'a' bottomSPair

bottomSPair  is of type  (String, String).
addToSPair   is declared as returning  (String, String).
Hence, the complier knows ab initio that after  addToSPair
the result is of kind
  ('a': _,  _) :: (String, String)

Hence, applying further   head $ fstyields  'a'.
This is in the air of a `lazy' computation.
In a more clear presentation, the computation should (?) be

   head $ fst $ addToSPair 'a' bottomSPair
   =
   head $ fst $ addToSPair 'a' (bottomStr, bottomStr)
   =
   head $ fst (`a':bottomStr, bottomStr)
   =
   head (`a':bottomStr)
   = 
   'a'

So, similarly as
  head ('a' : bottomStr)= 'a',   (1)
it should be
  head $ fst $ addToSPair 'a' bottomSPair   = 'a'(2)

Probably, Haskell-98 does not put so. Right?

Question 1
--
What may be the consequences for the language 
(let us call it HCLazy)  if it treats the data constructors like in 
(2), like more `lazy' ones?

For example,  fst (bottom :: (a,b)) =  (bottom :: a)


Question 2
--
How to arrange the above `lazy' output?
The whole result story is ready in several hours, or days,
and each step should be displayed immediately as it is ready.

So far, I see no other way as to compile the program together with 
the  Trace  library, inserting there the calls
\ step ... -> trace (show step) $ ...
(?)

Thank you in advance for the explanations.

Copy, please, the answer to  [EMAIL PROTECTED]

-
Serge Mechveliani
[EMAIL PROTECTED]




___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Wolfgang Thaller]

Well, Wadler's Law of Language Design has been disproved. We seem to 
agree on the syntax, that is, global "foo <- bar" bindings, and we're 
actually discussing semantics. That's great!

Just for the record, I want exactly what Adrian proposed.
There seem to be two interesting points about the semantics:
1) To prevent unwanted typecasts, all toplevel "<-" bindings must be 
monomorphic.

This restriction should be sufficient to keep everything perfectly safe
(does anyone disagree?), except for...
2) Evaluation order.
That's what everyone has been fighting about.
So what are our options?
a) unsafePerformIO - like.
This has some potential for abuse, but it works.
Lazy initialization is a good thing for large programs - and that 
includes side effects. People deliberately do that in OO programs - 
you'll find methods that look like getSomeMemberVar accessor methods, 
but the first time they're invoked, they'll actually initialize a part 
of the program. I'd actually like to abuse this feature that way.
Anyway, the non-determinism this introduces is not nearly as bad as 
what you get from concurrency or even signal handlers...

b) Some predetermined order, with semantics like mdo:
John Meacham wrote:
The basic idea is that your entire program behaves as if in a giant
'mdo' block, ordered in module dependency order.
What is module dependency order? There's no such thing when there are 
circular dependencies, and when there aren't any, it might still depend 
on the order of import directives, which is probably not something I 
want program semantics to depend on.
I feel that In a large program, you'll probably get more surprises from 
this.
The good thing is that you can always use unsafeInterleaveIO to get the 
other semantics back, so we should probably investigate this further.

Is there some option c) that I overlooked?
Another question is, if the order is to follow program order, what do 
we still need main for? Ugh...

Cheers,
Wolfgang
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Glynn Clements]

Vincenzo Ciancia wrote:

> > Unfortunately, in this case the whole point of what people are trying
> > to do with unsafePerformIO is to allow these things to be visible at
> > the top level :-)
> 
> Sometimes I get too much involved in what I think about, and forget the 
> original goal :) A little _too_ naive, it seems, I apologize. So it's 
> like the original idea, that using these toplevel IO bindings one has 
> to impose an order of evaluation over all program bindings, which 
> surely is against the current meaning of haskell programs, e.g. if I 
> say
> 
> conf <- readMyConfFile
> init = fn conf
> 
> people would agree that the correct meaning is to first evaluate all of 
> the IO bindings and then the rest of the program:
> 
> x1 <- a1
> ...
> xn <- an
> 
> v1 = expr1
> ...
> vn = exprn
> 
> main = action
> 
> should be equivalent to
> 
> main = do
>  x1 <- a1
>  ...
>  xn <- an
>  let v1 = expr1
>  ...
>  vn = exprn in
>action
> 
> This would not change the meaning of a standard haskell program I think 
> (but I am not an expert as you see). Am I wrong?

In the former, the variables have global scope, and may be exported
from the module. Also, what if you do this in a module other than
Main?

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Tuesday 12 Oct 2004 10:19 pm, Jules Bean wrote:
> It does matter for general IO operations at the top level.

All I'm aiming for is to disambiguate programs (avoid the use of
unsafePerformIO) in such a way that the programmer at least stands a
reasonable chance of getting it right without compiler optimisations
screwing things up.

> Order
> doesn't matter in in any essential way for the particular case of
> newIORef, no.

Or for a great many other IO operations that a programmer may wish
to use, though certainly not all that he could define (if sufficiently
malicious :-) 

> Now it's my turn not to understand you. What is a "thing with identity"?

Basically I mean some packet of state, where is makes a difference
which particular packet of state is referenced.

So an IORef is a reference to a "thing with identity".
Of course this is why the type of newIORef is..

newIORef :: a -> IO (IORef a)

not simply..

newIORef :: a -> IORef a

Any new "thing with identity" has be constructed via something like..

newThing :: IO Thing

..which makes it difficult to create such things at the top level, even
though (as Simon M pointed out) there's no problem with actually using
such things at the top level (assuming we had some magic that enabled
their creation).

Regards
--
Adrian Hey

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Global Variables and IO initializers: A proposal and semantics

[Greg Buchholz]

John Meacham wrote:
> 
> I have put some thought, some time ago, into the  'global
> initializers' problem in haskell but for various reasons never wrote
> up my conclusions.

I'm not really qualified to answer, but does anyone think that this
paper might have a solution? 

http://www.eecs.harvard.edu/~ccshan/prepose/prepose.pdf

   "The configurations problem is to propagate run-time preferences
throughout a program, allowing multiple concurrent configuration sets to
coexist safely under statically guaranteed separation.  This problem is
common in all software systems, but particularly acute in Haskell, where
currently the most popular solution relies on unsafe operations and
compiler pragmas.

We solve the configurations problem in Haskell using only stable and
widely implemented language features like the type-class system.  In our
approach, a term expression can refer to run-time configuration
parameters as if they were compile-time constants in global scope.
Besides supporting such intuitive term notation and statically
guaranteeing separation, our solution also helps improve the program's
performance by transparently dispatching to specialized code at
run-time.  We can propagate any type of configuration data---numbers,
strings, IO actions, polymorphic functions, closures, and abstract
data types.  No previous approach to propagating configurations
implicitly in any language provides the same static separation
guarantees."



Greg Buchholz
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Vincenzo Ciancia]

On Wednesday 13 October 2004 00:00, Adrian Hey wrote:
> Unfortunately, in this case the whole point of what people are trying
> to do with unsafePerformIO is to allow these things to be visible at
> the top level :-)

Sometimes I get too much involved in what I think about, and forget the 
original goal :) A little _too_ naive, it seems, I apologize. So it's 
like the original idea, that using these toplevel IO bindings one has 
to impose an order of evaluation over all program bindings, which 
surely is against the current meaning of haskell programs, e.g. if I 
say

conf <- readMyConfFile
init = fn conf

people would agree that the correct meaning is to first evaluate all of 
the IO bindings and then the rest of the program:

x1 <- a1
...
xn <- an

v1 = expr1
...
vn = exprn

main = action

should be equivalent to

main = do
 x1 <- a1
 ...
 xn <- an
 let v1 = expr1
 ...
 vn = exprn in
   action

This would not change the meaning of a standard haskell program I think 
(but I am not an expert as you see). Am I wrong? Could this be done 
with a preprocessor? Why not? 

V.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Global Variables and IO initializers: A proposal and semantics

[John Meacham]

I have put some thought, some time ago, into the  'global initializers' problem in
haskell but for various reasons never wrote up my conclusions.

The issues are
1) polymorphic references allow breaking of typesafety
2) when do the initializers get evaluated
3) do we need it? 

I will address these points in no particular order.

3) yes. the 
{-# noinline :: fooVar #-}
fooVar = unsafePerformIO $ newIORef 0
is a very common idiom in real programs, and very difficult to work
around not having.
and if that is not enough, a couple more points
* we can do it horribly inefficiently and unsafely already and the world
  has not collapsed:
  via getting and setting strings in the evironment we can create global variables 
holding read/showable values.
  via writing and reading temporary files
  and via the FFI  just a 
 foreign import "&global_var" :: Ptr Int
  note that we do not need any foregin code, just an object which
allocates the space in the bss for global_var, the fact we can access
and work with such space from haskell, but have no way to allocate it
is quite telling that there is something missing in the language.

1) This is a real problem. A straightforward solution is to enforce top-level
IO actions to be monomorphic. This is not a big restriction, as it is
the exact same restriction placed on bindings in 'do' blocks or on
lambda expressions. 

2) is the tricky one. 

One proposed solution is to treat the global binding

fooVar <- newIORef 0 as equivalant to 
fooVar = unsafePerformIO $ newIORef 0

with the appropriate compiler magic invoked to make sure that
optimizations do not ruin the intended effect that newIORef 0 is
executed exactly once and shared by (and only by) all uses of fooVar.

This has the advantage of being very easy to implement with ghc as it
currently is. ghc can just rewrite it as the above and turn off cse for
the module and inlining for the binding. 

but there are strong disadvantages:

 * we can observe execution order by making the top level bindings have side effects.
 * We may need or want the optimizations we have to turn off, A haskell
   implementation with aggressive inter-module optimization might end up
   having to turn them off for the whole program.
 * A semantic mess to formalize and hence to optimize (IMHO)
 * not optimally efficient, a thunk for 'fooVar' is still created, and the
   IORef is created on the heap.


A better way


The other way draws on the works done with fixIO and recursive monadic
bindings and is much more preferable in my estimation. In addition, Like
other syntatic sugar, it admits a simple rewriting to core haskell
without any special optimizer/compiler magic required and most of the
semantics work has already been done. 

The following papers have background material:
Recursive Monadic Bindings:
http://www.cse.ogi.edu/PacSoft/projects/rmb/mfix.ps.gz
Semantics of fixIO:
http://www.cse.ogi.edu/PacSoft/projects/rmb/fics.ps.gz


Unlike some other rewritings, it is not recommended this actually be
used to compile haskell programs (among other things, it would break
separate compilation as stated), the rewriting is used to show the
coorespondence between the semantics of fixIO as written in the paper
and global bindings. An actual efficient way to implement this idea
that behaves identically and allows separate compilation follows later.


The basic idea is that your entire program behaves as if in a giant
'mdo' block, ordered in module dependency order. 


so, 
module Main

import Bob 

fooVar <- newIORef bob
main = readIORef fooVar  >>= print

module Bob 

bob <- return 3


is transformed into

main = mdo
bob <- return 3
let main' =  readIORef fooVar >>= print
fooVar <- newIORef bob
main'


(if we were to actually carry out this transformation, appropriate
renamings will have to occur to avoid name capture, and the let bindings
in mdo must be of the polymorphic variety (see 3.2 of the first paper) )

note that normal values must be pushed ahead of all the global bindings
to ensure they scope properly over whery they may be used. (assuming the
polymorphic mdo notation described in the paper)


so the general tranformation results in 

newMain = mdo
# let values for module Foo
# global bindings for module Foo 
# let values for mutually recursive modules Bar and Baz
# global bindings for modules Bar and Baz
# let valuse for module Main
# global bindings for module Main
Main.main

note that mutually recursive modules must be treated as a unit and hence
the order their bindings occur in (across modules) is not well defined.
we can chalk this up to mutually recursive module oddness in general and
should not be a problem in practice.

This has a lot of nice properties, 
 * no unsafePerformIO like stuff.
 * evaluation order of the functional code does not matter, the IO actions
are carried out in the order stated in the m

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Tuesday 12 Oct 2004 10:47 pm, Marcin 'Qrczak' Kowalczyk wrote:
> Adrian Hey <[EMAIL PROTECTED]> writes:
> > The only real insanity with the current situation is the loss of
> > referential transparency implied by the use of unsafePerformIO,
> > which is why various pragma hacks and compiler switches need to be
> > used (in order to prevent inappropriate substitutions). What I want
> > to do is to make this or something similar "official", so the
> > compiler really knows not to do this inappropriate subsitution in
> > any event, even if the programmer forgot to use the necessary
> > pragmas or compiler flags, or just didn't understand why they are
> > needed.
>
> It's not the only problem:
> v = unsafePerformIO (newIORef undefined) :: IORef a
> You can store an Integer there and try to take out a String.

Yes of course, this is a well known problem with unsafePerformIO.
This is why in my earlier post I suggested that the use of special
syntax would also be a cue for the compiler to impose typing
restrictions.

Regards
--
Adrian Hey
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Tuesday 12 Oct 2004 8:43 pm, Vincenzo Ciancia wrote:
> The objection was for cases like
>
> x :: Int <- someIOAction
> y :: Int = x + 1
>
> Note that both have Int type but the second is a pure value while the
> first is the result of a computation.

Well obviously if people are going to use it stupidly (I.E. the value
returned by someIOAction is dependent on when it occurs) that might be
a bug. But there's really no guarantee of "sane" behaviour with
anything that's done in the via the IO monad (finalisers, forkIO..),
other than what the programmer ensures by writing bug free code.
So I dunno why we should insist on higher standards of sanity in
this case.

But there is a real fundamental problem with the only current
alternative (use of wierd library non-functions like unsafePerformIO),
in that the compiler itself cannot be relied upon to interpret the
program correctly and generate the code the programmer intended (at
least not unless the programmer understands the dangers and supplies
necessary flags & pragmas).

If I have..

myThing  = unsafePerformIO newThing
myOtherThing = unsafePerformIO newThing

Then conventional referential transparency means that the compiler
should be able to freely interchange (myThing),(myOtherThing) and
(unsafePerformIO newThing) anywhere it likes. Clearly a problem
if they're IORefs or similar.

By adding something like the myThing <- newThing at the top level
this danger could be eliminated. Certainly abuse is still possible,
but I don't care about that. (If some folk want to be that stupid
it's fine with me :-)

> I think that the easy way would be to allow a keyword like a top-level
> let, where a program like
>
> let x1 <- action1
> ...
> let xn <- actionn
>
> main = other_actions
>
> is equivalent to
>
> main = do
>  x1 <- action1
>  ...
>  xn <- actionn
>   other_actions
>
> top-level "ordinary" bindings can't see x1...xn, and order of evaluation
> is imposed.

Unfortunately, in this case the whole point of what people are trying to
do with unsafePerformIO is to allow these things to be visible at the top
level :-)

Regards
--
Adrian Hey

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[MR K P SCHUPKE]

>All we really need is a 'unique value monad' to give us unique values

This sounds a lot like Clean's unique-types?

Keean.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Marcin 'Qrczak' Kowalczyk]

Adrian Hey <[EMAIL PROTECTED]> writes:

> The only real insanity with the current situation is the loss of
> referential transparency implied by the use of unsafePerformIO,
> which is why various pragma hacks and compiler switches need to be
> used (in order to prevent inappropriate substitutions). What I want
> to do is to make this or something similar "official", so the
> compiler really knows not to do this inappropriate subsitution in
> any event, even if the programmer forgot to use the necessary
> pragmas or compiler flags, or just didn't understand why they are
> needed.

It's not the only problem:
v = unsafePerformIO (newIORef undefined) :: IORef a
You can store an Integer there and try to take out a String.

-- 
   __("< Marcin Kowalczyk
   \__/   [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Jules Bean]

On 12 Oct 2004, at 20:25, Adrian Hey wrote:
On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the 
unsafePerformIO
solution, I.E. Order unspecified, the action that creates a 
particular
top level thing is executed only once, when the value of thing is
demanded (perhaps not at all).
Also consider the case of
z = someAction(y)
Here z is a value outside the IO monad, calculated using a function
outside the IO monad, based on a value (y) which also lies outside the
IO monad... What sane semantics will explain when the actions which 
led
to the value y should be taken?
I've never really understood what people mean by things being "inside" 
and
"outside" the IO monad :-(

Assuming from Vincenzos original example that ..
someAction :: SomeType -> IO Thing
then in your example..
z :: IO Thing
Yes, I wrote it wrong. I meant
z = someFunction(y)
'Inside the IO Monad' means having some type IO a. Outside it means 
having a type not of this form. At least, that's what I meant. 
[Vincent's explanation is another way of looking at it]

This still leaves the uncertainty of exactly when the creation occurs,
but this is a minor issue IMO. We have the same problem with finalisers
and any concurrent code. Either it just doesn't matter, or if it does
then it's the programmers responsibility to use existing mechanisms
(such as seq) to control things.
It does matter for general IO operations at the top level. Order 
doesn't matter in in any essential way for the particular case of 
newIORef, no.

What I want is non-hack mechanism for creation of arbitrarily complex
"things with identity" at the top level. I guess you could arrange that
all such things were constructed at run time before executing main, but
I don't see any real advantage in that.
Now it's my turn not to understand you. What is a "thing with identity"?
Jules
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Jules Bean]

On 12 Oct 2004, at 18:59, Marcin 'Qrczak' Kowalczyk wrote:
Jules Bean <[EMAIL PROTECTED]> writes:
I think what people are trying to suggest is an 'initialization
phase' in the IO monad, which takes place "before" the pure
functions are defined.
If it was done before, what could you use to specify initial value of
such a variable? Only literals? Constructors? Named constants? Results
of arithmetic operations? Results of arbitrary functions?
Yes, that's what I was trying to get at. But you said it much better...
The well-definedness of a global IORef relies on the fact that
creation of an IORef doesn't have visible side effects, so it doesn't
matter when it happens, as long as it happens once between the
variable is used. An arbitrary IO computation doesn't have this
property.
Indeed.
There are other hacks you can think of, though, if IORefs are your only 
goal. For example, something like

getIORef :: Int -> a -> IORef a
or
getIORef :: String -> a -> IORef a
(importantly, it's IORef, not IO IORef.)  But this isn't great for 
programmer convenience, since there's nothing to help him discipline 
the use of particular variables.

All we really need is a 'unique value monad' to give us unique values 
to be keys for IORefs (or whatever else), and allow this monad to be 
accessible at the top level. Conceptually this monad is commutative, so 
ordering of the actions doesn't matter.

Jules
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Building from source

[Andre W B Furtado]

Christian Maeder wrote:
> [compilation] failed in the directory hood,
> because the target boot is unknown there.
> Could/Should this be fixed?

BTW, nofib is also breaking the fptools suite compilation.

Cheers,
-- AFurtado
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Vincenzo Ciancia]

On Tuesday 12 October 2004 21:25, Adrian Hey wrote:
> I've never really understood what people mean by things being
> "inside" and "outside" the IO monad :-(

Inside the IO monad means "correctly sequenced together with other IO 
operations which are inside the IO monad". It's called "inside" since 
people (me at least) view the IO monad as a one-way thingy where you 
have only an entry point (the main function), so you can either be 
"inside" and correctly sequenced, or "outside" like an 
unsafeInterleaveIO computation.

>
> Assuming from Vincenzos original example that ..
>
> someAction :: SomeType -> IO Thing
>
> then in your example..
>
> z :: IO Thing
>
> So z is a perfectly ordinary value. The someAction that creates y
> will be executed only once, as soon as the value of y is needed,
> which (assuming someAction is strict) will be as soon as the value of
> z is needed, I.E. "Whenever"

The objection was for cases like

x :: Int <- someIOAction
y :: Int = x + 1

Note that both have Int type but the second is a pure value while the 
first is the result of a computation.

I think that the easy way would be to allow a keyword like a top-level 
let, where a program like

let x1 <- action1
...
let xn <- actionn

main = other_actions

is equivalent to

main = do
 x1 <- action1
 ...
 xn <- actionn
  other_actions

top-level "ordinary" bindings can't see x1...xn, and order of evaluation 
is imposed. Or else you can simply say that NO binding, even x1...xn 
can see the others. This could be done with a special keyword and 
source-code preprocessing; ok, I am sorry for such a naive point of 
view - I mean the whole post :)

V.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
> On 12 Oct 2004, at 14:08, Adrian Hey wrote:
> >> x <- someAction
> >> y <- someAction(x)
> >
> > I would say keep things as they currently are with the unsafePerformIO
> > solution, I.E. Order unspecified, the action that creates a particular
> > top level thing is executed only once, when the value of thing is
> > demanded (perhaps not at all).
>
> Also consider the case of
>
> z = someAction(y)
>
> Here z is a value outside the IO monad, calculated using a function
> outside the IO monad, based on a value (y) which also lies outside the
> IO monad... What sane semantics will explain when the actions which led
> to the value y should be taken?

I've never really understood what people mean by things being "inside" and
"outside" the IO monad :-(

Assuming from Vincenzos original example that ..

someAction :: SomeType -> IO Thing

then in your example..

z :: IO Thing

So z is a perfectly ordinary value. The someAction that creates y will
be executed only once, as soon as the value of y is needed, which
(assuming someAction is strict) will be as soon as the value of z
is needed, I.E. "Whenever"

The only real insanity with the current situation is the loss of
referential transparency implied by the use of unsafePerformIO, which
is why various pragma hacks and compiler switches need to be used (in
order to prevent inappropriate substitutions). What I want to do
is to make this or something similar "official", so the compiler really
knows not to do this inappropriate subsitution in any event, even if
the programmer forgot to use the necessary pragmas or compiler flags,
or just didn't understand why they are needed.

This still leaves the uncertainty of exactly when the creation occurs,
but this is a minor issue IMO. We have the same problem with finalisers
and any concurrent code. Either it just doesn't matter, or if it does
then it's the programmers responsibility to use existing mechanisms
(such as seq) to control things.

> I think what people are trying to suggest is an 'initialization phase'
> in the IO monad, which takes place "before" the pure functions are
> defined. At compile time, conceptually. I don't have any clear idea how
> that should be made precise.

I can't speak for what others are trying to suggest, but that isn't
what I have in mind.

What I want is non-hack mechanism for creation of arbitrarily complex
"things with identity" at the top level. I guess you could arrange that
all such things were constructed at run time before executing main, but
I don't see any real advantage in that.

Regards
--
Adrian Hey

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] [Job] NLP Developer

[Jochen L. Leidner]

[Dear HASKELL subscribers,

Apologies for the job posting, but according to the responses to my 
previous enquiry it does seem to be okay for most of your to receive
Haskell-related job ads to this group.

Regards,
Jochen Leidner]

===
 Natural Language Processing DeveloperLinguit GmbH
---

This position is available in Edinburgh, UK, from 1 January, 2005.

We are looking for a skilled developer to join our friendly R&D team to 
develop our existing question answering technology, which is used in
our Nuggets mobile search engine .

Requirements:
-
- BSc/MSc/Diploma in Computer Science or Computational Linguistics
- At least 2 years of full-time commercial development experience in 
  C/C++/Java/C#
- Proven track record in Natural Language Processing (NLP)
- Significant practical development and self-management experience
  in Haskell under a UNIX(R) environment
- Python/Perl/sh considered a plus
- Prior exposure to software build process (make/ant, CVS/Subversion/
  Perforce etc.)
- The ability to work independently in a team and good communication 
  skills

Salary to be negotiated based on experience.

Linguit GmbH is a German-based, privately held, limited liability company
that aims to provide cutting edge consulting, services, and products in
language and speech technology. Linguit has broad expertise in all major
areas of NLP, but focuses especially on Information Extraction and 
Question Answering.

To apply, send your cover letter and curriculum vitae/resume in plain 
text, PDF, HTML or SPDL to <[EMAIL PROTECTED]> (please include the 
string 'Job: NLP Developer' in your subject line). Deadline for 
submission is 1 December, 2004. Thank you for your interest.

===
Try Nuggets, the mobile search engine!  
===

-- 
Jochen L Leidner
PhD student
University of Edinburgh

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Marcin 'Qrczak' Kowalczyk]

Jules Bean <[EMAIL PROTECTED]> writes:

> I think what people are trying to suggest is an 'initialization
> phase' in the IO monad, which takes place "before" the pure
> functions are defined.

If it was done before, what could you use to specify initial value of
such a variable? Only literals? Constructors? Named constants? Results
of arithmetic operations? Results of arbitrary functions?

The well-definedness of a global IORef relies on the fact that
creation of an IORef doesn't have visible side effects, so it doesn't
matter when it happens, as long as it happens once between the
variable is used. An arbitrary IO computation doesn't have this
property.

Unfortunately having only IORefs would be limiting. You couldn't
legally make stdin/stdout/stderr for example. Now they must rely
on compiler magic for something which doesn't seem to need magic
by nature (allocation of some MVars and other objects, not doing
actual I/O).

-- 
   __("< Marcin Kowalczyk
   \__/   [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Jules Bean]

On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the unsafePerformIO
solution, I.E. Order unspecified, the action that creates a particular
top level thing is executed only once, when the value of thing is
demanded (perhaps not at all).
Also consider the case of
z = someAction(y)
Here z is a value outside the IO monad, calculated using a function 
outside the IO monad, based on a value (y) which also lies outside the 
IO monad... What sane semantics will explain when the actions which led 
to the value y should be taken?

I think what people are trying to suggest is an 'initialization phase' 
in the IO monad, which takes place "before" the pure functions are 
defined. At compile time, conceptually. I don't have any clear idea how 
that should be made precise.

Jules
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Program maintenance tools

[Andy Moran]

- detection of unnecessary arguments for functions;
- detection of unnecesary imports of modules;
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html
ghc -W:
Provides the standard warnings 
plus -fwarn-incomplete-patterns, -fwarn-unused-matches, -fwarn-unused-imports, 
 -fwarn-misc, and -fwarn-unused-binds.
These also give you lots of dead code detection (unused-binds, 
unused-matches), but may miss some dead code.

Also very useful for getting specific with your import lists 
is -ddump-minimal-imports.

Cheers,
Andy
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: elementary tracing for Haskell

[Thomas Davie]

Hi,
I'm glad that there's interest for a tool like hat-anim.  I should warn you however that the current version is far from perfect - it has some problems with displaying infinite lists and with some lambda expressions and worst of all has a pretty nasty memory leek problem (there's what I get for writing it in C).  I am currently re-writing it in Haskell, and hopefully will produce a more reliable tool.  I'll tell you when the tool is working.

Thanks

Tom Davie

On 12 Oct 2004, at 14:34, Olaf Chitil wrote:


From: Colin Runciman <[EMAIL PROTECTED]>
Date: 11 October 2004 10:38:21 BST
To: Philip Wadler <[EMAIL PROTECTED]>
Cc: John Hughes <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Simon Thompson <[EMAIL PROTECTED]>,  Susan Eisenbach <[EMAIL PROTECTED]>
Subject: [Haskell] Re: elementary tracing for Haskell


Phil,

Are there any tools for beginning programmers that give traces of Haskell programs?  I want something like the following.  Given the defintion

sum [] = 0
sum (x:xs) = x + sum xs

typing

sum [1,2,3]

should yield this trace

sum [1,2,3]
1 + sum [2,3]
1 + 2 + sum [3]
1 + 2 + 3 + sum []
1 + 2 + 3 + 0
1 + 2 + 3
1 + 5
6

I know there are advanced tools like Hat, but (unless I'm missing something) they don't yield anything as naive as the above, and it's naive users I'm trying to help here.  -- P

There is a Hat tool called hat-anim that can do this kind of thing.  It was developed by Tom Davie as a student project.  It is not part of the current "official release" of Hat but is included in the CVS version.  Tom is now a PhD student at Canterbury ([EMAIL PROTECTED]), supervised by Olaf Chitil ([EMAIL PROTECTED]).

Regards
Colin R


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Program maintenance tools

[Johannes Waldmann]

- detection of unnecessary arguments for functions;
- detection of unnecesary imports of modules;
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html
ghc -W:
Provides the standard warnings plus -fwarn-incomplete-patterns, 
-fwarn-unused-matches, -fwarn-unused-imports, -fwarn-misc, and 
-fwarn-unused-binds.

--
-- Johannes Waldmann,  Tel/Fax: (0341) 3076 6479 / 6480 --
-- http://www.imn.htwk-leipzig.de/~waldmann/ -
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Program maintenance tools

[kahl]

Gavin Lowe <[EMAIL PROTECTED]> asked for:
 > 
 > - a graphical representation of dependencies between modules.

HsDep available from

http://www.cas.mcmaster.ca/~kahl/Haskell/

uses dot from AT&T's graphviz suite.
You can of course tune with the generated dot file manually
and run dot again to tune the result.


Wolfram

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Program maintenance tools

[Gavin Lowe]

Hello

I'm looking for some tools to help maintain a largish Haskell program.
Some of the things I'd like tool support for are:

- detection of dead code;

- detection of unnecessary arguments for functions;

- detection of unnecesary imports of modules;

- a graphical representation of dependencies between modules.

Any pointers would be much appreciated.

Gavin

--
Gavin Lowe

Oxford University Computing Laboratory, Parks Road, Oxford, OX1 3QD.
Phone: +44 1865 273841.  Fax: +44 1865 273839.
E-mail: [EMAIL PROTECTED]

The secret of all discoverers is that they regard nothing as impossible
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Tuesday 12 Oct 2004 1:44 pm, Vincenzo Ciancia wrote:
> On Tuesday 12 October 2004 12:23, Adrian Hey wrote:
> >  I don't know what more
> > general-purpose extension you have in mind, but couldn't you just
> > borrow from do syntax at the top level
>
> I think that the problem is with the order of execution of these
> bindings. For example ghci supports top-level "let x <- something"
> declarations, but the haskell compiler does not have to respect any
> order of execution, which would instead be forced. The general purpose
> extension could however require the same proof obligations of
> unsafeInterleaveIO, but how do we deal with
>
> x <- someAction
> y <- someAction(x)

I would say keep things as they currently are with the unsafePerformIO
solution, I.E. Order unspecified, the action that creates a particular
top level thing is executed only once, when the value of thing is
demanded (perhaps not at all).

If ordering is significant (due to important side effects say) then
it can be controlled with `seq` I think.

But I think something ought to be done about it. Having to use
unsafePerformIO to do something that ought to be perfectly safe
is just embarrassing I think :-)

There's also the type security issues that Marcin was talking about,
but I don't see why that can't be addressed with appropriate
constraints which are enforced at compile time.

Regards
--
Adrian Hey

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Vincenzo Ciancia]

On Tuesday 12 October 2004 12:23, Adrian Hey wrote:
>  I don't know what more
> general-purpose extension you have in mind, but couldn't you just
> borrow from do syntax at the top level

I think that the problem is with the order of execution of these 
bindings. For example ghci supports top-level "let x <- something" 
declarations, but the haskell compiler does not have to respect any 
order of execution, which would instead be forced. The general purpose 
extension could however require the same proof obligations of 
unsafeInterleaveIO, but how do we deal with

x <- someAction
y <- someAction(x)

V.

-- 
Bow down before the one you serve,
you're going to get what you deserve.
[Nine Inch Nails]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] looking for reference to wadler's (?) law of language design

[Jon Fairbairn]

On 2004-10-12 at 12:53+0200 Johannes Waldmann wrote:
> this is slightly off topic - I am preparing for a lecture on domain
> specific languages and I try to track down the source and original 
> version of (what I recall as) Wadler's "law" of language design,

I think it first appeared here:

http://www.informatik.uni-kiel.de/~mh/curry/listarchive/0017.html

-- 
Jón Fairbairn [EMAIL PROTECTED]


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] looking for reference to wadler's (?) law of language design

[Johannes Waldmann]

this is slightly off topic - I am preparing for a lecture on domain
specific languages and I try to track down the source and original 
version of (what I recall as) Wadler's "law" of language design,
"the energy spent in designing a programming language goes into,
in increasing order of effort: semantics, syntax, syntax of comments".
--
-- Johannes Waldmann,  Tel/Fax: (0341) 3076 6479 / 6480 --
-- http://www.imn.htwk-leipzig.de/~waldmann/ -

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Marcin 'Qrczak' Kowalczyk]

"Simon Marlow" <[EMAIL PROTECTED]> writes:

> I'd like to add that while the implementation might be a little unsafe,
> there's no problem in principle with the semantics of top-level IORefs.
> We could add such a thing as a GHC extension, but it would be nice if it
> were an instance of a more general-purpose extension.

Top-level MVars also make sense, the extension should not be limited
to IORefs. But permitting arbitrary values makes unsafePerformIO
official and opens a hole in the type system for polymorphic variables
(can such polymorphism be hidden in an apparently monomorphic datatype?).

-- 
   __("< Marcin Kowalczyk
   \__/   [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

[Adrian Hey]

On Monday 11 Oct 2004 4:03 pm, Simon Marlow wrote:
> On 08 October 2004 19:18, Sven Panne wrote:
> > c) Give up any hope of clean semantics and simply use a common hack
> > like:
> >
> >{-# NOINLINE myGlobalVar #-}
> >myGlobalVar :: IORef Int
> >myGlobalVar = unsafePerformIO (newIORef 0)
> >
> > My GLUT binding does it happily, as does GHC itself, [snip]
>
> I'd like to add that while the implementation might be a little unsafe,
> there's no problem in principle with the semantics of top-level IORefs.
> We could add such a thing as a GHC extension, but it would be nice if it
> were an instance of a more general-purpose extension.

I found myself doing this kind of thing quite a bit recently for FFI
binding. It would be nice have some solution such that the compiler
was guaranteed to be aware of the semantic problems and we didn't have
to rely on unsafePerformIO, NOINLINE etc hackery. I don't know what more
general-purpose extension you have in mind, but couldn't you just borrow
from do syntax at the top level, something like this..

> myThing :: Thing
> myThing <- newThing

(where newThing :: IO Thing)

Regards
--
Adrian Hey

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] -allow-extension-for-bottom

[Nils Anders Danielsson]

On Mon, 11 Oct 2004, Serge D. Mechveliani wrote:

> Consider the compilation flag  -allow-extension-for-bottom
>
> which changes the language meaning so that allows to ignore
> the bottom value. For example, the programs
>
>(1)   (\ x -> (if p x then  foo (g x)  else  foo (h x)) )
> and
>(2)   (\ x -> foo ((if p x then  g x  else  h x)) )
>
> become equivalent, and many program transformations become
> possible.

You may be interested in knowing that, under some circumstances, the
"feature" you are looking for is actually implemented, and you don't need
any flag to activate it. Try this function under GHC 6.2.1, for example:

> f = \x -> if x then (\y -> 0) else (\y -> 1)

*Main ChasingBottoms> isBottom (f bottom)
False

(Using your notation p = g = h = id, foo = const.)

I prefer to call this a bug, though. See
  http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-November/003735.html
and possibly
  http://www.cs.chalmers.se/~nad/software/ChasingBottoms/docs/index.html
for more details.

I should add that I think that the Haskell semantics makes proofs of
correctness overly complicated. A conservative approximation should
suffice in most cases. Hence there could also be a compiler setting which
took advantage of such approximations.

/NAD
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell