July 2017 - Haskell-Cafe

I'm afraid of OverloadedLabels.
by Nikita Churaev 10 Jul '17

10 Jul '17

So gi-gtk is already using OverloadedLabels to fight the namespacing problem. What I'm afraid is that eventually people will pick up on this and stop using normal functions altogether. My problem with OverloadedLabels is that it is a class: if people start using it widely, the original modules of types are going to become even more privileged than they already are: only it will be canonically able to define functions which can be conveniently called, and everybody else will have to only define "second-class" normal functions or risk instance collisions. I mean yes, it's the same as in most OOP languages, but isn't it also bad? There must be a better way... Is there any alternative approach to name collisions coming?

7 11

Fwd: constraint inference
by Dmitry Olshansky 10 Jul '17

10 Jul '17

Sorry, I didn't copy to cafe... ---------- Forwarded message ---------- From: Dmitry Olshansky <olshanskydr(a)gmail.com> Date: 2017-07-07 9:24 GMT+03:00 Subject: Re: [Haskell-cafe] constraint inference To: Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> I am not sure why but when I didn't set RankNTypes I got an appropriate error. So I specified it. But if I write let { f :: (forall n. KnownSymbol n => Proxy n) -> String; f p = symbolVal p } then nothing is changed. 2017-07-07 9:11 GMT+03:00 Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com>: > You've specified RankNTypes but aren't using it; did you mean "(forall > n. KnownSymbol n => Proxy n)" ? > > Typically in these situations you also can't partially apply it, so > you might need to make it "f p = symbolVal p". > > On 7 July 2017 at 15:50, Dmitry Olshansky <olshanskydr(a)gmail.com> wrote: > > Hello, cafe! > > > > If we have many constraints then compiling is sometimes too slow. > Especially > > if there are some type calculations. > > And I don't know how to divide this time among different source files > > because all constraints are checked only when we call a function. > > > > I tried to add constraint info into argument definition instead of the > > function signature but this trick is not working (see below). > > > > Is it (at least theoretically) possible to infer the constraint inside a > > function from the type of function's argument? > > > > ------------------------------------ > > $ stack ghci > > ---- GHCi, version 8.0.2: > > Prelude> import Data.Proxy > > Prelude Data.Proxy> import GHC.TypeLits > > Prelude Data.Proxy GHC.TypeLits> :set -XRankNTypes > > Prelude Data.Proxy GHC.TypeLits> let { f :: (KnownSymbol n => Proxy n) -> > > String; f = symbolVal } > > > > <interactive>:4:54: error: > > • No instance for (KnownSymbol n) arising from a use of ‘symbolVal’ > > Possible fix: > > add (KnownSymbol n) to the context of > > the type signature for: > > f :: (KnownSymbol n => Proxy n) -> String > > • In the expression: symbolVal > > In an equation for ‘f’: f = symbolVal > > ------------------------------------ > > > > Best regards, > > Dmitry > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic(a)gmail.com > http://IvanMiljenovic.wordpress.com >

2 2

[ANN] [Reminder] Budapest Haskell Hackathon 2017, 29-30th July 2017
by Daniel Berecz 10 Jul '17

10 Jul '17

Hi everybody, Just a last reminder about our hackathon in Budapest at the end of July: Our local user group will hold a Haskell Hackathon in Budapest this year (this will be the second)! We will hold it from the 29th to the 30th of July (Saturday & Sunday). You can find out more on the following link: https://wiki.haskell.org/Budapest_Hackathon_2017 We will reguraly update the site with new information. If you decide to come, please fill out the following Google Form: https://goo.gl/forms/QjTNdXTD1aEOMEQU2 If you have a project, demo, or talk that you want to bring to the event please contact us, and we can talk about the details. You can find our contact info the events wiki site, or you can just contact me directly. The event will be open to people of all experience levels, from beginners to gurus. The only requisite is that you’re interested in the Haskell language, and want to hang out with us, and have a good time! Greetings from Daniel, and the other BP-HUG organizers.

1 0

Re: [Haskell-cafe] I'm afraid of OverloadedLabels.
by Anthony Clayden 10 Jul '17

10 Jul '17

> On Mon Jul 10 02:57:02 UTC 2017, Nikita Churaev wrote: > > You can maybe fix that up with FunDeps > > or TypeFamilies, but then you lose most of TDNR's > > benefits (esp not coping with existential quanted fields > > , which is typically a requirement to cope with > > OOP-style). > > What benefits exactly are lost? Hi Nikita, I'm not sure I (or anybody) has the energy for another round of the "records debate". The TDNR (ex-)proposal seems so attractive because it just doesn't consider in detail all the complexities. They're magically swept under the carpet with the special dot syntax. So you might expect TDNR would support all of the functionality with H98 field names, plus having multiple fields of the same name. But how? Note the comment on TDNR section 'The Proposal' "TDNR is not "overloading" in the sense of type classes." And there were plenty of complaints that it's confusingly similar-but-different to type classes. You could look at SPJ's re-working of TDNR [2010] as SORF [2013]: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/SORF SORF took advantage of the new Symbol Kinds (not available in 2010), and tried to be more type-class-like, with the `Has` class. One of the motivations with SORF is "Records with polymorphic fields are very important in practice, so it would be a major wart not to support them." TDNR just didn't discuss higher-ranked types. It turned out that was just too hard, even for SORF. (Or rather for OverloadedRecordFields, which is what's being delivered from SORF.) SORF tries to tackle record update, for which TDNR said "However I propose not to apply it [TDNR] to record update. " I don't think our cousins in OOP would be impressed by a records system in which you can't write polymorphic record updates. (I.e. a method to update the `firstName` in any record that has that field.) Actually delivering improvements in GHC around records is being painfully slow. `DuplicateRecordFields` has eased the pain a little. Ironically `OverloadedRecordFields` doesn't tackle higher-ranked types, nor record updates. And needs special syntax `#firstName`. So perhaps TDNR's "benefits" were never achievable? ANtC

1 0

Re: [Haskell-cafe] I'm afraid of OverloadedLabels.
by Anthony Clayden 10 Jul '17

10 Jul '17

> On Mon Jul 10 00:16:02 UTC 2017, Richard A. O'Keefe wrote: > ... > As a native speaker of an SVO language (English) > in a country where one of the official languages is VSO (Māori), > I sometimes find the OVS structure of > "mainstream OO languages" a little uncomfortable... > "Backward ran sentences until reeled the mind." lol. That's a cute comparison. I don't think "mainstream OO" is OVS. In: > ... button.colour <- red Gloss: 'button's colour goes red'. `button's colour` is the grammatical Subject. (Yes it represents an OOP 'Object.method', but that's because everything in OOP is an 'Object'; and the only way to access is by methods.) > ... button.reset Again `button` is the grammatical Subject. (It must be, because there's no grammatical Object.) Then `reset` must be the verb, used intransitively. (In French you'd use a reflexive: `the button resets itself`.) This dot-suffixing is already in Haskell: Data.ByteString.Lazy.Builder.Extras 'Data's ByteString's Lazy's Builder's Extras'. To me it seemed natural to carry on ....Extras.untrimmedStrategy.buffSize That is, a field is just a component that might have (sub-)sub-component(s). The field 'belongs to' the structure, so dot represents English possessive. And that's just how lenses look, deliberately. (But that's a mystifying pun on use of the dot: the dot changes from compound name separator to function composition.) But the outcry against TDNR's proposal for dot really was voiciferous. (And nobody paid so much attention to the semantics. So the flaw in TDNR wasn't discovered for a long time.) AntC

3 2

Re: [Haskell-cafe] I'm afraid of OverloadedLabels.
by Anthony Clayden 09 Jul '17

09 Jul '17

> On Sun Jul 9 20:37:23 UTC 2017, Alexis King wrote: > > On Jul 9, 2017, at 10:36, Ertugrul Söylemez <esz at posteo.de> wrote: > > > AND PLEASE not the way an [existing proposal] suggests to do it! > > Please let's just do ad-hoc overloading. There is no reason to > > introduce new syntax, because syntax is completely orthogonal > > to this problem. > > > > [existing proposal]: > > https://prime.haskell.org/wiki/TypeDirectedNameResolution Folks, that is not an existing proposal. SPJ's write-up is seductive, but fatally flawed, as Edward Kmett pointed out during the OverLoadedRecordFields development work. Quite apart from its relying on special syntax, TDNR can't cope with nested records. In: > ... student.course.instructor ... the `.course.instructor` is irresolvably ambiguous, in exactly the same way as `(show . read)`. You can maybe fix that up with FunDeps or TypeFamilies, but then you lose most of TDNR's benefits (esp not coping with existential quanted fields, which is typically a requirement to cope with OOP-style). > If I understand correctly, what youre proposing is the syntax-free > variant of TDNR, which is already outlined here: > https://ghc.haskell.org/trac/ghc/wiki/SyntaxFreeTypeDirectedNameResolution I think everyone should read the accompanying discussion. That turned out to be not an 'outline' but just a piece of wishful thinking. It has all the flaws of the original TDNR, plus a few of its own. > I agree that would be a very nice feature to have, and I think doing it > without new syntax would be strongly preferable to adding new syntax. > The proposal outlines the basics of how it would work, but I have no > idea how difficult it would be to implement in practice. Quite. AntC

2 1

Re: [Haskell-cafe] I'm afraid of OverloadedLabels
by Anthony Clayden 09 Jul '17

09 Jul '17

> On Sun Jul 9 21:04:33 UTC 2017, MarLinn wrote: > ... > Isn't it about time to allow explicit imports, and more importantly, > explicit non-imports for instances? > Some time ago I fantasised about some special syntax for this, > calling the (very rough) idea "aspects" ... Sorry, I didn't realise that "aspects" thread was about controlling instance scope. I did try to start a thread on instance scope a few days ago https://mail.haskell.org/pipermail/haskell-cafe/2017-July/127435.html I am interested in use cases for scope-controlling instances. Specifically I'm not seeing how scoping instances (instances of what, exactly?) helps with the "record problem". Typically if you have several record types with the same-named field, you want all of those to be in scope, where the field-access gets resolved according to the record's type. The `DuplicateRecordFields` extension now provides reasonable support for that, doesn't it? AntC

1 0

Collision Detection
by Yotam Ohad 09 Jul '17

09 Jul '17

Dear Cafe, I am thinking about writing a small physics engine with collision detection and I wanted to go over my ideas with you to help me refine them. I want to express objects as a group of inequalities and their domain. For example, a sphere would be only one inequality: x^2+y^2+z^2 -1 <= 0 on the whole domain. That way, to check a collision between two objects, one needs to check if at least one pair of inequalities with overlapping domains has a solution. I am unsure about how to express the inequalities in a way that could still allow me to compare between two of them. To add forces in, I think I can express them by adding a time dimension to the inequalities. For example, a constant force in the x-dimension on the previous sphere could be represented as (C+dx/dt*t+0.5*a*t^2)^2+y^2+z^2 <= 0. But then I am not sure about how to treat non-integrable forces. Another approach is to calculate the displacement of the object after each time interval. I don't like this approach as I want to integrate it with FRP in the end, and FRP continues time is something I would like to preserve. After I'll have everything above sorted, the next things would be to run simulations. I think at the start I'll check every pair of objects and try to calculate whether or not the will collide in the future. I'll save all the results in ascending time order. and every iteration, update the movement after the closest collision and update the collision pair order. Thanks, Yotam

3 2

Speed of simulation in Aivika
by David Sorokin 09 Jul '17

09 Jul '17

Hi Cafe, I’m glad to inform that the speed of simulation in the aivika [1] simulation library of version >= 5.2 has been dramatically increased after I started using the mwc-random [2] package for generating random numbers. It was possible to use custom random number generators before, but now the random number generator from the mentioned package is used by default. To improve the speed of simulation, in most cases it will be sufficient just to recompile your simulation models. In some my tests the speed of simulation has been increased up to 7 times when using default settings. The mwc-random package is just fantastic! Another good news is that I recently improved the distributed simulation module [3], which has recovering capabilities now in case of temporary connection errors. It should be quite unusual for the optimistic Time Warp method. In short, it means that we can build discrete event distributed simulation models using the ordinary Internet and cloud services. Best regards, David Sorokin [1] http://hackage.haskell.org/package/aivika [2] http://hackage.haskell.org/package/mwc-random [3] http://hackage.haskell.org/package/aivika-distributed

2 1

Haskell in Leipzig 2017: 2nd call for papers
by Wolfgang Jeltsch 07 Jul '17

07 Jul '17

Event: Haskell in Leipzig 2017 Time: October 26–28, 2017 Place: HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions ============= Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 4, 2017. You will be notified by Friday, August 25, 2017. Hacking Projects ================ Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker =============== * Ivan Perez, University of Nottingham, UK Program Committee ================= * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it(a)jeltsch.info.

1 0