Johannes Waldmann wrote:
Imagine you're writing a parser for a simple programming language.
A program is a sequence of statements.
Fine, you do readFile (once) and then apply a pure Parsec parser.
Then you decide to include import statements in your language.
Suddenly the parser needs to
On 2008-08-28, Yitzchak Gale [EMAIL PROTECTED] wrote:
However we work that out, right now we need a working
idiom to get out of trouble when this situation comes up.
What we have is a hack that is not guaranteed to work.
We are abusing the NOINLINE pragma and assuming
things about it that are
On 2008-08-27, Henrik Nilsson [EMAIL PROTECTED] wrote:
And there are also potential issues with not every legal module name
being a legal file name across all possible file systems.
I find this unconvincing. Broken file systems need to be fixed.
--
Aaron Denney
--
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What stops the same rule from applying to
There's a whole bunch of other problems with lazy network IO. The big
problem is that you cannot detect when your stream ends since that
will happen inside unsafeInterleaveIO which is invisible from inside
pure code. You also have no guarantee that the lazy code actually
consumes code enough.
Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its
behaviour properly. This is one part of the necessary explanation.
To be concrete about scenarios I was considering, what happens if:
- the same process loads two copies of the GHC RTS as part of
Philippa Cowderoy wrote:
Talking of which, we really ought to look at an IO typeclass or two (not
just our existing MonadIO) and rework the library ops to use it in
Haskell'. You're not the only one to want it, and if it's not fixed this
time it may never get fixed.
This could allow both the
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its
behaviour properly. This is one part of the necessary explanation.
To be concrete about scenarios I was considering, what happens if:
- the same
Paul Johnson wrote:
This is a strange question, I know, but is there anyone working in any
of the above companies on this mailing list?
Everyone will no doubt be wondering what they have in common. I'm
afraid I can't discuss that.
Air Traffic Control?
--
Ashley Yakeley
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes,
2008/8/30 Ashley Yakeley [EMAIL PROTECTED]:
Paul Johnson wrote:
This is a strange question, I know, but is there anyone working in any of
the above companies on this mailing list?
Everyone will no doubt be wondering what they have in common. I'm afraid
I can't discuss that.
Air Traffic
They are all defense contractors.
On Sat, Aug 30, 2008 at 12:18 PM, Ashley Yakeley [EMAIL PROTECTED] wrote:
Paul Johnson wrote:
This is a strange question, I know, but is there anyone working in any of
the above companies on this mailing list?
Everyone will no doubt be wondering what they
Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a
different ref.
How do you know? How can you compare them, except in the same Haskell
expression?
The same one as a previous one can only be returned
once the old one has become unused (and GCed).
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a different
ref.
How do you know? How can you compare them, except in the same Haskell
expression?
I can write to one and see if the other changes.
The same
Ashley Yakeley wrote:
I don't really follow this. Do you mean the minimal such scope, or the
maximal such scope? The problem here is not about separate calls to
newIORef, it's about how many times an individual - will be executed.
Two IO executions are in the same global scope if their
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised? What stops the same rule from applying to
Data.Random?
Unique values should be no more deserialisable than IORefs.
Is it the functionality of Data.Unique that you
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Is it the functionality of Data.Unique that you object to, or the fact that
it's implemented with a global variable?
If the former, one could easily build Unique values on top of IORefs, since
IORef is in Eq. Thus Data.Unique is no worse than IORefs
Ganesh Sittampalam wrote:
How can they be the same unless the memory management system is broken?
I consider different pointers on different machines or in different
virtual address spaces different too; it's the fact that they don't
alias that matters.
But the actual pointer value might
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
instead of some new language feature that is actually hard to implement across
the process scope.
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
I'm not sure that they *define* process scope, because it
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes, but if I implemented a library in standard Haskell it would
always be safely
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
I'm not sure that they
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of
apfelmus wrote:
Design your language in a way that the *parse* tree does not depend on import
statements? I.e. Chasing imports is performed after you've got an abstract
syntax tree.
OK, that would work.
This property does not hold for Haskell,
because you need the fixities of the operators
Ganesh Sittampalam wrote:
Firstly, that's a property of the current implementation, rather than a
universal one, IMO. I don't for example see why you couldn't add a
newIORef variant that points into shared memory, locking issues aside.
OK, so that would be a new Haskell feature. And it's that
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Firstly, that's a property of the current implementation, rather than a
universal one, IMO. I don't for example see why you couldn't add a
newIORef variant that points into shared memory, locking issues aside.
OK, so that
Consider for instance defining datatype for 3x3 matrix.
I think the only sensible modelling for that
would use dependent types.
Also, if positional record notation is a design error, then is it also a
design error not to require all arguments to be explicitly associated
with named formal
Adrian Hey wrote:
Global variables are needed to ensure important safety properties,
but the only reasons I've seen people give for thread local variables
is that explicit state threading is just so tiresome and ugly. Well
that may be (wouldn't disagree), but I'm not aware of any library
that
On 2008 Aug 30, at 4:22, Aaron Denney wrote:
On 2008-08-27, Henrik Nilsson [EMAIL PROTECTED] wrote:
And there are also potential issues with not every legal module name
being a legal file name across all possible file systems.
I find this unconvincing. Broken file systems need to be fixed.
L.S.,
I found the Functional Game Engine FunGEn on the web:
http://www.cin.ufpe.br/~haskell/fungen/download.html
It looks useful, but since it hasn't been maintained for a long time, it
doesn't compile. Is there a newer version I can download?
--
Regards,
Henk-Jan van Tuyl
--
On Sat, Aug 30, 2008 at 3:51 AM, Thomas Schilling
[EMAIL PROTECTED] wrote:
I remember Johan Tibell (CC'd) working on an extended variant of
Parsec that can deal with this chunked processing. The idea is to
teach Parsec about a partial input and have it return a function to
process the rest (a
On 2008 Aug 30, at 6:28, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let
them be serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What
Henk-Jan van Tuyl wrote:
L.S.,
I found the Functional Game Engine FunGEn on the web:
http://www.cin.ufpe.br/~haskell/fungen/download.html
It looks useful, but since it hasn't been maintained for a long time, it
doesn't compile. Is there a newer version I can download?
Hi Henk-Jan,
yes,
---
Haskell Weekly News
http://sequence.complete.org/hwn/20080830
Issue 83 - August 30, 2008
---
Welcome to issue 83 of HWN, a newsletter covering
On 2008.08.30 12:06:33 -0700, Simon Michael [EMAIL PROTECTED] scribbled 0.7K
characters:
Henk-Jan van Tuyl wrote:
L.S.,
I found the Functional Game Engine FunGEn on the web:
http://www.cin.ufpe.br/~haskell/fungen/download.html
It looks useful, but since it hasn't been maintained for a
Ganesh Sittampalam wrote:
By global scope, I mean the largest execution scope an IORef created
by newIORef can have. Each top-level IORef declaration should create
an IORef at most once in this scope.
That's a reasonable definition, if by execution scope you mean your
previous definition of
On 2008-08-30, Johannes Waldmann [EMAIL PROTECTED] wrote:
apfelmus wrote:
Design your language in a way that the *parse* tree does not depend
on import statements? I.e. Chasing imports is performed after you've
got an abstract syntax tree.
OK, that would work.
This property does not hold
Hi,
I saw the (a?) page about FFI on Haskell:
http://www.cse.unsw.edu.au/~chak/haskell/ffi
It shows a link to a mailing list but,
checking the list archives at:
http://www.haskell.org/pipermail/ffi ,
it seems it's dead since 2007. Is there
a new list about FFI? Where should I
discuss my
briqueabraque:
Hi,
I saw the (a?) page about FFI on Haskell:
http://www.cse.unsw.edu.au/~chak/haskell/ffi
It shows a link to a mailing list but,
checking the list archives at:
http://www.haskell.org/pipermail/ffi ,
it seems it's dead since 2007. Is there
a new list about FFI?
Hi,
Maybe you've noted that I've started writing an XML library which
validates the generated XML against a given DTD at compile time.
Not everything is implemented right now and it would be quite usable if
it didn't take that much time.
The problem:
To see some details have look at my
41 matches
Mail list logo
