Re: How can I implement this arrow? Thanks

2003-09-15 Thread Marc A. Ziegert
Am Dienstag 16 September 2003 04:57 schrieb Yu Di:
> Hi, I want to create an arrow which is essentially
> 
> data MyArrow a b = MyArrow ((String, a) -> (String,b))
> 
> i.e. there is an "information" asscioated with each piece of data 
> (represented by the string), and I want
> to pass it around. But I have a problem about how to define "pure" and 
> "first". At first, I declared
> 
> pure f = MyArrow (\(s, x) -> (s, f x))
> first (MyArrow f) = MyArrow (\(s, (x, y)) -> let (s', z) = f (s, x) in (s', 
> (z, y)))
> 
> this seems to work, but then I begin to have problems with the 
> "data-plumbing" pure arrows, e.g. in
> 
> pure (\x -> (x, x)) >>> first someArrow  pure (\(_, x) -> x)
> 
> Ideally, this arrow will preserve whatever information I put there for the 
> input, but because "first
> someArrow" will change the whole information associated with the pair of 
> result, I can't find any
> way to let "pure (\(_, x)->x)" (which is an extremely generic function) 
> retrieve the part of information for the second piece in the pair tuple.


what does the compiler say? or is it a runtime error?
how did you implement "(>>>) :: a b c -> a c d -> a b d"?

(MyArrow f1) >>> (MyArrow f2) = MyArrow (f2 . f1)

does this compile?:

(pure (\x -> (x, x)) :: MyArrow a (a,a)) >>> (first (someArrow :: MyArrow a b) :: 
MyArrow (a,a) (b,a)) >>> (pure (\(_, x) -> x) :: MyArrow (b,a) a)

pure and first seem to be correct.
but ... just as an (slow) alternative:

-- first :: a x fx -> a (x, y) (fx, y)
first (MyArrow f) = MyArrow $ (\((fs,fx),y)->(fs,(fx,y))) . (\(sx,y)->(f sx,y)) . 
(\(s,(x,y))->((s,x),y))




- marc


> 
> Of course I can create specialized arrows for the tasks \x -> (x, x) and 
> \(_, x) -> x which passes the information around, but this will become 
> tedious as I will have to define specialized arrows for a lot of similar 
> tasks one by one, and I won't be able to use the arrow pre-processor at all.
> 
> So how can I implement this? Thanks very much!
> 
> Di, Yu
> 9.15
> 
> _

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


How can I implement this arrow? Thanks

2003-09-15 Thread Yu Di
Hi, I want to create an arrow which is essentially

data MyArrow a b = MyArrow ((String, a) -> (String,b))

i.e. there is an "information" asscioated with each piece of data 
(represented by the string), and I want
to pass it around. But I have a problem about how to define "pure" and 
"first". At first, I declared

pure f = MyArrow (\(s, x) -> (s, f x))
first (MyArrow f) = MyArrow (\(s, (x, y)) -> let (s', z) = f (s, x) in (s', 
(z, y)))

this seems to work, but then I begin to have problems with the 
"data-plumbing" pure arrows, e.g. in

pure (\x -> (x, x)) >>> first someArrow  pure (\(_, x) -> x)

Ideally, this arrow will preserve whatever information I put there for the 
input, but because "first
someArrow" will change the whole information associated with the pair of 
result, I can't find any
way to let "pure (\(_, x)->x)" (which is an extremely generic function) 
retrieve the part of information for the second piece in the pair tuple.

Of course I can create specialized arrows for the tasks \x -> (x, x) and 
\(_, x) -> x which passes the information around, but this will become 
tedious as I will have to define specialized arrows for a lot of similar 
tasks one by one, and I won't be able to use the arrow pre-processor at all.

So how can I implement this? Thanks very much!

Di, Yu
9.15
_
Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage.  
http://join.msn.com/?PAGE=features/es

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


RE: lexer puzzle

2003-09-15 Thread Simon Marlow
 
> I agree with Marcin,
> 
> A... should be split into "A.." and "."
> 
> As I read the (on-line) report the "maximal munch" rule says that you 
> should read the longest lexeme. It does not say that two 
> operators have 
> to be separated by whitespace.
> 
> Because A... is not a lexeme, the longest lexeme you can read from 
> "A..." is "A.." (qualified dot-operator).

Wow!  I hadn't noticed that before.  This means that for example,

   'M.where '

must be interpreted as the two tokens

   'M.wher' 'e'

This is bound to keep the Obfuscated Haskell programmers happy :-)

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


Re: lexer puzzle

2003-09-15 Thread Arthur Baars
I agree with Marcin,

A... should be split into "A.." and "."

As I read the (on-line) report the "maximal munch" rule says that you 
should read the longest lexeme. It does not say that two operators have 
to be separated by whitespace.

Because A... is not a lexeme, the longest lexeme you can read from 
"A..." is "A.." (qualified dot-operator).

Arthur

On maandag, sep 15, 2003, at 12:11 Europe/Amsterdam, Malcolm Wallace 
wrote:

Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:

Argh, I was wrong. It's A.. (qualified operator), then . (operator).
You are forgetting about the maximal munch rule.  An operator cannot 
appear
directly next to another operator without some whitespace to separate 
them.
For instance "A.+." is an operator called (+.) from module A, not an
operator called + followed by compose.

But, although "A" could be the three-dot operator "..." from the
module A, it is not possible to have "A..." interpreted as a two-dot
operator, because ".." is reserved as sugar for enumeration sequences,
and so is explicitly excluded from the varsym production.
Thus, the only possible lexical interpretation is the one you first
suggested, namely a constructor "A" followed by a three-dot operator
"...".
Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


RE: lexer puzzle

2003-09-15 Thread Simon Marlow

Iavor Diatchki writes:
 
> what do people think should be the tokens produced by a haskell lexer
> when applied to the following input:
> 
>A...

This has been discussed before (a while back, admittedly). See:

  http://www.mail-archive.com/[EMAIL PROTECTED]/msg04054.html

GHC (still) gets this wrong.  It's a documented bug though.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


Re: lexer puzzle

2003-09-15 Thread Malcolm Wallace
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:

> > > >A...
> > >
> > > A (constructor), then ... (operator).
> > > This is how I understand Haskell 98 lexing rules.
> 
> Argh, I was wrong. It's A.. (qualified operator), then . (operator).

You are forgetting about the maximal munch rule.  An operator cannot appear
directly next to another operator without some whitespace to separate them.
For instance "A.+." is an operator called (+.) from module A, not an
operator called + followed by compose.

But, although "A" could be the three-dot operator "..." from the
module A, it is not possible to have "A..." interpreted as a two-dot
operator, because ".." is reserved as sugar for enumeration sequences,
and so is explicitly excluded from the varsym production.

Thus, the only possible lexical interpretation is the one you first
suggested, namely a constructor "A" followed by a three-dot operator
"...".

Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell