Re: ORF for fields of higher-ranked type [was: TDNR without new operators or syntax changes]

On 15/06/16 04:29, AntC wrote: > ... > > The earlier design for SORF tried to support higher-ranked fields. > https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/SORF > > That had to be abandoned, > until explicit type application was available IIRC. > > We now have type

ORF for fields of higher-ranked type [was: TDNR without new operators or syntax changes]

> Adam Gundry writes: > ... Having spent more time thinking about record field overloading > than perhaps I should, ... Thanks Adam, another thing on the back burner ... The earlier design for SORF tried to support higher-ranked fields.

Re: TDNR without new operators or syntax changes

with disambiguation. There is some overlap, but it is a different solution for different requirements. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836818.html Sent from the Haskell - Glasgow-haskell

Re: TDNR without new operators or syntax changes

> Evan Laforge gmail.com> writes: > > That's why I was trying to emphasize "not an operator". > TDNR is complicated because ... >> Peter voldermort writes: >> A slightly more refined definition for disambiguation: ... Hi Evan, Peter, (and even James), I'm not seeing you're proposing anything

Re: TDNR without new operators or syntax changes

On Sat, May 28, 2016 at 3:13 AM, AntC wrote: >> Evan Laforge gmail.com> writes: > >> ... what would happen if you tried to do records >> just like C structs? So e.g. a•b requires 'a' to be a record with a >> 'b' field, and is just one identifier, no functions

Re: TDNR without new operators or syntax changes

(although it may require two passes to disambiguate on the inferred type of an argument), and disambiguating one name will not depend on disambiguating any other name. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes

Re: TDNR without new operators or syntax changes

> Evan Laforge gmail.com> writes: > ... what would happen if you tried to do records > just like C structs? So e.g. a•b requires 'a' to be a record with a > 'b' field, and is just one identifier, no functions involved, and 'b' > is not a separate value. Hi Evan, um, that's the original TDNR

Re: TDNR without new operators or syntax changes

As long as were back on this topic again (sort of), and just to satisfy my curiousity, what would happen if you tried to do records just like C structs? So e.g. a•b requires 'a' to be a record with a 'b' field, and is just one identifier, no functions involved, and 'b' is not a separate value. I

Re: TDNR without new operators or syntax changes

> Dan Doel gmail.com> writes: > >> On Thu, May 26, 2016 at 5:14 AM, Peter hotmail.com> wrote: >> Solving for everything but f, we get f :: T -> Int. > > So TDNR happens for things in function position (applied to something). Before we get carried away, TDNR doesn't happen at all. You're

Re: TDNR without new operators or syntax changes

On Thu, May 26, 2016 at 5:14 AM, Peter wrote: > Solving for everything but f, we get f :: T -> Int. So TDNR happens for things in function position (applied to something). > Solving for everything but f, we get f :: T -> Int. So TDNR happens for things in argument

Re: TDNR without new operators or syntax changes

:: Int > i3 = f v May not be solvable, would fail to disambiguate. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836657.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

Re: TDNR without new operators or syntax changes

As a supplement, here's a series of definitions to think about. The question is: what should happen in each section, and why? The more detailed the answer, the better. Definitions from previous sections are in scope in subsequent ones, for convenience. The examples are arranged in a slippery

Re: TDNR without new operators or syntax changes

Thanks for starting this discussion! Having spent more time thinking about record field overloading than perhaps I should, here are some things to think about... On 22/05/16 16:01, Jeremy wrote: > Bertram Felgenhauer-2 wrote >>> 1. If the compiler encounters a term f a, and there is more than

Re: TDNR without new operators or syntax changes

iven time, then you need special treatment for > unambiguous names or even trivial programs will fail to type-check, just > as Anthony said. Why special treatment for unambiguous names? They shouldn't be effected at all by this. -- View this message in context: http://haskell.1045720.n5.n

Re: TDNR without new operators or syntax changes

essage in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836376.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-h

Re: TDNR without new operators or syntax changes

On Sun, 22 May 2016, Jeremy . wrote: 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if

Re: TDNR without new operators or syntax changes

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the

Re: TDNR without new operators or syntax changes

> Bertram Felgenhauer googlemail.com> writes: > ... > I don't understand your conclusion. Hi Bertram, I'm trying to tease out of Jeremy, what he thinks his proposal amounts to. Seeing as he's given very little clue so far. So if I've arrived at an incorrect conclusion, I want him to tell me

Re: TDNR without new operators or syntax changes

AntC wrote: > > > > With syntaxless TDNR enabled, the last line could be: > > > > f b c = do { reset b; reset c } > > > > Heck, I didn't think you meant something that radical. > So bare name in a function application context is to need disambiguating. > > I think you'll find rather a lot

Re: TDNR without new operators or syntax changes

> Jeremy hotmail.com> writes: > > AntC wrote > > I think you'll find rather a lot of those in existing code. > > So this is a code-breaking change. > > Could you give an example of existing code that would break? > This certainly wasn't what I had in mind. Then what do you have in mind? "Do

Re: TDNR without new operators or syntax changes

m/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836060.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/m

Re: TDNR without new operators or syntax changes

isting code. So this is a code-breaking change. The merit of adding an extension via new syntax, is that in the places you didn't and don't use the syntax, nothing breaks. Note that currently if you have in scope both a bare name and that same name qualified, the bare name applies, the c

Re: TDNR without new operators or syntax changes

AntC wrote > No. For TDNR GHC needs some syntactic signal to trigger disambiguation. > ... > I suspect that if you took the syntax away from TDNR, you'd have very > little left. To copy an example from the TDNR wiki page: module Foo where import Button( Button, reset ) as

Re: TDNR without new operators or syntax changes

t; accompanying proposal to change the syntax of the dot or add a new operator > for postfix application. > > However, nothing about TDNR - other than certain motivating examples - > actually requires changes to the syntax of Haskell or new operators. ... You are possibly confusing pa

TDNR without new operators or syntax changes

Previous attempts to propose TDNR [1] have met with opposition over the accompanying proposal to change the syntax of the dot or add a new operator for postfix application. However, nothing about TDNR - other than certain motivating examples - actually requires changes to the syntax of Haskell

RE: status of rebindable syntax for arrows

| It already has a bug entry: #7828. What would help is to know the | kind of use you have in mind, to see whether it fits with the proposed | solution. Indeed. Moreover #7828 is stalled; it needs some arrow-savvy person to focus cycles on it. If rebindable syntax for arrows is considered

status of rebindable syntax for arrows

The GHC manual already for quite a number of version states: • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude

Re: status of rebindable syntax for arrows

On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote: The GHC manual already for quite a number of version states: • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (), first, app, (|||) and loop functions are in scope. But unlike the

Re: Permitting trailing commas for record syntax ADT declarations

To be fair, I'm not sure I like the make-commas-optional approach either. But, the solution occurred to me as possible, so I thought it was worth considering as we're exploring the design space. And, yes, I was suggesting only to make them optional, not to require everyone remove them.

Re: Permitting trailing commas for record syntax ADT declarations

Not a concrete suggestion, but just a related data point / nod to the sanity of the suggestion: I'm not sure I'd remove them entirely either, but FWIW, we don't require commas in fixity declarations in Ermine and it works well. On the other hand, our import lists are rather more complicated than

Re: Permitting trailing commas for record syntax ADT declarations

Richard Eisenberg e...@cis.upenn.edu writes: What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing. +1 John ___ Glasgow-haskell-users mailing list

Re: Permitting trailing commas for record syntax ADT declarations

That would be nice if we had a clean slate, but I don't people are going to change their whole import lists now. Adding a comma at the end is less disruptive. On Fri, Sep 26, 2014 at 11:06 PM, John Wiegley jo...@newartisans.com wrote: Richard Eisenberg e...@cis.upenn.edu writes: What if we

Re: Permitting trailing commas for record syntax ADT declarations

On Fri, Sep 26, 2014 at 5:12 PM, Johan Tibell johan.tib...@gmail.com wrote: That would be nice if we had a clean slate, but I don't people are going to change their whole import lists now. I read the proposal as making all commas optional, not as requiring them to not be present. -- brandon

Re: Permitting trailing commas for record syntax ADT declarations

I don't think that's necessarily is good style. I don't think we want two different ways of doing import lists. The original proposal was to address a quite small but important engineer issue: without allow *one* trailing comma your version control history gets messed up, because the wrong person

Re: Permitting trailing commas for record syntax ADT declarations

On Fri, Sep 26, 2014 at 5:21 PM, Johan Tibell johan.tib...@gmail.com wrote: I don't think that's necessarily is good style. I don't think we want two different ways of doing import lists. Yes; I kinda hate the idea myself, it encourages an unreadable programming style. But it's not the

RE: Concrete syntax for open type kind?

Is it possible to do so with any sort of concrete syntax? I’m afraid not. And I’m strongly disinclined to add it because we’d then just delete it again. Are you really really stuck? S From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott

Re: Concrete syntax for open type kind?

way around in the process. -- Conal On Mon, Apr 21, 2014 at 12:20 AM, Simon Peyton Jones simo...@microsoft.comwrote: Is it possible to do so with any sort of concrete syntax? I’m afraid not. And I’m strongly disinclined to add it because we’d then just delete it again. Are you really

Re: Concrete syntax for open type kind?

, somewhat clumsily, of no open kinds if I could make a definition polymorphic over unlifted kinds, e.g., foo :: # foo = error foo? Is it possible to do so with any sort of concrete syntax? -- Conal On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones simo...@microsoft.comwrote: Does anyone

Re: Concrete syntax for open type kind?

Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. Too bad it's not possible to replicate this type interpretation of `error` and `undefined`. I'm doing some Core transformation, and I have a polymorphic function (reify) that I want to apply to expressions of lifted and unlifted

RE: Concrete syntax for open type kind?

time to do these things. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 16 April 2014 18:01 To: Richard Eisenberg Cc: glasgow-haskell-users@haskell.org Subject: Re: Concrete syntax for open type kind? Oops! I was reading

Concrete syntax for open type kind?

I see ‘#’ for unlifted and ‘?’ for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind

Re: Concrete syntax for open type kind?

What version of the GHC code are you looking at? The parser is currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn’t have these lines. As far as I know, there is no way to refer to OpenKind from source. You’re absolutely right about the type of `undefined`. `undefined` (and

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

evaluates to MkT (f - True) Hello ? I guess they are not allowed, but if they are allowed, I do not know how their types can be expressed in the syntax you proposed. Best regards, Tsuyoshi ___ Glasgow-haskell-users mailing list Glasgow-haskell-users

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

and whatever syntax is eventually agreed upon, it shouldn't use the function type notation. By the way, do you allow higher-order pattern functions such as pattern Q p - p Hello with which Q P evaluates to MkT (f - True) Hello ? I guess they are not allowed, but if they are allowed, I do

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

Dear Gergo, Thank you for your prompt reply. Now the ordering makes sense. To be honest, I still find it a little confusing even after knowing that the order is logical, but maybe it is just a matter of getting used to it. Also thank you for the clarification that higher-order pattern

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

: I don't think that syntax is good, it's just the best we've come up with so far:) And the problem is exactly this, that it's not intuitive at all. One source of solace might be that 'provided' contexts will only pop up when you use GADTs with typeclass-constrained constructors, so for less

Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

, some syntax will be needed for pattern synonym type signatures so that at least there's something to generate into the docs. The basic problem with pattern synonyms in this regard is that their type is fully described by the following five pieces of information: 1, Universially bound type

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

are usable only as patterns, whereas bidirectional ones can also be used as expressions. For example: pattern Single x = [x] pattern Second x - (_:x:_) in this example, `Single` is bidirectional and `Second` is unidirectional. As you can see, this is indicated by syntax in the definition

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

Other than being A. displayed in the Haddocks will this syntax also, now or at any later point, be B. explicitly written by the programmer alongside the definition of the pattern, or C. used as a type argument for other types? If it's only A and B, perhaps abominations like these could

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

On Sun, 22 Dec 2013, Jacques Carette wrote: Since the first is an iso, why not pattern Single :: t a ~ [ a ] or pattern Single :: t a - [ a ] ? [I definitely prefer the first] Or is your 'type' for Single somehow different than my guess? the type of Single would be 'a - [a]', as in: in an

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

On Sun, 22 Dec 2013, Gábor Lehel wrote: Other than being  A. displayed in the Haddocks will this syntax also, now or at any later point, be  B. explicitly written by the programmer alongside the definition of the pattern, or  C. used as a type argument for other types? A and B. If it's

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

On Sun, 22 Dec 2013, Jacques Carette wrote: pattern P :: (Show t) = ( (Num t, Eq b) = b - T t ) perhaps? Given 'Show t', you get what's on the rhs of the first = ? I like this one; in fact, I originally wanted to go with something like that. But unfortunately, this type is already valid and

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

I'm not 100% sure what that 't' in 'P t' is supposed to be in your example. 'P' is not like a type constructor at all; it's a lot more like a data constructor. Thinking further about it, I think this could work, using a syntax similar to data constructor definitions instead of sticking

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

- T t I'm not 100% sure what that 't' in 'P t' is supposed to be in your example. 'P' is not like a type constructor at all; it's a lot more like a data constructor. Thinking further about it, I think this could work, using a syntax similar to data constructor definitions instead

Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types

On Mon, 23 Dec 2013, Carter Schonwald wrote: i'm confused, are these types ever human writeable?  Yes, this syntax is meant to be also used for giving human-written type signatures for pattern synonym definitions. If not, are they meant to be an operational way of communicating how

Re: [Haskell-cafe] Proposal: New syntax for Haskell

A specification language is desirable. (Test cases are special cases of specifications. Test-driven development is a revival of the waterfall process.) For specifying interactions (computer-computer or computer-human), I recommend live sequence charts of David Harel, or generally any one based

Re: [Haskell-cafe] Proposal: New syntax for Haskell

cucumber test that describes the system in an intuitive manner with zero line noise (programming language syntax). I am now free to think about implementation details, write lower level unit tests and implement things that can be described in much less verbose fashion. I really like that process

Re: [Haskell-cafe] Proposal: New syntax for Haskell

Honestly, I've not. Worth looking at, probably. On Thu, Sep 12, 2013 at 3:42 PM, Bob Ippolito b...@redivi.com wrote: Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's easy to read. On Thursday, September 12, 2013, David Thomas wrote: I've long been interested in

Re: [Haskell-cafe] Proposal: New syntax for Haskell

My problem with cucumber is not the idea of a high-level DSL for tests. Au contraire--I think this is a perfect place for a little language. I could easily see a similar tool being useful for Haskell. Rather, my issue is with the syntax. Not gherkin in particular but rather languages that try

Re: [Haskell-cafe] Proposal: New syntax for Haskell

+1 Cucumber seems to be great if you mainly want to read your code over the telephone, distribute it via national radio broadcast, or dictate it to your secretary or your voice recognition software. You can program thus without having to use you fingers. You can lie on your back on your sofa,

Re: [Haskell-cafe] Proposal: New syntax for Haskell

I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful. On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote: ** +1 Cucumber seems to be great if

Re: [Haskell-cafe] Proposal: New syntax for Haskell

On Thu, Sep 12, 2013 at 6:00 PM, David Thomas davidleotho...@gmail.comwrote: I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful.

Re: [Haskell-cafe] Proposal: New syntax for Haskell

Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's easy to read. On Thursday, September 12, 2013, David Thomas wrote: I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is

[Haskell-cafe] Proposal: New syntax for Haskell

Impressed by the productivity of my Ruby-writing friends, I have recently come across Cucumber: http://cukes.info It is a great tool for specifying tests and programs in natural language, and especially easy to learn for beginners. I propose that we add a Cucumber syntax for Haskell

Re: [Haskell-cafe] Proposal: New syntax for Haskell

Niklas Hambüchen m...@nh2.me writes: Code written in cucumber syntax is concise and easy to read concise |kənˈsīs|, adj. giving a lot of information clearly and in a few words; brief but comprehensive. Compare: Scenario: Defining the function foldl Given I want do

Re: [Haskell-cafe] Proposal: New syntax for Haskell

I think the normal motivation for cucumber syntax is that it is a way to communicate requirements with non-technical people. On Tue, Sep 10, 2013 at 11:48 AM, John Wiegley jo...@fpcomplete.com wrote: Niklas Hambüchen m...@nh2.me writes: Code written in cucumber syntax is concise and easy

Re: [Haskell-cafe] Proposal: New syntax for Haskell

It is a great tool for specifying tests and programs in natural language, and especially easy to learn for beginners. I propose that we add a Cucumber syntax for Haskell, with the extension .chs, next to .hs and .lhs. Code written in cucumber syntax is concise and easy to read: You

Re: [Haskell-cafe] Proposal: New syntax for Haskell

To be exact, the syntax is Gherkin not cucumber. https://github.com/cucumber/cucumber/wiki/Gherkin And, there's already a library to run specs written in Gherkin. https://github.com/marcotmarcot/chuchu On Tue, Sep 10, 2013 at 7:08 PM, Edward Z. Yang ezy...@mit.edu wrote: This is completely

Re: [Haskell-cafe] Proposal: New syntax for Haskell

On Sep 10, 2013 3:25 PM, AlanKim Zimmerman alan.z...@gmail.com wrote: I think the normal motivation for cucumber syntax is that it is a way to communicate requirements with non-technical people. +1 On Tue, Sep 10, 2013 at 11:48 AM, John Wiegley jo...@fpcomplete.com wrote: Niklas Hambüchen

Re: [Haskell-cafe] Proposal: New syntax for Haskell

* John Wiegley jo...@fpcomplete.com [2013-09-10 04:48:36-0500] Niklas Hambüchen m...@nh2.me writes: Code written in cucumber syntax is concise and easy to read concise |kənˈsīs|, adj. giving a lot of information clearly and in a few words; brief but comprehensive

Re: [Haskell-cafe] Proposal: New syntax for Haskell

syntax is concise and easy to read concise |kənˈsīs|, adj. giving a lot of information clearly and in a few words; brief but comprehensive. Compare: Scenario: Defining the function foldl Given I want do define foldl Which has the type (in brackets

Re: [Haskell-cafe] Proposal: New syntax for Haskell

Wiegley jo...@fpcomplete.com [2013-09-10 04:48:36-0500] Niklas Hambüchen m...@nh2.me writes: Code written in cucumber syntax is concise and easy to read concise |kənˈsīs|, adj. giving a lot of information clearly and in a few words; brief but comprehensive. Compare

Re: [Haskell-cafe] Proposal: New syntax for Haskell

The syntax is actually used by non-technical people to write tests. Using it to write Haskell code is a joke. (Using it for business specification is not, even if for technical people this seems overkill.) Thu 2013/9/10 Ian Ross i...@skybluetrades.net: Me too, but I wasn't brave enough to say

Re: [Haskell-cafe] Proposal: New syntax for Haskell

That was done around 100 years ago with COBOL. 2013/9/10 Vo Minh Thu not...@gmail.com The syntax is actually used by non-technical people to write tests. Using it to write Haskell code is a joke. (Using it for business specification is not, even if for technical people this seems overkill

Re: [Haskell-cafe] Proposal: New syntax for Haskell

Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. [1] The example detailed how foldl is implemented. Also, as it is intended to be a DSL for

Re: [Haskell-cafe] Proposal: New syntax for Haskell

I hope these jokes do not cause people to be afraid to post new ideas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: New syntax for Haskell

that we add a Cucumber syntax for Haskell, with the extension .chs, next to .hs and .lhs. Code written in cucumber syntax is concise and easy to read: You can find some example code in https://gist.github.com/nh2/6505995. Quoting from that: Feature: The Data.List module In order to be able

Re: [Haskell-cafe] Proposal: New syntax for Haskell

On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote: I hope these jokes do not cause people to be afraid to post new ideas. Agreed. I would also like to clarify that my message was much more a joke on the incomprehensibility of legal acts than on the original proposal.

Re: [Haskell-cafe] Proposal: New syntax for Haskell

voluntary action against LANGUAGE pragmas dedicated to theft of syntax. Sec. 104. Immunity for taking voluntary action against libraries that make heavy use of unsafePerformIO. Sec. 105. Guidelines and study. Sec. 106. Denying `base` maintainership to notorious Applicative = Monad proposal

Re: [Haskell-cafe] Haskell syntax/indentation for vim

Here is the crazy idea; instead of having a vim plugin to rule-them-all, why you don't join your efforts and create a plugin which does only indentation for Haskell code? This way, we could have a modular stack and be free to use whatever plugins work for syntax highlighting / unicode syntactic

Re: [Haskell-cafe] Haskell syntax/indentation for vim

seen vim2hs? https://github.com/dag/vim2hs On Sat, Mar 2, 2013 at 9:11 PM, Tristan Ravitch travi...@cs.wisc.eduwrote: Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new Haskell

Re: [Haskell-cafe] Haskell syntax/indentation for vim

, 2013 at 9:11 PM, Tristan Ravitch travi...@cs.wisc.eduwrote: Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new Haskell mode: https://github.com/travitch/hasksyn

Re: [Haskell-cafe] Haskell syntax/indentation for vim

, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new Haskell mode: https://github.com/travitch/hasksyn It is minimal in that it doesn't provide support for running external

Re: [Haskell-cafe] Haskell syntax/indentation for vim

, 2013 at 9:11 PM, Tristan Ravitch travi...@cs.wisc.edu wrote: Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new Haskell mode: https://github.com/travitch/hasksyn

Re: [Haskell-cafe] Haskell syntax/indentation for vim

Hi Have you seen vim2hs? https://github.com/dag/vim2hs On Sat, Mar 2, 2013 at 9:11 PM, Tristan Ravitch travi...@cs.wisc.eduwrote: Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand

Re: [Haskell-cafe] Haskell syntax/indentation for vim

Have you seen vim2hs? https://github.com/dag/vim2hs On Sat, Mar 2, 2013 at 9:11 PM, Tristan Ravitch travi...@cs.wisc.eduwrote: Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new

[Haskell-cafe] Haskell syntax/indentation for vim

Cafe, I've recently been playing with vim and wasn't quite satisfied with the existing syntax highlighting and indentation, so I thought I'd try my hand at a new Haskell mode: https://github.com/travitch/hasksyn It is minimal in that it doesn't provide support for running external commands over

Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

)}) [LinThruster 3.1415927 1.0,LinThruster 0.0 0.5] This seems to work well enough so far. But the issue I was concerned about is: if I can't layer record syntax onto the type synonym, then I have to rewrite a whole bunch of getters / setters each time I want to add an attribute (e.g., requiring

[Haskell-cafe] Layer on a layer of record syntax in the type synonym?

Using a simple type I gave earlier from my monadic type question... code: data Socket3 a b c = Socket3 a b c deriving (Show) Is it possible somehow to layer on record syntax onto a synonym of the type? The idea would be something like this... code: type SpaceShip

Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

On 22 December 2012 00:36, Christopher Howard christopher.how...@frigidcode.com wrote: Using a simple type I gave earlier from my monadic type question... code: data Socket3 a b c = Socket3 a b c deriving (Show) Is it possible somehow to layer on record syntax onto

Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

Hi Christopher, On Fri, Dec 21, 2012 at 04:36:04AM -0900, Christopher Howard wrote: Using a simple type I gave earlier from my monadic type question... code: data Socket3 a b c = Socket3 a b c deriving (Show) Is it possible somehow to layer on record syntax onto

Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

On Fri, 2012-12-21 at 04:36 -0900, Christopher Howard wrote: Using a simple type I gave earlier from my monadic type question... code: data Socket3 a b c = Socket3 a b c deriving (Show) Is it possible somehow to layer on record syntax onto a synonym of the type

Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

(Last {getLast = Just (Engine 100.0 1.0 Mark I)}) (Last {getLast = Just (RotThruster 10.0)}) [LinThruster 3.1415927 1.0,LinThruster 0.0 0.5] This seems to work well enough so far. But the issue I was concerned about is: if I can't layer record syntax onto the type synonym, then I have

Re: [GHC] #1383: mistaken qualified infix syntax could have a nicer error message

#1383: mistaken qualified infix syntax could have a nicer error message ---+ Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority

Re: [GHC] #1383: mistaken qualified infix syntax could have a nicer error message

#1383: mistaken qualified infix syntax could have a nicer error message -+-- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority

Re: [GHC] #7495: Rebindable list syntax?

#7495: Rebindable list syntax? -+-- Reporter: nwf | Owner: Type: feature request | Status: new Priority: normal| Milestone

[GHC] #7495: Rebindable list syntax?

#7495: Rebindable list syntax? -+-- Reporter: nwf | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler

[Haskell-cafe] Copying a syntax tree

Hi! I have a syntax tree defined like this: data A a = A Int Int (B a) data B a = B String String (C a) data C a = C Int Int (D a) and so on, all the data are parametrized with a type variable. This variable is actually used as a field in the very end of a hierarchy: data D a = D Int

Re: [Haskell-cafe] Copying a syntax tree

a syntax tree defined like this: data A a = A Int Int (B a) data B a = B String String (C a) data C a = C Int Int (D a) and so on, all the data are parametrized with a type variable. This variable is actually used as a field in the very end of a hierarchy: data D a = D Int a Now I

Re: [Haskell-cafe] Copying a syntax tree

a syntax tree defined like this: data A a = A Int Int (B a) data B a = B String String (C a) data C a = C Int Int (D a) and so on, all the data are parametrized with a type variable. This variable is actually used as a field in the very end of a hierarchy: data D a = D Int a Now I

  1   2   3   4   5   6   7   8   9   10   >