From oleg.grenrus at iki.fi Wed Nov 1 00:27:57 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 1 Nov 2023 02:27:57 +0200 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: References: Message-ID: Yes, the "communication between lexer and parser" is exactly what GHC does. Amelia has a nice post about it https://amelia.how/posts/parsing-layout.html which made it click it for me. Note, you don't actually need to use alex and happy, you can do hand-written lexer and parsec (or alex and parsec, ...). The key insight is to have stateful lexer, and control it from the parser. Amelia's post grammar is a bit too strict, e.g. GHC accepts real semis in virtual layout, and also empty "statements" in between, so we can write    \x y z -> case x of True -> y;;;;;; False -> z but that's easy (at least in parsec) to adjust the parser grammar to accept those. Or, you can *approximate* the parse-error rule with "alternative layout rule" [1], which can be implemented as a pass between lexing and parsing, or as a stateful lexer (but in this case parser won't need to adjust lexer's state). GHC has an undocumented AlternativeLayoutRule extension, so you can experiment with it to see what it accepts (look for tests in GHC source for examples). It handles let-in bindings well enough. [1] https://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html which can be imp - Oleg On 1.11.2023 0.31, Travis Athougies wrote: > According to the Haskell report [1] (See Note 5), a virtual `}` token > is inserted if parsing the next token would cause a parse error and the > indentation stack is non-empty. > > I'm trying to lex and parse Haskell source and this sort of interplay > (which requires two-way communication between lexer and parser) makes > it very difficult to write a conformant implementation. > > I can't change the standard (obviously), but I'm wondering if this is > actually what GHC (de facto the only Haskell compiler) does, or if it > applies some other rule. If so, does anyone know the exact mechanism of > its implementation? > > I've been programming Haskell for more than a decade, and while I have > an intuitive understanding of the indentation rules, I would have > assumed the source could be lexed without also having a parser. In > particular, the note seems to imply that the main purpose of this is to > properly lex `let`/`in` bindings. Perhaps there's an alternate > equivalent rule? > > Curious to hear other's thoughts. > > Travis > > [1] > https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Nov 1 00:32:12 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 1 Nov 2023 00:32:12 +0000 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: References: Message-ID: Feedback between lexer and parser isn't exactly unusual. Consider that parsing a C `typedef` generally needs to feed back to the lexer so uses will be recognized properly. On Wed, Nov 1, 2023 at 12:28 AM Oleg Grenrus wrote: > Yes, the "communication between lexer and parser" is exactly what GHC does. > > Amelia has a nice post about it > https://amelia.how/posts/parsing-layout.html which made it click it for > me. > > Note, you don't actually need to use alex and happy, you can do > hand-written lexer and parsec (or alex and parsec, ...). The key insight is > to have stateful lexer, and control it from the parser. > > Amelia's post grammar is a bit too strict, e.g. GHC accepts real semis in > virtual layout, and also empty "statements" in between, so we can write > > \x y z -> case x of True -> y;;;;;; False -> z > > but that's easy (at least in parsec) to adjust the parser grammar to > accept those. > > Or, you can *approximate* the parse-error rule with "alternative layout > rule" [1], which can be implemented as a pass between lexing and parsing, > or as a stateful lexer (but in this case parser won't need to adjust > lexer's state). GHC has an undocumented AlternativeLayoutRule extension, so > you can experiment with it to see what it accepts (look for tests in GHC > source for examples). It handles let-in bindings well enough. > > [1] https://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html > which can be imp > > - Oleg > > On 1.11.2023 0.31, Travis Athougies wrote: > > According to the Haskell report [1] (See Note 5), a virtual `}` token > is inserted if parsing the next token would cause a parse error and the > indentation stack is non-empty. > > I'm trying to lex and parse Haskell source and this sort of interplay > (which requires two-way communication between lexer and parser) makes > it very difficult to write a conformant implementation. > > I can't change the standard (obviously), but I'm wondering if this is > actually what GHC (de facto the only Haskell compiler) does, or if it > applies some other rule. If so, does anyone know the exact mechanism of > its implementation? > > I've been programming Haskell for more than a decade, and while I have > an intuitive understanding of the indentation rules, I would have > assumed the source could be lexed without also having a parser. In > particular, the note seems to imply that the main purpose of this is to > properly lex `let`/`in` bindings. Perhaps there's an alternate > equivalent rule? > > Curious to hear other's thoughts. > > Travis > > [1] > > https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 > > > _______________________________________________ > 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. > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Nov 1 00:51:04 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 1 Nov 2023 02:51:04 +0200 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: References: Message-ID: <61950d60-4aab-4c61-54e1-62fbe9b93905@iki.fi> In C, AFAIU you can (and probably should) defer `typedef` usage recognition to a separate "renamer/ name resolution" pass. In Haskell we are forced to do name resolution after parsing, as we don't need to declare stuff before use. Even so, separate pass is usually a good idea anyway, you are better equipped to produce good error messages. In fact GHC does even more: it defers the unbound names reporting to the type checking phase, so it can give the types to unbound variables, like:     Prelude> x : "foo"     :2:1: error: Variable not in scope: x :: Char - Oleg On 1.11.2023 2.32, Brandon Allbery wrote: > Feedback between lexer and parser isn't exactly unusual. Consider that > parsing a C `typedef` generally needs to feed back to the lexer so > uses will be recognized properly. > > On Wed, Nov 1, 2023 at 12:28 AM Oleg Grenrus wrote: > > Yes, the "communication between lexer and parser" is exactly what > GHC does. > > Amelia has a nice post about it > https://amelia.how/posts/parsing-layout.html which made it click > it for me. > > Note, you don't actually need to use alex and happy, you can do > hand-written lexer and parsec (or alex and parsec, ...). The key > insight is to have stateful lexer, and control it from the parser. > > Amelia's post grammar is a bit too strict, e.g. GHC accepts real > semis in virtual layout, and also empty "statements" in between, > so we can write > >    \x y z -> case x of True -> y;;;;;; False -> z > > but that's easy (at least in parsec) to adjust the parser grammar > to accept those. > > Or, you can *approximate* the parse-error rule with "alternative > layout rule" [1], which can be implemented as a pass between > lexing and parsing, or as a stateful lexer (but in this case > parser won't need to adjust lexer's state). GHC has an > undocumented AlternativeLayoutRule extension, so you can > experiment with it to see what it accepts (look for tests in GHC > source for examples). It handles let-in bindings well enough. > > [1] > https://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html > which can be imp > > - Oleg > > On 1.11.2023 0.31, Travis Athougies wrote: >> According to the Haskell report [1] (See Note 5), a virtual `}` token >> is inserted if parsing the next token would cause a parse error >> and the >> indentation stack is non-empty. >> >> I'm trying to lex and parse Haskell source and this sort of interplay >> (which requires two-way communication between lexer and parser) makes >> it very difficult to write a conformant implementation. >> >> I can't change the standard (obviously), but I'm wondering if this is >> actually what GHC (de facto the only Haskell compiler) does, or if it >> applies some other rule. If so, does anyone know the exact >> mechanism of >> its implementation? >> >> I've been programming Haskell for more than a decade, and while I >> have >> an intuitive understanding of the indentation rules, I would have >> assumed the source could be lexed without also having a parser. In >> particular, the note seems to imply that the main purpose of this >> is to >> properly lex `let`/`in` bindings. Perhaps there's an alternate >> equivalent rule? >> >> Curious to hear other's thoughts. >> >> Travis >> >> [1] >> https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 > > _______________________________________________ > 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. > _______________________________________________ > 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. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaace71295 at gmail.com Wed Nov 1 00:55:27 2023 From: isaace71295 at gmail.com (Isaac Elliott) Date: Wed, 1 Nov 2023 10:55:27 +1000 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: References: Message-ID: I like the approach from "Principled Parsing for Indentation-Sensitive Languages" (https://michaeldadams.org/papers/layout_parsing/) On Wed, Nov 1, 2023 at 8:32 AM Travis Athougies wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > According to the Haskell report [1] (See Note 5), a virtual `}` token > is inserted if parsing the next token would cause a parse error and the > indentation stack is non-empty. > > I'm trying to lex and parse Haskell source and this sort of interplay > (which requires two-way communication between lexer and parser) makes > it very difficult to write a conformant implementation. > > I can't change the standard (obviously), but I'm wondering if this is > actually what GHC (de facto the only Haskell compiler) does, or if it > applies some other rule. If so, does anyone know the exact mechanism of > its implementation? > > I've been programming Haskell for more than a decade, and while I have > an intuitive understanding of the indentation rules, I would have > assumed the source could be lexed without also having a parser. In > particular, the note seems to imply that the main purpose of this is to > properly lex `let`/`in` bindings. Perhaps there's an alternate > equivalent rule? > > Curious to hear other's thoughts. > > Travis > > [1] > > https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 > -----BEGIN PGP SIGNATURE----- > > iIsEARYKADMWIQRW81c55hOCXuY5k/H+BxaRGQDTjQUCZUGARhUcdHJhdmlzQGF0 > aG91Z2llcy5uZXQACgkQ/gcWkRkA041W+wEA/7n5NejGTYu4O6N+Pt7Rn0bBRw6D > 5D96idagahXqXioA/18hxYFpY45lWwB7pKCh83xQJu2Bcwkxj1xhhCEZBcoA > =FrDy > -----END PGP SIGNATURE----- > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From x at tomsmeding.com Thu Nov 2 20:50:01 2023 From: x at tomsmeding.com (Tom Smeding) Date: Thu, 2 Nov 2023 21:50:01 +0100 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: <61950d60-4aab-4c61-54e1-62fbe9b93905@iki.fi> References: <61950d60-4aab-4c61-54e1-62fbe9b93905@iki.fi> Message-ID: <0e8ba474-58d7-493a-a6c9-3b2d70df8825@tomsmeding.com> The fun (?) thing about C syntax is that you _cannot_ defer this. Consider the following (invalid) C program: int main(void) {   t * x;   int t;   t * x; } When I pass this through gcc, what I get is: file.c: In function ‘main’: file.c:2:3: error: unknown type name ‘t’     2 |   t * x;       |   ^ file.c:4:5: error: invalid operands to binary * (have ‘int’ and ‘int *’)     4 |   t * x;       |     ^ The first 't * x' statement was parsed as a declaration of the variable 'x' with as type 't*'. The second such statement was parsed as a multiplication. The difference in behaviour is the declaration of 't' as a variable in between. When starting this email I thought that the default was the other way round, i.e. 't * x' is parsed as a multiplication unless 't' is defined as a type; this would be accomplished by e.g. 'typedef int t;'. However it seems that the default, at least in gcc 13.2.1, is a variable declaration. Luckily (?), the point stands that to lex C, if you want to distinguish multiplication from the pointer type symbol, you need communication from the parser. - Tom On 01/11/2023 01:51, Oleg Grenrus wrote: > > In C, AFAIU you can (and probably should) defer `typedef` usage > recognition to a separate "renamer/ name resolution" pass. In Haskell > we are forced to do name resolution after parsing, as we don't need to > declare stuff before use. Even so, separate pass is usually a good > idea anyway, you are better equipped to produce good error messages. > In fact GHC does even more: it defers the unbound names reporting to > the type checking phase, so it can give the types to unbound > variables, like: > >     Prelude> x : "foo" >     :2:1: error: Variable not in scope: x :: Char > > - Oleg > > On 1.11.2023 2.32, Brandon Allbery wrote: >> Feedback between lexer and parser isn't exactly unusual. Consider >> that parsing a C `typedef` generally needs to feed back to the lexer >> so uses will be recognized properly. >> >> On Wed, Nov 1, 2023 at 12:28 AM Oleg Grenrus wrote: >> >> Yes, the "communication between lexer and parser" is exactly what >> GHC does. >> >> Amelia has a nice post about it >> https://amelia.how/posts/parsing-layout.html which made it click >> it for me. >> >> Note, you don't actually need to use alex and happy, you can do >> hand-written lexer and parsec (or alex and parsec, ...). The key >> insight is to have stateful lexer, and control it from the parser. >> >> Amelia's post grammar is a bit too strict, e.g. GHC accepts real >> semis in virtual layout, and also empty "statements" in between, >> so we can write >> >>    \x y z -> case x of True -> y;;;;;; False -> z >> >> but that's easy (at least in parsec) to adjust the parser grammar >> to accept those. >> >> Or, you can *approximate* the parse-error rule with "alternative >> layout rule" [1], which can be implemented as a pass between >> lexing and parsing, or as a stateful lexer (but in this case >> parser won't need to adjust lexer's state). GHC has an >> undocumented AlternativeLayoutRule extension, so you can >> experiment with it to see what it accepts (look for tests in GHC >> source for examples). It handles let-in bindings well enough. >> >> [1] >> https://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html >> which can be imp >> >> - Oleg >> >> On 1.11.2023 0.31, Travis Athougies wrote: >>> According to the Haskell report [1] (See Note 5), a virtual `}` >>> token >>> is inserted if parsing the next token would cause a parse error >>> and the >>> indentation stack is non-empty. >>> >>> I'm trying to lex and parse Haskell source and this sort of >>> interplay >>> (which requires two-way communication between lexer and parser) >>> makes >>> it very difficult to write a conformant implementation. >>> >>> I can't change the standard (obviously), but I'm wondering if >>> this is >>> actually what GHC (de facto the only Haskell compiler) does, or >>> if it >>> applies some other rule. If so, does anyone know the exact >>> mechanism of >>> its implementation? >>> >>> I've been programming Haskell for more than a decade, and while >>> I have >>> an intuitive understanding of the indentation rules, I would have >>> assumed the source could be lexed without also having a parser. In >>> particular, the note seems to imply that the main purpose of >>> this is to >>> properly lex `let`/`in` bindings. Perhaps there's an alternate >>> equivalent rule? >>> >>> Curious to hear other's thoughts. >>> >>> Travis >>> >>> [1] >>> https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 >> > _______________________________________________ > 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. >> _______________________________________________ >> 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. >> >> >> >> -- >> brandon s allbery kf8nh >> allbery.b at gmail.com > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Thu Nov 2 21:01:34 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 2 Nov 2023 23:01:34 +0200 Subject: [Haskell-cafe] Question on Lexing Haskell syntax In-Reply-To: <0e8ba474-58d7-493a-a6c9-3b2d70df8825@tomsmeding.com> References: <61950d60-4aab-4c61-54e1-62fbe9b93905@iki.fi> <0e8ba474-58d7-493a-a6c9-3b2d70df8825@tomsmeding.com> Message-ID: <6371c0ef-080b-76dc-5abb-0b98d62f9207@iki.fi> That is, if you want to have distinct tokens for multiplication and pointer type asterisks. I don't see why you would need to do that distinction in the lexer though. You can just lex * as an asterisk, and later in parser figure out what that asterisk meant. The same way various parenthesis and brackets, or comma are often overloaded in the programming languages, but that doesn't complicate their lexing in any way. The Haskell indentation is much more complicated. Your example illustrates that parser cannot operate (decide between variable definition or an expression) without also processing typedef statements. So C forces part of renaming to be done in parsing. That is unfortunate coupling, but it's different coupling. - Oleg On 2.11.2023 22.50, Tom Smeding wrote: > The fun (?) thing about C syntax is that you _cannot_ defer this. > Consider the following (invalid) C program: > > int main(void) { >   t * x; >   int t; >   t * x; > } > > When I pass this through gcc, what I get is: > > file.c: In function ‘main’: > file.c:2:3: error: unknown type name ‘t’ >     2 |   t * x; >       |   ^ > file.c:4:5: error: invalid operands to binary * (have ‘int’ and ‘int *’) >     4 |   t * x; >       |     ^ > > The first 't * x' statement was parsed as a declaration of the > variable 'x' with as type 't*'. The second such statement was parsed > as a multiplication. The difference in behaviour is the declaration of > 't' as a variable in between. > > When starting this email I thought that the default was the other way > round, i.e. 't * x' is parsed as a multiplication unless 't' is > defined as a type; this would be accomplished by e.g. 'typedef int > t;'. However it seems that the default, at least in gcc 13.2.1, is a > variable declaration. Luckily (?), the point stands that to lex C, if > you want to distinguish multiplication from the pointer type symbol, > you need communication from the parser. > > - Tom > > On 01/11/2023 01:51, Oleg Grenrus wrote: >> >> In C, AFAIU you can (and probably should) defer `typedef` usage >> recognition to a separate "renamer/ name resolution" pass. In Haskell >> we are forced to do name resolution after parsing, as we don't need >> to declare stuff before use. Even so, separate pass is usually a good >> idea anyway, you are better equipped to produce good error messages. >> In fact GHC does even more: it defers the unbound names reporting to >> the type checking phase, so it can give the types to unbound >> variables, like: >> >>     Prelude> x : "foo" >>     :2:1: error: Variable not in scope: x :: Char >> >> - Oleg >> >> On 1.11.2023 2.32, Brandon Allbery wrote: >>> Feedback between lexer and parser isn't exactly unusual. Consider >>> that parsing a C `typedef` generally needs to feed back to the lexer >>> so uses will be recognized properly. >>> >>> On Wed, Nov 1, 2023 at 12:28 AM Oleg Grenrus >>> wrote: >>> >>> Yes, the "communication between lexer and parser" is exactly >>> what GHC does. >>> >>> Amelia has a nice post about it >>> https://amelia.how/posts/parsing-layout.html which made it click >>> it for me. >>> >>> Note, you don't actually need to use alex and happy, you can do >>> hand-written lexer and parsec (or alex and parsec, ...). The key >>> insight is to have stateful lexer, and control it from the parser. >>> >>> Amelia's post grammar is a bit too strict, e.g. GHC accepts real >>> semis in virtual layout, and also empty "statements" in between, >>> so we can write >>> >>>    \x y z -> case x of True -> y;;;;;; False -> z >>> >>> but that's easy (at least in parsec) to adjust the parser >>> grammar to accept those. >>> >>> Or, you can *approximate* the parse-error rule with "alternative >>> layout rule" [1], which can be implemented as a pass between >>> lexing and parsing, or as a stateful lexer (but in this case >>> parser won't need to adjust lexer's state). GHC has an >>> undocumented AlternativeLayoutRule extension, so you can >>> experiment with it to see what it accepts (look for tests in GHC >>> source for examples). It handles let-in bindings well enough. >>> >>> [1] >>> https://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html >>> which can be imp >>> >>> - Oleg >>> >>> On 1.11.2023 0.31, Travis Athougies wrote: >>>> According to the Haskell report [1] (See Note 5), a virtual `}` >>>> token >>>> is inserted if parsing the next token would cause a parse error >>>> and the >>>> indentation stack is non-empty. >>>> >>>> I'm trying to lex and parse Haskell source and this sort of >>>> interplay >>>> (which requires two-way communication between lexer and parser) >>>> makes >>>> it very difficult to write a conformant implementation. >>>> >>>> I can't change the standard (obviously), but I'm wondering if >>>> this is >>>> actually what GHC (de facto the only Haskell compiler) does, or >>>> if it >>>> applies some other rule. If so, does anyone know the exact >>>> mechanism of >>>> its implementation? >>>> >>>> I've been programming Haskell for more than a decade, and while >>>> I have >>>> an intuitive understanding of the indentation rules, I would have >>>> assumed the source could be lexed without also having a parser. In >>>> particular, the note seems to imply that the main purpose of >>>> this is to >>>> properly lex `let`/`in` bindings. Perhaps there's an alternate >>>> equivalent rule? >>>> >>>> Curious to hear other's thoughts. >>>> >>>> Travis >>>> >>>> [1] >>>> https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3 >>> > _______________________________________________ > 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. >>> _______________________________________________ >>> 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. >>> >>> >>> >>> -- >>> brandon s allbery kf8nh >>> allbery.b at gmail.com >> >> _______________________________________________ >> 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. > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.wehr at gmail.com Fri Nov 3 10:01:30 2023 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Fri, 3 Nov 2023 11:01:30 +0100 Subject: [Haskell-cafe] Call for Contributions: BOB 2024 [March 15, Deadline Nov 17] Message-ID: ======================================================================== BOB Conference 2024 "What happens when we use what's best for a change?" https://bobkonf.de/2024/cfc.html Berlin, Mar 17 Call for Contributions Deadline: November 17, 2023 ======================================================================== You are actively engaged in advanced software engineering methods, solve ambitious problem with software and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not able to attend the conference for financial reasons. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - "fancy types" (dependent types, gradual typing, linear types, ...) - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - program synthesis - next-generation IDEs - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be - … includeing rough ideas worth discussing. Presenters should provide the audience with information that is practically useful for software developers. Challenges ---------- Furthermore, we seek contributions on successful approaches for solving hard problems, for example: - bias in machine-learning systems - digital transformation in difficult settings - accessibiltity - systems with critical reliability requirements - ecologically sustainable software development We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Organisation ------------ - Direct questions to konferenz at bobkonf dot de - Proposal deadline: November 17, 2023 - Notification: December 5, 2023 - Program: December 12, 2023 Submit here: https://pretalx.com/bob-2024/submit/ Program Committee ----------------- (more information here: https://bobkonf.de/2024/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Thu Nov 9 08:23:43 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 9 Nov 2023 00:23:43 -0800 Subject: [Haskell-cafe] [ANN] Copilot 3.17 Message-ID: Hi everyone!! We are very excited to announce Copilot 3.17 [2]. Copilot is a stream-based EDSL in Haskell for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Copilotis being used at NASA in drone test flights. Through the NASA tool Ogma [1] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), and FPrime (the software framework used in the Mars Helicopter) applications. This release introduces compatibility with what4 versions up to 1.5.1, and replaces several functions in copilot-core. The second change is a breaking change: the functions replaced have been deprecated and new alternatives introduced instead. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for Jan 7th, 2024. In our last announcement, we mentioned that Copilot has received full approval for release as NASA Class D open-source software. Current emphasis is on increasing test coverage for the two remaining libraries without tests (copilot-libraries and copilot-theorem), removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. There have been many updates on the Copilot front in the last few months. We'll be able to announce more soon. Stay tuned. Happy Haskelling! Ivan [1] https://github.com/nasa/ogma [2] https://github.com/Copilot-Language/copilot/releases/tag/v3.17 [3] https://github.com/Copilot-Language/copilot [4] https://hackage.haskell.org/package/copilot -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Thu Nov 9 17:26:31 2023 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Thu, 9 Nov 2023 20:26:31 +0300 Subject: [Haskell-cafe] [ANN] mig-0.2 library to build servers and clients Message-ID: I’m happy to announce the latest release of mig-0.2 library. It is a library to write composable servers for simple / boring haskell. The main focus of this release is the ability to serve Swagger UI from the server with ease and ability to create clients from the same code as servers. I’m happy to confirm that both goals are reached with this release. The tutorial for the library was created. Also there are many other improvements: - OpenApi schema for servers - swagger servers support (we can add swagger to server with one line of code: withSwagger def server ) - clients from the same code as servers - redesign of internal types - redesign of DSL for routes - many ergonomic improvements - packages for extra utils - split of mig package to several packages: - mig - core - mig-wai - rendering servers to wai apps - mig-client - clients - mig-extra - extra utils - mig-server - mig servers with batteries - mig-swagger-ui - swagger ui server - tutorial and quickstart guide on github pages - CI for repo with formatter, build and tests and update of docs on github pages The internal type for Servers was redesigned so that we assemble the handler function with API description at the same time. In the first release it was just a handler function under the hood. As a refresher mig is a family of libraries to write lightweight, simple, type-safe and composable servers. It strives to be in the middle ground between scotty and servant. To be composable, flexible and type-safe as servant and simple and lightweight in concepts as scotty. One thing that interesting to think about as Server is a first-class value and all servers have the same type and we have just a small number of functions to compose them (they are link server to path and make alternative routes with Monoid) it’s interesting to explore the possibility of creation small grain-like servers for typical tasks. For example, a server can be a function from interfaces (logging, DB or something else) to server value and we can join them together on various paths. This idea is interesting to consider. Thanks to Ambros for contribution. Also I’d like to thank the authors of packages servant, servant-swagger-ui and servant-openapi3 packages for inspiration for my work in this release. Many lines of code are influenced by those packages. Links: - github - tutorial - mig on hackage also see packages mig-server and mig-client . - examples Cheers, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Fri Nov 10 14:54:58 2023 From: capn.freako at gmail.com (David Banas) Date: Fri, 10 Nov 2023 09:54:58 -0500 Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell Message-ID: I just picked up a copy of “Parallel and Concurrent Programming in Haskell”. And I’m trying to follow the instructions on p.4 for getting the examples installed, but having trouble: [23-11-10 9:49] dbanas at Davids-Air-M2:~/prj % cabal unpack parconc-examples Downloading parconc-examples-0.4.8 Downloaded parconc-examples-0.4.8 Unpacking to parconc-examples-0.4.8/ [23-11-10 9:50] dbanas at Davids-Air-M2:~/prj % pushd parconc-examples-0.4.8 ~/prj/parconc-examples-0.4.8 ~/prj ~ [23-11-10 9:50] dbanas at Davids-Air-M2:~/prj/parconc-examples-0.4.8 % cabal install --only-dependencies cabal: Could not resolve dependencies: [__0] trying: parconc-examples-0.4.8 (user goal) [__1] next goal: base (dependency of parconc-examples) [__1] rejecting: base-4.17.2.0/installed-4.17.2.0 (conflict: parconc-examples => base>=4.5 && <4.14) [__1] skipping: base-4.19.0.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.5 && <4.14' from 'parconc-examples') [__1] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, parconc-examples) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, parconc-examples Thanks, -db From allbery.b at gmail.com Fri Nov 10 15:22:24 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 10 Nov 2023 10:22:24 -0500 Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell In-Reply-To: References: Message-ID: It has restrictive bounds on `base` (which secretly means ghc). You can try `--allow-newer` to see if it works with newer versions. On Fri, Nov 10, 2023 at 9:55 AM David Banas wrote: > I just picked up a copy of “Parallel and Concurrent Programming in > Haskell”. > And I’m trying to follow the instructions on p.4 for getting the examples > installed, but having trouble: > > [23-11-10 9:49] dbanas at Davids-Air-M2:~/prj > % cabal unpack parconc-examples > Downloading parconc-examples-0.4.8 > Downloaded parconc-examples-0.4.8 > Unpacking to parconc-examples-0.4.8/ > > [23-11-10 9:50] dbanas at Davids-Air-M2:~/prj > % pushd parconc-examples-0.4.8 > ~/prj/parconc-examples-0.4.8 ~/prj ~ > > [23-11-10 9:50] dbanas at Davids-Air-M2:~/prj/parconc-examples-0.4.8 > % cabal install --only-dependencies > cabal: Could not resolve dependencies: > [__0] trying: parconc-examples-0.4.8 (user goal) > [__1] next goal: base (dependency of parconc-examples) > [__1] rejecting: base-4.17.2.0/installed-4.17.2.0 (conflict: > parconc-examples > => base>=4.5 && <4.14) > [__1] skipping: base-4.19.0.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.0, > base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, > base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, > base-4.14.2.0, base-4.14.1.0, base-4.14.0.0 (has the same characteristics > that > caused the previous version to fail: excluded by constraint '>=4.5 && > <4.14' > from 'parconc-examples') > [__1] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, > base-4.11.0.0, > base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, > base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, > base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, > base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, > base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 > (constraint from non-upgradeable package requires installed instance) > [__1] fail (backjumping, conflict set: base, parconc-examples) > After searching the rest of the dependency tree exhaustively, these were > the > goals I've had most trouble fulfilling: base, parconc-examples > > Thanks, > -db > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Fri Nov 10 15:53:11 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 10 Nov 2023 21:23:11 +0530 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.8 is now available Message-ID: <6hiqewjmevgygianxd3bc3x6cz2dkwx5xrnntmwpxhwwzj6akd@cgncs2to3xkq> The GHC developers are happy to announce the availability of GHC 9.4.8. Binary distributions, source distributions, and documentation are available on the [release page](/download_ghc_9_4_8.html). This release is primarily a bugfix release addressing a few issues found in the 9.4 series. These include: * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746). * Support for `-split-sections` on Windows. * Enabling `-split-sections` for various Linux and Windows binary distributions, enabling GHC to produce smaller binaries on these platforms. * And a few other fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.8/docs/users_guide/9.4.8-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Fri Nov 10 15:57:28 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 10 Nov 2023 15:57:28 +0000 Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell In-Reply-To: References: Message-ID: On Fri, Nov 10, 2023 at 10:22:24AM -0500, Brandon Allbery wrote: > It has restrictive bounds on `base` (which secretly means ghc). You can try > `--allow-newer` to see if it works with newer versions. > > On Fri, Nov 10, 2023 at 9:55 AM David Banas wrote: > > I just picked up a copy of “Parallel and Concurrent Programming in > > Haskell”. > > And I’m trying to follow the instructions on p.4 for getting the examples > > installed, but having trouble: [...] Oh woe, this package is sorely out of date. Sadly --allow-newer is too loose. There are compile failures. Applying the patch below will get a lot of it working with GHCs up to 9.2, although things that rely on Network won't work (there is no longer a top-level Network module). repa doesn't seem to work with any later GHC, but the bits that don't depend on repa can probably be brought up to date with later GHCs. Anyway, it's rather a mess. Sorry about that. Hope you can get at least some use out of the below patch. Tom --- parconc-examples-0.4.8/parconc-examples.cabal 2023-11-10 15:49:49.065195771 +0000 +++ /home/tom/parconc-examples-0.4.8/parconc-examples.cabal 2023-11-10 15:47:09.037704366 +0000 @@ -84,10 +84,10 @@ build-depends: array >= 0.4 && <0.6, async >= 2.0 && < 2.3, - base >= 4.5 && < 4.14, + base >= 4.5 && < 4.20, binary >=0.6.3 && < 0.11, bytestring >= 0.9 && < 0.12, - containers >= 0.4 && < 0.6, + containers >= 0.4 && < 0.7, deepseq >= 1.3 && < 1.5, directory >= 1.1 && < 1.4, filepath >= 1.3 && < 1.5, @@ -98,15 +98,15 @@ random >= 1.0 && < 1.3, stm >=2.4 && < 2.6, time >= 1.4 && < 1.12, - template-haskell >= 2.7 && < 2.16, - transformers >=0.3 && <0.6, + template-haskell >= 2.7 && < 2.22, + transformers >=0.3 && <0.7, utf8-string >= 0.3 && < 1.1, - vector >= 0.10 && < 0.13, + vector >= 0.10 && < 0.14, xml ==1.3.*, common network if flag(network26) - build-depends: network >= 2.6 && < 2.9 + build-depends: network >= 2.6 && < 3.2 , network-uri >= 2.6 && < 2.7 else build-depends: network >= 2.3 && < 2.6 From capn.freako at gmail.com Sat Nov 11 21:24:22 2023 From: capn.freako at gmail.com (David Banas) Date: Sat, 11 Nov 2023 16:24:22 -0500 Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell In-Reply-To: References: Message-ID: <3D81C389-EF3E-42D8-A5BE-565EAFE58F7D@gmail.com> Thanks for the patch, Tom! :) So, is the `accelerate` package still the preferred approach to access a GPU from within a Haskell program, or has it been superseded by something else? Thanks, -db > On Nov 10, 2023, at 10:57 AM, Tom Ellis wrote: > > On Fri, Nov 10, 2023 at 10:22:24AM -0500, Brandon Allbery wrote: >> It has restrictive bounds on `base` (which secretly means ghc). You can try >> `--allow-newer` to see if it works with newer versions. >> >> On Fri, Nov 10, 2023 at 9:55 AM David Banas wrote: >>> I just picked up a copy of “Parallel and Concurrent Programming in >>> Haskell”. >>> And I’m trying to follow the instructions on p.4 for getting the examples >>> installed, but having trouble: > [...] > > Oh woe, this package is sorely out of date. Sadly --allow-newer is > too loose. There are compile failures. Applying the patch below will > get a lot of it working with GHCs up to 9.2, although things that rely > on Network won't work (there is no longer a top-level Network module). > > repa doesn't seem to work with any later GHC, but the bits that don't > depend on repa can probably be brought up to date with later GHCs. > > Anyway, it's rather a mess. Sorry about that. Hope you can get at > least some use out of the below patch. > > Tom > > > > > > --- parconc-examples-0.4.8/parconc-examples.cabal 2023-11-10 > 15:49:49.065195771 +0000 > +++ /home/tom/parconc-examples-0.4.8/parconc-examples.cabal > 2023-11-10 15:47:09.037704366 +0000 > @@ -84,10 +84,10 @@ > build-depends: > array >= 0.4 && <0.6, > async >= 2.0 && < 2.3, > - base >= 4.5 && < 4.14, > + base >= 4.5 && < 4.20, > binary >=0.6.3 && < 0.11, > bytestring >= 0.9 && < 0.12, > - containers >= 0.4 && < 0.6, > + containers >= 0.4 && < 0.7, > deepseq >= 1.3 && < 1.5, > directory >= 1.1 && < 1.4, > filepath >= 1.3 && < 1.5, > @@ -98,15 +98,15 @@ > random >= 1.0 && < 1.3, > stm >=2.4 && < 2.6, > time >= 1.4 && < 1.12, > - template-haskell >= 2.7 && < 2.16, > - transformers >=0.3 && <0.6, > + template-haskell >= 2.7 && < 2.22, > + transformers >=0.3 && <0.7, > utf8-string >= 0.3 && < 1.1, > - vector >= 0.10 && < 0.13, > + vector >= 0.10 && < 0.14, > xml ==1.3.*, > > common network > if flag(network26) > - build-depends: network >= 2.6 && < 2.9 > + build-depends: network >= 2.6 && < 3.2 > , network-uri >= 2.6 && < 2.7 > else > build-depends: network >= 2.3 && < 2.6 > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sun Nov 12 09:46:34 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 12 Nov 2023 09:46:34 +0000 Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell In-Reply-To: <3D81C389-EF3E-42D8-A5BE-565EAFE58F7D@gmail.com> References: <3D81C389-EF3E-42D8-A5BE-565EAFE58F7D@gmail.com> Message-ID: On Sat, Nov 11, 2023 at 04:24:22PM -0500, David Banas wrote: > So, is the `accelerate` package still the preferred approach to > access a GPU from within a Haskell program, or has it been > superseded by something else? I have no idea, sorry. It may even be possible to bring repa up to date with a small amount of tweaking, but I'm not familiar with it so couldn't say for sure. Tom From lemming at henning-thielemann.de Sun Nov 12 10:07:26 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 12 Nov 2023 11:07:26 +0100 (CET) Subject: [Haskell-cafe] Trouble installing example code for Parallel and Concurrent Programming in Haskell In-Reply-To: <3D81C389-EF3E-42D8-A5BE-565EAFE58F7D@gmail.com> References: <3D81C389-EF3E-42D8-A5BE-565EAFE58F7D@gmail.com> Message-ID: On Sat, 11 Nov 2023, David Banas wrote: > So, is the `accelerate` package still the preferred approach to access a > GPU from within a Haskell program, or has it been superseded by > something else? There is an active Google Group for accelerate: https://groups.google.com/g/accelerate-haskell Btw. I have implemented alternatives to 'repa' and 'accelerate': https://hackage.haskell.org/package/comfort-array https://hackage.haskell.org/package/knead The 'knead' package requires more manual planning of what to do on materialized arrays and what to do on-the-fly, compared to 'accelerate'. It does no GPU and no automatic parallelization. It simply translates to LLVM and relies on its vectorization. For readily vectorized arithmetic on the CPU you can use comfort-blas, which is a high-level binding to BLAS. My experience with GPU programming is that the speedup is by far less than claimed in advertisings and conference talks. Fantastic speedups of factors 100 or 1000 are usually due to a comparison of a GPU implementation optimized over months to a specific GPU and a CPU version quickly implemented in one day, often ignoring vectorization and cache optimization. GPU programs are hardly portable between vendors or even different GPU generations of the same vendor. From Graham.Hutton at nottingham.ac.uk Mon Nov 13 08:15:10 2023 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 13 Nov 2023 08:15:10 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: Dear all, If you or one of your students recently completed a PhD (or Habilitation) in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, 200+ published to date, deadline 30th November 2023. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2023 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the student and the advisor/supervisor although we encourage them to coordinate. Habilitation dissertations are also eligible for inclusion. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 30th November 2023. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From capn.freako at gmail.com Tue Nov 14 10:50:14 2023 From: capn.freako at gmail.com (David Banas) Date: Tue, 14 Nov 2023 05:50:14 -0500 Subject: [Haskell-cafe] How to use the GPU in Apple M2 from Haskell? In-Reply-To: References: Message-ID: <5ED2F787-CF4B-47A5-BCB7-AF7BD45C102D@gmail.com> Thanks, Carter! :) Wrt/ this: "Or use opencl / OpenGL APIs that still work despite being deprecated." Do you happen to know whether they work when using one of the newer GHC versions to compile natively to the `aarch64` architecture? Thanks, -db > On Oct 28, 2023, at 6:19 PM, Carter Schonwald wrote: > > Or use opencl / OpenGL APIs that still work despite being deprecated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.caldeira at ua.pt Tue Nov 14 21:27:57 2023 From: h.caldeira at ua.pt (Henrique Caldeira) Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) Subject: [Haskell-cafe] Haskell Usage Message-ID: Good Evening from Portugal, I write to you about the usage of Haskell because I had a professor recommending me Erlang instead because Haskell was "more for academic purposes", which left me wondering if all my time spent was spent only for curiosity sake. I want to know how true my professor's statement is. I am very passionate about Haskell, although I admit the ecosystem can be confusing sometimes (for example, when to use cabal or stack, which versions of packages to use in order to avoid conflicts, or simply installing them through nixos or arch can be a learning process). Would love to hear your thoughts about all of this and thank you with all my heart. Lastly, all these wonderings are asked in a curious, "wanting to learn more" mindset. Kind regards, Henrique Caldeira -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Nov 14 21:36:18 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 Nov 2023 16:36:18 -0500 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc ( https://pandoc.com), HLedger (https://hledger.org), and XMonad ( https://xmonad.org), among others, argue against Haskell being only an academic language. (I'm the principal maintainer of xmonad, but not involved with the other packages.) On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira wrote: > Good Evening from Portugal, > > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only for > curiosity sake. > > I want to know how true my professor's statement is. > > I am very passionate about Haskell, although I admit the ecosystem can be > confusing sometimes (for example, when to use cabal or stack, which > versions of packages to use in order to avoid conflicts, or simply > installing them through nixos or arch can be a learning process). > > Would love to hear your thoughts about all of this and thank you with all > my heart. > > Lastly, all these wonderings are asked in a curious, "wanting to learn > more" mindset. > > Kind regards, > Henrique Caldeira > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Nov 14 21:51:31 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 14 Nov 2023 22:51:31 +0100 (CET) Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: <61ae1ea8-3130-c374-bede-f6a883e329f2@henning-thielemann.de> On Tue, 14 Nov 2023, Brandon Allbery wrote: > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc > (https://pandoc.com), HLedger (https://hledger.org), and XMonad > (https://xmonad.org), among others, argue against Haskell being only an > academic language. Gitit, Darcs, Git-Annex, Chordify to name a few more ... Recently identified a bug, again, in a C++ library using QuickCheck. We are also doing art with Haskell: https://www.youtube.com/watch?v=5odGfOMAuf0 https://www.youtube.com/watch?v=0EQCgi5qa3E https://www.youtube.com/watch?v=l3JWiWVeEqk https://www.youtube.com/watch?v=LaGCE-STYkI (this is Haskell running on a Raspberry Pi) From jo at durchholz.org Tue Nov 14 22:15:56 2023 From: jo at durchholz.org (Jo Durchholz) Date: Tue, 14 Nov 2023 23:15:56 +0100 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: <5c9371c5-09e6-43a5-a107-602c2b22d88d@durchholz.org> On 14.11.23 22:27, Henrique Caldeira wrote: > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only > for curiosity sake. > > I want to know how true my professor's statement is. It depends on what you look at. Going by the number of positions in industry, both languages are niche. Haskell is somewhat more niche than Erlang, but this could change anytime; essentially both language would gain instant traction on the job market as soon as some large corporation starts supporting and advocating it. Going by history, Haskell started in research while Erlang started at Ericsson for programming telephony switches (which are scarily complicated beasts); however, both languages grew significantly beyond their respective origin. Going by ecosystem, both have toolchains, useful standard libraries, and nontrivial applications in production use. So... it's sort of true, but recommending Erlang over Haskell is a bit odd. HTH Jo From migmit at gmail.com Tue Nov 14 22:24:00 2023 From: migmit at gmail.com (MigMit) Date: Tue, 14 Nov 2023 23:24:00 +0100 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: <04884962-C299-4B7B-A1A5-F02B68B1D04E@gmail.com> Depends on what you really want. Erlang, in my experience, is not a functional language at all. There is a thin veneer of functionality, true, but mostly it's an object-oriented language, Smalltalk-style. They say "process" instead of "object", but it's basically the same thing. If you want a language that is significantly more functional (although still not really), and also quite practical and popular in the industry, you can try Scala. Especially Scala 3, which seems to have fixed quite a lot of grievances, in particular those related to Odersky not really understanding math. Additionally, in Scala world you have Akka, which is modelled after Erlang's multithreading model, so you don't really lose anything important. > On 14 Nov 2023, at 22:27, Henrique Caldeira wrote: > > Good Evening from Portugal, > > I write to you about the usage of Haskell because I had a professor recommending me Erlang instead because Haskell was "more for academic purposes", which left me wondering if all my time spent was spent only for curiosity sake. > > I want to know how true my professor's statement is. > > I am very passionate about Haskell, although I admit the ecosystem can be confusing sometimes (for example, when to use cabal or stack, which versions of packages to use in order to avoid conflicts, or simply installing them through nixos or arch can be a learning process). > > Would love to hear your thoughts about all of this and thank you with all my heart. > > Lastly, all these wonderings are asked in a curious, "wanting to learn more" mindset. > > Kind regards, > Henrique Caldeira > _______________________________________________ > 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. From ivanperezdominguez at gmail.com Tue Nov 14 22:39:19 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 14 Nov 2023 14:39:19 -0800 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: <04884962-C299-4B7B-A1A5-F02B68B1D04E@gmail.com> References: <04884962-C299-4B7B-A1A5-F02B68B1D04E@gmail.com> Message-ID: Hi Usage within NASA is very rare but we do use Haskell: https://github.com/Copilot-Language/copilot/ https://github.com/nasa/ogma Ivan On Tue, 14 Nov 2023 at 14:24, MigMit wrote: > Depends on what you really want. > > Erlang, in my experience, is not a functional language at all. There is a > thin veneer of functionality, true, but mostly it's an object-oriented > language, Smalltalk-style. They say "process" instead of "object", but it's > basically the same thing. > > If you want a language that is significantly more functional (although > still not really), and also quite practical and popular in the industry, > you can try Scala. Especially Scala 3, which seems to have fixed quite a > lot of grievances, in particular those related to Odersky not really > understanding math. Additionally, in Scala world you have Akka, which is > modelled after Erlang's multithreading model, so you don't really lose > anything important. > > > On 14 Nov 2023, at 22:27, Henrique Caldeira wrote: > > > > Good Evening from Portugal, > > > > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only for > curiosity sake. > > > > I want to know how true my professor's statement is. > > > > I am very passionate about Haskell, although I admit the ecosystem can > be confusing sometimes (for example, when to use cabal or stack, which > versions of packages to use in order to avoid conflicts, or simply > installing them through nixos or arch can be a learning process). > > > > Would love to hear your thoughts about all of this and thank you with > all my heart. > > > > Lastly, all these wonderings are asked in a curious, "wanting to learn > more" mindset. > > > > Kind regards, > > Henrique Caldeira > > _______________________________________________ > > 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. > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at jtobin.io Wed Nov 15 04:08:55 2023 From: jared at jtobin.io (Jared Tobin) Date: Wed, 15 Nov 2023 08:08:55 +0400 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: <20231115040855.GC77719@betelgeuse> On Tue, Nov 14, 2023 at 09:27:57PM +0000, Henrique Caldeira wrote: > Good Evening from Portugal, > > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only > for curiosity sake. > > I want to know how true my professor's statement is. Your professor's opinion feels very far out of date to me. Perhaps it was true many years ago, but I've used Haskell professionally at four companies over the past decade without ever really having "looked for a Haskell job," and Haskell would be my top choice for any number of commercial projects. -- jared -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From nikhil at acm.org Wed Nov 15 14:53:50 2023 From: nikhil at acm.org (Rishiyur Nikhil) Date: Wed, 15 Nov 2023 09:53:50 -0500 Subject: [Haskell-cafe] Re. Haskell Usage Message-ID: > Haskell was "more for academic purposes", The Bluespec Hardware Design Languages BSV (Bluespec SystemVerilog) and BH (Bluespec Haskell) digital hardware circuit design have been in industrial production and commercial use for over 20 years now. They have been used inside ST Micro, Texas Instruments, IBM, Qualcomm, Google, Galois and other companies, for ASIC and FPGA products and for high-level hardware prototyping and architecture exploration. The BSV and BH languages are themselves heavily inspired by Haskell. The 'bsc' compiler for BSV and BH is written entirely in Haskell, and has been in continuous use/development/maintenance/improvement for 20 years, and constitutes about 125K lines of Haskell. The 'bsc' compiler was open-sourced a few years ago and continues to be actively used and maintained: https://github.com/B-Lang-org/bsc The Haskell code for the compiler is in the src/ directory. Nikhil -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at openwork.nz Wed Nov 15 20:24:13 2023 From: adrian at openwork.nz (Adrian Cochrane) Date: Thu, 16 Nov 2023 09:24:13 +1300 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: Message-ID: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Hi from New Zealand! My Haskell usage is more hobbyist than academic or industrial, but I've got a massive personal project written in Haskell (a browser engine). And I'm actively for one of my upcoming contracts (a converter between metadata formats) to use Haskell! I find I'm more productive in Haskell, and that my code is of generally higher quality. Its certainly not a popular language (neither is Erlang) though, which I have to actively plan for when suggesting it for a project. But given the dominance of C/C++, does that count for much? On 16/11/2023 1:00 am, haskell-cafe-request at haskell.org wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request at haskell.org > > You can reach the person managing the list at > haskell-cafe-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Haskell Usage (Henrique Caldeira) > 2. Re: Haskell Usage (Brandon Allbery) > 3. Re: Haskell Usage (Henning Thielemann) > 4. Re: Haskell Usage (Jo Durchholz) > 5. Re: Haskell Usage (MigMit) > 6. Re: Haskell Usage (Ivan Perez) > 7. Re: Haskell Usage (Jared Tobin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) > From: Henrique Caldeira > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] Haskell Usage > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Good Evening from Portugal, > > I write to you about the usage of Haskell because I had a professor recommending me Erlang instead because Haskell was "more for academic purposes", which left me wondering if all my time spent was spent only for curiosity sake. > > I want to know how true my professor's statement is. > > I am very passionate about Haskell, although I admit the ecosystem can be confusing sometimes (for example, when to use cabal or stack, which versions of packages to use in order to avoid conflicts, or simply installing them through nixos or arch can be a learning process). > > Would love to hear your thoughts about all of this and thank you with all my heart. > > Lastly, all these wonderings are asked in a curious, "wanting to learn more" mindset. > > Kind regards, > Henrique Caldeira > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Tue, 14 Nov 2023 16:36:18 -0500 > From: Brandon Allbery > To: Henrique Caldeira > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Haskell Usage > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc ( > https://pandoc.com), HLedger (https://hledger.org), and XMonad ( > https://xmonad.org), among others, argue against Haskell being only an > academic language. > > (I'm the principal maintainer of xmonad, but not involved with the other > packages.) > > On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira wrote: > >> Good Evening from Portugal, >> >> I write to you about the usage of Haskell because I had a professor >> recommending me Erlang instead because Haskell was "more for academic >> purposes", which left me wondering if all my time spent was spent only for >> curiosity sake. >> >> I want to know how true my professor's statement is. >> >> I am very passionate about Haskell, although I admit the ecosystem can be >> confusing sometimes (for example, when to use cabal or stack, which >> versions of packages to use in order to avoid conflicts, or simply >> installing them through nixos or arch can be a learning process). >> >> Would love to hear your thoughts about all of this and thank you with all >> my heart. >> >> Lastly, all these wonderings are asked in a curious, "wanting to learn >> more" mindset. >> >> Kind regards, >> Henrique Caldeira >> _______________________________________________ >> 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. > > > From noonsilk at gmail.com Wed Nov 15 20:43:05 2023 From: noonsilk at gmail.com (Noon van der Silk) Date: Wed, 15 Nov 2023 20:43:05 +0000 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> References: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Message-ID: I'll just add that there are many companies that use Haskell in a professional setting (including the one I work for!) You can see a few at the bottom of the Haskell Foundation's website: https://haskell.foundation/. It's certainly an odd remark by your professor; but it also likely comes from their own experience; everyone has lived life in their own different way; maybe this person has just been exposed to more commercial Erlang than me; almost certainly :) So I would take the comment more with curiosity; to learn *why* they feel Erlang is more suitable; it's probably a good opportunity to learn something interesting! That said, I do think Haskell has an "academic" vibe that it will do well to shake off at some point! -- Noon On Wed, 15 Nov 2023 at 20:25, Adrian Cochrane wrote: > Hi from New Zealand! > > My Haskell usage is more hobbyist than academic or industrial, but I've > got a massive personal project written in Haskell (a browser engine). > And I'm actively for one of my upcoming contracts (a converter between > metadata formats) to use Haskell! > > I find I'm more productive in Haskell, and that my code is of generally > higher quality. Its certainly not a popular language (neither is Erlang) > though, which I have to actively plan for when suggesting it for a > project. But given the dominance of C/C++, does that count for much? > > On 16/11/2023 1:00 am, haskell-cafe-request at haskell.org wrote: > > Send Haskell-Cafe mailing list submissions to > > haskell-cafe at haskell.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > or, via email, send a message with subject or body 'help' to > > haskell-cafe-request at haskell.org > > > > You can reach the person managing the list at > > haskell-cafe-owner at haskell.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Haskell-Cafe digest..." > > > > > > Today's Topics: > > > > 1. Haskell Usage (Henrique Caldeira) > > 2. Re: Haskell Usage (Brandon Allbery) > > 3. Re: Haskell Usage (Henning Thielemann) > > 4. Re: Haskell Usage (Jo Durchholz) > > 5. Re: Haskell Usage (MigMit) > > 6. Re: Haskell Usage (Ivan Perez) > > 7. Re: Haskell Usage (Jared Tobin) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) > > From: Henrique Caldeira > > To: haskell-cafe at haskell.org > > Subject: [Haskell-cafe] Haskell Usage > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > Good Evening from Portugal, > > > > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only for > curiosity sake. > > > > I want to know how true my professor's statement is. > > > > I am very passionate about Haskell, although I admit the ecosystem can > be confusing sometimes (for example, when to use cabal or stack, which > versions of packages to use in order to avoid conflicts, or simply > installing them through nixos or arch can be a learning process). > > > > Would love to hear your thoughts about all of this and thank you with > all my heart. > > > > Lastly, all these wonderings are asked in a curious, "wanting to learn > more" mindset. > > > > Kind regards, > > Henrique Caldeira > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > http://mail.haskell.org/pipermail/haskell-cafe/attachments/20231114/2bf9158b/attachment-0001.html > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 14 Nov 2023 16:36:18 -0500 > > From: Brandon Allbery > > To: Henrique Caldeira > > Cc: haskell-cafe at haskell.org > > Subject: Re: [Haskell-cafe] Haskell Usage > > Message-ID: > > LX5KGXA_8gmBGnscEoQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc > ( > > https://pandoc.com), HLedger (https://hledger.org), and XMonad ( > > https://xmonad.org), among others, argue against Haskell being only an > > academic language. > > > > (I'm the principal maintainer of xmonad, but not involved with the other > > packages.) > > > > On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira > wrote: > > > >> Good Evening from Portugal, > >> > >> I write to you about the usage of Haskell because I had a professor > >> recommending me Erlang instead because Haskell was "more for academic > >> purposes", which left me wondering if all my time spent was spent only > for > >> curiosity sake. > >> > >> I want to know how true my professor's statement is. > >> > >> I am very passionate about Haskell, although I admit the ecosystem can > be > >> confusing sometimes (for example, when to use cabal or stack, which > >> versions of packages to use in order to avoid conflicts, or simply > >> installing them through nixos or arch can be a learning process). > >> > >> Would love to hear your thoughts about all of this and thank you with > all > >> my heart. > >> > >> Lastly, all these wonderings are asked in a curious, "wanting to learn > >> more" mindset. > >> > >> Kind regards, > >> Henrique Caldeira > >> _______________________________________________ > >> 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. > > > > > > > _______________________________________________ > 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. -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness." -------------- next part -------------- An HTML attachment was scrubbed... URL: From guthrie at miu.edu Wed Nov 15 20:58:19 2023 From: guthrie at miu.edu (Gregory Guthrie) Date: Wed, 15 Nov 2023 20:58:19 +0000 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Message-ID: I am also a fan of Haskell, but finding a few usages really does not address the main comment and general reality. Perhaps looking at TIOBE or other data driven sources might give a more realistic view. Yes, each ranking (TIOBE IEEE, …) has its merits and issues, but overall, they do give some reality-based insights! https://www.tiobe.com/tiobe-index/ { Python, C, C++, Java, … Fortran (#12),, COBOL(#22), … Haskell (#39) …} https://spectrum.ieee.org/top-programming-languages-2022 { Python, C, C++, C#, Java, … Assembly (#18), … Haskell (#27), …} Not meant to prolong a flame-war discussion, just FYI to answer the original query. 😊 Dr. Gregory Guthrie From: Haskell-Cafe On Behalf Of Noon van der Silk Sent: Wednesday, November 15, 2023 2:43 PM To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Haskell Usage I'll just add that there are many companies that use Haskell in a professional setting (including the one I work for!) You can see a few at the bottom of the Haskell Foundation's website: https://haskell.foundation/. It's certainly an odd remark by your professor; but it also likely comes from their own experience; everyone has lived life in their own different way; maybe this person has just been exposed to more commercial Erlang than me; almost certainly :) So I would take the comment more with curiosity; to learn why they feel Erlang is more suitable; it's probably a good opportunity to learn something interesting! That said, I do think Haskell has an "academic" vibe that it will do well to shake off at some point! -- Noon On Wed, 15 Nov 2023 at 20:25, Adrian Cochrane > wrote: Hi from New Zealand! My Haskell usage is more hobbyist than academic or industrial, but I've got a massive personal project written in Haskell (a browser engine). And I'm actively for one of my upcoming contracts (a converter between metadata formats) to use Haskell! I find I'm more productive in Haskell, and that my code is of generally higher quality. Its certainly not a popular language (neither is Erlang) though, which I have to actively plan for when suggesting it for a project. But given the dominance of C/C++, does that count for much? On 16/11/2023 1:00 am, haskell-cafe-request at haskell.org wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request at haskell.org > > You can reach the person managing the list at > haskell-cafe-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Haskell Usage (Henrique Caldeira) > 2. Re: Haskell Usage (Brandon Allbery) > 3. Re: Haskell Usage (Henning Thielemann) > 4. Re: Haskell Usage (Jo Durchholz) > 5. Re: Haskell Usage (MigMit) > 6. Re: Haskell Usage (Ivan Perez) > 7. Re: Haskell Usage (Jared Tobin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) > From: Henrique Caldeira > > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] Haskell Usage > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Good Evening from Portugal, > > I write to you about the usage of Haskell because I had a professor recommending me Erlang instead because Haskell was "more for academic purposes", which left me wondering if all my time spent was spent only for curiosity sake. > > I want to know how true my professor's statement is. > > I am very passionate about Haskell, although I admit the ecosystem can be confusing sometimes (for example, when to use cabal or stack, which versions of packages to use in order to avoid conflicts, or simply installing them through nixos or arch can be a learning process). > > Would love to hear your thoughts about all of this and thank you with all my heart. > > Lastly, all these wonderings are asked in a curious, "wanting to learn more" mindset. > > Kind regards, > Henrique Caldeira > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Tue, 14 Nov 2023 16:36:18 -0500 > From: Brandon Allbery > > To: Henrique Caldeira > > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Haskell Usage > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc ( > https://pandoc.com), HLedger (https://hledger.org), and XMonad ( > https://xmonad.org), among others, argue against Haskell being only an > academic language. > > (I'm the principal maintainer of xmonad, but not involved with the other > packages.) > > On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira > wrote: > >> Good Evening from Portugal, >> >> I write to you about the usage of Haskell because I had a professor >> recommending me Erlang instead because Haskell was "more for academic >> purposes", which left me wondering if all my time spent was spent only for >> curiosity sake. >> >> I want to know how true my professor's statement is. >> >> I am very passionate about Haskell, although I admit the ecosystem can be >> confusing sometimes (for example, when to use cabal or stack, which >> versions of packages to use in order to avoid conflicts, or simply >> installing them through nixos or arch can be a learning process). >> >> Would love to hear your thoughts about all of this and thank you with all >> my heart. >> >> Lastly, all these wonderings are asked in a curious, "wanting to learn >> more" mindset. >> >> Kind regards, >> Henrique Caldeira >> _______________________________________________ >> 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. > > > _______________________________________________ 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. -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness." -------------- next part -------------- An HTML attachment was scrubbed... URL: From ida.bzowska at gmail.com Wed Nov 15 21:06:16 2023 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Wed, 15 Nov 2023 22:06:16 +0100 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Message-ID: I will continue the thread on Haskell companies and share two more resources that list names of companies using the language in production. (although these resources may not be up-to-date, they provide valuable insights into the market): https://github.com/erkmos/haskell-companies https://haskellcosm.com Here are some additional statistics: https://github.com/nh2/haskell-jobs-statistics#haskell-jobs-statistics It is important to note that while Haskell is an excellent language, the Blub paradox may prevent it from becoming mainstream. λCheers, Ida śr., 15 lis 2023 o 21:59 Gregory Guthrie napisał(a): > I am also a fan of Haskell, but finding a few usages really does not > address the main comment and general reality. Perhaps looking at TIOBE or > other data driven sources might give a more realistic view. > > Yes, each ranking (TIOBE IEEE, …) has its merits and issues, but overall, > they do give some reality-based insights! > > > > https://www.tiobe.com/tiobe-index/ > > { Python, C, C++, Java, … Fortran (#12),, COBOL(#22), … Haskell (#39) …} > > > > https://spectrum.ieee.org/top-programming-languages-2022 > > { Python, C, C++, C#, Java, … Assembly (#18), … Haskell (#27), …} > > > > Not meant to prolong a flame-war discussion, just FYI to answer the > original query. > > 😊 > > > > Dr. Gregory Guthrie > > > > *From:* Haskell-Cafe *On Behalf Of *Noon > van der Silk > *Sent:* Wednesday, November 15, 2023 2:43 PM > *To:* haskell-cafe at haskell.org > *Subject:* Re: [Haskell-cafe] Haskell Usage > > > > I'll just add that there are many companies that use Haskell in a > professional setting (including the one I work for!) You can see a few at > the bottom of the Haskell Foundation's website: > https://haskell.foundation/. > > > > It's certainly an odd remark by your professor; but it also likely comes > from their own experience; everyone has lived life in their own different > way; maybe this person has just been exposed to more commercial Erlang than > me; almost certainly :) So I would take the comment more with curiosity; to > learn *why* they feel Erlang is more suitable; it's probably a good > opportunity to learn something interesting! > > > > That said, I do think Haskell has an "academic" vibe that it will do well > to shake off at some point! > > > > -- > > Noon > > > > > > On Wed, 15 Nov 2023 at 20:25, Adrian Cochrane wrote: > > Hi from New Zealand! > > My Haskell usage is more hobbyist than academic or industrial, but I've > got a massive personal project written in Haskell (a browser engine). > And I'm actively for one of my upcoming contracts (a converter between > metadata formats) to use Haskell! > > I find I'm more productive in Haskell, and that my code is of generally > higher quality. Its certainly not a popular language (neither is Erlang) > though, which I have to actively plan for when suggesting it for a > project. But given the dominance of C/C++, does that count for much? > > On 16/11/2023 1:00 am, haskell-cafe-request at haskell.org wrote: > > Send Haskell-Cafe mailing list submissions to > > haskell-cafe at haskell.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > or, via email, send a message with subject or body 'help' to > > haskell-cafe-request at haskell.org > > > > You can reach the person managing the list at > > haskell-cafe-owner at haskell.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Haskell-Cafe digest..." > > > > > > Today's Topics: > > > > 1. Haskell Usage (Henrique Caldeira) > > 2. Re: Haskell Usage (Brandon Allbery) > > 3. Re: Haskell Usage (Henning Thielemann) > > 4. Re: Haskell Usage (Jo Durchholz) > > 5. Re: Haskell Usage (MigMit) > > 6. Re: Haskell Usage (Ivan Perez) > > 7. Re: Haskell Usage (Jared Tobin) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) > > From: Henrique Caldeira > > To: haskell-cafe at haskell.org > > Subject: [Haskell-cafe] Haskell Usage > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > Good Evening from Portugal, > > > > I write to you about the usage of Haskell because I had a professor > recommending me Erlang instead because Haskell was "more for academic > purposes", which left me wondering if all my time spent was spent only for > curiosity sake. > > > > I want to know how true my professor's statement is. > > > > I am very passionate about Haskell, although I admit the ecosystem can > be confusing sometimes (for example, when to use cabal or stack, which > versions of packages to use in order to avoid conflicts, or simply > installing them through nixos or arch can be a learning process). > > > > Would love to hear your thoughts about all of this and thank you with > all my heart. > > > > Lastly, all these wonderings are asked in a curious, "wanting to learn > more" mindset. > > > > Kind regards, > > Henrique Caldeira > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > http://mail.haskell.org/pipermail/haskell-cafe/attachments/20231114/2bf9158b/attachment-0001.html > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 14 Nov 2023 16:36:18 -0500 > > From: Brandon Allbery > > To: Henrique Caldeira > > Cc: haskell-cafe at haskell.org > > Subject: Re: [Haskell-cafe] Haskell Usage > > Message-ID: > > LX5KGXA_8gmBGnscEoQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc > ( > > https://pandoc.com), HLedger (https://hledger.org), and XMonad ( > > https://xmonad.org), among others, argue against Haskell being only an > > academic language. > > > > (I'm the principal maintainer of xmonad, but not involved with the other > > packages.) > > > > On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira > wrote: > > > >> Good Evening from Portugal, > >> > >> I write to you about the usage of Haskell because I had a professor > >> recommending me Erlang instead because Haskell was "more for academic > >> purposes", which left me wondering if all my time spent was spent only > for > >> curiosity sake. > >> > >> I want to know how true my professor's statement is. > >> > >> I am very passionate about Haskell, although I admit the ecosystem can > be > >> confusing sometimes (for example, when to use cabal or stack, which > >> versions of packages to use in order to avoid conflicts, or simply > >> installing them through nixos or arch can be a learning process). > >> > >> Would love to hear your thoughts about all of this and thank you with > all > >> my heart. > >> > >> Lastly, all these wonderings are asked in a curious, "wanting to learn > >> more" mindset. > >> > >> Kind regards, > >> Henrique Caldeira > >> _______________________________________________ > >> 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. > > > > > > > _______________________________________________ > 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. > > > > > -- > > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed Nov 15 21:55:38 2023 From: jo at durchholz.org (Jo Durchholz) Date: Wed, 15 Nov 2023 22:55:38 +0100 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> References: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Message-ID: <57288db5-63ab-49e6-a3d2-71a9031876c8@durchholz.org> On 15.11.23 21:24, Adrian Cochrane wrote: > But given the dominance of C/C++, does that count for much? Actually, a language tends to dominate some niches and be totally absent in others. I.e. if you do servers, you'd likely find it dominated by Java (or maybe C++, I'm biased), and some Python; if you do embedded scripting in applications, you'd likely find yourself doing Lua (but it's a really small niche), in scientific computing, Python is dominant, etc. So the real question would be: Is there a niche that you gravitate towards, and what language(s) are they using there? Note that it's hard to predict what niche will work best. E.g. I would have never expected to end in backend servers for the most boring topics imaginable (company stuff), and find that I'm more of a process organizer than programmer at heart and find it fun and rewarding making things interact smoothly, be it server-to-server, server-to-frontend, frontend-to-human, or even human-to-human. I would have laughted anybody out of the door if that had been predicted to me when I was studying, and even when I was 30 and didn't (yet) know what would catch on for me. I'm well aware that this is a kind of anti-answer to your question, but it seems life does not always give you answers before forcing a choice on you - on the positive side: Don't worry too much about the choices that you make, just make the best of whatever cards life deals to you. Regards, Jo From carter.schonwald at gmail.com Wed Nov 15 23:15:29 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 15 Nov 2023 18:15:29 -0500 Subject: [Haskell-cafe] How to use the GPU in Apple M2 from Haskell? In-Reply-To: <5ED2F787-CF4B-47A5-BCB7-AF7BD45C102D@gmail.com> References: <5ED2F787-CF4B-47A5-BCB7-AF7BD45C102D@gmail.com> Message-ID: yes, have you tried using them? they will work the same way On Tue, Nov 14, 2023 at 5:50 AM David Banas wrote: > Thanks, Carter! :) > > Wrt/ this: > > "Or use opencl / OpenGL APIs that still work despite being deprecated." > > Do you happen to know whether they work when using one of the newer GHC > versions to compile natively to the `aarch64` architecture? > > Thanks, > -db > > > On Oct 28, 2023, at 6:19 PM, Carter Schonwald > wrote: > > Or use opencl / OpenGL APIs that still work despite being deprecated. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Thu Nov 16 01:34:55 2023 From: raoknz at gmail.com (Richard O'Keefe) Date: Thu, 16 Nov 2023 14:34:55 +1300 Subject: [Haskell-cafe] Haskell Usage In-Reply-To: References: <2a999050-795c-45e5-9981-56a21d1384fd@openwork.nz> Message-ID: I've a foot in both the Erlang and the Haskell camps. Erlang was designed at a commercial organisation (Ericsson) for a commercial purpose (programming telecoms devices and applications). It was heavily influenced by Lisp, Prolog, and Strand88, none of which was a mainstream "industrial" language, and was in some ways a reaction against Ericsson's "EriPascal" (think CHILL -- if you know what that is -- with a Pascal base instead of PL/I) which was very much an "industrial" language, and even more a reaction against the OO (= C++) hype of the day. You can think of Erlang as "concurrency, with just enough language", an experiment in language design that worked brilliantly. Haskell was designed to unify a number of functional language research groups. "How about instead of all working on our own little languages, we agree on one language so we can all use each other's ideas right away". I think it's fair to say that initially, Haskell too was " with just enough language". It has worked brilliantly too. The two languages have some overlap. Haskell picked up concurrency; Erlang picked up types. Both of them have lexical analyser generators and parser generators. Both of then ended up with preprocessors (Haskell = cpp, Erlang = home-brew). Both of them these days compile to a core. I'm reminded of one of my university lecturers from back about 1978. He was visiting from the Sorbonne. It was a one-year paper on Spinor Calculus. This guy began with meta-mathematics. By half way through the year he'd got as far as defining A raised to the power B where A and B are sets. He finally arrived at spinors in the last two weeks. He was SO theory oriented the paper was no practical use to me. But THAT guy said "all good theory has to start with a practical problem". The practical problem we face is "how do we write programs that work, with a reasonable amount of effort." When I run a PDF viewer on Linux, i tend to get a lot of error messages spewed out on the console due to changes in some internal interface. When I run a typical Windows program, just as many error messages come out, they just go into system logs. Whatever we're doing to write programs now, they DON'T WORK. Haskell is a very practical tool, if "making it work" is what you want to practice. On Thu, 16 Nov 2023 at 09:43, Noon van der Silk wrote: > > I'll just add that there are many companies that use Haskell in a professional setting (including the one I work for!) You can see a few at the bottom of the Haskell Foundation's website: https://haskell.foundation/. > > It's certainly an odd remark by your professor; but it also likely comes from their own experience; everyone has lived life in their own different way; maybe this person has just been exposed to more commercial Erlang than me; almost certainly :) So I would take the comment more with curiosity; to learn why they feel Erlang is more suitable; it's probably a good opportunity to learn something interesting! > > That said, I do think Haskell has an "academic" vibe that it will do well to shake off at some point! > > -- > Noon > > > On Wed, 15 Nov 2023 at 20:25, Adrian Cochrane wrote: >> >> Hi from New Zealand! >> >> My Haskell usage is more hobbyist than academic or industrial, but I've >> got a massive personal project written in Haskell (a browser engine). >> And I'm actively for one of my upcoming contracts (a converter between >> metadata formats) to use Haskell! >> >> I find I'm more productive in Haskell, and that my code is of generally >> higher quality. Its certainly not a popular language (neither is Erlang) >> though, which I have to actively plan for when suggesting it for a >> project. But given the dominance of C/C++, does that count for much? >> >> On 16/11/2023 1:00 am, haskell-cafe-request at haskell.org wrote: >> > Send Haskell-Cafe mailing list submissions to >> > haskell-cafe at haskell.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > or, via email, send a message with subject or body 'help' to >> > haskell-cafe-request at haskell.org >> > >> > You can reach the person managing the list at >> > haskell-cafe-owner at haskell.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of Haskell-Cafe digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Haskell Usage (Henrique Caldeira) >> > 2. Re: Haskell Usage (Brandon Allbery) >> > 3. Re: Haskell Usage (Henning Thielemann) >> > 4. Re: Haskell Usage (Jo Durchholz) >> > 5. Re: Haskell Usage (MigMit) >> > 6. Re: Haskell Usage (Ivan Perez) >> > 7. Re: Haskell Usage (Jared Tobin) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Tue, 14 Nov 2023 21:27:57 +0000 (GMT+00:00) >> > From: Henrique Caldeira >> > To: haskell-cafe at haskell.org >> > Subject: [Haskell-cafe] Haskell Usage >> > Message-ID: >> > Content-Type: text/plain; charset="utf-8" >> > >> > Good Evening from Portugal, >> > >> > I write to you about the usage of Haskell because I had a professor recommending me Erlang instead because Haskell was "more for academic purposes", which left me wondering if all my time spent was spent only for curiosity sake. >> > >> > I want to know how true my professor's statement is. >> > >> > I am very passionate about Haskell, although I admit the ecosystem can be confusing sometimes (for example, when to use cabal or stack, which versions of packages to use in order to avoid conflicts, or simply installing them through nixos or arch can be a learning process). >> > >> > Would love to hear your thoughts about all of this and thank you with all my heart. >> > >> > Lastly, all these wonderings are asked in a curious, "wanting to learn more" mindset. >> > >> > Kind regards, >> > Henrique Caldeira >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Tue, 14 Nov 2023 16:36:18 -0500 >> > From: Brandon Allbery >> > To: Henrique Caldeira >> > Cc: haskell-cafe at haskell.org >> > Subject: Re: [Haskell-cafe] Haskell Usage >> > Message-ID: >> > >> > Content-Type: text/plain; charset="utf-8" >> > >> > Yesod (https://yesodweb.com), Servant (https://www.servant.dev), Pandoc ( >> > https://pandoc.com), HLedger (https://hledger.org), and XMonad ( >> > https://xmonad.org), among others, argue against Haskell being only an >> > academic language. >> > >> > (I'm the principal maintainer of xmonad, but not involved with the other >> > packages.) >> > >> > On Tue, Nov 14, 2023 at 4:28 PM Henrique Caldeira wrote: >> > >> >> Good Evening from Portugal, >> >> >> >> I write to you about the usage of Haskell because I had a professor >> >> recommending me Erlang instead because Haskell was "more for academic >> >> purposes", which left me wondering if all my time spent was spent only for >> >> curiosity sake. >> >> >> >> I want to know how true my professor's statement is. >> >> >> >> I am very passionate about Haskell, although I admit the ecosystem can be >> >> confusing sometimes (for example, when to use cabal or stack, which >> >> versions of packages to use in order to avoid conflicts, or simply >> >> installing them through nixos or arch can be a learning process). >> >> >> >> Would love to hear your thoughts about all of this and thank you with all >> >> my heart. >> >> >> >> Lastly, all these wonderings are asked in a curious, "wanting to learn >> >> more" mindset. >> >> >> >> Kind regards, >> >> Henrique Caldeira >> >> _______________________________________________ >> >> 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. >> > >> > >> > >> _______________________________________________ >> 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. > > > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > _______________________________________________ > 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. From ietf-dane at dukhovni.org Mon Nov 20 19:47:39 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Nov 2023 14:47:39 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? Message-ID: It looks like there's some sort of syntax conflict between CPP and long string literals folded across multiple lines. Is there a way to have both CPP and folded long string literals? $ cat /tmp/foo.hs {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = "Hello\ \ World!" main :: IO () main = print hello ---- $ ghci /tmp/foo.hs GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Main ( /tmp/foo.hs, interpreted ) /tmp/foo.hs:5:25: error: [GHC-21231] lexical error in string/character literal at character 'W' | 5 | hello = "Hello\ | ^ Failed, no modules loaded. λ> Leaving GHCi. When I run the input through "cpp -E" I get: {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = "Hello \ World!" main :: IO () main = print hello Clearly not what I want, so the subsequent lexical error from GHC is not surprising, but is there a workaround that allows folding long strings across lines and retaining the layout. Given that the CPP lexer also recognises quoted strings, it looks like a difficult to reconcile mismatch. There would need be some other sort of joiner understood by GHC, where each string fragment is fully enclosed in quotes. Would the below be acceptable? {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = ##"Hello"\ ##"World!" main :: IO () main = print hello This is turned by CPP into either (version-dependent): {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = ##"Hello" ##"World!" main :: IO () main = print hello or: {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = ##"Hello" ##"World!" main :: IO () main = print hello which (or some suitable variant?) GHC could then also recognise as multiple fragments of the same single string literal? -- Viktor. From ietf-dane at dukhovni.org Mon Nov 20 20:07:42 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Nov 2023 15:07:42 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: On Mon, Nov 20, 2023 at 02:47:39PM -0500, Viktor Dukhovni wrote: > It looks like there's some sort of syntax conflict between CPP and > long string literals folded across multiple lines. Is there a > way to have both CPP and folded long string literals? > I may have found an acceptable work-around: {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = "Hello\ \ \ World!" main :: IO () main = print hello Is this trick "well known"? CPP turns the above into: {-# LANGUAGE CPP #-} module Main(main) where hello :: String hello = "Hello\ \ World!" main :: IO () main = print hello which is then valid Haskell syntax and yields the right value. -- Viktor. From ietf-dane at dukhovni.org Mon Nov 20 20:57:40 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Nov 2023 15:57:40 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: On Mon, Nov 20, 2023 at 03:07:42PM -0500, Viktor Dukhovni wrote: > > I may have found an acceptable work-around: > > {-# LANGUAGE CPP #-} > module Main(main) where > > hello :: String > hello = "Hello\ \ > \ World!" > > main :: IO () > main = print hello > > Is this trick "well known"? I have now (should have earlier) checked the user guide and found: https://downloads.haskell.org/ghc/latest/docs/users_guide/phases.html?highlight=string%20gaps#cpp-and-string-gaps and see that the it suggests adding trailing spaces. If that once worked, it no longer seems to. However adding a space and a trailing "\" does work. Perhaps the documentation can be updated? I do not know how portable my "\ \" sufix is across various systems. It works on a Fedora 36 system (Gnu toolchain), and with FreeBSD with both Clang and Gnu CPP. -- Viktor. From ietf-dane at dukhovni.org Tue Nov 21 03:29:11 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Nov 2023 22:29:11 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: On Mon, Nov 20, 2023 at 03:57:40PM -0500, Viktor Dukhovni wrote: > On Mon, Nov 20, 2023 at 03:07:42PM -0500, Viktor Dukhovni wrote: > > > > I may have found an acceptable work-around: > > > > {-# LANGUAGE CPP #-} > > module Main(main) where > > > > hello :: String > > hello = "Hello\ \ > > \ World!" > > > > main :: IO () > > main = print hello > > > > Is this trick "well known"? > > I have now (should have earlier) checked the user guide and found: > > https://downloads.haskell.org/ghc/latest/docs/users_guide/phases.html?highlight=string%20gaps#cpp-and-string-gaps > > and see that the it suggests adding trailing spaces. If that once > worked, it no longer seems to. However adding a space and a trailing > "\" does work. Perhaps the documentation can be updated? > > I do not know how portable my "\ \" sufix is across various systems. It > works on a Fedora 36 system (Gnu toolchain), and with FreeBSD with both > Clang and Gnu CPP. FWIW, GitHub CI shows that ending lines with "\ \" works on Ubuntu, MacOS and Windows. So it looks reasonably portable. The main downside is that the source code has to be changed when adding or removing "CPP", that would not have been the case with just "\ ", but that sadly does not work in practice. :-( -- Viktor. From haskellcafe at dandart.co.uk Tue Nov 21 09:27:12 2023 From: haskellcafe at dandart.co.uk (Dan Dart) Date: Tue, 21 Nov 2023 09:27:12 +0000 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: That does sound like a bug. but it doesn't seem patchable using {-# LANGUAGE CPP #-} because it *is* a bug in -XCPP... :p Have you reported it anywhere? Cheers From ietf-dane at dukhovni.org Tue Nov 21 10:52:49 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 21 Nov 2023 05:52:49 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: On Tue, Nov 21, 2023 at 09:27:12AM +0000, Dan Dart wrote: > That does sound like a bug. but it doesn't seem patchable using {-# > LANGUAGE CPP #-} because it *is* a bug in -XCPP... :p > > Have you reported it anywhere? Not yet reported outside this thread. Sure, morally speaking, this is a bug in "-XCPP", but in practice "-XCPP" unavoidably uses the actual C preprocessor, and is subject to its syntax idiosyncrasies. There's not a lot GHC can do once CPP joins the split lines and drops the trailing "\", and the documented trailing whitespace work-around no longer (if it once did) helps. So the only options appear to be to live with editing the code to to use a trailing "\ \" instead of just "\" when enablng -XCPP (and reverting when dropping "-XCPP", or else introduce a new syntax for multi-part string literals. Unless someone can suggest a better idea... -- Viktor. From raoknz at gmail.com Wed Nov 22 01:14:03 2023 From: raoknz at gmail.com (Richard O'Keefe) Date: Wed, 22 Nov 2023 14:14:03 +1300 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: A tiny change to Haskell, borrowed from Erlang, would solve the problem, I think, with an increase in readability. In Erlang, "c1...cn" ++ Pattern is a pattern, equivalent (in Haskell terms) to ('c1' :: 'c2' :: ... 'cn' :: Pattern). This means that a long string can be written as ("..." ++ "..." ++ ... ++ "..."), spread across as many lines as you need, with each substring being complete on a line, in any context you want. In an expression context, you can already do this, and that is easier to read than strings broken across multiple lines. It makes the treatment of leading white space completely obvious (if it's inside string quotes, it's part of the text, if not, it's not). The only problem is that you cannot use that construction where a pattern is needed (although if you are trying to use a long string as a pattern I have to wonder why). So the tiny extension is to allow an explicit concatenation of string literals as a string literal in a pattern. Right now, hello :: String hello = "Hello\ \ \ World!" can and should be written hello :: String hello = "Hello " ++ "World!" On Tue, 21 Nov 2023 at 23:53, Viktor Dukhovni wrote: > > On Tue, Nov 21, 2023 at 09:27:12AM +0000, Dan Dart wrote: > > > That does sound like a bug. but it doesn't seem patchable using {-# > > LANGUAGE CPP #-} because it *is* a bug in -XCPP... :p > > > > Have you reported it anywhere? > > Not yet reported outside this thread. Sure, morally speaking, this is a > bug in "-XCPP", but in practice "-XCPP" unavoidably uses the actual C > preprocessor, and is subject to its syntax idiosyncrasies. > > There's not a lot GHC can do once CPP joins the split lines and drops > the trailing "\", and the documented trailing whitespace work-around no > longer (if it once did) helps. > > So the only options appear to be to live with editing the code to to use > a trailing "\ \" instead of just "\" when enablng -XCPP (and reverting > when dropping "-XCPP", or else introduce a new syntax for multi-part > string literals. > > Unless someone can suggest a better idea... > > -- > Viktor. > _______________________________________________ > 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. From jclites at mac.com Wed Nov 22 01:36:13 2023 From: jclites at mac.com (Jeff Clites) Date: Tue, 21 Nov 2023 17:36:13 -0800 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: Message-ID: <8C4320CD-EB45-4D38-BEA8-253E303D54F8@mac.com> I like it. I would be interesting (though perhaps overkill) to have a special operator which is like ++ but which can only be applied to list literals (not only strings), and which is guaranteed to be syntactic sugar for the concatenated list. One step fancier would be to allow it not just for literals but for any known-at-compile-time values. (So it’s syntactically an operator but in actuality more of a compiler directive, to evaluate the concatenation at compile time, or fail if that’s not possible.) Just thinking out loud. Jeff > On Nov 21, 2023, at 5:14 PM, Richard O'Keefe wrote: > > A tiny change to Haskell, borrowed from Erlang, would solve the problem, > I think, with an increase in readability. > > In Erlang, "c1...cn" ++ Pattern is a pattern, equivalent (in Haskell terms) to > ('c1' :: 'c2' :: ... 'cn' :: Pattern). This means that a long string > can be written > as ("..." ++ "..." ++ ... ++ "..."), spread across as many lines as you need, > with each substring being complete on a line, in any context you want. > In an expression context, you can already do this, and that is easier to > read than strings broken across multiple lines. It makes the treatment of > leading white space completely obvious (if it's inside string quotes, it's > part of the text, if not, it's not). The only problem is that you cannot use > that construction where a pattern is needed (although if you are trying to > use a long string as a pattern I have to wonder why). So the tiny > extension is to allow an explicit concatenation of string literals as a string > literal in a pattern. > > Right now, > > hello :: String > hello = "Hello\ \ > \ World!" > > can and should be written > > hello :: String > hello = "Hello " ++ > "World!" > > >> On Tue, 21 Nov 2023 at 23:53, Viktor Dukhovni wrote: >> >>> On Tue, Nov 21, 2023 at 09:27:12AM +0000, Dan Dart wrote: >>> >>> That does sound like a bug. but it doesn't seem patchable using {-# >>> LANGUAGE CPP #-} because it *is* a bug in -XCPP... :p >>> >>> Have you reported it anywhere? >> >> Not yet reported outside this thread. Sure, morally speaking, this is a >> bug in "-XCPP", but in practice "-XCPP" unavoidably uses the actual C >> preprocessor, and is subject to its syntax idiosyncrasies. >> >> There's not a lot GHC can do once CPP joins the split lines and drops >> the trailing "\", and the documented trailing whitespace work-around no >> longer (if it once did) helps. >> >> So the only options appear to be to live with editing the code to to use >> a trailing "\ \" instead of just "\" when enablng -XCPP (and reverting >> when dropping "-XCPP", or else introduce a new syntax for multi-part >> string literals. >> >> Unless someone can suggest a better idea... >> >> -- >> Viktor. >> _______________________________________________ >> 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. > _______________________________________________ > 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. From reid.darryn at gmail.com Wed Nov 22 02:18:52 2023 From: reid.darryn at gmail.com (Darryn) Date: Wed, 22 Nov 2023 12:48:52 +1030 Subject: [Haskell-cafe] A question about type families conflicting instances Message-ID: <5744466.DvuYhMxLoT@farro> Sir/Madam, I have familiarity with Haskell and have recently returned to using it on a small project, and have just taken a crack at using type families for the first time. I've used functional dependencies more in the past. My example below is a greatly simplified version of what I'm trying to do; for context, the overall purpose is a clean representation of logical forms across languages for abstract case analysis for theorem-proving for certain multimodal logics. The idea represented here is a unified representation for sentential forms and labelled sentential forms. The instance for the latter would be defined in terms of the instance for the former, but to keep it as simple as possible, the snippet here just has a separate (nonsense) implementation of three functions f1,f2,f3 that represent the pattern. I understand that that I'm running into overlapping instances but am unsure about how to correct it, and I couldn't find anything to address this in a search of the haskell-cafe archive (which is not to say that it isn't there, just that I couldn't find and/or recognise it). I'm sure it will be a simple matter to point me in the right direction here for people with more experience. Thank you to anyone in advance who can help; I do really appreciate it. ------------------------------------------------------------------------------- {-# LANGUAGE TypeFamilies, TypeFamilyDependencies, MultiParamTypeClasses, FlexibleInstances #-} -- A simplified model for sentences. data S a = SA a (S a) | SB a (S a) | SC String deriving (Eq, Show) -- A simplified model for what will be abstract case analysis: data Form a b = FA a b | FB deriving (Eq, Show) -- A simplified a model for the case analysis class: class (F a ~ b) => Formable a b where type F a = t | t -> a f1 :: b -> Form a b f2 :: b -> b f3 :: b -> Bool -- Simple test instance of Formable for S: instance Formable a (S a) where type F a = S a f1 (SA a y) = FA a y f1 (SB a y) = FA a y f1 (SC x) = FB f2 (SA a y) = SA a y f2 (SB a y) = SA a y f2 (SC x) = SC "nothing" f3 (SA a y) = False f3 (SB a y) = False f3 (SC _) = True -- Some test instances all work fine: -- > f1 (SA "a" (SB "b" (SC "c"))) -- > f2 (SA "a" (SB "b" (SC "c"))) -- > f3 (SA "a" (SB "b" (SC "c"))) -- A model of a wrapper for sentences to iadd integer labels: data W a = W Int (S a) deriving (Eq, Show) -- Test instance modelling an instance for labelled sentences: instance Formable a (W a) where type F a = W a f1 (W k (SA a y)) = FA a (W k y) f1 (W k (SB a y)) = FA a (W k y) f1 (W k (SC x)) = FB f2 (W k x) = W (1+k) x f3 (W k (SA a y)) = False f3 (W k (SB a y)) = False f3 (W k (SC _)) = True -- Intend to re-implement f1,f2,f3 in terms of the instance for S once -- I can convince GHC to let both instances stand. ------------------------------------------------------------------------------- Everything is dandy if either of the two instances, for S and for W, are provided, but GHC is not at all impressed with the idea of having both. GHCi reports the following error. Test.hs:29:10: error: Conflicting family instance declarations: F a = S a -- Defined at Test.hs:29:10 F a = W a -- Defined at Test.hs:51:10 Regards, D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Nov 22 03:19:57 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 21 Nov 2023 22:19:57 -0500 Subject: [Haskell-cafe] A question about type families conflicting instances In-Reply-To: <5744466.DvuYhMxLoT@farro> References: <5744466.DvuYhMxLoT@farro> Message-ID: On Wed, Nov 22, 2023 at 12:48:52PM +1030, Darryn wrote: > Thank you to anyone in advance who can help; I do really appreciate it. I think a simple redefinition of "Formable" takes care of the described obstacle. Do you have other requirements that make it impractical? -- Viktor. --------- {-# LANGUAGE TypeFamilies, TypeFamilyDependencies, MultiParamTypeClasses, FlexibleInstances #-} import Data.Kind (Type) -- A simplified model for sentences. data S a = SA a (S a) | SB a (S a) | SC String deriving (Eq, Show) -- A simplified model for what will be abstract case analysis: data Form a b = FA a b | FB deriving (Eq, Show) -- A simplified a model for the case analysis class: class Formable b where type Aof b :: Type f1 :: b -> Form (Aof b) b f2 :: b -> b f3 :: b -> Bool -- Simple test instance of Formable for S: instance Formable (S a) where type Aof (S a) = a f1 (SA a y) = FA a y f1 (SB a y) = FA a y f1 (SC x) = FB f2 (SA a y) = SA a y f2 (SB a y) = SA a y f2 (SC x) = SC "nothing" f3 (SA a y) = False f3 (SB a y) = False f3 (SC _) = True -- Some test instances all work fine: -- > f1 (SA "a" (SB "b" (SC "c"))) -- > f2 (SA "a" (SB "b" (SC "c"))) -- > f3 (SA "a" (SB "b" (SC "c"))) -- A model of a wrapper for sentences to iadd integer labels: data W a = W Int (S a) deriving (Eq, Show) -- Test instance modelling an instance for labelled sentences: instance Formable (W a) where type Aof (W a) = a f1 (W k (SA a y)) = FA a (W k y) f1 (W k (SB a y)) = FA a (W k y) f1 (W k (SC x)) = FB f2 (W k x) = W (1+k) x f3 (W k (SA a y)) = False f3 (W k (SB a y)) = False f3 (W k (SC _)) = True -- Intend to re-implement f1,f2,f3 in terms of the instance for S once -- I can convince GHC to let both instances stand. From reid.darryn at gmail.com Wed Nov 22 23:57:39 2023 From: reid.darryn at gmail.com (Darryn) Date: Thu, 23 Nov 2023 10:27:39 +1030 Subject: [Haskell-cafe] A question about type families conflicting instances In-Reply-To: References: Message-ID: <10373031.nUPlyArG6x@farro> On Wednesday, 22 November 2023 10:30:01 PM ACDT haskell-cafe-request at haskell.org wrote: > > Thank you to anyone in advance who can help; I do really appreciate it. > > I think a simple redefinition of "Formable" takes care of the described > obstacle. Do you have other requirements that make it impractical? > > -- > Viktor. > Hi Viktor. Thanks again for taking a look at this and giving me advice. I hadn't thought of the problem like this, using kind representation. The short answer is that I'm not sure yet whether there are any other requirements that bear on this, given the exploratory nature of the little project, but having just played with your modifications and then worked it back to the main code, this solution looks excellent at this stage. Really appreciate it. Regards, D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From twilson at csufresno.edu Thu Nov 23 00:39:52 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 22 Nov 2023 16:39:52 -0800 Subject: [Haskell-cafe] Mutual scoping question Message-ID: Hello, Cafe: Is there a preferred way to define two top-level mutually recursive functions, f and g, that both use a common local function h such that h is (1) only defined once and (2) does not escape the scope of f and g? I suppose it could be done like this: fg = let f ... = ... f,g,h ... g ... = ... f,g,h ... h ... = ... h ... in (f,g) f = fst fg g = snd fg but is there something more elegant than this that I'm not seeing? Todd Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcconnell17704 at yahoo.com Thu Nov 23 01:26:09 2023 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Thu, 23 Nov 2023 01:26:09 +0000 (UTC) Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: Message-ID: <335244844.3833569.1700702769106@mail.yahoo.com> What about let h ... = ... h ...in let f ... = ... f,g,h ...       g ... = ... f,g,h ...   in ... (main body that uses f and g) ... This makes the dependencies clear.  h stands on its own, f and g use each other together with h, and the main body can use f, g, and h. I believe what you wanted, however, was to express that the main body *cannot* (will not, should not) use h.  This version does not express that. On Wednesday, November 22, 2023 at 07:40:25 PM EST, Todd Wilson wrote: Hello, Cafe: Is there a preferred way to define two top-level mutually recursive functions, f and g, that both use a common local function h such that h is (1) only defined once and (2) does not escape the scope of f and g? I suppose it could be done like this: fg = let f ... = ... f,g,h ...          g ... = ... f,g,h ...          h ... = ... h ...       in (f,g) f = fst fg g = snd fg   but is there something more elegant than this that I'm not seeing? Todd Wilson_______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From twilson at csufresno.edu Thu Nov 23 01:30:32 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 22 Nov 2023 17:30:32 -0800 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: <335244844.3833569.1700702769106@mail.yahoo.com> References: <335244844.3833569.1700702769106@mail.yahoo.com> Message-ID: Thanks, Mark. I wanted f and g to be defined at the top level for use throughout my whole file, rather just inside of a let. Of course, I could also put the definitions of f, g, and h in their own module/file that hides the name h and then import this, but I was hoping to have this all in one place. --Todd On Wed, Nov 22, 2023 at 5:26 PM Mark McConnell wrote: > What about > > let h ... = ... h ... > in let f ... = ... f,g,h ... > g ... = ... f,g,h ... > in ... (main body that uses f and g) ... > > This makes the dependencies clear. h stands on its own, f and g use each > other together with h, and the main body can use f, g, and h. > > I believe what you wanted, however, was to express that the main body > *cannot* (will not, should not) use h. This version does not express that. > On Wednesday, November 22, 2023 at 07:40:25 PM EST, Todd Wilson < > twilson at csufresno.edu> wrote: > > > Hello, Cafe: > > Is there a preferred way to define two top-level mutually recursive > functions, f and g, that both use a common local function h such that h is > (1) only defined once and (2) does not escape the scope of f and g? I > suppose it could be done like this: > > fg = let f ... = ... f,g,h ... > g ... = ... f,g,h ... > h ... = ... h ... > in (f,g) > f = fst fg > g = snd fg > > > but is there something more elegant than this that I'm not seeing? > > Todd Wilson > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Thu Nov 23 01:43:19 2023 From: jclites at mac.com (Jeff Clites) Date: Wed, 22 Nov 2023 17:43:19 -0800 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: Message-ID: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Can you do: (f, g) = let f’ = … in (f’, g’) or is a pattern match not allowed at top level? Jeff > On Nov 22, 2023, at 4:40 PM, Todd Wilson wrote: > >  > Hello, Cafe: > > Is there a preferred way to define two top-level mutually recursive functions, f and g, that both use a common local function h such that h is (1) only defined once and (2) does not escape the scope of f and g? I suppose it could be done like this: > > fg = let f ... = ... f,g,h ... > g ... = ... f,g,h ... > h ... = ... h ... > in (f,g) > f = fst fg > g = snd fg > > but is there something more elegant than this that I'm not seeing? > > Todd Wilson > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From twilson at csufresno.edu Thu Nov 23 03:41:35 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 22 Nov 2023 19:41:35 -0800 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: <2D513109-070B-495A-8060-126CD73922BC@mac.com> References: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Message-ID: It seems (surprisingly to me) that such pattern matches are allowed at the top level, so that would simplify my kludge a bit by skipping the definition of fg. But is using pairs (or the equivalent) in this way the only solution? I was hoping that there might be some kind of top-level definition syntax like {f .. = ... ; g .. = ...} where h .. = ... that would correctly capture the scoping I'm looking for. --Todd On Wed, Nov 22, 2023 at 5:43 PM Jeff Clites wrote: > Can you do: > > (f, g) = let f’ = … in (f’, g’) > > or is a pattern match not allowed at top level? > > Jeff > > On Nov 22, 2023, at 4:40 PM, Todd Wilson wrote: > >  > Hello, Cafe: > > Is there a preferred way to define two top-level mutually recursive > functions, f and g, that both use a common local function h such that h is > (1) only defined once and (2) does not escape the scope of f and g? I > suppose it could be done like this: > > fg = let f ... = ... f,g,h ... > g ... = ... f,g,h ... > h ... = ... h ... > in (f,g) > f = fst fg > g = snd fg > > > but is there something more elegant than this that I'm not seeing? > > Todd Wilson > _______________________________________________ > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Nov 23 05:59:59 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 23 Nov 2023 00:59:59 -0500 Subject: [Haskell-cafe] A question about type families conflicting instances In-Reply-To: <10373031.nUPlyArG6x@farro> References: <10373031.nUPlyArG6x@farro> Message-ID: On Thu, Nov 23, 2023 at 10:27:39AM +1030, Darryn wrote: > > I think a simple redefinition of "Formable" takes care of the described > > obstacle. Do you have other requirements that make it impractical? > > Hi Viktor. Thanks again for taking a look at this and giving me > advice. I hadn't thought of the problem like this, using kind > representation. I hope that I didn't give the impression that the use of import Data.Kind (Type) was an essential (or even required) part of the suggested alternative. It is was rather just pedantic precision. The "kind annotation" in type Aof b :: Type is entirely optional, the actual change was to define how "a" depends on "b", rather than how "b" depends on a. This is because extracting: (S a) -> a (W a) -> a is just simple pattern matching, while divining with of (S a) or (W a) to associate with "a" is hopelessly ambiguous. -- Viktor. From ietf-dane at dukhovni.org Thu Nov 23 06:41:49 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 23 Nov 2023 01:41:49 -0500 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: <8C4320CD-EB45-4D38-BEA8-253E303D54F8@mac.com> References: <8C4320CD-EB45-4D38-BEA8-253E303D54F8@mac.com> Message-ID: On Tue, Nov 21, 2023 at 05:36:13PM -0800, Jeff Clites via Haskell-Cafe wrote: > I like it. I would be interesting (though perhaps overkill) to have a special operator which is like ++ but which can only be applied to list literals (not only strings), and which is guaranteed to be syntactic sugar for the concatenated list. One step fancier would be to allow it not just for literals but for any known-at-compile-time values. (So it’s syntactically an operator but in actuality more of a compiler directive, to evaluate the concatenation at compile time, or fail if that’s not possible.) Well, I guess we already have that in the form of Template Haskell splices, but that's rather a heavy hammer to swat this particular fly... {-# LANGUAGE TemplateHaskell #-} module Data.CompileTime(compileTimeString) where import Language.Haskell.TH.Syntax as TH compileTimeString :: TH.Quote m => String -> TH.Code m String compileTimeString str = let !lit = str in [|| lit ||] Which when imported into: {-# LANGUAGE CPP, TemplateHaskell #-} module Main(main) where import Data.CompileTime hello :: String hello = $$( compileTimeString $ "Hello" ++ " World!" ) main :: IO () main = print hello Produces the "Core" below: ... main :: IO () main = print ($fShowList $fShowChar) (unpackCString# "Hello World!"#) -- Viktor. From qdunkan at gmail.com Thu Nov 23 16:21:56 2023 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 23 Nov 2023 08:21:56 -0800 Subject: [Haskell-cafe] Folded long string literals and CPP? In-Reply-To: References: <8C4320CD-EB45-4D38-BEA8-253E303D54F8@mac.com> Message-ID: I switched to cpphs which doesn't have this problem. On Wed, Nov 22, 2023, 10:42 PM Viktor Dukhovni wrote: > On Tue, Nov 21, 2023 at 05:36:13PM -0800, Jeff Clites via Haskell-Cafe > wrote: > > > I like it. I would be interesting (though perhaps overkill) to have a > special operator which is like ++ but which can only be applied to list > literals (not only strings), and which is guaranteed to be syntactic sugar > for the concatenated list. One step fancier would be to allow it not just > for literals but for any known-at-compile-time values. (So it’s > syntactically an operator but in actuality more of a compiler directive, to > evaluate the concatenation at compile time, or fail if that’s not possible.) > > Well, I guess we already have that in the form of Template Haskell > splices, but that's rather a heavy hammer to swat this particular > fly... > > {-# LANGUAGE TemplateHaskell #-} > module Data.CompileTime(compileTimeString) where > import Language.Haskell.TH.Syntax as TH > > compileTimeString :: TH.Quote m => String -> TH.Code m String > compileTimeString str = let !lit = str in [|| lit ||] > > Which when imported into: > > {-# LANGUAGE CPP, TemplateHaskell #-} > module Main(main) where > import Data.CompileTime > > hello :: String > hello = $$( compileTimeString $ "Hello" ++ " World!" ) > > main :: IO () > main = print hello > > Produces the "Core" below: > > ... > main :: IO () > main > = print ($fShowList $fShowChar) (unpackCString# "Hello World!"#) > > -- > Viktor. > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.gibbons at cs.ox.ac.uk Mon Nov 27 09:21:49 2023 From: jeremy.gibbons at cs.ox.ac.uk (Jeremy Gibbons) Date: Mon, 27 Nov 2023 09:21:49 +0000 Subject: [Haskell-cafe] [Haskell] ANT 2024 CFP (December 4, 2023 (extended)): The 15th International Conference on Ambient Systems, Networks and Technologies (ANT) , Hasselt, Belgium, April 23-25, 2024 In-Reply-To: References: Message-ID: <61E3F2BC-77EC-44C6-8C3B-58AEDF665BEF@cs.ox.ac.uk> I don’t know what Ivan’s relationship to the list is (for the record, I am not a list administrator myself, just a member of the community). But Ivan makes a good point. The three Haskell mailing lists have a specific purpose: "to discuss issues related to Haskell”. In the last year you appear to have posted 53 adverts for five conferences, called "Ambient Systems, Networks and Technologies", "Emerging Data and Industry", "Information and Communication Technologies in Healthcare", "Emerging Ubiquitous Systems and Pervasive Networks", "Sustainable Energy Information Technology", and "Mobile Systems and Pervasive Computing”. I don’t see that any of these are “related to Haskell”. Has there ever been any paper mentioning Haskell at any of these conferences? Do their calls for papers mention functional programming? If these conferences are not “related to Haskell”, then their announcements do not belong on the Haskell mailing list. Jeremy PS Diverting from the announcements list to haskell-cafe, the discussion list. > On 27 Nov 2023, at 07:28, Ali BENZERBADJ wrote: > > Dear Ivan, > I would like to ask you to introduce yourself first, please. Are you the admin of the mailing list? I assume that Haskell is the one who assesses the relevance of announcements. If the topic doesn't interest you, just ignore it, and that's it. > > Yours sincerely. > > On Sun, 26 Nov 2023 at 23:07, Ivan Perez > wrote: > Ali, > > None of the CfPs you've sent to this mailing list over the past year appear even remotely related to Haskell. I doubt people on this list will find them relevant or interesting. > > Could you please stop sending CfPs to haskell and haskell-cafe? > > Thanks > > Ivan > > On Sun, 26 Nov 2023 at 11:19, Ali BENZERBADJ > wrote: > *************************************************************************** > The 15th International Conference on Ambient Systems, Networks and Technologies (ANT) > Hasselt, Belgium > April 23-25, 2024 > > *************************************************************************** > Conference Website: http://cs-conferences.acadiau.ca/ant-24/ > Workshops: http://cs-conferences.acadiau.ca/ant-24/#workshop > > Important Dates > - Workshops Proposals Due: October 20, 2023 > - Paper Submission Due: December 4, 2023 (extended) > - Acceptance Notification: January 15, 2024 > - Camera-Ready Submission: February 9, 2024 > > ANT 2024 accepted papers will be published by Elsevier Science in the open-access Procedia Computer Science series on-line. Procedia Computer Science is hosted by Elsevier on www.Elsevier.com and on Elsevier content platform ScienceDirect (www.sciencedirect.com ), and will be freely available worldwide. All papers in Procedia will be indexed by Scopus (www.scopus.com ) and by Thomson Reuters' Conference Proceeding Citation Index (http://thomsonreuters.com/conference-proceedings-citation-index/ ). All papers in Procedia will also be indexed by Scopus (www.scopus.com ) and Engineering Village (Ei) (www.engineeringvillage.com ). This includes EI Compendex (www.ei.org/compendex ). Moreover, all accepted papers will be indexed in DBLP (http://dblp.uni-trier.de/ ). The papers will contain linked references, XML versions and citable DOI numbers. You will be able to provide a hyperlink to all delegates and direct your conference website visitors to your proceedings. Selected papers will be invited for publication, in the special issues of: > > > - International Journal of Ambient Intelligence and Humanized Computing (IF: 4.594), by Springer (http://www.springer.com/engineering/journal/12652 ) > - International Journal Personal and Ubiquitous Computing (IF:3.006), Springer (https://www.springer.com/journal/779 ) > - International Journal on Transportation Research Part A: Policy and Practice (IF: 3.992), by Elsevier (https://www.journals.elsevier.com/transportation-research-part-a-policy-and-practice/ ) > > > ANT 2024 will be held in Hasselt, Belgium. ANT 2024 is co-organized & co-hosted by the Hasselt University, Belgium. Since 1973 Hasselt University is located on the Campus Diepenbeek, which occupies an attractive 150 acre site in the middle of Limburg's green belt. It is 2 kms west of the town centre of Diepenbeek, a residential town of 17.717 inhabitants, and 4 kms east of Hasselt which has a population of about 69.529 and is the administrative and commercial centre of the province. Brussels is 90 kms away (to the South-West), Antwerp lies 90 kms to the West, Liège (in the French-speaking part of Belgium) 45 kms to the South, Maastricht (in the Netherlands) 25 kms to the East, Aachen (in Germany) 60 kms to the South-East. > > ANT 2024 will be held in conjunction with the 7th International Conference on Emerging Data and Industry (EDI40). > > Conference Tracks > - Agent Systems, Intelligent Computing and Applications > - Big Data and Analytics > - Cloud Computing > - Context-awareness and Multimodal Interfaces > - Emerging Networking, Tracking and Sensing Technologies > - Human Computer Interaction > - Internet of Things > - Mobile Networks, Protocols and Applications > - Modelling and Simulation in Transportation Sciences > - Multimedia and Social Computing > - Service Oriented Computing for Systems & Applications > - Smart, Sustainable Cities and Climate Change Management > - Smart Environments and Applications > - Systems Security and Privacy > - Systems Software Engineering > - Vehicular Networks and Applications > - General Track > > > General Chairs > > Atta Badii, University of Reading, UK > Albert Zomaya, The University of Sydney, Australia > > Program Chairs > > Hossam Hassanein, Queen's University, Canada > Ansar-Ul-Haque Yasar, Hasselt University, Belgium > > Workshops Chair > > Stephane Galland, UTBM, France > > Vice Chairs > > Muhammad Adnan, Hasselt University, Belgium > Manzoor Ahmed, Hubei Engineering University, Xiaogan, China > Akramul Azim, Ontario Tech University, Canada > Ayoub Bahnasse, Hassan II University, Morocco > Nik Bessis, Edge Hill University, UK > Samia Bouzefrane, CEDRIC Lab Conservatoire National des Arts et Metiers, France > Junsung Choi, Chungbuk National University, Republic of Korea > Robertas Damasevicius, Kaunas University of Technology, Lithuania > Antonella Galizia, Principal Scientist, CNR, Italy > Mohammad Ghanim, Ministry of Transport, Qatar > Stefano Guarino, IAC-CNR Rome, Italy > Faouzi Kammoun, Ecole Superieure Privee d'Ingenierie et de Technologies, Tunis > Bouabdellah Kechar, Oran 1 Ahmed BenBella University, Algeria > Ridha Khedri, McMaster University, Canada > Flavio Lombardi, Roma Tre University of Rome, Italy > Yazan Mualla, UTBM, France > Aneta Poniszewska-Maranda, Lodz University of Technology, Poland > Khair Eddin Sabri, The University of Jordan, Jordan > Cristina Seceleanu, Malardalen University, Sweden > Khaled Shaaban, Utah Valley University, USA > Kamran Siddique, Xiamen University Malaysia, Malaysia > Mohamed Tabaa, EMSI, Morocco > Igor Tchappi, University of Luxembourg, Luxembourg > > Technical Program Committee > > http://cs-conferences.acadiau.ca/ant-24/#programCommittees > > Publicity Chairs > > Ali Benzerbadj, University of Ain Temouchent Belhadj Bouchaib, Algeria > Wim Ectors, Hasselt University, Belgium > Siddardha Kaja, Air Canada, Canada > Orven E. Llantos, MSU-IIT, Philippines > Farhan Ullah, Northwestern Polytechnical University, China > > International Journals Chairs > > Haroon Malik, Marshall University, USA > Michael Sheng, Macquarie University, Australia > > Advisory Committee > > Reda Alhajj, University of Calgary, Canada > Sajal K. Das, The University of Texas at Arlington, USA > Erol Gelenbe, Imperial College, UK > Ibad Kureshi, Inlecomm Systems, Belgium > Vincenzo Loia, University of Salerno, Italy > Peter Sloot, Universiteit van Amsterdam, Netherlands > Ralf Steinmetz, Technische Universitaet Darmstadt, Germany > Katia Sycara, Carnegie Mellon University, USA > Peter Thomas, Manifesto Research, Australia > > International Liaison Chairs > > Soumaya Cherkaoui, Sherbrooke University, Canada > Paul Davidsson, Malmo University, Sweden > David Taniar, Monash University, Australia > > Steering Committee Chair and Founder of ANT > > Elhadi Shakshuki, Acadia University, Canada > > -- > Ali Benzerbadj > Lecturer, University of Ain Temouchent > Ain Temouchent, Algeria > Research Laboratory in Industrial Computing and Networks (RIIR) > Research team :"Networks and QoS" > University of Oran 1 Ahmed Ben Bella, Oran, Algeria > Mob(s): +213 6 61622162 > E-mail(s):.benzerbadj at univ-temouchent.edu.dz , ali_benz at yahoo.fr , > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > > -- > Ali Benzerbadj > Lecturer, University of Ain Temouchent > Ain Temouchent, Algeria > Research Laboratory in Industrial Computing and Networks (RIIR) > Research team :"Networks and QoS" > University of Oran 1 Ahmed Ben Bella, Oran, Algeria > Mob(s): +213 6 61622162 > E-mail(s):.benzerbadj at univ-temouchent.edu.dz , ali_benz at yahoo.fr , > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell Jeremy.Gibbons at cs.ox.ac.uk Oxford University Department of Computer Science, Wolfson Building, Parks Road, Oxford OX1 3QD, UK. +44 1865 283521 http://www.cs.ox.ac.uk/people/jeremy.gibbons/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Mon Nov 27 13:41:41 2023 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Mon, 27 Nov 2023 14:41:41 +0100 Subject: [Haskell-cafe] STOP THESE PATHOLOGIES... [Was: ANT 2024 CFP (December 4, 2023 ... etc.] In-Reply-To: <61E3F2BC-77EC-44C6-8C3B-58AEDF665BEF@cs.ox.ac.uk> References: <61E3F2BC-77EC-44C6-8C3B-58AEDF665BEF@cs.ox.ac.uk> Message-ID: <77429c44-6eba-4aae-9675-fe1100de092c@unicaen.fr> Le 27/11/2023 à 10:21, Jeremy Gibbons gently reacts  to an inacceptable response of Mr. Ali Benzerbadj addressed to Ivan Perez and the Haskell language communities, concerning sending irrelevant messages to our mailing lists. Jeremy writes: > > I don’t see that any of these are “related to Haskell”. Has there ever > been any paper mentioning Haskell at any of these conferences? Do > their calls for papers mention functional programming? If these > conferences are not “related to Haskell”, then their announcements do > not belong on the Haskell mailing list. > > Jeremy == Jeremy, please... It is plainly obvious that Mr. A.B has no idea what Haskell is... : > >> On 27 Nov 2023, at 07:28, Ali BENZERBADJ >> wrote: >> >> /.../ Are you the admin of the mailing list? *I assume that Haskell >> is the one who assesses the relevance of announcements. **If the >> topic doesn't interest you, just ignore it, and that's it.* I send a copy of my posting to Mr. Benzerbadj, since I am certain that he doesn't read */any /*of numerous lists, where he dumps his spam. Otherwise he would recognize that Haskell is the name of a programming language, and the Mystical Administrator and the Spirit of all those lists is called Curry (well, I know that in Algeria people ignore Curry, because they employ more powerful spices, e.g.,   Ras-El-Hanout, but a university lecturer and Publicity Chair of a world-wide conference in Belgium, should be more cosmopolitan!) BTW, the staff of the advertised conference is very, very international, you will find therein even some Belgians, for example Ansar-Ul-Haque Yasar, Muhammad Adnan, and  Ibad Kureshi. I believe that they could have helped  Mr. Benzerbadj with the selection of the mailing lists which would accept his announcements with true joy, gratitude, and enthusiasm. Speaking about gratitude... We should thank Mr. Benzerbadj for the broadcasting of news about this important conference, which covers many fascinating and cutting-edge  domains! I was particularly interested by the last item: "General Track", whose name already promises a world-changing revolution! Also, the tracks:  - Context-awareness and Multimodal Interfaces  - Human Computer Interaction  - Smart Environments and Applications are for me of paramount importance, seriously! For example, the context-aware interaction between your humble servitor and my laptop, encouraged me to install a really smart environment, which permitted my multimodal interfaces to filter away and throw to Limbo (Jahannam, Gehenna, etc., choose your favourite place) all messages by Mr. Benzerbadj [and similar], so I couldn't even know that he became a Person of Interest. Jerzy Karczmarczuk -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Tue Nov 28 06:35:57 2023 From: raoknz at gmail.com (Richard O'Keefe) Date: Tue, 28 Nov 2023 19:35:57 +1300 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Message-ID: SML has local declarations in declarations end and there is no fundamental reason why Haskell couldn't. Is there some reason why you cannot put f g and h in a module and just export f and g? On Thu, 23 Nov 2023 at 16:42, Todd Wilson wrote: > > It seems (surprisingly to me) that such pattern matches are allowed at the top level, so that would simplify my kludge a bit by skipping the definition of fg. But is using pairs (or the equivalent) in this way the only solution? I was hoping that there might be some kind of top-level definition syntax like > > {f .. = ... ; g .. = ...} where h .. = ... > > that would correctly capture the scoping I'm looking for. > > --Todd > > On Wed, Nov 22, 2023 at 5:43 PM Jeff Clites wrote: >> >> Can you do: >> >> (f, g) = let f’ = … in (f’, g’) >> >> or is a pattern match not allowed at top level? >> >> Jeff >> >> On Nov 22, 2023, at 4:40 PM, Todd Wilson wrote: >> >>  >> Hello, Cafe: >> >> Is there a preferred way to define two top-level mutually recursive functions, f and g, that both use a common local function h such that h is (1) only defined once and (2) does not escape the scope of f and g? I suppose it could be done like this: >> >> fg = let f ... = ... f,g,h ... >> g ... = ... f,g,h ... >> h ... = ... h ... >> in (f,g) >> f = fst fg >> g = snd fg >> >> >> but is there something more elegant than this that I'm not seeing? >> >> Todd Wilson >> _______________________________________________ >> 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. > > _______________________________________________ > 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. From daniel.casanueva at proton.me Tue Nov 28 08:40:44 2023 From: daniel.casanueva at proton.me (Daniel Casanueva) Date: Tue, 28 Nov 2023 08:40:44 +0000 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Message-ID: I hope I am not misunderstanding the question, but if you want to define f, g and h, but only export f and g, this is what you would do in Haskell: module Foo.Bar (f, g) where f = ... g = ... h = ... The module header determines what gets exported. On Tuesday, November 28th, 2023 at 07:35, Richard O'Keefe wrote: > > > SML has > local > declarations > in > declarations > end > and there is no fundamental reason why Haskell couldn't. > Is there some reason why you cannot put f g and h in a module and just > export f and g? > > On Thu, 23 Nov 2023 at 16:42, Todd Wilson twilson at csufresno.edu wrote: > > > It seems (surprisingly to me) that such pattern matches are allowed at the top level, so that would simplify my kludge a bit by skipping the definition of fg. But is using pairs (or the equivalent) in this way the only solution? I was hoping that there might be some kind of top-level definition syntax like > > > > {f .. = ... ; g .. = ...} where h .. = ... > > > > that would correctly capture the scoping I'm looking for. > > > > --Todd > > > > On Wed, Nov 22, 2023 at 5:43 PM Jeff Clites jclites at mac.com wrote: > > > > > Can you do: > > > > > > (f, g) = let f’ = … in (f’, g’) > > > > > > or is a pattern match not allowed at top level? > > > > > > Jeff > > > > > > On Nov 22, 2023, at 4:40 PM, Todd Wilson twilson at csufresno.edu wrote: > > > > > > Hello, Cafe: > > > > > > Is there a preferred way to define two top-level mutually recursive functions, f and g, that both use a common local function h such that h is (1) only defined once and (2) does not escape the scope of f and g? I suppose it could be done like this: > > > > > > fg = let f ... = ... f,g,h ... > > > g ... = ... f,g,h ... > > > h ... = ... h ... > > > in (f,g) > > > f = fst fg > > > g = snd fg > > > > > > but is there something more elegant than this that I'm not seeing? > > > > > > Todd Wilson > > > _______________________________________________ > > > 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. > > > > _______________________________________________ > > 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. > > _______________________________________________ > 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. From twilson at csufresno.edu Tue Nov 28 15:54:52 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Tue, 28 Nov 2023 07:54:52 -0800 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Message-ID: I mentioned earlier wanting to avoid modules for this, and hoping for something like the SML syntax that Richard mentioned, even making my own equivalent syntactic proposal {f = ...; g = ...} where h = ... which looks in line with current Haskell conventions. Given the existing options, however, I would probably go with a top-level pair definition: (f,g) = (..., ...) where h = ... or (f,g) = let f' = ...; g' = ...' ; h = ... in (f',g') as mentioned by Jeff. Thanks to all who contributed! --Todd On Tue, Nov 28, 2023 at 12:40 AM Daniel Casanueva < daniel.casanueva at proton.me> wrote: > I hope I am not misunderstanding the question, but if you want to define > f, g and h, but only export f and g, this is what you would do in Haskell: > > module Foo.Bar (f, g) where > > f = ... > g = ... > h = ... > > The module header determines what gets exported. > > On Tuesday, November 28th, 2023 at 07:35, Richard O'Keefe < > raoknz at gmail.com> wrote: > > > > > > > > SML has > > local > > declarations > > in > > declarations > > end > > and there is no fundamental reason why Haskell couldn't. > > Is there some reason why you cannot put f g and h in a module and just > > export f and g? > > > > On Thu, 23 Nov 2023 at 16:42, Todd Wilson twilson at csufresno.edu wrote: > > > > > It seems (surprisingly to me) that such pattern matches are allowed at > the top level, so that would simplify my kludge a bit by skipping the > definition of fg. But is using pairs (or the equivalent) in this way the > only solution? I was hoping that there might be some kind of top-level > definition syntax like > > > > > > {f .. = ... ; g .. = ...} where h .. = ... > > > > > > that would correctly capture the scoping I'm looking for. > > > > > > --Todd > > > > > > On Wed, Nov 22, 2023 at 5:43 PM Jeff Clites jclites at mac.com wrote: > > > > > > > Can you do: > > > > > > > > (f, g) = let f’ = … in (f’, g’) > > > > > > > > or is a pattern match not allowed at top level? > > > > > > > > Jeff > > > > > > > > On Nov 22, 2023, at 4:40 PM, Todd Wilson twilson at csufresno.edu > wrote: > > > > > > > > Hello, Cafe: > > > > > > > > Is there a preferred way to define two top-level mutually recursive > functions, f and g, that both use a common local function h such that h is > (1) only defined once and (2) does not escape the scope of f and g? I > suppose it could be done like this: > > > > > > > > fg = let f ... = ... f,g,h ... > > > > g ... = ... f,g,h ... > > > > h ... = ... h ... > > > > in (f,g) > > > > f = fst fg > > > > g = snd fg > > > > > > > > but is there something more elegant than this that I'm not seeing? > > > > > > > > Todd Wilson > > > > _______________________________________________ > > > > 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. > > > > > > _______________________________________________ > > > 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. > > > > _______________________________________________ > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Tue Nov 28 16:26:20 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Nov 2023 11:26:20 -0500 Subject: [Haskell-cafe] Mutual scoping question In-Reply-To: References: <2D513109-070B-495A-8060-126CD73922BC@mac.com> Message-ID: On Tue, Nov 28, 2023 at 07:54:52AM -0800, Todd Wilson wrote: > I mentioned earlier wanting to avoid modules for this, and hoping for > something like the SML syntax that Richard mentioned, even making my own > equivalent syntactic proposal > > {f = ...; g = ...} where h = ... > > which looks in line with current Haskell conventions. Given the existing > options, however, I would probably go with a top-level pair definition: > > (f,g) = (..., ...) where h = ... > > or > > (f,g) = let f' = ...; g' = ...' ; h = ... in (f',g') > > as mentioned by Jeff. Thanks to all who contributed! Or, with heavy artilery, that I rather expect entirely optimises away: {-# LANGUAGE DataKinds, GADTs, LambdaCase, StandaloneKindSignatures, TypeFamilies #-} module Demo(f, g) where import Data.Kind (Type) type FG :: Bool -> Type type family FG b where FG False = String -> Bool FG True = Int -> String data SBool b where SFalse :: SBool False STrue :: SBool True f :: String -> Bool f = fg SFalse g :: Int -> String g = fg STrue fg :: SBool b -> FG b fg = \ case SFalse -> f' STrue -> g' where h :: Int -> String h = show f' s = s == h 0 g' i = h (i + 1) {-# INLINE fg #-} The "Core" output shows: -- RHS size: {terms: 15, types: 14, coercions: 0, joins: 0/0} g :: Int -> String g = \ (i :: Int) -> case i of { I# x -> case $wshowSignedInt 0# (+# x 1#) [] of { (# ww5, ww6 #) -> : ww5 ww6 } } -- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0} f1 :: String f1 = case $wshowSignedInt 0# 0# [] of { (# ww5, ww6 #) -> : ww5 ww6 } -- RHS size: {terms: 4, types: 1, coercions: 0, joins: 0/0} f :: String -> Bool f = \ (s :: String) -> eqString s f1 -- Viktor. From zoran.bosnjak at via.si Wed Nov 29 11:49:06 2023 From: zoran.bosnjak at via.si (Zoran =?utf-8?Q?Bo=C5=A1njak?=) Date: Wed, 29 Nov 2023 11:49:06 +0000 (UTC) Subject: [Haskell-cafe] ByteString and ByteString.Builder questions Message-ID: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> Hi all, if I understand correctly, the ByteString.Builder is used to efficiently construct sequence of bytes from smaller parts. However, for inspecting data (take, head, index...), a plain ByteString is required. What if the byte sequence manipulation task requires both, for example: - receive ByteString from the network (e.g: Network.Socket.ByteString.recv :: ... -> IO ByteString) - inspect and manipulate data (pure function) - resend to the network (e.g: Network.Socket.ByteString.sendMany :: ... -> [ByteString] -> IO ()) ... where a pure data manipulation could be something like: - extract some segments out of the original sequence - create and add some segments of bytes - reorder - concatinate It is somewhat inconvenient to use 2 different types for the task, namely the ByteString and the Builder... where both represent a sequence of bytes. I have tryed to define a Bytes type where both representations are available: import qualified Data.ByteString as BS import qualified Data.ByteString.Lazy as Bsl import qualified Data.ByteString.Builder as Bld data Bytes = Bytes { toByteString :: ByteString , toBuilder :: Builder , length :: Int } instance Semigroup Bytes ... instance Monoid Bytes ... -- create fromByteString :: ByteString -> Bytes fromByteString bs = Bytes { toByteString = bs , toBuilder = Bld.byteString bs , length = BS.length bs } -- inspect function example head :: Bytes -> Word8 head = BS.head . toByteString -- prepare to send data over the network toChunks :: Bytes -> [ByteString] toChunks = Bsl.toChunks . Bld.toLazyByteString . toBuilder The fields of Bytes are non-strict, so the expectation was that lazy evaluation will suspend unnecessary calculations and to have efficient inspection (via ByteString part) and efficient concatination (via Builder part). I have performed some benchmarks (not sure if they are exactly to the point), but the results of Bytes are not so good: Inspect test using ByteString: OK (0.50s) 5.51 ms ± 342 μs using Bytes: OK (0.17s) 62.0 ms ± 3.0 ms Construct test using Builder: OK (0.21s) 5.29 ms ± 361 μs using Bytes: OK (0.17s) 21.3 ms ± 1.6 ms naive: OK (0.81s) 49.6 ms ± 4.1 ms Here is the full code: https://gist.github.com/zoranbosnjak/7887d843056f07bac6061d20970e1d6a My questions are: 0) Where does the big timing difference comming from? Thunks? 1) Is there any simple way (INLINE pragmas... or some other tricks) to get the performance back with the current implementation? 2) Would DList [ByteString] or any other type be any better over the ByteString.Builder in this case? 3) What would be the most efficient (and reasonable) implementation to support this kind of data processing (inspecting and concatination) in some uniform way? In other words: Is it worth to have uniformity here? 4) Is the Network.Socket.ByteString.sendMany function the way to go in cases where the byte sequence is constructed from segment or is there any better (faster) way? regards, Zoran From ietf-dane at dukhovni.org Wed Nov 29 17:24:17 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2023 12:24:17 -0500 Subject: [Haskell-cafe] ByteString and ByteString.Builder questions In-Reply-To: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> References: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> Message-ID: On Wed, Nov 29, 2023 at 11:49:06AM +0000, Zoran Bošnjak wrote: > if I understand correctly, the ByteString.Builder is used to > efficiently construct sequence of bytes from smaller parts. Best used in continuation-passing-style (right-associatively), where all the subsequent builders are lazily added as part of constructing the "head" builder. builder = chunk1 <> (chunk2 <> (chunk3 <> (... <> chunkN)...)) Repeatedly appending tail chunks (effectively left-associate) is noticeably less efficient (similar to lists). A work-around is to instead append (Builder->Builder) endomorphisms. b1 = Endo (mappend chunk1) b2 = b1 <> Endo (mappend chunk2) b3 = b2 <> Endo (mappend chunk3) ... bN = ... and then extract the final builder via: `appEndo bN mempty`. Endomorphism append will be more efficient once there are many parts to combine. > However, for inspecting data (take, head, index...), a plain > ByteString is required. For efficient processing of network streams, you'd perhaps use a streaming API that exposes the input as a monadic stream of chunks, and perhaps a corresponding parser layered on top that supports consuming chunks monadically. The `streaming` ecosystem for example has support for this model. > What if the byte sequence manipulation task requires both, for example: > - receive ByteString from the network (e.g: Network.Socket.ByteString.recv :: ... -> IO ByteString) > - inspect and manipulate data (pure function) > - resend to the network (e.g: Network.Socket.ByteString.sendMany :: ... -> [ByteString] -> IO ()) The input packet will be a `ByteString`, the output packet should be a builder, that is converted at the last moment to a (possibly lazy) bytestring for transmission. You shouldn't need to read your output, so a single representation is sufficient. > It is somewhat inconvenient to use 2 different types for the task, > namely the ByteString and the Builder... where both represent a > sequence of bytes. A builder is not a sequence of bytes as such, it is a CPS-style generator for a slice of a future sequence of bytes that can incrementally build the entire sequence without reallocation or copying (at least when the output is a lazy bytestring). > I have tryed to define a Bytes type where both representations are available: > > import qualified Data.ByteString as BS > import qualified Data.ByteString.Lazy as Bsl > import qualified Data.ByteString.Builder as Bld > > data Bytes = Bytes > { toByteString :: ByteString > , toBuilder :: Builder > , length :: Int > } This is not a productive direction to explore. Instead your *output* should be a Builder, either constructed lazily in one go (with the tail parts already lazily appended), or constructed by concatenation of (Builder->Builder) endomorphisms. The inputs that individual builder chunks will consume can be bytestring slices mixed with various other data (e.g. builders for binary length fields that convert ints to big-endian wire-form, ...). -- Viktor. From ietf-dane at dukhovni.org Wed Nov 29 23:27:18 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2023 18:27:18 -0500 Subject: [Haskell-cafe] ByteString and ByteString.Builder questions In-Reply-To: References: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> Message-ID: On Wed, Nov 29, 2023 at 12:24:17PM -0500, Viktor Dukhovni wrote: > > > if I understand correctly, the ByteString.Builder is used to > > efficiently construct sequence of bytes from smaller parts. > > Best used in continuation-passing-style (right-associatively), where all > the subsequent builders are lazily added as part of constructing the > "head" builder. > > builder = chunk1 <> (chunk2 <> (chunk3 <> (... <> chunkN)...)) > > Repeatedly appending tail chunks (effectively left-associate) is > noticeably less efficient (similar to lists). A work-around is to > instead append (Builder->Builder) endomorphisms. > > b1 = Endo (mappend chunk1) > b2 = b1 <> Endo (mappend chunk2) > b3 = b2 <> Endo (mappend chunk3) > ... > bN = ... Actually, this part is was a myth I failed to check, looking at the `Builder` code, I see that builder `mappend` is already endomorphism composition, so the extra wrapping is redundant. So use builders for output, and don't attempt to model some hybrid of builders and bytestrings. It is rather unclear what problem that is actually intended to solve. -- Viktor. From zoran.bosnjak at via.si Thu Nov 30 06:58:32 2023 From: zoran.bosnjak at via.si (Zoran =?utf-8?Q?Bo=C5=A1njak?=) Date: Thu, 30 Nov 2023 06:58:32 +0000 (UTC) Subject: [Haskell-cafe] ByteString and ByteString.Builder questions In-Reply-To: References: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> Message-ID: <163446786.5876.1701327512828.JavaMail.zimbra@via.si> Thanks for your answer. That makes sense. In particular the fact that there should be no need to read own output. However, one problem remains. Data format I am working with contains a total-length prefix. That is: 2 bytes of total length somewhere in the header of the message (header is of the fixed length). But the builder does not directly provide length. So, how do I suppose to effectively encode the message in the form: msg = header <> chunk1 <> chunk2 <> ... Should I use (Builder, Sum Int) instead of plain Builder when composing? Or data MyBuilder = MyBuilder Builder Int ... and create a Monoid instance? Or any other approach? Zoran ----- Original Message ----- From: "Viktor Dukhovni" To: "haskell-cafe" Sent: Thursday, November 30, 2023 12:27:18 AM Subject: Re: [Haskell-cafe] ByteString and ByteString.Builder questions On Wed, Nov 29, 2023 at 12:24:17PM -0500, Viktor Dukhovni wrote: > > > if I understand correctly, the ByteString.Builder is used to > > efficiently construct sequence of bytes from smaller parts. > > Best used in continuation-passing-style (right-associatively), where all > the subsequent builders are lazily added as part of constructing the > "head" builder. > > builder = chunk1 <> (chunk2 <> (chunk3 <> (... <> chunkN)...)) > > Repeatedly appending tail chunks (effectively left-associate) is > noticeably less efficient (similar to lists). A work-around is to > instead append (Builder->Builder) endomorphisms. > > b1 = Endo (mappend chunk1) > b2 = b1 <> Endo (mappend chunk2) > b3 = b2 <> Endo (mappend chunk3) > ... > bN = ... Actually, this part is was a myth I failed to check, looking at the `Builder` code, I see that builder `mappend` is already endomorphism composition, so the extra wrapping is redundant. So use builders for output, and don't attempt to model some hybrid of builders and bytestrings. It is rather unclear what problem that is actually intended to solve. -- Viktor. _______________________________________________ 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. From ietf-dane at dukhovni.org Thu Nov 30 08:07:25 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Nov 2023 03:07:25 -0500 Subject: [Haskell-cafe] ByteString and ByteString.Builder questions In-Reply-To: <163446786.5876.1701327512828.JavaMail.zimbra@via.si> References: <692421368.5734.1701258546824.JavaMail.zimbra@via.si> <163446786.5876.1701327512828.JavaMail.zimbra@via.si> Message-ID: On Thu, Nov 30, 2023 at 06:58:32AM +0000, Zoran Bošnjak wrote: > Thanks for your answer. That makes sense. In particular the fact that > there should be no need to read own output. > > However, one problem remains. Data format I am working with contains a > total-length prefix. That is: 2 bytes of total length somewhere in the > header of the message (header is of the fixed length). But the builder > does not directly provide length. I knew you'd eventually ask this question. > So, how do I suppose to effectively encode the message in the form: > > msg = header <> chunk1 <> chunk2 <> ... Take a look at my DNS Stub resolver codec: https://github.com/dnsbase/dnsbase/blob/7f381795d190ff4096095e90c34a5d3a16ef91c1/internal/Net/DNSBase/Encode/Internal/State.hs#L65-L133 and its "passLen" function: https://github.com/dnsbase/dnsbase/blob/7f381795d190ff4096095e90c34a5d3a16ef91c1/internal/Net/DNSBase/Encode/Internal/State.hs#L297-L302 -- Viktor. From P.Achten at cs.ru.nl Thu Nov 30 09:44:04 2023 From: P.Achten at cs.ru.nl (Peter Achten) Date: Thu, 30 Nov 2023 10:44:04 +0100 Subject: [Haskell-cafe] [TFP 2024 Final Call for Papers] 25th International Symposium on Trends in Functional Programming Message-ID: <1c3515ed91458c88e43958baeaf4d59e@cs.ru.nl> # TFP 2024 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers, Saturday 4 November, 2023 (AOE) Submission deadline: pre-symposium, draft papers, Friday 8 December, 2023 (AOE) Notification: pre-symposium full papers, Friday 8 December, 2023 Notification: pre-symposium draft papers, Thursday 14 December, 2023 Registration: Friday 5 January, 2024 TFPIE Workshop: Tuesday 9 January, 2024 TFP Symposium: Wednesday 10 - Friday 12 January, 2024 Submission deadline: post-symposium review, Friday 23 February, 2024 (AOE) Notification: post-symposium submissions, Friday 5 April, 2024 Camera-ready: post-symposium submissions, Friday 3 May, 2024 (AOE) The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at Seton Hall University, in South Orange, NJ in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 4, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, November 30, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 23. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2024 program chair, Jason Hemann. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, each year TFP also awards a prize for the best student paper. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are the paper's first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Authors must submit papers to: https://easychair.org/conferences/?conf=tfp24 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS Guidelines web site: https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines ## Organizing Committee Jason Hemann PC Chair Seton Hall University, USA Stephen Chang Symposium Chair University of Massachusetts Boston, USA Shajina Anand Local Arrangements Seton Hall University, South Orange, USA Peter Achten Publicity Chair Radboud University Nijmegen, Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Thu Nov 30 10:58:33 2023 From: icfp.publicity at googlemail.com (ICFP Publicity) Date: Thu, 30 Nov 2023 11:58:33 +0100 Subject: [Haskell-cafe] ICFP 2024: Call for Papers Message-ID: PACMPL Volume 7, Issue ICFP 2024 Call for Papers Accepted papers to be invited for presentation at The 29th ACM SIGPLAN International Conference on Functional Programming Milan, Italy ### Important dates (All dates are in 2023 at 11.59pm Anywhere on Earth.) Paper Submission -- Wed 28 Feb 2024 (AOE) Paper Author Response -- Mon 29 Apr 12:00 - Wed 1 May 12:00 2024 Paper Notification --Mon 20 May 2024 ### NEW THIS YEAR ------------------- * Full double blind reviewing ### Scope ------------------- PACMPL issue ICFP 2024 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modularity; components and composition; meta-programming; macros; pattern matching; type systems; type inference; dependent types; effect types; gradual types; refinement types; session types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimisation; garbage collection and memory management; runtime systems; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling; build systems; program synthesis. * Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; computational effects; continuations; control; state; names and binding; program verification. * Analysis and Transformation: control flow; data flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed systems and web programming; hardware design; databases; scientific and numerical computing; graphical user interfaces; graphics and multimedia; GPU programming; scripting; system administration; security. * Education: teaching introductory programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2024 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. In an effort to achieve a balanced, diverse program, each author may be listed as a (co)author on a maximum of four submissions. Submissions from underrepresented groups are encouraged. Authors who require financial support to attend the conference can apply for PAC funding ( http://www.sigplan.org/PAC/). The General Chair and PC Chair may not submit papers. PC members (other than the PC Chair) may submit papers. Please contact the Program Chair if you have questions or are concerned about the appropriateness of a topic. ### Full Double-Blind Reviewing Process ICFP 2024 will use a full double-blind reviewing process (similar to the one used for POPL 2024 but different from the lightweight double-blind process used in previous years). This means that identities of authors will not be made visible to reviewers until after conditional-acceptance decisions have been made, and then only for the conditionally-accepted papers. The use of full double-blind reviewing has several consequences for authors. * Submissions: Authors must omit their names and institutions from their paper submissions. In addition, references to authors’ own prior work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). * Supplementary material: Authors are permitted to provide supplementary material (e.g., detailed proofs, proof scripts, system implementations, or experimental data) along with their submission, which reviewers may (but are not required to) examine. This material may take the form of a single file, such as a PDF or a tarball. Authors must fully anonymize any supplementary material. Links to supplementary material on external websites are not permitted. * Author response: In responding to reviews, authors should not say anything that reveals their identity, since author identities will not be revealed to reviewers at that stage of the reviewing process. * Dissemination of work under submission: Authors are welcome to disseminate their ideas and post draft versions of their paper(s) on their personal website, institutional repository, or arXiv (reviewers will be asked to turn off arXiv notifications during the review period). But authors should not take steps that would almost certainly reveal their identities to members of the Program Committee, e.g., directly contacting PC members or publicizing the work on widely-visible social media or major mailing lists used by the community. The purpose of the above restrictions is to help the Program Committee and external reviewers come to a judgment about the paper without bias, not to make it impossible for them to discover the authors’ identities if they were to try. In particular, nothing should be done in the name of anonymity that weakens the quality of the submission. However, there are occasionally cases where adhering to the above restrictions is truly difficult or impossible for one reason or another. In such cases, the authors should contact the Program Chair to discuss the situation and how to handle it. ### Preparation of submissions ------------------------------- * Deadline: The deadline for submissions is Wednesday, 28 February , 2024, Anywhere on Earth (https://www.timeanddate.com/time/zones/aoe). This deadline will be strictly enforced. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper and interpretable by common PDF tools. All submissions must adhere to the “ACM Small” template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. There is a limit of 25 pages for a full paper or Functional Pearl and 12 pages for an Experience Report; in either case, the bibliography and an optional clearly marked appendix will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL’s Information and Guidelines for Authors at https://pacmpl.acm.org/authors.cfm. * Submission: Submissions will be accepted at https://icfp24.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. * Author Response Period: Authors will have a 72-hour period, starting at 12:00 (noon) AOE on Monday, 29 April, 2024, to read reviews and respond to them. * Appendix and Supplementary Material: Authors have the option to include a clearly marked appendix and/or to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at such an appendix or supplementary material. Supplementary material may be uploaded as a separate PDF document or tarball. Any supplementary material must be uploaded at submission time, not by providing a URL in the paper that points to an external repository. All supplementary material must be anonymised. * Authorship Policies: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at https://www.acm.org/publications/authors/information-for-authors. * Republication Policies: Each submission must adhere to SIGPLAN’s republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication. * ORCID: ORCID provides a persistent digital identifier (an ORCID iD) that you own and control, and that distinguishes you from every other researcher: https://orcid.org/. ACM now require an ORCID iD for every author of a paper, not just the corresponding author. So, the author who is filling out the permission form should make sure they have the ORCID iDs for all of their coauthors before filling out the form. Any authors who do not yet have an ORCID iD can go to https://orcid.org/register to have one assigned. ### Review Process ------------------- This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2024. New this year, ICFP 2024 will adapt a full double-blind reviewing process. More information see below. ICFP 2024 will have an Associate Chair who will help the PC Chair monitor reviews, solicit external expert reviews for submissions when there is not enough expertise on the committee, and facilitate reviewer discussions. PACMPL issue ICFP 2024 will employ a two-stage review process. The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. As a result of the review process, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on 20 May, 2024. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. By 11 June, 2024, the authors should provide a second revised submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can feasibly be addressed within three weeks. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. ### Information for Authors of Accepted Papers ---------------------------------------------- As a condition of acceptance, final versions of all papers must adhere to the ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: 27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report. Authors of accepted submissions will be required to agree to one of the three ACM licensing options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article Why CC-BY? published by OASPA, the Open Access Scholarly Publishers Association. The other options are copyright transfer to ACM or retaining copyright but granting ACM exclusive publication rights. PACMPL is a Gold Open Access journal, and authors are encouraged to publish their work under a CC-BY license. Gold Open Access guarantees permanent free online access to the definitive version in the ACM Digital Library, and the recommended CC-BY option also allows anyone to copy and distribute the work with attribution. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit http://www.acm.org/publications/acm-author-izer-service to learn how to create links for free downloads from the ACM DL. The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. ### Artifact Evaluation ----------------------- Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as “source materials” in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. ### Special categories of papers ------------------------------- In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. * Functional Pearls - A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much-specialised knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page and should contain the words “Functional Pearl” somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference’s acceptance rate. * Experience Reports The purpose of an Experience Report is to describe the experience of using functional programming in practice, whether in industrial application, tool development, programming education, or any other area. Possible topics for an Experience Report include, but are not limited to: - insights gained from real-world projects using functional programming - comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum - project-management, business, or legal issues encountered when using functional programming in a real-world project - curricular issues encountered when using functional programming in education - real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. Both in the papers and in any citations, the title of each accepted Experience Report must end with the words “(Experience Report)” in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. Experience Report submissions can be at most 12 pages long, excluding bibliography. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience Reports may be asked to give shorter talks. Because the purpose of Experience Reports is to enable our community to understand the application of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the report describes an illuminating experience with functional programming, or provides evidence for a clear thesis about the use of functional programming. The experience or thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the paper to illuminate some aspect of the use of functional programming. Anecdotal evidence will be acceptable provided it is well-argued and the author explains what efforts were made to gather as much evidence as possible. Typically, papers that show how functional programming was used are more convincing than papers that say only that functional programming was used. It can be especially effective to present comparisons of the situations before and after the experience described in the paper, but other kinds of evidence would also make sense, depending on context. Experience drawn from a single person’s experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point. For an industrial project, it should make a claim about how well functional programming worked and why; for a pedagogy paper, it might make a claim about the suitability of a particular teaching style or educational exercise. Either way, it should produce evidence to substantiate the claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarise the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the experience and its implementation, but the paper should characterise it and its context well enough so that readers can judge to what degree this experience is relevant to their own circumstances. The paper should take care to highlight any unusual aspects; specifics about the experience are more valuable than generalities about functional programming. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The Program Chair will be happy to advise on any concerns about which category to submit to. ### About PACMPL ---------------- Proceedings of the ACM on Programming Languages (PACMPL https://pacmpl.acm.org/) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicised Calls for Papers, like this one. ### ICFP Organisers General Chair: Marco Gaboardi (Boston University, USA) Programme Chair: Brigitte Pientka (McGill University, Canada) Associate Programme Chair: Gabriele Keller (Utrecht University, Netherlands) Publicity Chair: Ilya Sergey (National University of Singapore, Singapore) Programme Committee: https://icfp24.sigplan.org/committee/icfp-2024-papers-icfp-papers-and-events ----------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Thu Nov 30 13:37:47 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 30 Nov 2023 13:37:47 +0000 Subject: [Haskell-cafe] Does the constraints library give (a :- b) -> Dict (a |- b)? Message-ID: The constraints library [1] has implied :: forall a b. (a => b) => a :- b from which I can obtain implied' :: Dict (a |- b) -> a :- b implied' Dict = implied but can I get the converse of this, that is coimplied :: (a :- b) -> Dict (a |- b) coimplied = error "Can it be done?" I don't see how. The library itself only mentions "|-" in its definition. Would this combinator violate some guarantee that's essential for the safe use of type classes? I'm a bit confused why the same library allows abstraction over type variables with forall_[2] forall_ :: (forall a. Dict (p a)) -> Dict (Forall p) but not abstraction over "term" variables (i.e. of kind Constraint), as in coimplied. Alternatively, can someone help me achieve my goal another way? That is, I need to be able to dischange the quantified constraint forall i. T0 i => T2 i given that I can already discharge the constraint forall i. T1 i => T2 i and I have available the value forall i. T0 i => Dict (T1 i) >From the latter I can easily get forall i. T0 i :- T1 i But without coimplied I don't know how to proceed. Thanks, Tom [1] https://hackage.haskell.org/package/constraints-0.14/docs/Data-Constraint-Forall.html [2] https://hackage.haskell.org/package/constraints-0.14/docs/Data-Constraint-Forall.html#v:forall_ From noonsilk at gmail.com Thu Nov 30 13:46:30 2023 From: noonsilk at gmail.com (Noon van der Silk) Date: Thu, 30 Nov 2023 13:46:30 +0000 Subject: [Haskell-cafe] Strange quirk with {} syntax? Message-ID: Sometimes I have a type like: data A = A1 Int | A2 Int Int Then if I want to do pattern matching and ignore the parameters I do: f (A1 _) = .. f (A2 _ _) = ... But that's annoying; I need to remember how many parameters each one has! Yesterday I learned I can just do this: f A1 {} = ... f A2 {} = ... And GHC is happy. Is this expected? Am I the last to learn about this trick? -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaro.reinders at gmail.com Thu Nov 30 13:58:28 2023 From: jaro.reinders at gmail.com (J. Reinders) Date: Thu, 30 Nov 2023 14:58:28 +0100 Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: References: Message-ID: I’ve known it for a while and use it now and then. There are quite a few packages on Hackage that use it: https://hackage-search.serokell.io/?q=%5BA-Z%5D%5Ba-zA-Z0-9%27_%5D*%5Cs%2B%5C%7B%5C%7D > On 30 Nov 2023, at 14:46, Noon van der Silk wrote: > > Sometimes I have a type like: > > data A = A1 Int | A2 Int Int > > Then if I want to do pattern matching and ignore the parameters I do: > > f (A1 _) = .. > f (A2 _ _) = ... > > But that's annoying; I need to remember how many parameters each one has! > > Yesterday I learned I can just do this: > > f A1 {} = ... > f A2 {} = ... > > And GHC is happy. > > Is this expected? Am I the last to learn about this trick? > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > _______________________________________________ > 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. From kane at kane.cx Thu Nov 30 13:58:43 2023 From: kane at kane.cx (David Kraeutmann) Date: Thu, 30 Nov 2023 14:58:43 +0100 Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: References: Message-ID: <490dd003-4626-461a-9937-3c6547a544c7@kane.cx> Yes. You're just using record pattern match with no records. Why would it be unexpected? On 30.11.2023 14:46, Noon van der Silk wrote: > Sometimes I have a type like: > >     data A = A1 Int | A2 Int Int > > Then if I want to do pattern matching and ignore the parameters I do: > >     f (A1 _) = .. >     f (A2 _ _) = ... > > But that's annoying; I need to remember how many parameters each one has! > > Yesterday I learned I can just do this: > >     f A1 {} = ... >     f A2 {} = ... > > And GHC is happy. > > Is this expected? Am I the last to learn about this trick? > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Thu Nov 30 14:06:00 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 30 Nov 2023 14:06:00 +0000 Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: <490dd003-4626-461a-9937-3c6547a544c7@kane.cx> References: <490dd003-4626-461a-9937-3c6547a544c7@kane.cx> Message-ID: It was unexpected to me because A1 and A2 were not defined as record constructors. (Since I discovered it I now use it regularly; it's very nice.) On Thu, Nov 30, 2023 at 02:58:43PM +0100, David Kraeutmann wrote: > Yes. You're just using record pattern match with no records. Why would it be > unexpected? > > On 30.11.2023 14:46, Noon van der Silk wrote: > > Sometimes I have a type like: > > > >     data A = A1 Int | A2 Int Int > > > > Then if I want to do pattern matching and ignore the parameters I do: > > > >     f (A1 _) = .. > >     f (A2 _ _) = ... > > > > But that's annoying; I need to remember how many parameters each one has! > > > > Yesterday I learned I can just do this: > > > >     f A1 {} = ... > >     f A2 {} = ... > > > > And GHC is happy. > > > > Is this expected? Am I the last to learn about this trick? From noonsilk at gmail.com Thu Nov 30 14:08:20 2023 From: noonsilk at gmail.com (Noon van der Silk) Date: Thu, 30 Nov 2023 14:08:20 +0000 Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: References: <490dd003-4626-461a-9937-3c6547a544c7@kane.cx> Message-ID: Yes I agree with Tom; it's at least a bit unexpected because unlike with records, there is (if I understand well) nothing I can write inside the {} that would actually be valid for that type. On Thu, 30 Nov 2023 at 14:06, Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > It was unexpected to me because A1 and A2 were not defined as record > constructors. (Since I discovered it I now use it regularly; it's > very nice.) > > On Thu, Nov 30, 2023 at 02:58:43PM +0100, David Kraeutmann wrote: > > Yes. You're just using record pattern match with no records. Why would > it be > > unexpected? > > > > On 30.11.2023 14:46, Noon van der Silk wrote: > > > Sometimes I have a type like: > > > > > > data A = A1 Int | A2 Int Int > > > > > > Then if I want to do pattern matching and ignore the parameters I do: > > > > > > f (A1 _) = .. > > > f (A2 _ _) = ... > > > > > > But that's annoying; I need to remember how many parameters each one > has! > > > > > > Yesterday I learned I can just do this: > > > > > > f A1 {} = ... > > > f A2 {} = ... > > > > > > And GHC is happy. > > > > > > Is this expected? Am I the last to learn about this trick? > _______________________________________________ > 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. -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness." -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Thu Nov 30 14:11:37 2023 From: byorgey at gmail.com (Brent Yorgey) Date: Thu, 30 Nov 2023 08:11:37 -0600 Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: References: Message-ID: Yes, you're the last to learn about it; we were all wondering when you would figure it out. ;-) It's definitely "folklore", I can't remember where I first learned about it. I agree with Tom that it's surprising (but nice) that it works even with data types that were not declared using record syntax. I also always find it surprising that record update or matching binds more tightly than function application, so that no parentheses are needed. Sometimes I feel like it would actually look nicer to write f (A1 {}) = ... but then hlint yells at me. (Yes, I'm aware I can turn off individual hlint warnings. =) -Brent On Thu, Nov 30, 2023 at 7:47 AM Noon van der Silk wrote: > Sometimes I have a type like: > > data A = A1 Int | A2 Int Int > > Then if I want to do pattern matching and ignore the parameters I do: > > f (A1 _) = .. > f (A2 _ _) = ... > > But that's annoying; I need to remember how many parameters each one has! > > Yesterday I learned I can just do this: > > f A1 {} = ... > f A2 {} = ... > > And GHC is happy. > > Is this expected? Am I the last to learn about this trick? > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Thu Nov 30 14:32:56 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 30 Nov 2023 14:32:56 +0000 Subject: [Haskell-cafe] Does the constraints library give (a :- b) -> Dict (a |- b)? In-Reply-To: References: Message-ID: On Thu, Nov 30, 2023 at 01:37:47PM +0000, Tom Ellis wrote: > The constraints library [1] has > > implied :: forall a b. (a => b) => a :- b > > from which I can obtain > > implied' :: Dict (a |- b) -> a :- b > implied' Dict = implied > > but can I get the converse of this, that is > > coimplied :: (a :- b) -> Dict (a |- b) > coimplied = error "Can it be done?" > > I don't see how. The library itself only mentions "|-" in its > definition. Would this combinator violate some guarantee that's > essential for the safe use of type classes? It seems this question has been asked at least a couple of times of the GHC bug tracker, firstly in https://gitlab.haskell.org/ghc/ghc/-/issues/14822 where it was deemed unsound (I don't understand why) and again in https://gitlab.haskell.org/ghc/ghc/-/issues/14937 where it remains open without having explicitly been deemed unsound. Tom From mmcconnell17704 at yahoo.com Thu Nov 30 15:39:04 2023 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Thu, 30 Nov 2023 15:39:04 +0000 (UTC) Subject: [Haskell-cafe] Strange quirk with {} syntax? In-Reply-To: References: Message-ID: <1300672878.5390457.1701358744777@mail.yahoo.com> Like others, this caught me by surprise, but now I use it regularly. I use hlint to advise me on the quality of my Haskell code.  I have learned many, many good ideas from hlint. As of a few years ago, hlint begins to recommend changing f (A3 _ _ _) = ... to f A3 {} = ... as soon as there are three or more components. On Thursday, November 30, 2023 at 09:12:09 AM EST, Brent Yorgey wrote: Yes, you're the last to learn about it; we were all wondering when you would figure it out. ;-) It's definitely "folklore", I can't remember where I first learned about it.  I agree with Tom that it's surprising (but nice) that it works even with data types that were not declared using record syntax.  I also always find it surprising that record update or matching binds more tightly than function application, so that no parentheses are needed.  Sometimes I feel like it would actually look nicer to write  f (A1 {}) = ... but then hlint yells at me.  (Yes, I'm aware I can turn off individual hlint warnings. =) -Brent On Thu, Nov 30, 2023 at 7:47 AM Noon van der Silk wrote: Sometimes I have a type like:     data A = A1 Int | A2 Int Int Then if I want to do pattern matching and ignore the parameters I do:     f (A1 _) = ..    f (A2 _ _) = ... But that's annoying; I need to remember how many parameters each one has! Yesterday I learned I can just do this:     f A1 {} = ...    f A2 {} = ... And GHC is happy. Is this expected? Am I the last to learn about this trick? -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness."_______________________________________________ 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. _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Thu Nov 30 18:33:25 2023 From: abela at chalmers.se (Andreas Abel) Date: Thu, 30 Nov 2023 19:33:25 +0100 Subject: [Haskell-cafe] [ANNOUNCE] Agda 2.6.4.1 In-Reply-To: References: Message-ID: Dear all, The Agda Team is pleased to announce Agda 2.6.4.1. Agda 2.6.4.1 is a minor release of Agda 2.6.4 featuring a few changes: - Make recursion on proofs legal again (regression in 2.6.4). - Improve performance, e.g. by removing debug printing unless built with cabal flag `debug`. - Switch to XDG directory convention. - Reflection: change to order of results returned by `getInstances`. - Fix some internal errors. - Fix some issues with `opaque`. # GHC supported versions Agda 2.6.4.1 has been tested with GHC 9.8.1, GHC 9.6.3, 9.4.7, 9.2.8, 9.0.2, 8.10.7, 8.8.4 and 8.6.5 on Linux, macOS and Windows. # Installation Agda 2.6.4.1 can be installed using cabal-install or stack: 1. Getting the tarball $ cabal update $ cabal get Agda-2.6.4.1 $ cd Agda-2.6.4.1 2. a. Using cabal-install $ cabal install -f +optimise-heavily -f +enable-cluster-counting 2. b. Using stack $ stack --stack-yaml stack-a.b.c.yaml install --flag Agda:optimise-heavily --flag Agda:enable-cluster-counting replacing `a.b.c` with your version of GHC. The flags mean: - optimise-heavily: Turn on extra optimisation for a faster Agda. Takes large resources during compilation of Agda. - enable-cluster-counting: Enable unicode clusters for alignment in the LaTeX backend. Requires the ICU lib to be installed and known to pkg-config. These flags can be dropped from the install if causing trouble. # Standard library You can use standard library v1.7.3 or v2.0 (soon to be released) of the standard library with Agda 2.6.4.1. # Fixed issues over Agda 2.6.4 https://hackage.haskell.org/package/Agda-2.6.4.1/changelog Enjoy Agda! Andreas, on behalf of the Agda Team -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/