On 5/24/07, Adrian Hey <[EMAIL PROTECTED]> wrote:
Taral wrote:
> The other syntaxes proposed don't strike me as sufficiently rigorous.
Me neither. It's always been a great source of puzzlement to me why this
very simple and IMO conservative proposal should be so controvers
don't strike me as sufficiently rigorous.
--
Taral <[EMAIL PROTECTED]>
"Please let me know if there's any further trouble I can give you."
-- Unknown
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
is was regarded as unfriendly to Fortran programmers.
[breaking cc list]
Would this kind of thing be eligible for Haskell'? I never had a
problem with _1 in APL-type languages... and I think it's best to be
very clear about intent.
--
Taral <[EMAIL PROTECTED]>
"Please let me
lot safer for tuples than for lists, for example.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
with required braces. The
layout rule never generates empty braces.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
are almost certainly going
to be given monomorphic types after inlining, enabling constant
folding.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailin
On 10/26/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
btw, your variant requires re-calculating values on each their use
That's what constant folding is for.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
requires a bunch of harder-to-read () instead of
nice delimiting reserved words.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
extra indentation does
nothing to improve readability, and is a common frustration. The point
of all sugar is to reduce frustration, so I am strongly in favor of
the new syntax.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- G
Haskell' will not have this, if only under the "must
already be implemented" requirement for major features. However, it
seems that Haskell' is a good way to get people thinking about future
improvements, and I'd hate to stifle that.
--
Taral <
:) Fold is
somewhat specific to the structure of the underlying collection (hence
the numerous fold* functions), map is not.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
licitly uses
the defaults and then an explicit Functor comes into scope via import.
The current proposal to require people to write "instance Functor"
isn't so pretty as the hierarchy becomes more fine-grained:
instance Monad [] where
instance Functor
instance PointedFunc
t;>=) :: m a -> (a -> m b) -> m b
instance Functor m where
fmap f = (>>= return . f)
What's wrong with this? All Monads are Functors. If you don't provide
a Functor, it gets defined for you. The problem is working out whether
to use the default Functor or an ext
ods have a small problem:
module A contains instance Monad []
module B contains instance Functor []
module C imports A and B.
Do we complain about a duplicate instance declarations? If not, does
the use of fmap in A use the default definition, or the one from B?
--
Taral <[EMAIL PROTECTED]>
&qu
y! (But a little inefficient. You'd probably want to
define ap/lift2 in there.)
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@hask
compiler or interpreter.
Perhaps this could be forwarded onto the GHC and other compiler people
for consideration as an extension?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Has
fall-through semantics in
Clean. Probably for the best -- accidental fallthrough might be a
nasty source of bugs.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mail
2 arg2 = calculate2 arg1 arg2
| otherwise = calculate3 arg1 arg2
| predicate12 arg1 = calculate4 arg1 arg2
I think this is great. Does it have fall-through semantics?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- G
s, however, to decide on what level of
*minimum* termination support Haskell' will insist upon. The CHR paper
(with the confluence improvements by Claus) is currently the most
promising option, and has an implementation (another important
consideration) in GHC.
--
Taral <[EMAIL PROTECTE
tely often" is a very well-defined term in temporal logic. I
think it is this that John is referring to.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mail
On 4/15/06, John Goerzen <[EMAIL PROTECTED]> wrote:
> On the downside, this means that I couldn't just say:
>
> take 5 mylist
>
> I'd instead have to write:
>
> take (5::Int) mylist
Wouldn't defaulting do this?
--
Taral <[EMAIL PROTECTED]>
"Y
mer happens to know otherwise. So maybe... "returnsquickly"?
Hear, hear:
fast - takes very little time to execute
pure - side-effect free
nocallback - does not call back into Haskell
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompe
;m afraid that claim may need qualifications:
I was thinking that it might be more useful to express it programatically:
if preemptive then fork _|_ >> return () => ()
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
mentation.
Why is this necessary?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
. The semantics of
forkCPU is that the computation involved in the argument is
time-consuming and should not block other computations if possible.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
_
s primitves.
And they're all a pain because they don't take sets of files, only
single ones. Can we please have something like:
threadWait :: Timeout -> [Handle] -> IO ?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence T
On 3/29/06, Taral <[EMAIL PROTECTED]> wrote:
> On 3/29/06, Ross Paterson <[EMAIL PROTECTED]> wrote:
> > -- The reference contains a rollback action to be executed on exceptions
> > newtype STM a = STM (IORef (IO ()) -> IO a)
>
> Cute, but why use an IORef?
&g
On 3/29/06, Ross Paterson <[EMAIL PROTECTED]> wrote:
> -- The reference contains a rollback action to be executed on exceptions
> newtype STM a = STM (IORef (IO ()) -> IO a)
Cute, but why use an IORef?
newtype STM a = STM (IO () -> IO a)
--
Taral <[EMAIL PROTECTED]>
&
;d suggest
>
> unsafe
> concurrent unsafe
> concurrent -- the hard one
> {- nothing -}
Can I suggest "sef" in this? Most cases of "unsafe" are actually
claims that the call is side-effect free.
--
Taral <
you suggest omitting retry/orElse?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
r is
> released or when you have to change your code.
That kind of tweaking isn't required to simulate this. "a `seq` b
`seq` (a, b)" is perfectly sufficient, and is quite commonly seen in
such programs.
--
Taral <[EMAIL PROTECTED]>
"You ca
ubt of this. My comment refers to the idea that somehow
such strictness annotations are (a) required at the type level and (b)
required at all to enable such optimization. I believe the
optimization happens without any annotation from the user, and it
should stay that way.
--
Taral <[EMAIL PROTECTED]
allows the inference of HasResolution a from Fixed a,
thus removing the HasResolution condition on your instances.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime
the availability of
information regarding the strictness of a function result's
subcomponents.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
he
FunctionalDependencies ticket? I think that the new confluence results
lends a lot towards the adoption of FDs in Haskell'.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
H
On 3/20/06, Ashley Yakeley <[EMAIL PROTECTED]> wrote:
> Never as far as I can imagine. The 'a' parameter will be taken by a
> phantom type.
> <http://haskell.org/haskellwiki/Phantom_type>
Now I don't recall, but is it allowed to do:
data HasResolution a
a) without (HasResolution a)?
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
text.
> Rather confusing, and there is no link to "add a new page" or similar.
Very useful reference:
http://meta.wikimedia.org/wiki/Help:Contents#For_editors
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astro
On 3/13/06, Claus Reinke <[EMAIL PROTECTED]> wrote:
> [still talking to myself..?]
This is all wonderful stuff! Are you perhaps planning to put it all
together into a paper?
What effect do you think this can have on existing algorithms to resolve FDs?
--
Taral <[EMAIL PROTECTED
;more specific" term. It's not well-defined,
i.e. not a total order on possible instance declarations.
The point I was trying to make was that in the case where a
precondition (in this case, Fail a) does not apply, what stops the
resolution algorithm falling back on the other instance
ances
> resolution mechanism that we want to avoid :)))
Actually, it illustrates beautifully why ad-hoc overlapping doesn't
work. There are two interpretations, the desired one, and one that
just ignores the the first and uses the second for everything.
--
Taral <[EMAIL PROTECTED]>
On 2/23/06, Ben Rudiak-Gould <[EMAIL PROTECTED]> wrote:
> In fact, this suggests a compromise: how about implicitly importing the
> Prelude only if the module header is omitted? That way there'll be no impact
> on short (single-module) programs.
+1
--
Taral <[EMAIL PROTEC
uniq =
Now if Set switches to an Ord implementation, I will suddenly have a problem...
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-pr
red an extra problem with RDT: Context can "appear" from nowhere:
In module Heap:
data Ord a => Heap a = ...
In another module:
sort :: [a] -> [a]
sort =
You wanted to mask the constraint, but it will leak into the type
signature of "sort", and there's nothing you can
7;t. I'd love to see
this, but it needs to be implemented as an extension before it can
reasonably be considered for a conservative language extension like
Haskell'.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is
quot;uppercase", "lowercase", while Unicode is a bit more... diverse.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-prime mai
On 2/2/06, Benjamin Franksen <[EMAIL PROTECTED]> wrote:
> This would open the possibility to allow unary (prefix) operators in
> general which I find rather more useful than sections.
Down that road lies APL.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no mo
On 2/2/06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Montag, 30. Januar 2006 17:24 schrieb Taral:
> > On 1/30/06, Thomas Davie <[EMAIL PROTECTED]> wrote:
> > > It gives you regexp and nothing more - this makes it a pain in the
> > > arse to input
in what "predicative" means,
in detail?
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-prime mailing list
Haskell-prime@haskell.o
Haskell' into Haskell'-core and
Haskell'-lazy, and moving ~ and ! patterns into Haskell'-lazy.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
; you don't create some of the same name.
I like the idea. It would merge well with the existential type for
single-parameter classes proposal.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
t
ecial.
This requires scoped type variables.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
On 1/30/06, Johannes Waldmann <[EMAIL PROTECTED]> wrote:
> How can we achieve the same effect in Haskell?
I see no reason why we can't create an existential datatype for every
single-parameter type class, perhaps with autoboxing.
--
Taral <[EMAIL PROTECTED]>
"Computer
\*\+./<=>[EMAIL
PROTECTED]|~].*\)\?$"
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
On 1/28/06, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> Do you have an example of such a program handy?
b = (x, x) where { x :: Num a => a; x = fromInteger 1 }
fromInteger is called twice.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astron
that
under the current grammar, := is a constructor.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
___
Haskell-prime mailing list
Haskell-prime@ha
a type variable would?
If one had a type annotation, say:
f :: a -> _ -> Constr a Int _
would this be unification-equivalent to:
f :: exists b c. a -> b -> Constr a Int c
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers t
57 matches
Mail list logo
