> Niklas Hambüchen nh2.me> writes:
>
> > On 14/10/13 03:20, AntC wrote:
> > ...
> > Then here's a further possible optimisation, instead of making
> > separate calls to `member` and `insert`:
>
> This I understand again. Where do you get insert
> Niklas Hambüchen nh2.me> writes:
>
> > On 13/10/13 21:42, AntC wrote:
> > ...
> > If you use the Set library, that fact may be very visible!
> > Because Set re-sequences the whole list, as per its Ord instance.
> >
> > But List.nub preserv
> Niklas Hambüchen nh2.me> writes:
>
> In sets, the order does not matter, while for nub it does.
>
Let's be careful here!. Niklas, when you say "order", do you mean:
* the _ordering_ from the Ord instance? Or
* the relative sequence of elements in the list?
> ... the fact that Set is used ins
ntages over
old-fashioned records. (But! We do need to solve the Field names problem.
It's great that Adam's GSOC work has incorporated lenses.)
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
> Brent Yorgey seas.upenn.edu> writes:
>
> > On Tue, Sep 03, 2013 at 11:33:46AM +, AntC wrote:
> >
> > I want an instance and type improvement constraint of the form
> >
> > instance (f ~ (-> Bool)) => C Foo (f b) where ...
> >
I'm probably being dumb, but Hoogle nor the wiki are helping me.
I want an instance and type improvement constraint of the form
instance (f ~ (-> Bool)) => C Foo (f b) where ...
The first arg to C is driving type improvement, for example:
instance (f ~ []) => C Bar (f b) where ...
(The
ng the AST, and consumes/outputs each
comment where the comment's Span falls between the nodes' Loc? Would this
need too much lookahead?
(And thank you to Adam for introducing me to the joys of source-munging.
http://www.haskell.org/pipermai
is the original, though I think that would require working
> with the messier Annotated syntax tree.
>
wow! Adam, thank you.
Even copes with multiple nested parens nested parens
instance C ((a, b)) c ...
==> instance C ((a, b)
Since I am working with tuples, I want the code to be clear where it's
dealing with tuples vs the Haskell type infrastructure.
Thanks Ivan for the dependencies list. No surprise that Hlist is using
OneTuple <==> HCons a HNil. That need is exactly what I'm talking about,
not a joke. Lenn
n (and
ideas from Tropashko's 'Relational Lattice' [6]).
Is there anybody using OneTuple 'in anger'?
AntC
[1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings
of the 28th ACM SIGPLAN-SIGACT symposium on Principles
of Programming Languages, pages 261
> Richard A. O'Keefe cs.otago.ac.nz> writes:
>
> There are at least four different things that "an Ord version" might
> mean:
>
> - first sort a list, then eliminate duplicates
> - sort a list eliminating duplicates stably as you go
>(think 'merge sort', using 'union' instead of 'merge')
>
> Brent Yorgey seas.upenn.edu> writes:
> >
> > data Oneple a = Oneple a -- (or newtype)
> > (Oneple $ CustId 47) -- too verbose
> >
>
> This is what the OneTuple package is for:
>
Thank you Brent, and Ivan made the same suggestion.
Apart from b
-- too verbose
type Oneple a = [a]
[CustId 47] -- at least looks bracket-y
What do you do?
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
o` is clearly bound to an Int.
So why is there this `foo` thing that isn't an Int?
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
self.)
Just don't do that! Use long_and_meaningful names.
50-100 near-identical lines of code sounds like an opportunity for an
algorithm.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Francesco Mazzoli mazzo.li> writes:
>
> I have stumbled upon a strange annoyance:
>
> {-# LANGUAGE GADTs #-}
Hi Francesco, I think you'll find that the 'annoyance' is nothing to do
with GADTs. I suggest you take the type signature off of foo1, and see
what type ghc infers for it. It isn'
e same type appears twice in a tuple.
(Contrast that HList uses a 'Lacks' pseudo-constraint/instance failure.)
I hope Template Haskell would help with generating the instances for all
of the n-tuples -- otherwise it's a lot of boilerplate.
The tricky part comes with
the current situation ;-).
I'm saying that many people find the Haskell record system 'as is' so
dysfunctional that they give up on it! I feel strongly that as soon as we
get past the name collissions, there'll be other blockages to using it.
I'd be interested to
ay and in EmployeeTimeSheet.)
[And this use case is what TP/DORF is primarily aimed at.]
[**] Do I need to explain what data model normalisation is? I fear that so-
called XML 'databases' mean academics don't get taught normalisation any
more(?)
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
s in common avoiding doubling-up those fields (aka Relational
Natural Join).
The DORF/TPDORF proposals are aimed much better as a step towards first-
class record types. [IMO **]
Oleg/Ralf's HList paper covers all the ground for first-class records. It
depends heavily on overlaps, which is
to avoid the wasted space of sparse records, it could be a helpful
discipline to design data structures without needing Maybe's.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dmitry Vyal gmail.com> writes:
>
> On 10/19/2012 06:14 AM, AntC wrote:
> > Roman Cheplyaka ro-che.info> writes:
> >
[snip]
> >>> instance (Upcast a b, Upcast b c) => Upcast a c where
> >>>upcast = (upcast :: b -> a) . (upcast :: c -&
y to handle this is using type functions (aka type families aka
associated types), but I'm not sure how that would apply here. (And, for the
record, the old-fashioned way would use functional dependencies, as per the
Heterogenous Collections paper aka 'HList's).
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
better off using an imperative/object-oriented language?
If you're trying to create a static data structure, perhaps the credit card
transform is the approach to use?
> ... I would like just to run some benchmarks and see the results.
Running benchmarks for destructive updates in Haskell see
Surely a case where explicit parens would be better.
(Anything else we can bikeshed about while we're at it?)
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ism gaining?
And by the way, I couldn't help trying a bit of 'compiler archaeology'. I dug
out Hugs version November 2002. My revised hDeleteMany works fine, as does
my 'repair' to the example in 'Ended up in murky water'.
So I can't see a need for TTypeable even back in 2004.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
that to build helper
functions, then banish overlapping type classes?
(I still think that explicitly dis-overlapped instances would be easier to
understand.)
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
s.)
4. Instead of FunDeps, put TypeCasts on all of the instances.
(Or other Class constraints to 'chain' typevars.)
5. And all of the instances must be framed with a bare typevar in the 'result'.
(That is, a typevar distinct from any others in the head.)
6. (As you said to Ryan)
out FunDeps -- and it works in Hugs (using
TypeCast -- but looks prettier in GHC with equality constraints).
Essentially it's a FunDep-like mechanism without FunDeps (as SPJ calls it), to
achieve what Ryan's talking about. But you are quite right that we still need
overlapping insta
structure
that means you have to scan down the structure to get to the element you want.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ere ought to be
close correspondence to type-level functions.
To me, NewAxioms is aiming at type-level case, to provide a different style of
defining type functions, as well as dis-overlapping overlaps.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
penetrable -- the TTypeable
code is a tour de force).
It's all so *dys-functional* (IMO).
My take is that we should abandon Fundeps, and concentrate on introducing
overlaps into type functions in a controlled way (what I've called 'dis-
overlapped overlaps'.)
AntC
__
that to work in
Hugs with fundeps and no overlaps.)
I'm surprised there isn't a Monad Transformer example: [3] by MPJ uses
overlaps for MonadT. And MonadT was (I thought) what gave all the trouble with
overlaps and default instances and silently changing behaviour. (There's a
bri
Gábor Lehel gmail.com> writes:
>
> On Fri, May 25, 2012 at 7:06 AM, AntC clear.net.nz>
wrote:
> > But it looks like the work SPJ pointed to is using closed style. ...
>
> If you're referring to the NewAxioms work Simon linked to in the other
> thread, I don
Twan van Laarhoven gmail.com> writes:
>
> On 24/05/12 14:14, AntC wrote:
> > Simon Peyton-Jones microsoft.com> writes:
> >
>
> Have you considered the alternative notation where multiple guards are
allowed,
> as in normal function definitions? Something
e guards into account.
[SPJ admits that such a restriction "loses part of the point of
overlap in the first place."]
>
>
> Type families already implement the first of these.
> I believe that if we added the second and third, then overlap of type
families would
> be fine. (I may live to eat my words here.)
>
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ch (without a wrapper, but with some fancy instance constraints)
can 'dig out' the function and apply it polymorphically, but he can't get
the function into the record without using an explicit data constructor.
What am I doing wrong?
AntC
--
View this message in context:
http:
d by a discussion on ghc-users re 'Records in Haskell'.
There's a proposal using a typeclass with type arguments in a different order
to the other proposals.]
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
chanism then supports the idea of 'virtual' fields -- SPJ's example of
fullName, built from polymorphic firstName and lastName.
[By the way, did you mean to post to the cafe only? Most of the discussion is
going on on ghc-users.]
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Gábor Lehel gmail.com> writes:
>
> On Mon, Feb 20, 2012 at 4:41 AM, AntC clear.net.nz>
wrote:
> > Folks, I've put my 'Record in Haskell' proposal on the wiki
> > http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared
> > Overl
l.org/trac/ghc/wiki/Records as suggestion 5 Declared
Overloaded Record Fields.
Thanks to the voiciferousness on this thread, dot notation is completely
optional.
Feedback welcome.
AntC
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Some-thoughts-on-Type-Directed-Name-Res
ded,
there's currently no way to put an expression in its place.
So you still can't define a modifyConfig: you couldn't put anything in place
of its (r -> a) parameter that could represent "x".
Now in return for me answering that, please answer the questions in my earlier
post about what limitations on update you'd like:
* record-type changing?
* Higher-ranked fields?
* How many forall'd variables?
* Constrained forall'd variables?
Thank you
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
hen never change it?
How many forall'd variables might you like in the HR field?
- Do you want to put constraints on the HR's forall'd types?
This is where the issue is stuck. Very possibly if we agree workable
constraints, we're going to just run into further difficulties
.
Also we want the (pseudo-) fields to be updatable, which means field update
needs to be polymorphic (overloaded). Then all I need is a type-(or kind-)
level 'peg' for the name, and an instance for Has/get/set.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
' when it comes to dot notation:
A few little-known programming languages have for some reason bucked the well-
established convention of small circle for function composition.
There's certainly nothing about a dot that suggests function composition,
*unless* ...
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Donn Cave avvanta.com> writes:
>
> Quoth AntC clear.net.nz>,
> ...
> > We're on the slippery slope! Where will it end?
> >
> > And now that I've found it, I so love:
> >
> > customer.lastName.tail.head.toUpper-- Yay!
>
>
Gábor Lehel gmail.com> writes:
>
> On Fri, Feb 3, 2012 at 2:37 PM, AntC clear.net.nz>
wrote:
> > Do people really write code with huge pile-ups of functions prefix upon
> > prefix? Wouldn't that be confusing even when it's unidirectional?
>
> Not real
Gábor Lehel gmail.com> writes:
>
> On Fri, Feb 3, 2012 at 10:30 AM, AntC clear.net.nz>
wrote:
> > You seem to be not alone in wanting some special syntax for applying field
> > selectors (see other posts on this thread). H98 field selectors don't do
thi
Kevin Quick sparq.org> writes:
>
> > Currently under H98:
> >f.g-- (both lower case, no space around the dot)
> > Is taken as function composition -- same as (f . g).
> >f. g -- is taken as func composition (f . g)
> >f .g -- is taken as func composition (f . g)
>
gineering' has got to be
careful to 'fit in', and not use up too many of the options that are still
available.
What's special with dot syntax is it's well-established and with well-
established (range of) meanings in other programming paradigms. If we
introduce dot-notation into Haskell, we have to try to make it behave like
those paradigms, but in a 'Haskelly' way.
[To go a little off-topic/out of scope. My gold standard is
polymorphic/anonymous records with concatenation, merge, projection,
extension, everything you get in relational algebra. I don't want to use up
all the design options just getting through the current namespace
restrictions -- infuriating though they are.]
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kevin Quick sparq.org> writes:
>
>
> On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden
> clear.net.nz> wrote:
> > I'm proposing x.f is _exactly_ f x. That is, the x.f gets
> > desugared at an early phase in compilation.
>
> Anthony,
>
> I think part of the concern people are expressing h
Donn Cave avvanta.com> writes:
>
> Quoth AntC clear.net.nz>,
> ...
> > My proposal is that field selection functions be just ordinary functions,
and
> > dot notation be just function application(tight-binding). Then:
> > object.fieldfuncmethod ==>
ite in your familiar style, and can use polymorphic field
selectors as plain functions (same syntax as presently).
Those under the influence of OO can write dot notation, until they discover
the joys of pointless style.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Steve Horne blueyonder.co.uk> writes:
>
> There's a proposal at the moment to add support for TDNR to Haskell
> - to leverage "the power of the dot" (e.g. for
intellisense).http://hackage.haskell.org/trac/haskell-
prime/wiki/TypeDirectedNameResolution
> I approve of the goal, ...
S
54 matches
Mail list logo
