Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
I chose the most available non-ASCII character I could find. Set the criterion to be present in most ISO 8-bit character sets and there are really only two candidates, section sign and degrees sign. ... Brilliant! We'll use degrees sign for function composition (so that it follows the convention in everything except a handful of obscure programming languages). That frees up dot for record.field. And still we can scratch our heads for something to do with section sign. SS as in set? Some smoother syntax for swifter, saner, salubrious setting. Super! AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 1/02/2012, at 11:38 AM, AntC wrote: As soon as you decide to make 'virtual record selectors' just ordinary functions (so they select but not update) , then you can see that field names are also just ordinary functions (for selection purposes). So the semantics for field 'selection' (whether or not you use dot notation) is just function application. So Type-Directed Name resolution is just instance resolution. So it all gets much easier. Richard O'Keefe wrote: ... Making f x and x.f the same is pretty appealing, but it is imaginable that the former might require importing the name of f from a module and the latter might not. That is to say, it lets f and .f have completely different meanings. Oh the joy! Oh the improved readability! -- on some other planet, maybe. Hi Richard, I'm not sure I understand what you're saying. I'm proposing x.f is _exactly_ f x. That is, the x.f gets desugared at an early phase in compilation. If the one needs importing some name from a module, than so does the other. A 'one-sided dot doesn't mean anything. (Also, I feel vaguely nauseous even seeing it written down.) Under my proposal, the only thing .f could mean is: \z - z.f which desugars to \z - f z which means (by eta-reduction) f And to complete the story: the only thing (x.) could mean is: \g - x.g So a use like: (x.) f-- or z f, where z = (x.) would desugar to f x which is the same as x.f A use like (x.)f (no spaces around the parens) would amount to the same thing. This is all so weird I'm inclined to say that one-sided dot is probably a syntax error, and reject it. It's too dangerously ambiguous between the syntax for 'proper' dot notation and function composition. Or is there something I'm not understanding? [Good to see another NZ'er on the list, by the way.] AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name
There is an effort underway to make Haskell's Records better. The discussion is ongoing on the ghc-users mail list, ... in the direction of making the most minimal changes possible to achieve some simple record name-spacing. Thanks, Greg Weber Thank you Greg, Yes I know, and I have been trying to follow along (intermittently). Thank you for your attempts to marshall the discussion. What would really, really help me is for someone to have a look at the 'solution' I posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to Steve.) It seemed from my testing to address the needs. Since I got it working in GHC 7.2.1, there's a good chance it will need only minimal changes to implement (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and generalisable enough. It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ used, but wasn't available to me at the time). I keep trying to make the time to write up the full proposal on the Wiki. I see it as a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to make time until/unless someone else double-checks whether I'm barking up the wrong tree. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: group-by (Was: Nested guards?)
Henning Thielemann lemming at henning-thielemann.de writes: On Fri, 7 Dec 2007, Simon Peyton-Jones wrote: | And I think that the solution is not to make the language larger and larger | everytime someone wants a feature but to give people the tools to provide | features without language changes. Of course that would be even better! (Provided of course the resulting programs were comprehensible.) Haskell is already pretty good in this respect, thanks to type classes, higher order functions, and laziness; that's why it's so good at embedded domain-specific languages. When I learned about GROUP BY and HAVING in SQL with its rules about what is allowed in GROUP BY and SELECT I considered GROUP BY a terrible hack, that was just introduced because the SQL people didn't want to allow types different from TABLE, namely lists of tables. I try to convince my data base colleagues that GROUP BY can nicely be handled in relational algebra by allowing sets of sets and that this is a fine combinatorial approach. I [snip] I agree with Henning that HAVING is a 'terrible hack', but then SQL altogether is a terrible hack. I would expect the Haskell approach to be based on the much sounder theoretical principles of Relational Algebra, and I applaud that Wadler+SPJ's 'Comprehensive Comprehensions' restricts itself to a subset of SQL that corresponds to Relational Algebra. In that context, GROUP BY is reasonably well-defined as a mapping from a table to a table. (The hack in SQL vintage 1975 is in trying to squeeze GROUP BY into the structure of SELECT ... FROM ... WHERE ..., the mess now can be blamed on trying to preserve backwards compatability.) As that paper points out, HAVING is unnecessary - it's just a filter on the result set of group-by. And relational theorists agree that HAVING is unneccessary (see for example 'The Importance of Column Names', Hugh Darwen 2003 from www.thethirdmanifesto.com). It's crucial that in Relational Algebra everything is a table. (See Codd's 12 rules). The result of GROUP BY we might want to pass to another GROUP BY, or JOIN to another table, etc -- or does Henning propose a hierarchy of sets of sets ... of tables, presumably with a hierarchy of HAVINGHAVING's? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is this haskelly enough? -- errm but every answer is wrong(?)
(Or at least the problem is under-specified.) 1. There may be several sub-sequences having the maximum sum. So the type for the solution should be :: Num a = [a] - [[a]] (Note that the problem didn't ask for the maximum itself.) 2. The inits . tails approach adds a fault: It introduces a sprinkling of empty sub-sequences. These have sum zero. So in case the input list is all negative numbers ... Being a software tester for my day job, I looked first not for an elegant and/or efficient solution; but for where to stretch the boundaries of the problem. However, the key point is that this is a TRICK QUESTION. snip ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
