Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Ryan Ingram]

On Tue, Sep 18, 2012 at 8:39 PM, Dan Doel  wrote:

> On Tue, Sep 18, 2012 at 11:19 PM, Ryan Ingram 
> wrote:
> > Fascinating!
> >
> > But it looks like you still 'cheat' in your induction principles...
> >
> > ×-induction : ∀{A B} {P : A × B → Set}
> > → ((x : A) → (y : B) → P (x , y))
> > → (p : A × B) → P p
> > ×-induction {A} {B} {P} f p rewrite sym (×-η p) = f (fst p) (snd p)
> >
> > Can you somehow define
> >
> > x-induction {A} {B} {P} f p = p (P p) f
>
> No, or at least I don't know how.
>
> The point is that with parametricity, I can prove that if p : A × B,
> then p = (fst p , snd p). Then when I need to prove P p, I change the
> obligation to P (fst p , snd p). But i have (forall x y. P (x , y))
> given.
>
> I don't know why you think that's cheating. If you thought it was
> going to be a straight-forward application of the Church (or some
> other) encoding, that was the point of the first paper (that's
> impossible). But parametricity can be used to prove statements _about_
> the encodings that imply the induction principle.
>

The line of logic I was thinking is that you could lift the parametricity
proof to the (proof-irrelevant) typelevel; that is, you rewrite the type of
f from

f :: (x : A) -> (y : B) -> P (x,y)

to

f :: A -> B -> P p

given that p = (x,y), to make f 'compatible' with p.  But I see the
trickiness, because if you allow yourself to do that, you no longer are
constrained to pass (fst p) and (snd p) to f, you could pass any objects of
type A and B.

Wait, can't you just use x-lemma1 to rewrite the rhs of x-induction?

×-lemma₁ : ∀{A B R} → (p : A × B) (k : A → B → R)
 → k (fst p) (snd p) ≡ p R k


x-lemma1 {A} {B} {P p} p f :: f (fst p) (snd p) = p (P p) f

Or is the problem that the "k" parameter to x-lemma1 isn't 'dependently
typed' enough?

  -- ryan



>
> > On Tue, Sep 18, 2012 at 4:09 PM, Dan Doel  wrote:
> >>
> >> This paper:
> >>
> >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.957
> >>
> >> Induction is Not Derivable in Second Order Dependent Type Theory,
> >> shows, well, that you can't encode naturals with a strong induction
> >> principle in said theory. At all, no matter what tricks you try.
> >>
> >> However, A Logic for Parametric Polymorphism,
> >>
> >> http://www.era.lib.ed.ac.uk/bitstream/1842/205/1/Par_Poly.pdf
> >>
> >> Indicates that in a type theory incorporating relational parametricity
> >> of its own types,  the induction principle for the ordinary
> >> Church-like encoding of natural numbers can be derived. I've done some
> >> work here:
> >>
> >> http://code.haskell.org/~dolio/agda-share/html/ParamInduction.html
> >>
> >> for some simpler types (although, I've been informed that sigma was
> >> novel, it not being a Simple Type), but haven't figured out natural
> >> numbers yet (I haven't actually studied the second paper above, which
> >> I was pointed to recently).
> >>
> >> -- Dan
> >>
> >> On Tue, Sep 18, 2012 at 5:41 PM, Ryan Ingram 
> wrote:
> >> > Oleg, do you have any references for the extension of lambda-encoding
> of
> >> > data into dependently typed systems?
> >> >
> >> > In particular, consider Nat:
> >> >
> >> > nat_elim :: forall P:(Nat -> *). P 0 -> (forall n:Nat. P n -> P
> >> > (succ
> >> > n)) -> (n:Nat) -> P n
> >> >
> >> > The naive lambda-encoding of 'nat' in the untyped lambda-calculus has
> >> > exactly the correct form for passing to nat_elim:
> >> >
> >> > nat_elim pZero pSucc n = n pZero pSucc
> >> >
> >> > with
> >> >
> >> > zero :: Nat
> >> > zero pZero pSucc = pZero
> >> >
> >> > succ :: Nat -> Nat
> >> > succ n pZero pSucc = pSucc (n pZero pSucc)
> >> >
> >> > But trying to encode the numerals this way leads to "Nat" referring to
> >> > its
> >> > value in its type!
> >> >
> >> >type Nat = forall P:(Nat  -> *). P 0 -> (forall n:Nat. P n -> P
> (succ
> >> > n))
> >> > -> P ???
> >> >
> >> > Is there a way out of this quagmire?  Or are we stuck defining actual
> >> > datatypes if we want dependent types?
> >> >
> >> >   -- ryan
> >> >
> >> >
> >> >
> >> > On Tue, Sep 18, 2012 at 1:27 AM,  wrote:
> >> >>
> >> >>
> >> >> There has been a recent discussion of ``Church encoding'' of lists
> and
> >> >> the comparison with Scott encoding.
> >> >>
> >> >> I'd like to point out that what is often called Church encoding is
> >> >> actually Boehm-Berarducci encoding. That is, often seen
> >> >>
> >> >> > newtype ChurchList a =
> >> >> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
> >> >>
> >> >> (in
> >> >> http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs)
> >> >>
> >> >> is _not_ Church encoding. First of all, Church encoding is not typed
> >> >> and it is not tight. The following article explains the other
> >> >> difference between the encodings
> >> >>
> >> >>
> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
> >> >>
> >> >> Boehm-Berarducci encoding is very insightful and influential. The
> >> 

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Dan Doel]

On Tue, Sep 18, 2012 at 11:19 PM, Ryan Ingram  wrote:
> Fascinating!
>
> But it looks like you still 'cheat' in your induction principles...
>
> ×-induction : ∀{A B} {P : A × B → Set}
> → ((x : A) → (y : B) → P (x , y))
> → (p : A × B) → P p
> ×-induction {A} {B} {P} f p rewrite sym (×-η p) = f (fst p) (snd p)
>
> Can you somehow define
>
> x-induction {A} {B} {P} f p = p (P p) f

No, or at least I don't know how.

The point is that with parametricity, I can prove that if p : A × B,
then p = (fst p , snd p). Then when I need to prove P p, I change the
obligation to P (fst p , snd p). But i have (forall x y. P (x , y))
given.

I don't know why you think that's cheating. If you thought it was
going to be a straight-forward application of the Church (or some
other) encoding, that was the point of the first paper (that's
impossible). But parametricity can be used to prove statements _about_
the encodings that imply the induction principle.

> On Tue, Sep 18, 2012 at 4:09 PM, Dan Doel  wrote:
>>
>> This paper:
>>
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.957
>>
>> Induction is Not Derivable in Second Order Dependent Type Theory,
>> shows, well, that you can't encode naturals with a strong induction
>> principle in said theory. At all, no matter what tricks you try.
>>
>> However, A Logic for Parametric Polymorphism,
>>
>> http://www.era.lib.ed.ac.uk/bitstream/1842/205/1/Par_Poly.pdf
>>
>> Indicates that in a type theory incorporating relational parametricity
>> of its own types,  the induction principle for the ordinary
>> Church-like encoding of natural numbers can be derived. I've done some
>> work here:
>>
>> http://code.haskell.org/~dolio/agda-share/html/ParamInduction.html
>>
>> for some simpler types (although, I've been informed that sigma was
>> novel, it not being a Simple Type), but haven't figured out natural
>> numbers yet (I haven't actually studied the second paper above, which
>> I was pointed to recently).
>>
>> -- Dan
>>
>> On Tue, Sep 18, 2012 at 5:41 PM, Ryan Ingram  wrote:
>> > Oleg, do you have any references for the extension of lambda-encoding of
>> > data into dependently typed systems?
>> >
>> > In particular, consider Nat:
>> >
>> > nat_elim :: forall P:(Nat -> *). P 0 -> (forall n:Nat. P n -> P
>> > (succ
>> > n)) -> (n:Nat) -> P n
>> >
>> > The naive lambda-encoding of 'nat' in the untyped lambda-calculus has
>> > exactly the correct form for passing to nat_elim:
>> >
>> > nat_elim pZero pSucc n = n pZero pSucc
>> >
>> > with
>> >
>> > zero :: Nat
>> > zero pZero pSucc = pZero
>> >
>> > succ :: Nat -> Nat
>> > succ n pZero pSucc = pSucc (n pZero pSucc)
>> >
>> > But trying to encode the numerals this way leads to "Nat" referring to
>> > its
>> > value in its type!
>> >
>> >type Nat = forall P:(Nat  -> *). P 0 -> (forall n:Nat. P n -> P (succ
>> > n))
>> > -> P ???
>> >
>> > Is there a way out of this quagmire?  Or are we stuck defining actual
>> > datatypes if we want dependent types?
>> >
>> >   -- ryan
>> >
>> >
>> >
>> > On Tue, Sep 18, 2012 at 1:27 AM,  wrote:
>> >>
>> >>
>> >> There has been a recent discussion of ``Church encoding'' of lists and
>> >> the comparison with Scott encoding.
>> >>
>> >> I'd like to point out that what is often called Church encoding is
>> >> actually Boehm-Berarducci encoding. That is, often seen
>> >>
>> >> > newtype ChurchList a =
>> >> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
>> >>
>> >> (in
>> >> http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )
>> >>
>> >> is _not_ Church encoding. First of all, Church encoding is not typed
>> >> and it is not tight. The following article explains the other
>> >> difference between the encodings
>> >>
>> >> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
>> >>
>> >> Boehm-Berarducci encoding is very insightful and influential. The
>> >> authors truly deserve credit.
>> >>
>> >> P.S. It is actually possible to write zip function using
>> >> Boehm-Berarducci
>> >> encoding:
>> >> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Haskell-Cafe mailing list
>> >> Haskell-Cafe@haskell.org
>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Ryan Ingram]

Fascinating!

But it looks like you still 'cheat' in your induction principles...

×-induction : ∀{A B} {P : A × B → Set}
→ ((x : A) → (y : B) → P (x , y))
→ (p : A × B) → P p
×-induction {A} {B} {P} f p rewrite sym (×-η p) = f (fst p) (snd p)

Can you somehow define

x-induction {A} {B} {P} f p = p (P p) f


On Tue, Sep 18, 2012 at 4:09 PM, Dan Doel  wrote:

> This paper:
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.957
>
> Induction is Not Derivable in Second Order Dependent Type Theory,
> shows, well, that you can't encode naturals with a strong induction
> principle in said theory. At all, no matter what tricks you try.
>
> However, A Logic for Parametric Polymorphism,
>
> http://www.era.lib.ed.ac.uk/bitstream/1842/205/1/Par_Poly.pdf
>
> Indicates that in a type theory incorporating relational parametricity
> of its own types,  the induction principle for the ordinary
> Church-like encoding of natural numbers can be derived. I've done some
> work here:
>
> http://code.haskell.org/~dolio/agda-share/html/ParamInduction.html
>
> for some simpler types (although, I've been informed that sigma was
> novel, it not being a Simple Type), but haven't figured out natural
> numbers yet (I haven't actually studied the second paper above, which
> I was pointed to recently).
>
> -- Dan
>
> On Tue, Sep 18, 2012 at 5:41 PM, Ryan Ingram  wrote:
> > Oleg, do you have any references for the extension of lambda-encoding of
> > data into dependently typed systems?
> >
> > In particular, consider Nat:
> >
> > nat_elim :: forall P:(Nat -> *). P 0 -> (forall n:Nat. P n -> P (succ
> > n)) -> (n:Nat) -> P n
> >
> > The naive lambda-encoding of 'nat' in the untyped lambda-calculus has
> > exactly the correct form for passing to nat_elim:
> >
> > nat_elim pZero pSucc n = n pZero pSucc
> >
> > with
> >
> > zero :: Nat
> > zero pZero pSucc = pZero
> >
> > succ :: Nat -> Nat
> > succ n pZero pSucc = pSucc (n pZero pSucc)
> >
> > But trying to encode the numerals this way leads to "Nat" referring to
> its
> > value in its type!
> >
> >type Nat = forall P:(Nat  -> *). P 0 -> (forall n:Nat. P n -> P (succ
> n))
> > -> P ???
> >
> > Is there a way out of this quagmire?  Or are we stuck defining actual
> > datatypes if we want dependent types?
> >
> >   -- ryan
> >
> >
> >
> > On Tue, Sep 18, 2012 at 1:27 AM,  wrote:
> >>
> >>
> >> There has been a recent discussion of ``Church encoding'' of lists and
> >> the comparison with Scott encoding.
> >>
> >> I'd like to point out that what is often called Church encoding is
> >> actually Boehm-Berarducci encoding. That is, often seen
> >>
> >> > newtype ChurchList a =
> >> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
> >>
> >> (in
> http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )
> >>
> >> is _not_ Church encoding. First of all, Church encoding is not typed
> >> and it is not tight. The following article explains the other
> >> difference between the encodings
> >>
> >> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
> >>
> >> Boehm-Berarducci encoding is very insightful and influential. The
> >> authors truly deserve credit.
> >>
> >> P.S. It is actually possible to write zip function using
> Boehm-Berarducci
> >> encoding:
> >> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
> >>
> >>
> >>
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hello Richard,

I made a first draft of your letter example.
It is not exactly as you had written but I think you might like it.
It is the combination of a content document (letter) and a style
document (letter.style). You can see the results in the PDF, which
was created using the Latex backend and the letter document
class.

Cheers,
José

On 19-09-2012 01:21, José Lopes wrote:

Hey Richard,

Regarding the languages, I think it is better to start with English
and see how successful Fmark is. There's no point in trying to tackle
lots of languages if we cannot solve the problem for one of them.
But then again, keeping everything Unicode.

In fact, in this matter, I think with Haskell we have an advantage
because things like 'isSpace' and 'isPuncuation' work with Unicode.

I now understand that the README.md is rather incomplete. I will
add some more information about the markup. Although, things
like bold, italics and so on are not implemented yet.

I will also take a look at your letter example. I think the real
challenge here is center alignment. I will think about a
way to solve it in Fmark so we can discuss it later on.

Thank you for the feedback.

Cheers,
José

On 19-09-2012 00:37, Richard O'Keefe wrote:

On 19/09/2012, at 1:43 AM, Stefan Monnier wrote:


The problem with that is that some people DO end some headings with
a full stop; for them your special syntax is not natural.

Markdown/ReST is already using the "no syntax" idea (e.g. compared to
pre-wiki markup such a LaTeX or Texinfo), so he's simply trying to push
this idea further.

Markdown is very heavy on syntax,
what it is *light* on is specification of what the
syntax actually is.  As a result,
I'm aware of three different dialects,
and someone told me about having to reverse
engineer the syntax from a Perl implementation.
As a further result, I cannot write a program to
reliably *generate* Markdown.

I suspect it'll be difficult.

Oh, more power to him for trying.
I just don't think it can be pushed very far.

Oh, there is a really *filthy* hack that could be pulled
for italics, bold face, and so on.  Contrary to its original
principles, Unicode includes several copies of ASCII
(see http://unicode.org/charts/PDF/U1D400.pdf):
Mathematical bold,
Mathematical italic,
Mathematical bold italic,
Mathematical script,
Mathematical bold script,
Mathematical fraktur,
Mathematical double struck (blackboard-bold),
Mathematical bold fraktur,
Mathematical sans-serif,
Mathematical sans-serif bold,
Mathematical sans-serif italic,
Mathematical sans-serif bold italic,
Mathematical monospace,
and some similar sets of Greek.
So as long as you don't want strike-through or underlying,
and as long as you don't want italic Cyrillic &c, ...
Too bad if you want a bold italic capital Thorn...


What if I want to use indentation to express quotation instead?

I think this one is solvable: a paragraph that's more indented than the
previous heading can be considered a quote.

Ah, but the quotation might not end with a sentence terminator,
so that would be considered a new heading.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

123 Copper Road,
Gemstone,
Dunedin,
New Zealand 

31 February 2016

Dear Schnorer,
   I am writing to you because I am tired of frobulating.
   I am also tired of this and that.

Yours without wax,

Dr Strabismus of Utrecht
(whom God preserve!)


letter.pdf
Description: Adobe PDF document
Address

Date

Opening,
  Letter.

Closing,

Signature___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hey Richard,

Regarding the languages, I think it is better to start with English
and see how successful Fmark is. There's no point in trying to tackle
lots of languages if we cannot solve the problem for one of them.
But then again, keeping everything Unicode.

In fact, in this matter, I think with Haskell we have an advantage
because things like 'isSpace' and 'isPuncuation' work with Unicode.

I now understand that the README.md is rather incomplete. I will
add some more information about the markup. Although, things
like bold, italics and so on are not implemented yet.

I will also take a look at your letter example. I think the real
challenge here is center alignment. I will think about a
way to solve it in Fmark so we can discuss it later on.

Thank you for the feedback.

Cheers,
José

On 19-09-2012 00:37, Richard O'Keefe wrote:

On 19/09/2012, at 1:43 AM, Stefan Monnier wrote:


The problem with that is that some people DO end some headings with
a full stop; for them your special syntax is not natural.

Markdown/ReST is already using the "no syntax" idea (e.g. compared to
pre-wiki markup such a LaTeX or Texinfo), so he's simply trying to push
this idea further.

Markdown is very heavy on syntax,
what it is *light* on is specification of what the
syntax actually is.  As a result,
I'm aware of three different dialects,
and someone told me about having to reverse
engineer the syntax from a Perl implementation.
As a further result, I cannot write a program to
reliably *generate* Markdown.

I suspect it'll be difficult.

Oh, more power to him for trying.
I just don't think it can be pushed very far.

Oh, there is a really *filthy* hack that could be pulled
for italics, bold face, and so on.  Contrary to its original
principles, Unicode includes several copies of ASCII
(see http://unicode.org/charts/PDF/U1D400.pdf):
Mathematical bold,
Mathematical italic,
Mathematical bold italic,
Mathematical script,
Mathematical bold script,
Mathematical fraktur,
Mathematical double struck (blackboard-bold),
Mathematical bold fraktur,
Mathematical sans-serif,
Mathematical sans-serif bold,
Mathematical sans-serif italic,
Mathematical sans-serif bold italic,
Mathematical monospace,
and some similar sets of Greek.
So as long as you don't want strike-through or underlying,
and as long as you don't want italic Cyrillic &c, ...
Too bad if you want a bold italic capital Thorn...


What if I want to use indentation to express quotation instead?

I think this one is solvable: a paragraph that's more indented than the
previous heading can be considered a quote.

Ah, but the quotation might not end with a sentence terminator,
so that would be considered a new heading.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Richard O'Keefe]

On 19/09/2012, at 1:43 AM, Stefan Monnier wrote:

>> The problem with that is that some people DO end some headings with
>> a full stop; for them your special syntax is not natural.
> 
> Markdown/ReST is already using the "no syntax" idea (e.g. compared to
> pre-wiki markup such a LaTeX or Texinfo), so he's simply trying to push
> this idea further.

Markdown is very heavy on syntax,
what it is *light* on is specification of what the
syntax actually is.  As a result,
I'm aware of three different dialects,
and someone told me about having to reverse
engineer the syntax from a Perl implementation.
As a further result, I cannot write a program to
reliably *generate* Markdown.
> 
> I suspect it'll be difficult.

Oh, more power to him for trying.
I just don't think it can be pushed very far.

Oh, there is a really *filthy* hack that could be pulled
for italics, bold face, and so on.  Contrary to its original
principles, Unicode includes several copies of ASCII
(see http://unicode.org/charts/PDF/U1D400.pdf):
Mathematical bold,
Mathematical italic,
Mathematical bold italic,
Mathematical script,
Mathematical bold script,
Mathematical fraktur,
Mathematical double struck (blackboard-bold),
Mathematical bold fraktur,
Mathematical sans-serif,
Mathematical sans-serif bold,
Mathematical sans-serif italic,
Mathematical sans-serif bold italic,
Mathematical monospace,
and some similar sets of Greek.
So as long as you don't want strike-through or underlying,
and as long as you don't want italic Cyrillic &c, ...
Too bad if you want a bold italic capital Thorn...

> 
>> What if I want to use indentation to express quotation instead?
> 
> I think this one is solvable: a paragraph that's more indented than the
> previous heading can be considered a quote.

Ah, but the quotation might not end with a sentence terminator,
so that would be considered a new heading.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Richard O'Keefe]

On 19/09/2012, at 12:04 AM, José Lopes wrote:

> Hello Richard,
> 
> When you say "(for) some people (...) you special syntax is not natural"
> that's a good thing. I want these people involved in the project. I want
> to understand what they find natural in order to weigh the options and
> make a proper decision.

One important question is how many *scripts* you want to support.
Do you, for example, want to support Greek?  There is a Unicode
character for Greek question mark U+037E, some documentation I've
seen says that the preferred character is U+003F.  So does ";"
terminate a sentence or not?
How many *languages* do you want to support?
Are you going to support Armenian, where the question mark that
ends a sentence goes not _after the last letter_ of the last
word but _over the last vowel_?

(As someone who only writes in English, I have no trouble with the
answer "only the Latin script, only the English language".)

I don't actually believe that there _is_ a natural convention for
italics, boldface, superscripts, etc.  Even _this_ is an artificial
convention going back to mechanical typewriters that could underline
but not change font.
> 
> On the README file in the github page you will find a brief explanation
> of the markup elements. I need to elaborate you that though because
> I feel I explain it too fast.
> https://github.com/jabolopes/fmark

I did read the README.md.  I disagree that there exists any problem
of manual removal of special characters.  If I want to remove XML markup,
I just do unxml foobar.xml >foobar.txt.  If I want to convert from one
kind of markup to another, there is pandoc, which is admittedly a touch
buggy, ...

The problem is that the README.md does not in fact explain what any
of the 'markup elements' are.

Let's take one little example, a letter of the kind I used to write
by hand.

123 Copper Road,
   Gemstone,
  Dunedin,
 New Zealand .
31 February 2016.

Dear Schnorer,
   I am writing to you because I am tired of frobulating.

Yours without wax,
   Dr Strabismus of Utrecht
  (whom God preserve!)

How do I tell Fmark about this structure?
How do I get this layout?  (The '1' and 'Y' should be in the centre.)

> Let me answer your questions about sections. The amount of indentation
> is not fixed. You can use whatever you want. There is also no nesting limit
> in Fmark, however, there is a nesting limit in the Latex backend. For now,
> quotations, block quotes, source code embedding, etc, are not implemented.
> Those will be added in the future.

These answers belong in the README.me.
> 
> About embedding a Fmark document in another document. That seems to
> be a very cool feature. I will definitely think about it! Maybe you can come
> up with a "natural" way of doing it?

The last time I thought I had a natural way to do anything like that
I found that the SGML design was worse broken than I would have believed 
possible.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Dan Doel]

This paper:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.957

Induction is Not Derivable in Second Order Dependent Type Theory,
shows, well, that you can't encode naturals with a strong induction
principle in said theory. At all, no matter what tricks you try.

However, A Logic for Parametric Polymorphism,

http://www.era.lib.ed.ac.uk/bitstream/1842/205/1/Par_Poly.pdf

Indicates that in a type theory incorporating relational parametricity
of its own types,  the induction principle for the ordinary
Church-like encoding of natural numbers can be derived. I've done some
work here:

http://code.haskell.org/~dolio/agda-share/html/ParamInduction.html

for some simpler types (although, I've been informed that sigma was
novel, it not being a Simple Type), but haven't figured out natural
numbers yet (I haven't actually studied the second paper above, which
I was pointed to recently).

-- Dan

On Tue, Sep 18, 2012 at 5:41 PM, Ryan Ingram  wrote:
> Oleg, do you have any references for the extension of lambda-encoding of
> data into dependently typed systems?
>
> In particular, consider Nat:
>
> nat_elim :: forall P:(Nat -> *). P 0 -> (forall n:Nat. P n -> P (succ
> n)) -> (n:Nat) -> P n
>
> The naive lambda-encoding of 'nat' in the untyped lambda-calculus has
> exactly the correct form for passing to nat_elim:
>
> nat_elim pZero pSucc n = n pZero pSucc
>
> with
>
> zero :: Nat
> zero pZero pSucc = pZero
>
> succ :: Nat -> Nat
> succ n pZero pSucc = pSucc (n pZero pSucc)
>
> But trying to encode the numerals this way leads to "Nat" referring to its
> value in its type!
>
>type Nat = forall P:(Nat  -> *). P 0 -> (forall n:Nat. P n -> P (succ n))
> -> P ???
>
> Is there a way out of this quagmire?  Or are we stuck defining actual
> datatypes if we want dependent types?
>
>   -- ryan
>
>
>
> On Tue, Sep 18, 2012 at 1:27 AM,  wrote:
>>
>>
>> There has been a recent discussion of ``Church encoding'' of lists and
>> the comparison with Scott encoding.
>>
>> I'd like to point out that what is often called Church encoding is
>> actually Boehm-Berarducci encoding. That is, often seen
>>
>> > newtype ChurchList a =
>> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
>>
>> (in http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )
>>
>> is _not_ Church encoding. First of all, Church encoding is not typed
>> and it is not tight. The following article explains the other
>> difference between the encodings
>>
>> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
>>
>> Boehm-Berarducci encoding is very insightful and influential. The
>> authors truly deserve credit.
>>
>> P.S. It is actually possible to write zip function using Boehm-Berarducci
>> encoding:
>> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
>>
>>
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Ryan Ingram]

Oleg, do you have any references for the extension of lambda-encoding of
data into dependently typed systems?

In particular, consider Nat:

nat_elim :: forall P:(Nat -> *). P 0 -> (forall n:Nat. P n -> P (succ
n)) -> (n:Nat) -> P n

The naive lambda-encoding of 'nat' in the untyped lambda-calculus has
exactly the correct form for passing to nat_elim:

nat_elim pZero pSucc n = n pZero pSucc

with

zero :: Nat
zero pZero pSucc = pZero

succ :: Nat -> Nat
succ n pZero pSucc = pSucc (n pZero pSucc)

But trying to encode the numerals this way leads to "Nat" referring to its
value in its type!

   type Nat = forall P:(Nat  -> *). P 0 -> (forall n:Nat. P n -> P (succ
n)) -> P ???

Is there a way out of this quagmire?  Or are we stuck defining actual
datatypes if we want dependent types?

  -- ryan


On Tue, Sep 18, 2012 at 1:27 AM,  wrote:

>
> There has been a recent discussion of ``Church encoding'' of lists and
> the comparison with Scott encoding.
>
> I'd like to point out that what is often called Church encoding is
> actually Boehm-Berarducci encoding. That is, often seen
>
> > newtype ChurchList a =
> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
>
> (in http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )
>
> is _not_ Church encoding. First of all, Church encoding is not typed
> and it is not tight. The following article explains the other
> difference between the encodings
>
> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
>
> Boehm-Berarducci encoding is very insightful and influential. The
> authors truly deserve credit.
>
> P.S. It is actually possible to write zip function using Boehm-Berarducci
> encoding:
> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

However if in a tab out of sync the user press refresh, the tab will
refresh to the current state.
I took care not to try to synchronize back as a consequence of a page that
is in a  forward state in one tab, as a consequence of navigating back in
other tab.  However I may have not considered all the edge extreme cases.

There is a back detection primitive
"goingBack"
that allow the programmer to control the back behaviour in some special
cases.

For example if i want to step over  a menu and present a default page, But
if when the user go back i want to present the menu, I can detect this
condition and present this menu, that did not appeared in a normal
navigation:

This code sets and get a default option  in the menu, so the menu is not
shown again in the navigation, except in the case that the user press the
back button. Otherwise, the menu would be never accessible.

However this is very specialized. normally the back button detection is not
necessary. In a persistent flow even this default entry option would be
completely automatic, since the process would restar at the last page
visited. No setting is necessary.


menu= do
   mop <- getGoStraighTo
   back <- goingBack

   case (mop,back) of
(Just goop,False) -> goop
_ -> do
   r <- ask

option1 <|> option2
   case r of
op1 -> setGoStraighTo (Just goop1) >> goop1
op2 -> setGoStraighTo (Just goop2) >> goop2





2012/9/18 Alberto G. Corona 

> Hi Jake,
> right, it depends on the identification of the session:
>
> iAll the tabs share the same state because they share the same cookies. so
> if in one tab the use continue the interaction then the other tabs are out
> of sync. If the user goes to these other tabs and press any widget, the
> application will  synchronize back to this page.
>
>
> This happens also if the user is logged in different computers.
>
> Alberto.
>
> 2012/9/18 Jake McArthur 
>
>> Actually, I meant users that spawn multiple tabs from a single root
>> session. You mentioned that you have some special support for the back
>> button. What happens if I open a couple new tabs in which I may or may
>> not go forward and backward. Do they all share the same state?
>> Different states (how?)? Partially shared states?
>>
>> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona 
>> wrote:
>> > Oh,  I´m stupid. You mean web pages with multiple tabs
>> >
>> >  I have not tested it. but each tab can be handled easily by a different
>> > server process.. or it can be handled in a single server process, like
>> in a
>> > menu. For example, this code present different options, and the process
>> > renders different things depending on the response.
>> >
>> > The last option is a link to a different process, while the others(
>> wlinks)
>> > are links that return back to the same process.
>> > The operator <|> is the applicative operator.  a breakline is prepended
>> to
>> > each link:
>> >
>> > data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read,
>> > Show)
>> >
>> >  mainf=   do
>> > r <- ask $   wlink Ints (bold << "increase an Int")
>> > <|>  br ++> wlink Strings (bold << "increase a String")
>> > <|>  br ++> wlink Actions (bold << "Example of a string
>> > widget with an action")
>> > <|>  br ++> wlink Ajax (bold << "Simple AJAX example")
>> > <|>  br ++> wlink Opt (bold << "select options")
>> > <++ (br +++ linkShop) -- this is an ordinary XHtml link
>> >
>> > case r of
>> >   Ints->  clickn 0
>> >   Strings ->  clicks "1"
>> >   Actions ->  actions 1
>> >   Ajax->  ajaxsample
>> >   Opt ->  options
>> > mainf
>> >  where
>> >  linkShop= toHtml $ hotlink  "shop" << "shopping"
>> >
>> > .
>> > Alberto
>> >
>> > 2012/9/18 Alberto G. Corona :
>> >
>> >> Hi Jake
>> >>
>> >> I don´t know what you mean with multiple tabs. The user management is
>> >> simple, anonymous clients are identified with  a cookie. if the user
>> >> is logged (MFlow has widgets for logging-validation) the user is the
>> >> identifier.
>> >>
>> >> The state of a process is associated to the client identifier and to
>> >> the path invoked in the url requested.
>> >>
>> >> I don´t know if this answer your question
>> >>
>> >> Alberto
>> >>
>> >> 2012/9/18 Jake McArthur :
>> >>> This sounds really cool.
>> >>>
>> >>> How do you handle users having multiple tabs?
>> >>>
>> >>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona <
>> agocor...@gmail.com>
>> >>> wrote:
>>  Hi haskellers and specially the web developers.
>> 
>>

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hey Tillmann,

That is a good point. What would you suggest for emphasis ?

Cheers,
José

On 18-09-2012 21:00, Tillmann Rendel wrote:

Hi,

José Lopes wrote in an earlier email:
I want to find a natural way of not burdening the user with the task 
of having to learn

some special syntax in order to write a document.


And then:

[...] we can leave " for quoting and use the ' for something else.


That sounds like 'some special syntax' to me. Or should it be "some 
special syntax"? I can't remember which was for quoting and which was 
for something else. Maybe I need to look that up in the Fmark 
documentation, again.


  Tillmann


--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Tillmann Rendel]

Hi,

José Lopes wrote in an earlier email:

I want to find a natural way of not burdening the user with the task of having 
to learn
some special syntax in order to write a document.


And then:

[...] we can leave " for quoting and use the ' for something else.


That sounds like 'some special syntax' to me. Or should it be "some 
special syntax"? I can't remember which was for quoting and which was 
for something else. Maybe I need to look that up in the Fmark 
documentation, again.


  Tillmann

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

Hi Jake,
right, it depends on the identification of the session:

iAll the tabs share the same state because they share the same cookies. so
if in one tab the use continue the interaction then the other tabs are out
of sync. If the user goes to these other tabs and press any widget, the
application will  synchronize back to this page.


This happens also if the user is logged in different computers.

Alberto.

2012/9/18 Jake McArthur 

> Actually, I meant users that spawn multiple tabs from a single root
> session. You mentioned that you have some special support for the back
> button. What happens if I open a couple new tabs in which I may or may
> not go forward and backward. Do they all share the same state?
> Different states (how?)? Partially shared states?
>
> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona 
> wrote:
> > Oh,  I´m stupid. You mean web pages with multiple tabs
> >
> >  I have not tested it. but each tab can be handled easily by a different
> > server process.. or it can be handled in a single server process, like
> in a
> > menu. For example, this code present different options, and the process
> > renders different things depending on the response.
> >
> > The last option is a link to a different process, while the others(
> wlinks)
> > are links that return back to the same process.
> > The operator <|> is the applicative operator.  a breakline is prepended
> to
> > each link:
> >
> > data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read,
> > Show)
> >
> >  mainf=   do
> > r <- ask $   wlink Ints (bold << "increase an Int")
> > <|>  br ++> wlink Strings (bold << "increase a String")
> > <|>  br ++> wlink Actions (bold << "Example of a string
> > widget with an action")
> > <|>  br ++> wlink Ajax (bold << "Simple AJAX example")
> > <|>  br ++> wlink Opt (bold << "select options")
> > <++ (br +++ linkShop) -- this is an ordinary XHtml link
> >
> > case r of
> >   Ints->  clickn 0
> >   Strings ->  clicks "1"
> >   Actions ->  actions 1
> >   Ajax->  ajaxsample
> >   Opt ->  options
> > mainf
> >  where
> >  linkShop= toHtml $ hotlink  "shop" << "shopping"
> >
> > .
> > Alberto
> >
> > 2012/9/18 Alberto G. Corona :
> >
> >> Hi Jake
> >>
> >> I don´t know what you mean with multiple tabs. The user management is
> >> simple, anonymous clients are identified with  a cookie. if the user
> >> is logged (MFlow has widgets for logging-validation) the user is the
> >> identifier.
> >>
> >> The state of a process is associated to the client identifier and to
> >> the path invoked in the url requested.
> >>
> >> I don´t know if this answer your question
> >>
> >> Alberto
> >>
> >> 2012/9/18 Jake McArthur :
> >>> This sounds really cool.
> >>>
> >>> How do you handle users having multiple tabs?
> >>>
> >>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona <
> agocor...@gmail.com>
> >>> wrote:
>  Hi haskellers and specially the web developers.
> 
>  http://hackage.haskell.org/package/MFlow-0.1.5.3
> 
>  MFlow is a is a Web framework with some unique, and I mean unique,
>  characteristics that I find exciting:
> 
>  - It is a Web application server that start and restart on-demand
>  stateful web server processes (not request.-response)
>    This means that all the page navigation can be coded in a single
>  procedure. This increases readability of the programmer code. I woul
>  call it
>  a anti-node.js.  Buit usual request-response (stateless) server
>  processes are also allowed
> 
>  - When the process is invoqued as result of an URL request, the Web
>  app server not only restart the process but also recover its execution
>  state. The enclosing Workflow monad provides the thread state
>  persistence. There are state timeouts and process timeouts defined by
>  the programmer. Processes with no persistent state (transient) are
>  possible.
> 
>  -The user interface is made of widgets. They are  formlets with added
>  formatting,   attributes, validations, modifiers and callbacks, that
>  are composable, so the pieces are reusable and return type safe
>  responses to the calling process. Even the links are part of widgets
>  and return back type safe inputs at compile time to the calling server
>  process. Tho glue these components, ordinary applicative combinators
>  and other extra combinators are used.
> 
>  - The widgets and the communication don´t make assumptions about the
>  architecture, so it can be adapted to non-web environments. This
>  versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and
>  Haskell Server Pages.
> 
>  -The widget rendering can be converted to ByteStrings automatically
>  with special combinators. A mix of widgets wi

Re: [Haskell-cafe] Choosing color of the track

[Eugene Kirpichov]

Hi,

Suppose you have data like this:

2012-09-18 00:10:48,166 =responseTime 53
...

Then you should just use -dk 'quantile 0.95' and you'll see a graph of
stacked bars like [][Y] (but vertical) where XXX is min..95%
and YYY is 95%..max.

On Tue, Sep 18, 2012 at 11:44 AM, Manish Trivedi  wrote:
> Thanks a ton Eugene. that worked like a charm :) Appreciate you looking into
> this and suggesting me the correct approach.
> I have another question that if I had single track storing response time of
> each request, how could I get 95th percentile of the response time. I know
> TimePlot wiki has quantile example but I havent been able to successfully
> use it.
>
> Regards,
> -Manish
>
>
> On Tue, Sep 18, 2012 at 10:48 AM, Eugene Kirpichov 
> wrote:
>>
>> Hi Manish,
>>
>> The meaning of "@" is not what you think it is. It merely draws
>> colored bars, it does NOT control the color of other kinds of charts.
>>
>> Here's how what you want can be achieved:
>> * Remove the "@" lines
>> * Append a common prefix to the input tracks you want to be displayed
>> on the same output track, e.g. "t.":
>> 2012-09-18 00:10:48,166 =t.CurrentPerHour13057 0.0
>> 2012-09-18 00:10:58,155 =t.CurrentPerHour13057 0.0
>> ..
>> 2012-09-18 03:58:28,159 =t.PacingReqPerHr13057 2375.0534412521242
>> 2012-09-18 03:58:38,161 =t.PacingReqPerHr13057 2375.383005739316
>>
>> * Use the "within" diagram kind: tplot  -dk ''within[.] lines"
>>
>> Then you'll have a single output track where data from these input
>> tracks is displayed with different color. However, you don't control
>> the precise color (I just never really needed to control it, I only
>> needed it to be different for different tracks).
>>
>> On Mon, Sep 17, 2012 at 9:40 PM, Manish Trivedi 
>> wrote:
>> > Hi Folks,
>> >
>> > I am trying to plot two tracks with different colors.
>> > Following is my input file,
>> >
>> > --
>> > 2012-09-18 00:10:48,166 @CurrentPerHour13057 Red
>> > 2012-09-18 00:10:48,166 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:10:58,155 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:08,203 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:18,166 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:28,159 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:38,170 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:48,175 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:11:58,174 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:12:08,216 =CurrentPerHour13057 0.0
>> > 2012-09-18 00:12:18,218 =CurrentPerHour13057 0.0
>> > 2012-09-18 03:58:28,159 @PacingReqPerHr13057 Blue
>> > 2012-09-18 03:58:28,159 =PacingReqPerHr13057 2375.0534412521242
>> > 2012-09-18 03:58:38,161 =PacingReqPerHr13057 2375.383005739316
>> > 2012-09-18 03:58:48,175 =PacingReqPerHr13057 2375.713057258422
>> > 2012-09-18 03:58:58,160 =PacingReqPerHr13057 2376.0422443063935
>> > 2012-09-18 03:59:08,192 =PacingReqPerHr13057 2376.3730727321126
>> > 2012-09-18 03:59:18,207 =PacingReqPerHr13057 2375.9038854561304
>> > 2012-09-18 03:59:28,168 =PacingReqPerHr13057 2376.232615497
>> > 2012-09-18 03:59:38,156 =PacingReqPerHr13057 2376.5619853019184
>> > 2012-09-18 03:59:48,160 =PacingReqPerHr13057 2376.892145685344
>> > 2012-09-18 03:59:58,160 =PacingReqPerHr13057 2377.65743067
>> > -
>> >
>> > tplot -o /root/color.png  -or 1024x768 -k 'CurrentPerHour' 'lines' -k
>> > 'PacingReqPerHr' 'lines' -if /root/color.input -tf 'date %Y-%m-%d
>> > %H:%M:%OS'
>> >
>> > I cant get to print plots in different color. Could anyone point out
>> > what am
>> > I doing wrong?
>> >
>> > Thanks,
>> > Manish
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>>
>>
>>
>> --
>> Eugene Kirpichov
>> http://www.linkedin.com/in/eugenekirpichov
>> We're hiring! http://tinyurl.com/mirantis-openstack-engineer
>
>



-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
We're hiring! http://tinyurl.com/mirantis-openstack-engineer

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Jake McArthur]

Actually, I meant users that spawn multiple tabs from a single root
session. You mentioned that you have some special support for the back
button. What happens if I open a couple new tabs in which I may or may
not go forward and backward. Do they all share the same state?
Different states (how?)? Partially shared states?

On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona  wrote:
> Oh,  I´m stupid. You mean web pages with multiple tabs
>
>  I have not tested it. but each tab can be handled easily by a different
> server process.. or it can be handled in a single server process, like in a
> menu. For example, this code present different options, and the process
> renders different things depending on the response.
>
> The last option is a link to a different process, while the others( wlinks)
> are links that return back to the same process.
> The operator <|> is the applicative operator.  a breakline is prepended to
> each link:
>
> data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read,
> Show)
>
>  mainf=   do
> r <- ask $   wlink Ints (bold << "increase an Int")
> <|>  br ++> wlink Strings (bold << "increase a String")
> <|>  br ++> wlink Actions (bold << "Example of a string
> widget with an action")
> <|>  br ++> wlink Ajax (bold << "Simple AJAX example")
> <|>  br ++> wlink Opt (bold << "select options")
> <++ (br +++ linkShop) -- this is an ordinary XHtml link
>
> case r of
>   Ints->  clickn 0
>   Strings ->  clicks "1"
>   Actions ->  actions 1
>   Ajax->  ajaxsample
>   Opt ->  options
> mainf
>  where
>  linkShop= toHtml $ hotlink  "shop" << "shopping"
>
> .
> Alberto
>
> 2012/9/18 Alberto G. Corona :
>
>> Hi Jake
>>
>> I don´t know what you mean with multiple tabs. The user management is
>> simple, anonymous clients are identified with  a cookie. if the user
>> is logged (MFlow has widgets for logging-validation) the user is the
>> identifier.
>>
>> The state of a process is associated to the client identifier and to
>> the path invoked in the url requested.
>>
>> I don´t know if this answer your question
>>
>> Alberto
>>
>> 2012/9/18 Jake McArthur :
>>> This sounds really cool.
>>>
>>> How do you handle users having multiple tabs?
>>>
>>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona 
>>> wrote:
 Hi haskellers and specially the web developers.

 http://hackage.haskell.org/package/MFlow-0.1.5.3

 MFlow is a is a Web framework with some unique, and I mean unique,
 characteristics that I find exciting:

 - It is a Web application server that start and restart on-demand
 stateful web server processes (not request.-response)
   This means that all the page navigation can be coded in a single
 procedure. This increases readability of the programmer code. I woul
 call it
 a anti-node.js.  Buit usual request-response (stateless) server
 processes are also allowed

 - When the process is invoqued as result of an URL request, the Web
 app server not only restart the process but also recover its execution
 state. The enclosing Workflow monad provides the thread state
 persistence. There are state timeouts and process timeouts defined by
 the programmer. Processes with no persistent state (transient) are
 possible.

 -The user interface is made of widgets. They are  formlets with added
 formatting,   attributes, validations, modifiers and callbacks, that
 are composable, so the pieces are reusable and return type safe
 responses to the calling process. Even the links are part of widgets
 and return back type safe inputs at compile time to the calling server
 process. Tho glue these components, ordinary applicative combinators
 and other extra combinators are used.

 - The widgets and the communication don´t make assumptions about the
 architecture, so it can be adapted to non-web environments. This
 versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and
 Haskell Server Pages.

 -The widget rendering can be converted to ByteStrings automatically
 with special combinators. A mix of widgets with different formats can
 be combined in the same source file. For example Text.Html and HSP
 (Haskell server pages)

 -These widgets can be cached, to avoid widget rendering on every
 interaction.

 -To handle the back button, and because the processes are stateful,
 they can run backwards until the response match. This is transparent
 for the programmer, thanks to the embedded FlowM monad.

 -All the code is in pure Haskell. No deployment, special scripts,
 formats etc are necessary.

 -Besides automatic state persistence, TCache provides transactions and
 user data persistence, that can be configured for SQL 

Re: [Haskell-cafe] Choosing color of the track

[Manish Trivedi]

Thanks a ton Eugene. that worked like a charm :) Appreciate you looking
into this and suggesting me the correct approach.
I have another question that if I had single track storing response time of
each request, how could I get 95th percentile of the response time. I know
TimePlot wiki has quantile example but I havent been able to successfully
use it.

Regards,
-Manish

On Tue, Sep 18, 2012 at 10:48 AM, Eugene Kirpichov wrote:

> Hi Manish,
>
> The meaning of "@" is not what you think it is. It merely draws
> colored bars, it does NOT control the color of other kinds of charts.
>
> Here's how what you want can be achieved:
> * Remove the "@" lines
> * Append a common prefix to the input tracks you want to be displayed
> on the same output track, e.g. "t.":
> 2012-09-18 00:10:48,166 =t.CurrentPerHour13057 0.0
> 2012-09-18 00:10:58,155 =t.CurrentPerHour13057 0.0
> ..
> 2012-09-18 03:58:28,159 =t.PacingReqPerHr13057 2375.0534412521242
> 2012-09-18 03:58:38,161 =t.PacingReqPerHr13057 2375.383005739316
>
> * Use the "within" diagram kind: tplot  -dk ''within[.] lines"
>
> Then you'll have a single output track where data from these input
> tracks is displayed with different color. However, you don't control
> the precise color (I just never really needed to control it, I only
> needed it to be different for different tracks).
>
> On Mon, Sep 17, 2012 at 9:40 PM, Manish Trivedi 
> wrote:
> > Hi Folks,
> >
> > I am trying to plot two tracks with different colors.
> > Following is my input file,
> >
> > --
> > 2012-09-18 00:10:48,166 @CurrentPerHour13057 Red
> > 2012-09-18 00:10:48,166 =CurrentPerHour13057 0.0
> > 2012-09-18 00:10:58,155 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:08,203 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:18,166 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:28,159 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:38,170 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:48,175 =CurrentPerHour13057 0.0
> > 2012-09-18 00:11:58,174 =CurrentPerHour13057 0.0
> > 2012-09-18 00:12:08,216 =CurrentPerHour13057 0.0
> > 2012-09-18 00:12:18,218 =CurrentPerHour13057 0.0
> > 2012-09-18 03:58:28,159 @PacingReqPerHr13057 Blue
> > 2012-09-18 03:58:28,159 =PacingReqPerHr13057 2375.0534412521242
> > 2012-09-18 03:58:38,161 =PacingReqPerHr13057 2375.383005739316
> > 2012-09-18 03:58:48,175 =PacingReqPerHr13057 2375.713057258422
> > 2012-09-18 03:58:58,160 =PacingReqPerHr13057 2376.0422443063935
> > 2012-09-18 03:59:08,192 =PacingReqPerHr13057 2376.3730727321126
> > 2012-09-18 03:59:18,207 =PacingReqPerHr13057 2375.9038854561304
> > 2012-09-18 03:59:28,168 =PacingReqPerHr13057 2376.232615497
> > 2012-09-18 03:59:38,156 =PacingReqPerHr13057 2376.5619853019184
> > 2012-09-18 03:59:48,160 =PacingReqPerHr13057 2376.892145685344
> > 2012-09-18 03:59:58,160 =PacingReqPerHr13057 2377.65743067
> > -
> >
> > tplot -o /root/color.png  -or 1024x768 -k 'CurrentPerHour' 'lines' -k
> > 'PacingReqPerHr' 'lines' -if /root/color.input -tf 'date %Y-%m-%d
> %H:%M:%OS'
> >
> > I cant get to print plots in different color. Could anyone point out
> what am
> > I doing wrong?
> >
> > Thanks,
> > Manish
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Eugene Kirpichov
> http://www.linkedin.com/in/eugenekirpichov
> We're hiring! http://tinyurl.com/mirantis-openstack-engineer
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Choosing color of the track

[Eugene Kirpichov]

Hi Manish,

The meaning of "@" is not what you think it is. It merely draws
colored bars, it does NOT control the color of other kinds of charts.

Here's how what you want can be achieved:
* Remove the "@" lines
* Append a common prefix to the input tracks you want to be displayed
on the same output track, e.g. "t.":
2012-09-18 00:10:48,166 =t.CurrentPerHour13057 0.0
2012-09-18 00:10:58,155 =t.CurrentPerHour13057 0.0
..
2012-09-18 03:58:28,159 =t.PacingReqPerHr13057 2375.0534412521242
2012-09-18 03:58:38,161 =t.PacingReqPerHr13057 2375.383005739316

* Use the "within" diagram kind: tplot  -dk ''within[.] lines"

Then you'll have a single output track where data from these input
tracks is displayed with different color. However, you don't control
the precise color (I just never really needed to control it, I only
needed it to be different for different tracks).

On Mon, Sep 17, 2012 at 9:40 PM, Manish Trivedi  wrote:
> Hi Folks,
>
> I am trying to plot two tracks with different colors.
> Following is my input file,
>
> --
> 2012-09-18 00:10:48,166 @CurrentPerHour13057 Red
> 2012-09-18 00:10:48,166 =CurrentPerHour13057 0.0
> 2012-09-18 00:10:58,155 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:08,203 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:18,166 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:28,159 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:38,170 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:48,175 =CurrentPerHour13057 0.0
> 2012-09-18 00:11:58,174 =CurrentPerHour13057 0.0
> 2012-09-18 00:12:08,216 =CurrentPerHour13057 0.0
> 2012-09-18 00:12:18,218 =CurrentPerHour13057 0.0
> 2012-09-18 03:58:28,159 @PacingReqPerHr13057 Blue
> 2012-09-18 03:58:28,159 =PacingReqPerHr13057 2375.0534412521242
> 2012-09-18 03:58:38,161 =PacingReqPerHr13057 2375.383005739316
> 2012-09-18 03:58:48,175 =PacingReqPerHr13057 2375.713057258422
> 2012-09-18 03:58:58,160 =PacingReqPerHr13057 2376.0422443063935
> 2012-09-18 03:59:08,192 =PacingReqPerHr13057 2376.3730727321126
> 2012-09-18 03:59:18,207 =PacingReqPerHr13057 2375.9038854561304
> 2012-09-18 03:59:28,168 =PacingReqPerHr13057 2376.232615497
> 2012-09-18 03:59:38,156 =PacingReqPerHr13057 2376.5619853019184
> 2012-09-18 03:59:48,160 =PacingReqPerHr13057 2376.892145685344
> 2012-09-18 03:59:58,160 =PacingReqPerHr13057 2377.65743067
> -
>
> tplot -o /root/color.png  -or 1024x768 -k 'CurrentPerHour' 'lines' -k
> 'PacingReqPerHr' 'lines' -if /root/color.input -tf 'date %Y-%m-%d %H:%M:%OS'
>
> I cant get to print plots in different color. Could anyone point out what am
> I doing wrong?
>
> Thanks,
> Manish
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
We're hiring! http://tinyurl.com/mirantis-openstack-engineer

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

Oh,  I´m stupid. You mean web pages with multiple tabs

 I have not tested it. but each tab can be handled easily by a different
server process.. or it can be handled in a single server process, like in a
menu. For example, this code present different options, and the process
renders different things depending on the response.

The last option is a link to a different process, while the others( wlinks)
are links that return back to the same process.
The operator <|> is the applicative operator.  a breakline is prepended to
each link:

data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read,
Show)

 mainf=   do
r <- ask $   wlink Ints (bold << "increase an Int")
<|>  br ++> wlink Strings (bold << "increase a String")
<|>  br ++> wlink Actions (bold << "Example of a string
widget with an action")
<|>  br ++> wlink Ajax (bold << "Simple AJAX example")
<|>  br ++> wlink Opt (bold << "select options")
<++ (br +++ linkShop) -- this is an ordinary XHtml link

case r of
  Ints->  clickn 0
  Strings ->  clicks "1"
  Actions ->  actions 1
  Ajax->  ajaxsample
  Opt ->  options
mainf
 where
 linkShop= toHtml $ hotlink  "shop" << "shopping"

.
Alberto

2012/9/18 Alberto G. Corona :

> Hi Jake
>
> I don´t know what you mean with multiple tabs. The user management is
> simple, anonymous clients are identified with  a cookie. if the user
> is logged (MFlow has widgets for logging-validation) the user is the
> identifier.
>
> The state of a process is associated to the client identifier and to
> the path invoked in the url requested.
>
> I don´t know if this answer your question
>
> Alberto
>
> 2012/9/18 Jake McArthur :
>> This sounds really cool.
>>
>> How do you handle users having multiple tabs?
>>
>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona 
wrote:
>>> Hi haskellers and specially the web developers.
>>>
>>> http://hackage.haskell.org/package/MFlow-0.1.5.3
>>>
>>> MFlow is a is a Web framework with some unique, and I mean unique,
>>> characteristics that I find exciting:
>>>
>>> - It is a Web application server that start and restart on-demand
>>> stateful web server processes (not request.-response)
>>>   This means that all the page navigation can be coded in a single
>>> procedure. This increases readability of the programmer code. I woul
>>> call it
>>> a anti-node.js.  Buit usual request-response (stateless) server
>>> processes are also allowed
>>>
>>> - When the process is invoqued as result of an URL request, the Web
>>> app server not only restart the process but also recover its execution
>>> state. The enclosing Workflow monad provides the thread state
>>> persistence. There are state timeouts and process timeouts defined by
>>> the programmer. Processes with no persistent state (transient) are
>>> possible.
>>>
>>> -The user interface is made of widgets. They are  formlets with added
>>> formatting,   attributes, validations, modifiers and callbacks, that
>>> are composable, so the pieces are reusable and return type safe
>>> responses to the calling process. Even the links are part of widgets
>>> and return back type safe inputs at compile time to the calling server
>>> process. Tho glue these components, ordinary applicative combinators
>>> and other extra combinators are used.
>>>
>>> - The widgets and the communication don´t make assumptions about the
>>> architecture, so it can be adapted to non-web environments. This
>>> versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and
>>> Haskell Server Pages.
>>>
>>> -The widget rendering can be converted to ByteStrings automatically
>>> with special combinators. A mix of widgets with different formats can
>>> be combined in the same source file. For example Text.Html and HSP
>>> (Haskell server pages)
>>>
>>> -These widgets can be cached, to avoid widget rendering on every
interaction.
>>>
>>> -To handle the back button, and because the processes are stateful,
>>> they can run backwards until the response match. This is transparent
>>> for the programmer, thanks to the embedded FlowM monad.
>>>
>>> -All the code is in pure Haskell. No deployment, special scripts,
>>> formats etc are necessary.
>>>
>>> -Besides automatic state persistence, TCache provides transactions and
>>> user data persistence, that can be configured for SQL databases.
>>> Default persistence in files permit very rapid prototyping. Just code
>>> and run it with runghc.
>>>
>>> -Has AJAX support
>>>
>>> All of this sounds very complicated, but really it is simple!. Most of
>>> these things are transparent. The resulting code is quite readable and
>>> has very little plumbing!
>>>
>>> There is a non trivial example that some of these functionalities
>>> embedded here that you can run:
>>>
>>>
http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html
>>>
>>> T

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Brandon Allbery]

On Tue, Sep 18, 2012 at 10:34 AM, José Lopes  wrote:

> Why do you say that _italics_ and *italics* are semantically different?
> What do you mean?
>

The parenthetical hinted at it:

(I tend to use the former for titles and such)
>
> There's a convention at work here, namely that italicized book titles and
similar are often underlined in plain text — and in plain text without
backspaces this is represented as leading and trailing _.  So there's a
semantic (i.e. content) difference even though the generated markup is the
same.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

Hi haskellers and specially the web developers.

http://hackage.haskell.org/package/MFlow-0.1.5.3

MFlow is a is a Web framework with some unique, and I mean unique,
characteristics that I find exciting:

- It is a Web application server that start and restart on-demand
stateful web server processes (not request.-response)
  This means that all the page navigation can be coded in a single
procedure. This increases readability of the programmer code. I woul
call it
a anti-node.js.  Buit usual request-response (stateless) server
processes are also allowed

- When the process is invoqued as result of an URL request, the Web
app server not only restart the process but also recover its execution
state. The enclosing Workflow monad provides the thread state
persistence. There are state timeouts and process timeouts defined by
the programmer. Processes with no persistent state (transient) are
possible.

-The user interface is made of widgets. They are  formlets with added
formatting,   attributes, validations, modifiers and callbacks, that
are composable, so the pieces are reusable and return type safe
responses to the calling process. Even the links are part of widgets
and return back type safe inputs at compile time to the calling server
process. Tho glue these components, ordinary applicative combinators
and other extra combinators are used.

- The widgets and the communication don´t make assumptions about the
architecture, so it can be adapted to non-web environments. This
versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and
Haskell Server Pages.

-The widget rendering can be converted to ByteStrings automatically
with special combinators. A mix of widgets with different formats can
be combined in the same source file. For example Text.Html and HSP
(Haskell server pages)

-These widgets can be cached, to avoid widget rendering on every interaction.

-To handle the back button, and because the processes are stateful,
they can run backwards until the response match. This is transparent
for the programmer, thanks to the embedded FlowM monad.

-All the code is in pure Haskell. No deployment, special scripts,
formats etc are necessary.

-Besides automatic state persistence, TCache provides transactions and
user data persistence, that can be configured for SQL databases.
Default persistence in files permit very rapid prototyping. Just code
and run it with runghc.

-Has AJAX support

All of this sounds very complicated, but really it is simple!. Most of
these things are transparent. The resulting code is quite readable and
has very little plumbing!

There is a non trivial example that some of these functionalities
embedded here that you can run:

 
http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html

Take a look and tell me your opinion.  I hope that you find it as
exciting as me.

 I´m looking for people  to collaborate in the development of MFlow.

Although still it is experimental, it is being used in at least one
future commercial project. So I have te commitment to continue its
development. There are many examples in the documentation and in the
package.

Alberto

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hey,

Why do you say that _italics_ and *italics* are semantically different?
What do you mean?

Cheers,
José

On 18-09-2012 15:30, Brandon Allbery wrote:
On Tue, Sep 18, 2012 at 1:05 AM, Ivan Lazar Miljenovic 
mailto:ivan.miljeno...@gmail.com>> wrote:


to it (though I agree that Markdown has some odd choices; in
particular, the ability to use both _ and * for italics whilst
requiring ** for bold).


The odd thing is, I've found that I use those constructs "naturally" 
(i.e. when simply writing text in a text-only medium) in pretty much 
exactly the way Markdown uses them.  _italics_ and *italics* are 
semantically different (I tend to use the former for titles and such) 
but are both usually italics in my normal usage.  (There's also 
/italics/ but that is not very widespread.)  I do tend to use # 
instead of = for headings but that's kinda stolen (and mutated) from a 
different variety of non-natural markup.


I suspect that when the dust has settled, it'll turn out that Markdown 
is pretty much right.  Maybe with some tweaking, but largely it 
represents (and IIRC was derived from) actual in-the-wild textual usage.


--
brandon s allbery allber...@gmail.com 
wandering unix systems administrator (available) (412) 475-9364 vm/sms



--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Brandon Allbery]

On Tue, Sep 18, 2012 at 1:05 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> to it (though I agree that Markdown has some odd choices; in
> particular, the ability to use both _ and * for italics whilst
> requiring ** for bold).
>

The odd thing is, I've found that I use those constructs "naturally" (i.e.
when simply writing text in a text-only medium) in pretty much exactly the
way Markdown uses them.  _italics_ and *italics* are semantically different
(I tend to use the former for titles and such) but are both usually italics
in my normal usage.  (There's also /italics/ but that is not very
widespread.)  I do tend to use # instead of = for headings but that's kinda
stolen (and mutated) from a different variety of non-natural markup.

I suspect that when the dust has settled, it'll turn out that Markdown is
pretty much right.  Maybe with some tweaking, but largely it represents
(and IIRC was derived from) actual in-the-wild textual usage.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] foldl vs. foldr

[Chaddaï Fouché]

>
> 18.09.2012, 16:32, "Jan Stolarek" :
> > Hi list,
> >
> > I have yet another question about folds. Reading here and there I
> encountered statements that
> > foldr is more important than foldl, e.g. in this post on the list:
> > http://www.haskell.org/pipermail/haskell-cafe/2012-May/101338.html
> > I want to know are such statements correct and, if so, why? I am aware
> that foldl' can in some
> > circumstances operate in constant space, while foldr can operate on
> infinite lists if the folding
> > function is lazy in the second parameter. Is there more to this subject?
>

Basically the difference is that foldr is really the natural catamorphism
for the list type, that is for a type like :

data MyType = Zero | One A | Two B C | Recurse MyType

the natural catamorphism is a function that takes four arguments by which
it will replace the four constructor so as to deconstruct a value of MyType
:

myTypeCata :: r -> (A -> r) -> (B -> C -> r) -> (r -> r)   ->(MyType ->
r)
myTypeCata z o t re Zero = z
myTypeCata z o t re (One a) = o a
myTypeCata z o t re (Two b c) = t b c
myTypeCata z o t re (Recurse myType) = re (myTypeCata z o t re myType)

So foldr is the natural catamorphism for the list type and foldl is not.

-- 
Jedaï
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hello Stefan,

Thank you for the input.

Cheers,
José

On 18-09-2012 14:43, Stefan Monnier wrote:

The problem with that is that some people DO end some headings with
a full stop; for them your special syntax is not natural.

Markdown/ReST is already using the "no syntax" idea (e.g. compared to
pre-wiki markup such a LaTeX or Texinfo), so he's simply trying to push
this idea further.

I suspect it'll be difficult.


What if I want to use indentation to express quotation instead?

I think this one is solvable: a paragraph that's more indented than the
previous heading can be considered a quote.


 Stefan


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Stefan Monnier]

> The problem with that is that some people DO end some headings with
> a full stop; for them your special syntax is not natural.

Markdown/ReST is already using the "no syntax" idea (e.g. compared to
pre-wiki markup such a LaTeX or Texinfo), so he's simply trying to push
this idea further.

I suspect it'll be difficult.

> What if I want to use indentation to express quotation instead?

I think this one is solvable: a paragraph that's more indented than the
previous heading can be considered a quote.


Stefan


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] foldl vs. foldr

[Miguel Mitrofanov]

Hi Jan!

foldl always traverses the list to the end; in particular, if there is no end, 
it would hang forever (unless the compiler is smart enough to detect an 
infinite loop, in which case it can throw an error). On the other hand, if the 
first argument is lazy enough, foldr would stop before processing the complete 
list. So, for example

foldr (\_ _ -> ()) () [1..]

would give an answer, while

foldl (\_ _ -> ()) () [1..]

would hang.

In particular, you can reimplement foldl in terms of foldr, like that:

foldl op i ls = foldr (flip op) i (reverse ls)

but if you attempt to do the same with foldr:

foldr op i ls = foldl (flip op) i (reverse ls)

you would end up with a function which is more strict than the real foldr.

18.09.2012, 16:32, "Jan Stolarek" :
> Hi list,
>
> I have yet another question about folds. Reading here and there I encountered 
> statements that
> foldr is more important than foldl, e.g. in this post on the list:
> http://www.haskell.org/pipermail/haskell-cafe/2012-May/101338.html
> I want to know are such statements correct and, if so, why? I am aware that 
> foldl' can in some
> circumstances operate in constant space, while foldr can operate on infinite 
> lists if the folding
> function is lazy in the second parameter. Is there more to this subject? 
> Properties that I
> mentioned are more of technical nature, not theoretical ones. Are there any 
> significant
> theoretical advantages of foldr? I read Bird's and Wadler's "Introduction to 
> functional
> programming" and it seems to me that foldl and foldr have the same properties 
> and in many cases
> are interchangeable.
>
> Greets,
> Janek
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type error with Type families

[Marco Túlio Pimenta Gontijo]

On Mon, Sep 17, 2012 at 6:27 PM, Alexander Solla  wrote:
>
>
> On Mon, Sep 17, 2012 at 10:59 AM, Ryan Ingram  wrote:
>>
>> The problem is that the function 'element' is ambiguous, for the reasons
>> MigMit pointed out.
>>
>> The standard solution to this problem is to add a dummy argument to fix
>> the type argument to the type function:
>>
>> data Proxy a = Proxy
>>
>> class ... => ReplaceOneOf full where
>> type Item full ::  *
>>
>> -- implementations can just ignore the first argument
>> element :: Proxy full -> Item full -> [Item full] -> Bool
>>
>> replaceOneOf :: ...
>> ...
>> | element (Proxy :: Proxy full) x from = ...
>>
>> Now the choice of which 'element' to use can be determined by the type of
>> the proxy.
>
>
> It might be best if we point users to a "standard" Proxy type so we don't
> end up lots of packages defining distinct/incompatible types for the same
> code.
>
> Edward Kmett's "tagged" package has a Proxy type.

Thank you for your answers.

Greetings.
(...)
-- 
marcot
http://marcot.eti.br/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cost-centre names

[Marco Túlio Pimenta Gontijo]

Hi Felipe.

On Sun, Sep 16, 2012 at 1:57 PM, Felipe Almeida Lessa
 wrote:
> On Sun, Sep 16, 2012 at 7:57 AM, Marco Túlio Pimenta Gontijo
>  wrote:
>> I have a question about cost-centre names, as shown on .hp files
>> produced by +RTS -hc.  They have the form A/B/C/D/E/F/G/...  Usually,
>> it seems that it means A, called by B, called by C, etc, but that's
>> not the case sometimes.  I have a case here (called with -L200):
>> replaceOneOf’/clean/tagsText/anyTag/dropTagClose/parseObservations/specificTagText/tagText/parseOab/dropTagText/dropTill/tag/tagOpen...
>>
>> tagsText calls clean which calls replaceOneOf', but anyTag does not
>> call tagsText.  parseObservations calls dropTagClose which calss
>> anyTag, but specificTagText does not call parseObservations.  They
>> seem to be grouped by three.
>>
>> Is this correct?  How should I interpret it?
>
> That's probably because anyTag took a closure as argument, and that
> closure called tagsText when forced.  Does that make sense?

That makes sense, thanks.

Greetings.
(...)
-- 
marcot
http://marcot.eti.br/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] foldl vs. foldr

[Jan Stolarek]

Hi list,

I have yet another question about folds. Reading here and there I encountered 
statements that 
foldr is more important than foldl, e.g. in this post on the list: 
http://www.haskell.org/pipermail/haskell-cafe/2012-May/101338.html
I want to know are such statements correct and, if so, why? I am aware that 
foldl' can in some 
circumstances operate in constant space, while foldr can operate on infinite 
lists if the folding 
function is lazy in the second parameter. Is there more to this subject? 
Properties that I 
mentioned are more of technical nature, not theoretical ones. Are there any 
significant 
theoretical advantages of foldr? I read Bird's and Wadler's "Introduction to 
functional 
programming" and it seems to me that foldl and foldr have the same properties 
and in many cases 
are interchangeable.

Greets,
Janek

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hi,

Like I said it's a tradeoff. I will try to use this philosophy as much as
possible. But it's also important not to be fundamentalist. We'll see
as it goes.

I like that strikethrough. You are right about the quotes, but we can
leave " for quoting and use the ' for something else.

Cheers,
José

On 18-09-2012 13:18, Ivan Lazar Miljenovic wrote:

On 18 September 2012 21:53, José Lopes  wrote:

Hello Ivan,

I agree with your point: if you want a heading that ends with a punctuation
sign then you cannot do it in Fmark (for now). That gives me something to
think about. However, I will still look for a way that avoids (as much as
possible) special syntax. Do you have any suggestion?

I also agree with you on the "natural" conventions. I want to find a good
tradeoff between syntax and expressiveness. In other words, I want to
avoid as much those "odd choices" you mentioned. For example, I have
been thinking seriously about emphasis and what would be a good way
to do it. So far I could only come up with quotes (either " or '). What do
you think?

I think that _emphasis_ is pretty "natural", as is *bold* and possibly
-strikethrough-.

But you _are_ adding in some aspects of markup now.

Using quotes is bad because what happens if you're actually quoting someone? ;-)


Cheers,
José


On 18-09-2012 06:05, Ivan Lazar Miljenovic wrote:

On 18 September 2012 13:57, José Lopes  wrote:

Hello Kris,

Thank you for your email.

At this moment, Fmark is not as powerful as Markdown, also because Fmark
just started.
Markdown offers things such as Blockquotes, Lists, Code blocks, links,
emphasis, images, etc.
Fmark does not offer as many features: for now, there are only
paragraphs,
headings,
subsections (endless nesting) and footnotes. In the near future, I want
to
bolds/italics,
ordered and unordered lists, links, and later on as many elements as
possible :)

The problem with Fmark is also its greatest feature. While other markup
languages
introduce special syntactic characters to give meaning to the document's
elements,
I would like to take a different approach: I want to use characters that
people already
use in document writing to achieve the same result. For example, in
Mediawiki a
heading is some text surrounded by equal signs. But in Fmark a heading is
simply some
text that does not end in a punctuation character, such as period or an
exclamation mark.
I argue that this is a more "natural" approach.

Is it possible to override this?  What happens if I want a heading of
"This is the greatest Heading Ever!" ?

"Natural" conventions seem to be to be rather hacky and with lots of
corner cases; I think it's better to define a specific syntax for
markup (e.g. what is the "natural" way of emphasising text?) and stick
to it (though I agree that Markdown has some odd choices; in
particular, the ability to use both _ and * for italics whilst
requiring ** for bold).


I want to find a natural way of not burdening the user with the task of
having to learn
some special syntax in order to write a document. Instead I want to find
"natural" ways
of writing and use those ways to reconstruct the elements in a document.
Of
course,
what is natural is subjective and that is why I want to find a good
tradeoff
between
expressiveness and simplicity in the syntax. For example, in Fmark a
footnote is some
text surrounded by square brackets. Maybe you find this natural, maybe
you
don't. If a
handful of people defend a more natural way of writing footnotes I want
to
implement
the way they say. If there is a more natural way of doing this I want to
find it. But for now
I think square brackets are better than the equal signs or any other
strange
syntactic
character such as exclamation marks and so on...

Another thing about Fmark is styles. I want to use fmark personally to
write
papers, using
Latex as backend. While experimenting with previous versions of Fmark I
realized that I
could not specify the title, the author, the date, and the abstract.
which
are essential in a
paper. I came up with an idea which I think is quite interesting. I wrote
another document
also using Fmark which only had the words "Title", "Author", "Date", and
"Abstract". And
then I combined these two documents together, such that, Fmark associated
title, author,
date and abstract, with the corresponding content. I thought the idea was
interesting
because the content and style documents have both the same structure and
are
both
written in Fmark. Of course, there is still a long way to go, in order to
be
able to fully
customize a document.

But styles are a good and simple approach, similar to document classes in
Latex: the idea is
to write one document (content) and then use multiple (predefined, user
defined) styles, such
as, article, report, etc, to stylize your document. Another interesting
thing I have been thinking
about (but not implemented yet) is recursion in document styling. In a
way,
weaving a style
with content can be compared to matching a regular expres

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[Ivan Lazar Miljenovic]

On 18 September 2012 21:53, José Lopes  wrote:
> Hello Ivan,
>
> I agree with your point: if you want a heading that ends with a punctuation
> sign then you cannot do it in Fmark (for now). That gives me something to
> think about. However, I will still look for a way that avoids (as much as
> possible) special syntax. Do you have any suggestion?
>
> I also agree with you on the "natural" conventions. I want to find a good
> tradeoff between syntax and expressiveness. In other words, I want to
> avoid as much those "odd choices" you mentioned. For example, I have
> been thinking seriously about emphasis and what would be a good way
> to do it. So far I could only come up with quotes (either " or '). What do
> you think?

I think that _emphasis_ is pretty "natural", as is *bold* and possibly
-strikethrough-.

But you _are_ adding in some aspects of markup now.

Using quotes is bad because what happens if you're actually quoting someone? ;-)

>
> Cheers,
> José
>
>
> On 18-09-2012 06:05, Ivan Lazar Miljenovic wrote:
>>
>> On 18 September 2012 13:57, José Lopes  wrote:
>>>
>>> Hello Kris,
>>>
>>> Thank you for your email.
>>>
>>> At this moment, Fmark is not as powerful as Markdown, also because Fmark
>>> just started.
>>> Markdown offers things such as Blockquotes, Lists, Code blocks, links,
>>> emphasis, images, etc.
>>> Fmark does not offer as many features: for now, there are only
>>> paragraphs,
>>> headings,
>>> subsections (endless nesting) and footnotes. In the near future, I want
>>> to
>>> bolds/italics,
>>> ordered and unordered lists, links, and later on as many elements as
>>> possible :)
>>>
>>> The problem with Fmark is also its greatest feature. While other markup
>>> languages
>>> introduce special syntactic characters to give meaning to the document's
>>> elements,
>>> I would like to take a different approach: I want to use characters that
>>> people already
>>> use in document writing to achieve the same result. For example, in
>>> Mediawiki a
>>> heading is some text surrounded by equal signs. But in Fmark a heading is
>>> simply some
>>> text that does not end in a punctuation character, such as period or an
>>> exclamation mark.
>>> I argue that this is a more "natural" approach.
>>
>> Is it possible to override this?  What happens if I want a heading of
>> "This is the greatest Heading Ever!" ?
>>
>> "Natural" conventions seem to be to be rather hacky and with lots of
>> corner cases; I think it's better to define a specific syntax for
>> markup (e.g. what is the "natural" way of emphasising text?) and stick
>> to it (though I agree that Markdown has some odd choices; in
>> particular, the ability to use both _ and * for italics whilst
>> requiring ** for bold).
>>
>>> I want to find a natural way of not burdening the user with the task of
>>> having to learn
>>> some special syntax in order to write a document. Instead I want to find
>>> "natural" ways
>>> of writing and use those ways to reconstruct the elements in a document.
>>> Of
>>> course,
>>> what is natural is subjective and that is why I want to find a good
>>> tradeoff
>>> between
>>> expressiveness and simplicity in the syntax. For example, in Fmark a
>>> footnote is some
>>> text surrounded by square brackets. Maybe you find this natural, maybe
>>> you
>>> don't. If a
>>> handful of people defend a more natural way of writing footnotes I want
>>> to
>>> implement
>>> the way they say. If there is a more natural way of doing this I want to
>>> find it. But for now
>>> I think square brackets are better than the equal signs or any other
>>> strange
>>> syntactic
>>> character such as exclamation marks and so on...
>>>
>>> Another thing about Fmark is styles. I want to use fmark personally to
>>> write
>>> papers, using
>>> Latex as backend. While experimenting with previous versions of Fmark I
>>> realized that I
>>> could not specify the title, the author, the date, and the abstract.
>>> which
>>> are essential in a
>>> paper. I came up with an idea which I think is quite interesting. I wrote
>>> another document
>>> also using Fmark which only had the words "Title", "Author", "Date", and
>>> "Abstract". And
>>> then I combined these two documents together, such that, Fmark associated
>>> title, author,
>>> date and abstract, with the corresponding content. I thought the idea was
>>> interesting
>>> because the content and style documents have both the same structure and
>>> are
>>> both
>>> written in Fmark. Of course, there is still a long way to go, in order to
>>> be
>>> able to fully
>>> customize a document.
>>>
>>> But styles are a good and simple approach, similar to document classes in
>>> Latex: the idea is
>>> to write one document (content) and then use multiple (predefined, user
>>> defined) styles, such
>>> as, article, report, etc, to stylize your document. Another interesting
>>> thing I have been thinking
>>> about (but not implemented yet) is recursion in document styling. In a
>>> way,
>>> weaving a 

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hello Richard,

When you say "(for) some people (...) you special syntax is not natural"
that's a good thing. I want these people involved in the project. I want
to understand what they find natural in order to weigh the options and
make a proper decision.

On the README file in the github page you will find a brief explanation
of the markup elements. I need to elaborate you that though because
I feel I explain it too fast.
https://github.com/jabolopes/fmark

Let me answer your questions about sections. The amount of indentation
is not fixed. You can use whatever you want. There is also no nesting limit
in Fmark, however, there is a nesting limit in the Latex backend. For now,
quotations, block quotes, source code embedding, etc, are not implemented.
Those will be added in the future.

About embedding a Fmark document in another document. That seems to
be a very cool feature. I will definitely think about it! Maybe you can come
up with a "natural" way of doing it?

Cheers,
José


On 18-09-2012 06:19, Richard O'Keefe wrote:

On 18/09/2012, at 3:57 PM, José Lopes wrote:

The problem with Fmark is also its greatest feature. While other markup 
languages
introduce special syntactic characters to give meaning to the document's 
elements,
I would like to take a different approach: I want to use characters that people 
already
use in document writing to achieve the same result. For example, in Mediawiki a
heading is some text surrounded by equal signs. But in Fmark a heading is 
simply some
text that does not end in a punctuation character, such as period or an 
exclamation mark.
I argue that this is a more "natural" approach.

The problem with that is that some people DO end some headings with
a full stop; for them your special syntax is not natural.

I want to find a natural way of not burdening the user with the task of having 
to learn
some special syntax in order to write a document.

You haven't found it.  What you *have* is very special syntax expressed using
several methods, AND IT IS NOT DOCUMENTED.  I have read the examples, and I can
find nothing explaining what the syntax is.

For example, I find indenting subsections rather unnatural and error-prone.
(For example, moving a paragraph from a deep location to a shallow one would
create a new subsection unintentionally.)
Is the amount of indentation fixed?  How many levels of subsections are
supported?  What if I want to use indentation to express quotation instead?
How do I embed source code?  How can you get an example of Fmark in an
Fmark document without having it acted on?  I could go on and on with
questions about syntax.




--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANNOUNCE] Fmark markup language

[José Lopes]

Hello Ivan,

I agree with your point: if you want a heading that ends with a punctuation
sign then you cannot do it in Fmark (for now). That gives me something to
think about. However, I will still look for a way that avoids (as much as
possible) special syntax. Do you have any suggestion?

I also agree with you on the "natural" conventions. I want to find a good
tradeoff between syntax and expressiveness. In other words, I want to
avoid as much those "odd choices" you mentioned. For example, I have
been thinking seriously about emphasis and what would be a good way
to do it. So far I could only come up with quotes (either " or '). What do
you think?

Cheers,
José

On 18-09-2012 06:05, Ivan Lazar Miljenovic wrote:

On 18 September 2012 13:57, José Lopes  wrote:

Hello Kris,

Thank you for your email.

At this moment, Fmark is not as powerful as Markdown, also because Fmark
just started.
Markdown offers things such as Blockquotes, Lists, Code blocks, links,
emphasis, images, etc.
Fmark does not offer as many features: for now, there are only paragraphs,
headings,
subsections (endless nesting) and footnotes. In the near future, I want to
bolds/italics,
ordered and unordered lists, links, and later on as many elements as
possible :)

The problem with Fmark is also its greatest feature. While other markup
languages
introduce special syntactic characters to give meaning to the document's
elements,
I would like to take a different approach: I want to use characters that
people already
use in document writing to achieve the same result. For example, in
Mediawiki a
heading is some text surrounded by equal signs. But in Fmark a heading is
simply some
text that does not end in a punctuation character, such as period or an
exclamation mark.
I argue that this is a more "natural" approach.

Is it possible to override this?  What happens if I want a heading of
"This is the greatest Heading Ever!" ?

"Natural" conventions seem to be to be rather hacky and with lots of
corner cases; I think it's better to define a specific syntax for
markup (e.g. what is the "natural" way of emphasising text?) and stick
to it (though I agree that Markdown has some odd choices; in
particular, the ability to use both _ and * for italics whilst
requiring ** for bold).


I want to find a natural way of not burdening the user with the task of
having to learn
some special syntax in order to write a document. Instead I want to find
"natural" ways
of writing and use those ways to reconstruct the elements in a document. Of
course,
what is natural is subjective and that is why I want to find a good tradeoff
between
expressiveness and simplicity in the syntax. For example, in Fmark a
footnote is some
text surrounded by square brackets. Maybe you find this natural, maybe you
don't. If a
handful of people defend a more natural way of writing footnotes I want to
implement
the way they say. If there is a more natural way of doing this I want to
find it. But for now
I think square brackets are better than the equal signs or any other strange
syntactic
character such as exclamation marks and so on...

Another thing about Fmark is styles. I want to use fmark personally to write
papers, using
Latex as backend. While experimenting with previous versions of Fmark I
realized that I
could not specify the title, the author, the date, and the abstract. which
are essential in a
paper. I came up with an idea which I think is quite interesting. I wrote
another document
also using Fmark which only had the words "Title", "Author", "Date", and
"Abstract". And
then I combined these two documents together, such that, Fmark associated
title, author,
date and abstract, with the corresponding content. I thought the idea was
interesting
because the content and style documents have both the same structure and are
both
written in Fmark. Of course, there is still a long way to go, in order to be
able to fully
customize a document.

But styles are a good and simple approach, similar to document classes in
Latex: the idea is
to write one document (content) and then use multiple (predefined, user
defined) styles, such
as, article, report, etc, to stylize your document. Another interesting
thing I have been thinking
about (but not implemented yet) is recursion in document styling. In a way,
weaving a style
with content can be compared to matching a regular expression.

Anyway, these are just some key ideas. I see Fmark as a work in progress and
in a way as a
research project, trying to find a natural way of writing documents while
escaping as much
as possible from the syntax of a programming language. I also have a
metagoal with this
project: if my father (the non programming guy) could use it to write his
PhD dissertation,
I would be quite happy :)

If you have any more questions I would be happy to answer.
But if you're interested in using markup languages for blogs perhaps a HTML
backend
in Fmark would be more interesting for you. Although, XML + JavaScript + CSS
is also po

Re: [Haskell-cafe] Either Monad and Laziness

[Malcolm Wallace]

On 12 Sep 2012, at 16:04, Eric Velten de Melo wrote:

 The behaviour I want to achieve is like this: I want the program when
 compiled to read from a file, parsing the PGM and at the same time
 apply transformations to the entries as they are read and write them
 back to another PGM file.
>>> 
>>> Such problems are the main motivation for iteratees, conduits, pipes,
>>> etc. Every such library contains procedures for doing exactly what you
>>> want.
>>> 
> 
> It would be really awesome, though, if it were possible to use a
> parser written in Parsec with this, in the spirit of avoiding code
> rewriting and enhancing expressivity and abstraction.

The polyparse library on Hackage is another parser combinator framework that 
allows lazy incremental parsing.
http://hackage.haskell.org/package/polyparse

A PDF paper/tutorial is here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.1754&rep=rep1&type=pdf

Regards,
Malcolm

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Kim-Ee Yeoh]

Oleg,

Let me try to understand what you're saying here:

(1) Church encoding was discovered and investigated in an untyped setting.
I understand your tightness criterion to mean surjectivity, the absence of
which means having to deal with junk.

(2) Church didn't give an encoding for pattern-matching to match with
construction. Boehm and Berarducci did. So properly speaking, tail and pred
for Church-encoded lists and nats are trial-and-error affairs. But the
point is they need not be if we use B-B encoding, which looks _exactly_ the
same, except one gets a citation link to a systematic procedure.

So it looks like you're trying to set the record straight on who actually
did what.


-- Kim-Ee


On Tue, Sep 18, 2012 at 3:27 PM,  wrote:

>
> There has been a recent discussion of ``Church encoding'' of lists and
> the comparison with Scott encoding.
>
> I'd like to point out that what is often called Church encoding is
> actually Boehm-Berarducci encoding. That is, often seen
>
> > newtype ChurchList a =
> > CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
>
> (in 
> http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs
>  )
>
> is _not_ Church encoding. First of all, Church encoding is not typed
> and it is not tight. The following article explains the other
> difference between the encodings
>
> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
>
> Boehm-Berarducci encoding is very insightful and influential. The
> authors truly deserve credit.
>
> P.S. It is actually possible to write zip function using Boehm-Berarducci
> encoding:
> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[Ivan Lazar Miljenovic]

On 18 September 2012 18:27,   wrote:
>
> There has been a recent discussion of ``Church encoding'' of lists and
> the comparison with Scott encoding.
>
> I'd like to point out that what is often called Church encoding is
> actually Boehm-Berarducci encoding. That is, often seen
>
>> newtype ChurchList a =
>> CL { cataCL :: forall r. (a -> r -> r) -> r -> r }
>
> (in http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )
>
> is _not_ Church encoding. First of all, Church encoding is not typed
> and it is not tight. The following article explains the other
> difference between the encodings
>
> http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
>
> Boehm-Berarducci encoding is very insightful and influential. The
> authors truly deserve credit.
>
> P.S. It is actually possible to write zip function using Boehm-Berarducci
> encoding:
> http://okmij.org/ftp/ftp/Algorithms.html#zip-folds

You have one too many "ftp/" in there (in case others get confused
about why the link fails).

>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Church vs Boehm-Berarducci encoding of Lists

[oleg]

There has been a recent discussion of ``Church encoding'' of lists and
the comparison with Scott encoding.

I'd like to point out that what is often called Church encoding is
actually Boehm-Berarducci encoding. That is, often seen

> newtype ChurchList a =
> CL { cataCL :: forall r. (a -> r -> r) -> r -> r }

(in http://community.haskell.org/%7Ewren/list-extras/Data/List/Church.hs )

is _not_ Church encoding. First of all, Church encoding is not typed
and it is not tight. The following article explains the other
difference between the encodings

http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html

Boehm-Berarducci encoding is very insightful and influential. The
authors truly deserve credit.

P.S. It is actually possible to write zip function using Boehm-Berarducci
encoding:
http://okmij.org/ftp/ftp/Algorithms.html#zip-folds




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Dynamic Programming with Data.Vector

[Roman Leshchinskiy]

Myles C. Maxfield wrote:
> Aha there it is! Thanks so much. I didn't see it because it's under the
> "Unfolding" section instead of the "Construction" section.

You're quite right, having a separate "Unfolding" section isn't the best
idea. I'll fix this.

Roman

> On Mon, Sep 17, 2012 at 6:07 AM, Roman Leshchinskiy
> wrote:
>
>> Myles C. Maxfield wrote:
>> >
>> > Overall, I'm looking for a function, similar to Data.Vector's
>> 'generate'
>> > function, but instead of the generation function taking the
>> destination
>> > index, I'd like it to take the elements that have previously been
>> > constructed. Is there such a function? If there isn't one, is this
>> kind
>> of
>> > function feasible to write? If such a function doesn't exist and is
>> > feasible to write, I'd be happy to try to write and contribute it.
>>
>> Indeed there is, it's called constructN (or constructrN if you want to
>> construct it right to left).
>>
>> Roman
>>
>>
>>
>>
>



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe