Johan Tibell wrote:
> I suggest that we implement an alternative haddock syntax that's a
> superset of Markdown.
Here is a previous thread on this exact topic, from five years ago:
http://www.haskell.org/pipermail/haskell-cafe/2008-February/039846.html
It mentions a few additional shades of bike
2013/4/8 Evan Laforge
> Can't we just add some features to haddock? There are a lot of ways
> to improve haddock a lot, and no one is doing them, so my impression
> is that haddock doesn't really have active maintainers. Adding a
> whole new backend seems risky, unless it results in new maintai
It supports ```language blocks, but not autolink detection. I have not
fully documented which features are supported. I also haven't done any
performance analysis versus other tools, simply because my goal is in no
way high efficiency. It is fast enough for my use cases, and I don't intend
to spend
On Mon, Apr 8, 2013 at 3:49 PM, Ivan Lazar Miljenovic
wrote:
> On 9 April 2013 05:08, MigMit wrote:
>>
>>
>> Отправлено с iPad
>>
>> 08.04.2013, в 21:44, Evan Laforge написал(а):
>>
>>> Can't we just add some features to haddock?
>>
>> No, we can't. At the very least we should FIX haddock before
On 9 April 2013 05:08, MigMit wrote:
>
>
> Отправлено с iPad
>
> 08.04.2013, в 21:44, Evan Laforge написал(а):
>
>> Can't we just add some features to haddock?
>
> No, we can't. At the very least we should FIX haddock before adding features.
How specifically does haddock need to be fixed?
>
>
>
Отправлено с iPad
08.04.2013, в 21:44, Evan Laforge написал(а):
> Can't we just add some features to haddock?
No, we can't. At the very least we should FIX haddock before adding features.
> There are a lot of ways
> to improve haddock a lot, and no one is doing them, so my impression
> is
On 8 Apr 2013, at 14:52, Roman Cheplyaka wrote:
>> In my opinion, it is perfectly valid to have intentional preprocessor
>> directives inside Haskell comments.
>
> Could you give an example where this is useful?
> ... macro expansions inside the comments are rather exotic.
{- | Some module docu
Can't we just add some features to haddock? There are a lot of ways
to improve haddock a lot, and no one is doing them, so my impression
is that haddock doesn't really have active maintainers. Adding a
whole new backend seems risky, unless it results in new maintainers
joining.
For my personal b
+++ John MacFarlane [Apr 05 13 16:04 ]:
> I like markdown and use it all the time. While I acknowledge the
> problems that have been pointed out, markdown has the advantage of being
> easily readable "as it is" in the source document, and not looking like
> markup.
>
> But I do want to point out
* Ivan Lazar Miljenovic [2013-04-08 10:18:32+1000]
> On 8 April 2013 07:12, Roman Cheplyaka wrote:
> > Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
> > comments. E.g. GNU cpp strips C comments.
>
> Not quite: http://hackage.haskell.org/trac/ghc/ticket/4836
This seems to b
* Malcolm Wallace [2013-04-08 10:00:11+0100]
> And cpphs strips C comments too. :-)
>
> But seriously, John's use-case is the exact opposite of what you
> suggest. John wants to keep the # inside the comment block. You
> suggest to remove the comment-block altogether?
No, my point was that the
Could you elaborate a bit on which markdown features you support (or
even better: write it into your module haddocks)?
Thinks like
- autolink detection
- ```language blocks?
Also, you build on performance-oriented libraries - it would be cool if
you could make a small benchmark comparing with the
And cpphs strips C comments too. :-)
But seriously, John's use-case is the exact opposite of what you suggest. John
wants to keep the # inside the comment block. You suggest to remove the
comment-block altogether?
When I checked the example with cpphs, it turns out that the # line is
retaine
On 6 April 2013 01:57, John Wiegley wrote:
> > Johan Tibell writes:
>
> > I suggest that we implement an alternative haddock syntax that's a
> superset
> > of Markdown.
>
> Definite +1 from me too.
>
+1
Conrad.
___
Haskell-Cafe mailing list
Haske
On 8 April 2013 07:12, Roman Cheplyaka wrote:
> Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
> comments. E.g. GNU cpp strips C comments.
Not quite: http://hackage.haskell.org/trac/ghc/ticket/4836
>
> Roman
>
> * John MacFarlane [2013-04-05 16:04:32-0700]
>> I like markdow
Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
comments. E.g. GNU cpp strips C comments.
Roman
* John MacFarlane [2013-04-05 16:04:32-0700]
> I like markdown and use it all the time. While I acknowledge the
> problems that have been pointed out, markdown has the advantage o
+1 for concistency.
Also, consider interop with non-haskell environments. For example showing
the documentation of a function in emacs, eclipse, on github, and from a
javascript library.
All of these can be engineered around, and tooling can be provided.
But let me give an example: the other we
I like markdown and use it all the time. While I acknowledge the
problems that have been pointed out, markdown has the advantage of being
easily readable "as it is" in the source document, and not looking like
markup.
But I do want to point out one problem with markdown as a format for
documentat
On Thu, Apr 4, 2013 at 11:22 PM, Kim-Ee Yeoh wrote:
> Could you say something about /why/ you make the suggestion? I, for
> one, would be happy to google and read links, but what's missing from
> that experience would be input from a fellow haskeller. In context. In
> real-time. On topic.
Pretty
I forgot the mention the craziness with the *significant trailing
whitespace*.
On Fri, Apr 5, 2013 at 9:49 PM, dag.odenh...@gmail.com <
dag.odenh...@gmail.com> wrote:
> Personally I think Markdown sucks, although perhaps less than Haddock
> markup.
>
> Still:
>
> * No document meta data
> * No c
Personally I think Markdown sucks, although perhaps less than Haddock
markup.
Still:
* No document meta data
* No code block meta data like language for syntax highlighting
* No tables
* No footnotes
* HTML fallback is insecure
* Confusing syntax (is it []() or ()[] for links?)
* Syntax that gets
> Johan Tibell writes:
> I suggest that we implement an alternative haddock syntax that's a superset
> of Markdown.
Definite +1 from me too.
--
John Wiegley
FP Complete Haskell tools, training and consulting
http://fpcomplete.com johnw on #haskell/irc.
On Fri, Apr 5, 2013 at 10:12 AM, Petr Pudlák wrote:
>
> While I like the idea of allowing any markup language (let's say supported
> by Pandoc) and freedom it gives to developers, it also has also drawbacks:
> It makes contributing more difficult, if a project uses some wierd,
> non-standard mark
Hi,
I also support the idea of having Markdown for Haddock. Using some well
established markup language would make Haddock much easier to adopt and use.
While I like the idea of allowing any markup language (let's say supported
by Pandoc) and freedom it gives to developers, it also has also drawb
I'm not proposing the LaTeX is used for hyperlinking the
reference - hence my comment about nicely integrating
Perhaps a \begin{haddock} ... \end{haddock} environment* ?
* This would only affect those using LaTeX/lhs - everyone else could haddock**
as usual
** haddock = whatever markdow/up/si
On 5 April 2013 12:20, Andrew Butterfield
wrote:
>
> On 4 Apr 2013, at 22:53, Aleksey Khudyakov wrote:
>
>> If we are going to change haddock syntax we should add ability to add
>> math formulae to documentation. It's not currently possible and it makes
>> documenting numeric code properly difficu
On 4 Apr 2013, at 22:53, Aleksey Khudyakov wrote:
> If we are going to change haddock syntax we should add ability to add
> math formulae to documentation. It's not currently possible and it makes
> documenting numeric code properly difficult.
How about support for .lhs files?
- both those with
I think this thread has went to became a quest for One True Markup
Language...
I would like to propose a different approach: while we are at extending
Haddock why not make it possible to choose from a set of different
documentation plugins? Something that works akin to the type: Text ->
Environmen
On 5 April 2013 15:49, Kim-Ee Yeoh wrote:
> On Fri, Apr 5, 2013 at 10:44 AM, Ivan Lazar Miljenovic
> wrote:
>> I don't think so; this was one of the big issues recently when people
>> were trying to get Gruber to actually _do_ something with Markdown as
>> there were all these corner cases.
>
> I
On Fri, Apr 5, 2013 at 10:44 AM, Ivan Lazar Miljenovic
wrote:
> I don't think so; this was one of the big issues recently when people
> were trying to get Gruber to actually _do_ something with Markdown as
> there were all these corner cases.
In that case, surely this is an opportunity to convene
On 5 April 2013 13:24, Richard A. O'Keefe wrote:
>
> On 5/04/2013, at 2:00 PM, Johan Tibell wrote:
>
>>> Would it be too much to ask that a notation be used which has
>>> a formal syntax and a formal semantics?
>>
>> We will document our superset, sure. That's what others did as well.
>> The point
On 5/04/2013, at 2:00 PM, Johan Tibell wrote:
>> Would it be too much to ask that a notation be used which has
>> a formal syntax and a formal semantics?
>
> We will document our superset, sure. That's what others did as well.
> The point is using Markdown as the shared base.
Nononono.
Sure, th
+++ Simon Heath [Apr 04 13 13:04 ]:
> I humbly suggest reStructuredText rather than Markdown, which is what
> is used by the Python community for documentation. Since it's specifically
> made for documentation it may be nicer. But, I don't want to spark
> a format argument.
>
> There is also the
> Would it be too much to ask that a notation be used which has
> a formal syntax and a formal semantics?
We will document our superset, sure. That's what others did as well.
The point is using Markdown as the shared base.
___
Haskell-Cafe mailing list
On 5/04/2013, at 12:34 PM, Johan Tibell wrote:
>
> Markdown has won. Look at all the big programming sites out there,
> from GitHub to StackOverflow, they all use a superset of Markdown.
Yes, but they tend to use _different_ supersets of Markdown.
Would it be too much to ask that a notation be
Johan Tibell writes:
> On Thu, Apr 4, 2013 at 9:49 AM, Johan Tibell wrote:
>> I suggest that we implement an alternative haddock syntax that's a
>> superset of Markdown. It's a superset in the sense that we still want
>> to support linkifying Haskell identifiers, etc. Modules that want to
>> use
On Thu, Apr 4, 2013 at 9:49 AM, Johan Tibell wrote:
> I suggest that we implement an alternative haddock syntax that's a
> superset of Markdown. It's a superset in the sense that we still want
> to support linkifying Haskell identifiers, etc. Modules that want to
> use the new syntax (which will p
On 4 April 2013 20:49, Johan Tibell wrote:
> Hi all,
>
> Haddock's current markup language leaves something to be desired once
> you want to write more serious documentation (e.g. several paragraphs
> of introductory text at the top of the module doc). Several features
> are lacking (bold text, li
On Thu, Apr 4, 2013 at 11:22 PM, Kim-Ee Yeoh wrote:
> On Fri, Apr 5, 2013 at 3:04 AM, Simon Heath wrote:
> > I humbly suggest reStructuredText rather than Markdown, which is what
> > is used by the Python community for documentation. Since it's
> specifically
> > made for documentation it may b
On Fri, Apr 5, 2013 at 3:04 AM, Simon Heath wrote:
> I humbly suggest reStructuredText rather than Markdown, which is what
> is used by the Python community for documentation. Since it's specifically
> made for documentation it may be nicer. But, I don't want to spark
> a format argument.
Could
I humbly suggest reStructuredText rather than Markdown, which is what
is used by the Python community for documentation. Since it's specifically
made for documentation it may be nicer. But, I don't want to spark
a format argument.
There is also the Pandoc program, which is a universal-ish markup
A sane markup for haddock would be greatly appreciated. I've grown
tired of noticing highlighted words arising from unescaped quotes all
over hackage.
On Thu, 4 Apr 2013 09:49:04 -0700 Johan Tibell
wrote:
> Hi all,
>
> Haddock's current markup language leaves something to be desired once
> you
On Thu, Apr 4, 2013 at 7:49 PM, Johan Tibell wrote:
> Hi all,
>
> Haddock's current markup language leaves something to be desired once
> you want to write more serious documentation (e.g. several paragraphs
> of introductory text at the top of the module doc). Several features
> are lacking (bol
On Thu, Apr 04, 2013 at 06:41:19PM +0100, Edsko de Vries wrote:
> Yes please!
+1 as well. I find the current syntax too restrictive…
iustin
> On Thu, Apr 4, 2013 at 5:49 PM, Johan Tibell wrote:
>
> > Hi all,
> >
> > Haddock's current markup language leaves something to be desired once
> > you
Yes please!
-E
On Thu, Apr 4, 2013 at 5:49 PM, Johan Tibell wrote:
> Hi all,
>
> Haddock's current markup language leaves something to be desired once
> you want to write more serious documentation (e.g. several paragraphs
> of introductory text at the top of the module doc). Several features
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
46 matches
Mail list logo
