How do I derive a regular grammars from this regular expression? - regex

How do I derive a regular grammars from this regular expression?
(a or b)*ba(ba)*
I'm stuck with the last part
so
S -> A | B | C
A -> aA | bA
B -> bC
C -> cD
D->bE ?
E->af | ^ ?
Any help would be appreciated thanks!

S → (a + b)* b a (b a)*
The initial (a + b)* gives three possibilities: it can expand to a (a + b)*, or it can expand to b (a + b)*, or it can be empty:
S → a (a + b)* b a (b a)* = aS
S → b (a + b)* b a (b a)* = bS
S → b a (b a)* = A
For A, the initial b a is fully constrained, so we clearly must write:
A → b a (b a)* = bB
B → a (b a)* = aC
For C, (b a)* gives two possibilities: it can expand to b a (b a)*, or it can be empty:
C → b a (b a)* = bB
C → ε
(Using the fact that a (b a)* matched a non-terminal we'd already defined. Failing that, we could instead have written:
C → b a (b a)* = bD
D → a (b a)* = aC
C → ε
.)
Putting it together:
S → aS
S → bS
S → A
A → bB
B → aC
C → bB
C → ε

Related

Are there any languages such that they are proper subsets of each other and satisfy these conditions

Are there languages such that A ⊂ B ⊂ C ⊂ D ⊂ E over the alphabet {a,b,c} where:
A is not context-free
B is context-free and non-regular
C is regular
D is non regular
E is regular and not {a,b,c}*
Start by taking non-context-free language A over {a,b}. For example A = { ww | w \in {a,b}*}, but any other would also work.
You can then build the other languages on top of that:
B = {a,b}* U {a^i c^i | i >= 0}
C = {a,b}* U {a,c}*
D = {a,b}* U {a,c}* U {b^i c^i | i>= 0}
E = {a,b}* U {a,c}* U {b,c}*
You can then verify for each of these that they have the desired properties.
First, let us simplify this and take care of E by just not using c in any language and making E the language (a + b)*. Next, let us deal with D by making it the same as E, but with all strings of prime length greater than two removed. We can choose C to be the set of all even-length strings over {a, b}: (aa + ab + ba + bb)*. For a context-free and non-regular language we can choose the set of even-length palindromes over {a, b}: S -> aSa | bSb | e. Finally, we can choose as A the set of even-length palindromes over {a, b} which begin with a prime number of as.
We might have tried getting rid of D by making it the union of C and some language involving only b, then making C equal to a* and then trying to find A and B using only a... but we might have had trouble finding a context-free non-regular language involving only one symbol.

F#. Expecting a type supporting the operator '-' but given a function type

I'm new to F# and have some compilation problems in this code fragment:
let rec mywhile p f s =
if p s then s
else
let s1 = f s
mywhile p f s1
let eps = 0.001
let dichotomy f a b =
let out (a, b) = a
let c a b = (a + b) / 2.
out (mywhile (fun (a, b) -> a - b < eps)
(fun (a, b) -> if f c * f a < 0 then (a, c) else (c, b))
(a, b))
In particular, here: a - b < eps, then (a, c)
Expecting a type supporting the operator '-' but given a function type. You may be missing an argument to a function.
Since c is defined as c : float -> float -> float, and you're writing f c, it must mean that f : (float -> float -> float) -> 'x (for some 'x that we don't know yet).
Since you also write f a, and we already know that f's argument is float -> float -> float, it means that a : float -> float -> float.
And this, in turn means that you can't subtract anything from a. It's a function, not a number. This is what the compiler is telling you.
Usually, when you get yourself in a situation where you don't understand what your type are doing, go ahead and add some type annotations. They will provide anchors for the compiler, sort of walls that the type inference cannot cross, and thus will contain the type inconsistencies.
For example, if you specify the type of f:
let dichotomy (f : float -> float) a b =
...
this immediately reveals an error at f c, stating that c was expected to be a float, but actually is a function.
If I understand correctly, what you meant to do is to apply f to (c a b), not to c itself. And then, correspondingly, return that same value in the tuples (a, c) and (c, b):
out (mywhile (fun (a, b) -> a - b < eps)
(fun (a, b) ->
let d = c a b
if f d * f a < 0. then (a, d) else (d, b)
)
(a, b))
(also, your zero was an int; I made it into a float by adding a dot after it)

Writing foldl as foldr confusion

I know there are other posts about this, but mine is slightly different.
I have a function that performs the task of foldl, using foldr. I have the solution given to me, but would like help understanding.
foldlTest:: (b -> a -> b) -> [a] -> (b -> b)
foldlTest f xs = foldr (\x r b -> r (f b x))
(\b -> b)
xs
And It is called using something like this:
foldlTest (-) [1,2,3] 10 = -4
First thing I understand is that my function takes in 2 arguments, but 3 are given in the above test case. This means that the 10 will take part in a lambda expression I assume.
1) Does the 10 take the place of the b in b -> b? (then the b would be the initial accumulator value)
What I don't understand is what the (\x r b -> r (f b x)) part does.
2) What is the value of each of the variables? I am very confused about this lambda function.
3) What exactly does the lambda function do and how is it different from a regular foldr?
OK, since none of our resident Haskell experts has yet stepped up to explain this, I thought I'd have a go. Please everyone, feel free to correct anything you see wrong, because I'm really just feeling my way towards the answer here, and the following will by its very nature be a bit rambling.
First, as always in Haskell, it's a good idea to look at the types:
Prelude> :t foldl
foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b
Since we're just interested in lists here, and not generic Foldables, let's specialise this to:
foldl :: (b -> a -> b) -> b -> [a] -> b
and compare with the function you've been given:
foldlTest:: (b -> a -> b) -> [a] -> (b -> b)
Since Haskell functions are curried, which is another way of saying that -> arrows in type signatures are right associative, the last pair of parentheses there is unnecessary, so this is the same as:
foldlTest:: (b -> a -> b) -> [a] -> b -> b
Comparing with that for foldl above, we see that they're identical except for the fact that the last two parameters - the [a] and the b - have been flipped over.
So we can already observe that, while the library function foldl takes a fold function, a starting accumulator, and a list to fold, to produce a new accumulator, the foldlTest version takes a fold function, a list to fold, and a starting accumulator, to produce a new accumulator. That sounds like the exact same thing, which it is, but if we now reintroduce the pair of brackets which I took off a few steps ago, we see that foldlTest, in the form you've shown, can be thought of as:
taking a fold function and a list, and producing a function b -> b which describes how folding over the list transforms the initial accumulator into the final result.
Note in particular that what it returns, in this formulation, is indeed a function.
So now we're ready to look at the actual implementation that you've seen:
foldlTest f xs = foldr (\x r b -> r (f b x))
(\b -> b)
xs
I'll be the first to admit that this is rather complicated, even confusing. As ever, lets examine the types.
The input types are easy. We know from the above discussion that f has type b -> a -> b, and xs has type [a].
OK, what about that lambda? Let's take it in stages:
It takes 3 arguments, x, r and b, in that order.
The result of the function call is r (f b x). This already tells us a lot, if we sit down and think about it!
For one, we know f has type b -> a -> b, so from f b x we know that b has type b and x has type a.
As for r, we see that it must be a function, because it's applied to f b x. And we know the latter has type b (from the type signature of f). So r has type b -> c, for some type c.
Therefore our complicated lambda function has the type a -> (b -> c) -> b -> c, where c is some type we haven't yet determined.
Now comes a key point. This lambda is presented as the first argument (the fold function) to the foldr function. Therefore it must have the type d -> e -> e, for some types d and e.
Remember that functions are curried, and although it seems like the lambda's signature takes 3 arguments, we can reduce it to 2 by rewriting as a -> (b -> c) -> (b -> c). That's an exact match for the signature we know foldr is looking for, with d equal to a and e equal to b -> c.
And it we specialise foldr's signature so that it accepts this type of function, we find that it is:
foldr :: (a -> (b -> c) -> (b -> c)) -> (b -> c) -> [a] -> (b -> c)`
We still don't know what c is - but we don't have to wonder much longer. The above is the signature for a fold which goes over a list of as, and produces a function from b to c. The next argument to foldr, which is of type b -> c, is given (by the implementation we're trying to decipher) as \b -> b. This is just the identity function, of course, and crucially it is a function from a type to itself. So the b -> c type must actually be b -> b, or in other words c was the same as b all along!
So that lambda must have the following type:
a -> (b -> b) -> (b -> b)
It takes an a, and an endomorphism on b (that just means a function from b to itself), and returns another endomorphism on b. And this is the function we will fold the list of as with, taking the identity function as a starting point, to produce the endomorphism b -> b that will implement the left fold we're after.
The above type signature on its own doesn't give us much clue of how to implement it, given that a and b could be anything. However, we do have our function f that relates them - recall it takes a b and an a, and produces a b. Given that (by undoing the currying again), the above function requires us, given an a, a b -> b function, and a b, to produce another b, I can only see two non-trivial ways to do it:
apply the function to the b, then apply f to the a and the result.
apply f to the a and the b, then apply the b -> b function to the result
The second of these two is exactly what that lambda you are asking about does, as hopefully is now obvious from looking at it. (The first option would be written \x r b -> f (r b) x. I'm not actually sure what overall effect this would produce, although I haven't thought about it much.)
I've covered a lot of ground, although it feels like more than it really is, because I've tried to be very painstaking. To recap, what the foldlTest function does is, given a list of as and a function f :: b -> a -> b, produces a function b -> b that is built by starting with the identity function, and walking right-to-left along the list, changing the current function r :: b -> b to the one that sends b to r (f b x) - where x :: a is the element of the list we are currently at.
That's a rather algorithmic description of what foldlTest does. Let's try to see what it does to an actual list - not a concrete one, but let's say a 3-element list [a1, a2, a3]. We start with the identity function \b -> b, and successively transform it into:
b -> f b a3 (recall that r starts as the identity function)
b -> f (f b a2) a3 (this is just substituting the previous function as r into \b -> r (f b x), with a2 now playing the role of x)
b -> f (f (f b a1) a2) a3
I hope you can now see that this looks an awful lot like folding the list from the left with the same function f. And by "looks an awful lot like", I actually mean it's identical! (If you haven't seen or tried it before, try to write out the successive stages of foldl f b [a1, a2, a3] and you'll see the identical pattern.)
So apologies again that this has been a bit rambling, but I hope this has given you enough information to answer the questions you asked. And don't worry if it makes your brain hurt a bit - it does mine too! :)
The answer you've been given (not the one on SO, the one you cited in your question) seems to be more difficult than necessary. I assume it is intended to teach you some aspects of folds, but apparently this is not working well. I try to show what's happening and in the process answer your questions.
3) What exactly does the lambda function do and how is it different from a regular foldr?
The whole thing just builds a left fold (foldl) out of a right fold (foldr) and flips the last two arguments. It is equivalent to
foldTest f = flip (foldr (flip f))
foldTest f = flip (foldl f)
and it does so in a rather obscure way, by accumulating a function and does the flipping via a lambda.
1) Does the 10 take the place of the b in b -> b? (then the b would be the initial accumulator value) What I don't understand is what the (\x r b -> r (f b x)) part does.
Yes, correct. The 10 takes to role of the initial accumulator of a left fold.
2) What is the value of each of the variables? I am very confused about this lambda function.
To get an intuition as to what is happening, I find it helpful to do the actual lambda calculus step by step:
foldTest (-) [1,2,3] 10
foldTest (-) (1:(2:(3:[]))) 10
-- remember the definition of foldTest which is given in a point-free way
foldlTest f xs = foldr (\x r b -> r (f b x)) (\b -> b) xs
-- add the hidden parameter and you get
foldlTest f xs b' = (foldr (\x r b -> r (f b x)) (\b -> b) xs) b'
-- apply that definition with f = (-), xs = (1:(2:(3:[]))), b' = 10
(foldr (\x r b -> r ((-) b x)) (\b -> b) (1:(2:(3:[])))) 10
(foldr (\x r b -> r (b - x)) (\b -> b) (1:(2:(3:[])))) 10
-- the inner lambda function is curried, thus we can write it as
-- \x r (\b -> r (b - x)), which is equivalent but will be handy later on.
(
foldr (\x r -> (\b -> r (b - x))) (\b -> b) (1:(2:(3:[])))
) 10
-- keep in mind foldr is defined as
foldr f' b'' [] = b''
foldr f' b'' (x:xs') = f' x (foldr f' b'' xs')
-- apply second row of foldr with f' = (\x r -> (\b -> r (b - x))),
-- b'' = (\b -> b), x = 1 and xs' = (2:(3:[]))
(
(\x r -> (\b -> r (b - x))) 1 (foldr (\x r -> (\b -> r (b - x))) (\b -> b) (2:(3:[])))
) 10
-- apply accumulation lambda for the first time with x = 1,
-- r = foldr (\x r -> (\b -> r (b - x))) (\b -> b) (2:(3:[])) gives
(
\b -> (foldr (\x r -> (\b -> r (b - x))) (\b -> b) (2:(3:[]))) (b - 1)
) 10
-- now we repeat the process for the inner folds
(
\b -> (
foldr (\x r -> (\b -> r (b - x))) (\b -> b) (2:(3:[]))
) (b - 1)
) 10
(
\b -> (
(\x r -> (\b -> r (b - x))) 2 (foldr (\x r -> (\b -> r (b - x))) (\b -> b) (3:[]))
) (b - 1)
) 10
(
\b -> (
\b -> (foldr (\x r -> (\b -> r (b - x))) (\b -> b) (3:[])) (b - 2)
) (b - 1)
) 10
(
\b -> (
\b -> (
foldr (\x r -> (\b -> r (b - x))) (\b -> b) (3:[])
) (b - 2)
) (b - 1)
) 10
(
\b -> (
\b -> (
(\x r -> (\b -> r (b - x))) 3 (foldr (\x r -> (\b -> r (b - x))) (\b -> b) [])
) (b - 2)
) (b - 1)
) 10
(
\b -> (
\b -> (
\b -> (foldr (\x r -> (\b -> r (b - x))) (\b -> b) [])) (b - 3)
) (b - 2)
) (b - 1)
) 10
(
\b -> (
\b -> (
\b -> (
foldr (\x r -> (\b -> r (b - x))) (\b -> b) []
) (b - 3)
) (b - 2)
) (b - 1)
) 10
-- Now the first line of foldr's definition comes in to play
(
\b -> (
\b -> (
\b -> (
\b -> b
) (b - 3)
) (b - 2)
) (b - 1)
) 10
-- applying those lambdas gives us
(
\b -> (
\b -> (
\b -> (
\b -> b
) (b - 3)
) (b - 2)
) (b - 1)
) 10
-- So we can see that the foldTest function built another function
-- doing what we want:
(\b -> (\b -> (\b -> (\b -> b) (b - 3)) (b - 2)) (b - 1)) 10
(\b -> (\b -> (\b -> b) (b - 3)) (b - 2)) (10 - 1)
(\b -> (\b -> b) (b - 3)) ((10 - 1) - 2)
(\b -> b) (((10 - 1) - 2) - 3)
(((10 - 1) - 2) - 3)
((9 - 2) - 3)
(7 - 3)
4
By the definition of foldlTest, we have
foldlTest (-) xs b = foldr g n xs b
where
n b = b
g x r b = r (b - x)
By the definition of foldr, we have
foldr g n [x,y,z] = g x (foldr g n [y,z])
but also
foldr g n [x,y,z] b = g x (foldr g n [y,z]) b -- (1)
---- r -----------
= foldr g n [y,z] (b-x)
(when used "inside" the foldlTest), and so, by repeated application of (1),
= g y (foldr g n [z]) (b-x)
= foldr g n [z] ((b-x)-y)
= g z (foldr g n [] ) ((b-x)-y)
= foldr g n [] (((b-x)-y)-z)
= n (((b-x)-y)-z)
= (((b-x)-y)-z)
Thus an expression which is equivalent to the left fold is built by the right fold straight up, because g is tail recursive. And thus
foldlTest (-) [1,2,3] 10
-- [x,y,z] b
==
(((10 - 1) - 2) - 3))
==
foldl (-) 10 [1,2,3]
and so we see that no, the b in the n = (\b -> b) does not accept the 10, but rather it accepts the whole expression equivalent to the left fold that has been built by the right fold.
But yes, 10 is the initial accumulator value in the expression equivalent of the left fold, as intended, that has been built by the right fold.

Proving the Continuation Passing Style Monad in Coq

I'm trying to prove the Monad laws (left and right unit + associativity) for the Continuation Passing Style (CPS) Monad.
I'm using a Type Class based Monad defintion from https://coq.inria.fr/cocorico/AUGER_Monad:
Class Monad (m: Type -> Type): Type :=
{
return_ {A}: A -> m A;
bind {A B}: m A -> (A -> m B) -> m B;
right_unit {A}: forall (a: m A), bind a return_ = a;
left_unit {A}: forall (a: A) B (f: A -> m B),
bind (return_ a) f = f a;
associativity {A B C}:
forall a (f: A -> m B) (g: B -> m C),
bind a (fun x => bind (f x) g) = bind (bind a f) g
}.
Notation "a >>= f" := (bind a f) (at level 50, left associativity).
The CPS type constructor is from Ralf Hinze's Functional Pearl about Compile-time parsing in Haskell
Definition CPS (S:Type) := forall A, (S->A) -> A.
I defined bind and return_ like this
Instance CPSMonad : Monad CPS :=
{|
return_ := fun {A} a {B} => fun (f:A->B) => f a ;
bind A B := fun (m:CPS A) (k: A -> CPS B)
=>(fun C => (m _ (fun a => k a _))) : CPS B
|}.
but I'm stuck with the proof obligations for right_unit and associativity.
- unfold CPS; intros.
gives the obligation for right_unit:
A : Type
a : forall A0 : Type, (A -> A0) -> A0
============================
(fun C : Type => a ((A -> C) -> C) (fun (a0 : A) (f : A -> C) => f a0)) = a
Would be very grateful for help!
EDIT: András Kovács pointed out that eta conversion in the type checker is sufficient, so intros; apply eq_refl., or reflexivity. is enough.
Bur first I had to correct my incorrect definition of bind. (The invisible argument c was on the wrong side of the )...
Instance CPSMonad : Monad CPS :=
{|
return_ S s A f := f s ;
bind A B m k C c := m _ (fun a => k a _ c)
|}.
The solution, as mentioned in a comment by András Kovács on Mar 11 at 12:26, is
Maybe you could try going straight for reflexivity? From Coq 8.5 there's eta conversion for records, so all the laws should be apparent immediately by normalization and eta conversion.
That gives us the following instance:
Instance CPSMonad : Monad CPS :=
{|
return_ S s A f := f s ;
bind A B m k C c := m _ (fun a => k a _ c) ;
right_unit A a := eq_refl ;
left_unit A a B f := eq_refl ;
associativity A B C a f g := eq_refl
|}.

CFG to Regular expression

I am confused with this CFG. I want to convert it into a regular expression:
A -> aA | B | epsilon
B -> bB | A
Please also mention the conversion rule from CFG to RE.
I suppose you're talking about formal regular expression here.
Short answer: this is simply: (a | b)*.
Why? Let's see:
A -> aA | B | epsilon
B -> bB | A
This is equivalent to this grammar:
A -> aA
A -> B
A -> epsilon
B -> bB
B -> A
See something here?
A -> B
B -> A
These are equivalent. Let's just replace B with A:
A -> aA
A -> epsilon
A -> bA
Reorder this:
A -> aA
A -> bA
A -> epsilon
Rewrite it with ORs
A -> aA | bA
A -> epsilon
Factor it:
A -> (a | b) A
A -> epsilon
Simplify:
A -> (a | b) A | epsilon
Which is:
A -> (a | b)*
Or, in concrete PCRE notation: [ab]*.
Also, it's not clear from your question, but you should be aware that only some CFGs can be translated to regular expressions.