Jonathan Cast wrote:
On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote:
I've been playing with this today, and no matter what rules I come up
with, it seems to be ridiculously easy to put the interpretter into an
infinite loop from which it will never escape. Is there any way to know
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an infinite
number of copies of Y, even though in theory the factorial function should
You could dump the archives, grep out the names and then
Google...
--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Doel wrote:
Here's a first pass:
-- snip --
{-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-}
module Unique where
import Control.Monad.Reader
import Control.Monad.Trans
import Control.Concurrent.MVar
-- Give Uniques a phantom region parameter, so that you can't accidentally
--
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
OK. Let's call it top-level scope. Haskell naturally defines such a
thing, regardless of processes and processors. Each top-level - would
run at most once in top-level scope.
If you had two Haskell runtimes call by C code, each would have its own
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Well, yes, but if I implemented a library in standard Haskell it would
always be safely serialisable/deserialisable (I think). So the global
variables hack somehow destroys that property - how do I work out why it
does in some
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
But then again, I'm sure that some that will be adamant that any way
of making global variables is a hack. But they'll still be happy
to go on using file IO, sockets etc regardless, blissfully unaware
of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are things provided by the OS to a process. That's what defines
them as having process scope, not something the
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout
and stderr are things provided by the OS to a process. That's what
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API. The
main complaint would be what I see as loss of modularity, in that
somehow what should be a small irrelevant detail of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just file
descriptors 0, 1 and 2, aren't they? You can create them as many times as
you want with using that information
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just
file descriptors 0, 1 and 2, aren't they? You can create them as
many
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API.
The main complaint would be what I see as loss of modularity, in that
somehow what should be a
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
In that case it seems that any library that might be used from a
runtime that isn't the top-level of a process should avoid doing
IO
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
process-global (or process-local depending on how you think
On Sun, 31 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety requirement
has been met, but I think it fails on the improved API. The main complaint
would be what I see as loss of
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an infinite
number of copies of Y, even though in theory the
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you
On Sun, 2008-08-31 at 17:29 +0100, Andrew Coppin wrote:
Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an
On Sun, Aug 31, 2008 at 9:29 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
All of this strongly suggests that if you execute things in the correct
order, you can arrange it so that expressions that have a normal form will
be evaluated to it. But how to decide the correct evaluation order? For the
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
module Prob where
import qualified Data.Map as M
...
newtype Prob p a = Prob { runProb ::
Dear Johannes,
Besides the IPT course, we also teach a course hat used to be called
grammars and parsing. This course is taken before the compiler
construction course. In this course we deal with parser combinators,
datatypes, folds, first and follow, LL(1), and some more stuff, all
in Haskell.
Am Sonntag, 31. August 2008 20:21 schrieb Ryan Ingram:
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
module Prob where
import qualified
My proposal is to allow ad-hoc overloading of names;
+1, although ...
this could interact badly with the (still common?)
practice of leaving out type declarations.
(of course having allowed this in the first place
is another language design error :-)
when considering language changes
Hello Ryan,
Sunday, August 31, 2008, 10:21:44 PM, you wrote:
Cons: potentially exponential compile time?
yes, and exponential programming complexity growth, going to brain explosion :)
don't forget that OOP languages that supports ad-hoc overloading
doesn't allow to infer types in both
Ryan Ingram wrote:
What are you trying to get from the let binding? Sharing?
Convinience.
let x = foo in bar
is so much easier to write than
(\x - bar) foo
when foo and/or bar is large.
Trouble is, as soon as you allow let-bindings, some clever person is
going to start writing
On 2008 Aug 31, at 14:58, Daniel Fischer wrote:
Am Sonntag, 31. August 2008 20:21 schrieb Ryan Ingram:
Do you see it? All those M. just seem dirty to me, especially
because the compiler should be able to deduce them from the types of
the arguments.
Another Con is that the compiler can catch
Well, I was thinking that way when I was starting learning Haskell.
But then I realized that this feature would make code much harder to
read. Suppose you have different thing all named insertWith. You've
got one somewhere in your program; how do YOU know when looking at the
code after a
Ryan Ingram wrote:
My proposal is to allow ad-hoc overloading of names; if a name is
ambiguous in a scope, attempt to type-check the expression against
each name. It is only an error if type-checking against all names
fails. If type-checking succeeds for more than one then the
expression is
On 2008.08.31 11:21:44 -0700, Ryan Ingram [EMAIL PROTECTED] scribbled 1.0K
characters:
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
Gwern Branwen wrote:
I think this would be very nice in GHCi, because there the situation is even
*worse*.
I think we've all experienced importing Data.Map or Data.ByteString and
discovering we need to tediously write it out in *full*, because we can't even
do qualified imports of it!
On Wed, Aug 27, 2008 at 10:20 PM, David Bremner [EMAIL PROTECTED] wrote:
Ketil Malde wrote:
Another Debian question, once I've populated the debian/ directory one
way or another, how should this be integrated with the rest of the
project? Should it be part of the darcs archive, or a separate
Erm... Why can't we?
On 1 Sep 2008, at 00:43, Gwern Branwen wrote:
I think we've all experienced importing Data.Map or Data.ByteString
and discovering we need to tediously write it out in *full*, because
we can't even do qualified imports of it!
--
gwern
BND fritz FKS 1071 Face
Oh, sorry, haven't noticed you said ghcI.
On 1 Sep 2008, at 00:59, Miguel Mitrofanov wrote:
Erm... Why can't we?
On 1 Sep 2008, at 00:43, Gwern Branwen wrote:
I think we've all experienced importing Data.Map or Data.ByteString
and discovering we need to tediously write it out in *full*,
On 2008.09.01 01:01:21 +0400, Miguel Mitrofanov [EMAIL PROTECTED] scribbled
0.5K characters:
Oh, sorry, haven't noticed you said ghcI.
On 1 Sep 2008, at 00:59, Miguel Mitrofanov wrote:
Erm... Why can't we?
The GHC API just doesn't support it. See the bug report filed on this issue:
Miguel Mitrofanov wrote:
Suppose you have different thing all named insertWith. You've got one
somewhere in your program; how do YOU know when looking at the code
after a month or so, which one is this?
We already have that situation when classes are involved. If you replace
specialised
2008/9/1 Andrew Coppin [EMAIL PROTECTED]:
Ryan Ingram wrote:
What are you trying to get from the let binding? Sharing?
Convinience.
let x = foo in bar
is so much easier to write than
(\x - bar) foo
when foo and/or bar is large.
Trouble is, as soon as you allow let-bindings, some
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
OK. Let's call it top-level scope. Haskell naturally defines such a
thing, regardless of processes and processors. Each top-level - would
run at most once in top-level scope.
If you had two Haskell runtimes call by C code,
Well, I was thinking that way when I was starting learning Haskell.
But then I realized that this feature would make code much harder to
read. Suppose you have different thing all named insertWith. You've
got one somewhere in your program; how do YOU know when looking at the
code after a
Oleg has pointed me into the right direction:
He has suggested to use kind of
class AttrOk elTrype attr
for attributes (result 35s - 30s)
and do something similar with the state.
(30s - 4,5s).
After doing this I was quite happy:
The 4,5s do include reading the dtd and generating about 1500
On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle
On Sun, Aug 31, 2008 at 2:10 PM, Claus Reinke [EMAIL PROTECTED] wrote:
Indeed. Too much overloading can be a lot of trouble.
You can do adhoc overloading already:
{-# LANGUAGE FlexibleInstances #-}
class Adhoc a where adhoc :: a
instance Adhoc ((a-b)-([a]-[b])) where adhoc = map
On Sun, 2008-08-31 at 16:08 -0700, Ryan Ingram wrote:
In particular I do NOT want each function in its own typeclass; the
previous post saying:
foo x = map (bar x)
should be rejected as ambiguous without a type signature somewhere
What type signature do you propose?
It seems as if you're
As to the argument that a sufficiently smart IDE would insert the
M. for me, I think that is flawed. First, there isn't a
sufficiently smart IDE yet,
I do believe there will be.
What we do now is sort of putting down requirements ...
and second, it'd be better for the
type-aware IDE to
2008/8/31 Ryan Ingram [EMAIL PROTECTED]:
My proposal is to allow ad-hoc overloading of names; if a name is
ambiguous in a scope, attempt to type-check the expression against
each name. It is only an error if type-checking against all names
fails. If type-checking succeeds for more than one
Oops, forgot to send to list.
On Mon, 2008-09-01 at 01:27 +0100, Philippa Cowderoy wrote:
On Mon, 2008-09-01 at 01:11 +0100, David House wrote:
2008/8/31 Ryan Ingram [EMAIL PROTECTED]:
My proposal is to allow ad-hoc overloading of names; if a name is
ambiguous in a scope, attempt to
On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast
[EMAIL PROTECTED] wrote:
It seems as if you're proposing that
doubleSet :: Set.Set Int - Set.Set Int
doubleSet = map (*2)
doubleList :: [Int] - [Int]
doubleList :: map (*2)
work, but that you not be allowed to notice that the definitions
On Sun, Aug 31, 2008 at 5:11 PM, David House [EMAIL PROTECTED] wrote:
Here's an example of such a concern: you write the following:
module Amb where
import Data.Map
foo = map
What is the type of `foo'?
Exactly the same as now: it has no type:
amb.hs:4:6:
Ambiguous occurrence `map'
On Sun, Aug 31, 2008 at 11:21:44AM -0700, Ryan Ingram wrote:
[..]
Any thoughts?
-- ryan
Nice problem, nice idea..
Maybe the time is better spend on IDEs than extending the (or all)
compilers..
Right now I've something like this in my vim script files:
function!
On Sun, 2008-08-31 at 19:06 -0700, Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast
[EMAIL PROTECTED] wrote:
It seems as if you're proposing that
doubleSet :: Set.Set Int - Set.Set Int
doubleSet = map (*2)
doubleList :: [Int] - [Int]
doubleList :: map (*2)
There might still be some duplication.. in state transformation steps.
I've removed duplicate state machine paths.
Instead of approxmiately 1500 there are only 500 left.
You can see the impact on speed here
http://mawercer.de/~marc/vxml.svg
data + (red): approx 1500
data3 * (blue): approx
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:
I'm afraid I don't see how this generalises to sharing something across an
entire process where the things that want to do the sharing are not in or
controlled by the same shared
55 matches
Mail list logo
