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
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
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 sema
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 littl
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 compil
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.
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
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 thes
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 swit
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
>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
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).
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 crea
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 i
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
[EMAI
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
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
> >
[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]
===
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? Con
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 (pe
- 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,
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
- 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, -
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
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 dependencie
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 o
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
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:
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: se
"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 gen
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
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
32 matches
Mail list logo
