More flexible literate Haskell extensions (Trac #9789), summary on wiki

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

More flexible literate Haskell extensions (Trac #9789), summary on wiki

Merijn Verstraaten
As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension

I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation.

Unless there's any vehement objections, I'll produce a diff on fabricator asap.

Cheers,
Merijn
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Simon Hengel
> I don't expect a lot of disagreement on discussion, aside from minor
> bike shedding on the flavour of the extension. I've started
> implementing this already. I'm open to bikesheds on exact extension,
> as it shouldn't affect the implementation.

Joining the party late, my main use case for literate Haskell is
README.md files.  The solution I currently use is to have a symlink:

    README.lhs -> README.md

(see e.g. https://github.com/hspec/hspec-wai)

As I understand it the current proposal neither helps nor conflicts with
this use case/solution.

I leave this here as a comment mainly to indicated that:

 * the proposal as it stands does not solve my use case
 * there are other ways to solve this (namely: using symlinks)

Cheers,
Simon Hengel
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Simon Peyton Jones
In reply to this post by Merijn Verstraaten
Thanks.  I don't have strong opinions about any of this.  But I would love to have an actual specification of what is proposed.  The wiki page starts with "Proposal" but lists a set of alternatives.  Later "Concrete proposal" discusses only file suffixes, and has lots of discussion of alternatives.

Would it be possible to have a section
   a) describing a single alternative, as precisely as possible.
   b) saying what the effect or meaning of proposal is

For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or whatever?

For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some markdown in there.  But how is it delimited?  Is md the only one proposed or are there others? Is it meant to be extensible or is there a fixed set?

In short, a *specification* of what is proposed.  I think that would be helpful for people who come to this without having participated in the discussion that led up to it.

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of Merijn Verstraaten
|  Sent: 14 November 2014 04:22
|  To: [hidden email]; GHC Users Mailing List
|  Subject: More flexible literate Haskell extensions (Trac #9789),
|  summary on wiki
|  
|  As requested on my ticket I summarised the entire proposal on the wiki
|  here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension
|  
|  I don't expect a lot of disagreement on discussion, aside from minor
|  bike shedding on the flavour of the extension. I've started
|  implementing this already. I'm open to bikesheds on exact extension,
|  as it shouldn't affect the implementation.
|  
|  Unless there's any vehement objections, I'll produce a diff on
|  fabricator asap.
|  
|  Cheers,
|  Merijn
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  [hidden email]
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Jan Stolarek
In reply to this post by Merijn Verstraaten
.lhs = Literate Haskell

So maybe .mhs = Markdown Haskell instead of .lhs+md?

Jan
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Simon Hengel
In reply to this post by Simon Hengel
On Fri, Nov 14, 2014 at 03:53:13PM +0800, Simon Hengel wrote:
> > Can you explain why this would not solve your usecase? i.e., why would
> > README.lhs.md not suffice?
>
> I haven't tried, but my assumption was that this is not picked up by
> GitHub.

I just verified, GitHub dose not pick up README.lhs.md files as READMEs,
meaning that a README.lhs.md file will not be rendered as a projects
README file on GitHub.

Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Merijn Verstraaten
In reply to this post by Simon Peyton Jones
Hi Simon,

Thanks for the comments. I think most of the confusion stems from people overthinking the scope of what I was proposing. I'll clear up the page a bit as it's currently conflating implementation details with semantics.

> On 14 Nov 2014, at 2:29, Simon Peyton Jones <[hidden email]> wrote:
> Would it be possible to have a section
>   a) describing a single alternative, as precisely as possible.

The single alternative would simply be:
If GHC tries to find the source for a module Foo and none of "Foo.hs", "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.

>   b) saying what the effect or meaning of proposal is

The proposal does NOT modify the way GHC treats the contents of files or unlits literate haskell in anyway. While I'm in favour of supporting more literate formats, that's orthogonal to this proposal.

> For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or whatever?

Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist. But the implementation prefers extensions in the following order: "hs", "lhs", "hsig" and "lhsig". I would just add the new allowed extension behind that as lower priority than the current ones.

> For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some markdown in there.  But how is it delimited?  Is md the only one proposed or are there others? Is it meant to be extensible or is there a fixed set?

See my earlier point, I do *not* intend to affect the way GHC interprets/unlits the contents of files. Pandoc is already perfectly happy to work with literate files, it just currently lacks a way to determine what the content type of the non-literate bits is. Which is what I hope to deal with here.

Cheers,
Merijn
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Simon Peyton Jones
Marijn,

Thanks.  Can you make sure that you update the wiki page to reflect what you say here?  Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.  Misunderstandings expressed in email are simply tell you how to improve the wiki page!

thanks

Simon

| -----Original Message-----
| From: Merijn Verstraaten [mailto:[hidden email]]
| Sent: 16 November 2014 21:42
| To: Simon Peyton Jones
| Cc: [hidden email]; GHC Users Mailing List
| Subject: Re: More flexible literate Haskell extensions (Trac #9789),
| summary on wiki
|
| Hi Simon,
|
| Thanks for the comments. I think most of the confusion stems from people
| overthinking the scope of what I was proposing. I'll clear up the page a
| bit as it's currently conflating implementation details with semantics.
|
| > On 14 Nov 2014, at 2:29, Simon Peyton Jones <[hidden email]>
| wrote:
| > Would it be possible to have a section
| >   a) describing a single alternative, as precisely as possible.
|
| The single alternative would simply be:
| If GHC tries to find the source for a module Foo and none of "Foo.hs",
| "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file
| with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.
|
| >   b) saying what the effect or meaning of proposal is
|
| The proposal does NOT modify the way GHC treats the contents of files or
| unlits literate haskell in anyway. While I'm in favour of supporting more
| literate formats, that's orthogonal to this proposal.
|
| > For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or
| Foo.md.hs or whatever?
|
| Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual
| specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist.
| But the implementation prefers extensions in the following order: "hs",
| "lhs", "hsig" and "lhsig". I would just add the new allowed extension
| behind that as lower priority than the current ones.
|
| > For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some
| markdown in there.  But how is it delimited?  Is md the only one proposed
| or are there others? Is it meant to be extensible or is there a fixed
| set?
|
| See my earlier point, I do *not* intend to affect the way GHC
| interprets/unlits the contents of files. Pandoc is already perfectly
| happy to work with literate files, it just currently lacks a way to
| determine what the content type of the non-literate bits is. Which is
| what I hope to deal with here.
|
| Cheers,
| Merijn
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Merijn Verstraaten
On 16 Nov 2014, at 14:09, Simon Peyton Jones <[hidden email]> wrote:
> Thanks.  Can you make sure that you update the wiki page to reflect what you say here?  Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.  Misunderstandings expressed in email are simply tell you how to improve the wiki page!

I had already updated the wiki with the relevant notes before replying, but apparently I forgot to mention this!

Cheers,
Merijn
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users