Ms. high heels is no longer the monopoly of men has become a Discount Christian Louboutin shoes are now loyal customers. Latest baked spring and summer 2011 Milan Fashion Week, the luxury brand Prada has released their latest design men's shoes. These Christian Louboutin Peep-toe might be called the platform shoes more suitable for the design concept is to increase the vertical height, lengthen the leg line, make a man more confident.

    In fact, ladies and for men to wear Christian Louboutin Sandals really do not care too much about. You know, Christian Louboutin Evening first originally designed for men. Early 16th century, people riding knight to solve the foot in the stirrup sliding problems, which padded the heel. French monarch Louis XIV's personal interest in this achievement was later popular inChristian Louboutin Pumps, but it was mainly all male wearing high heels.

    But the success of women seeking high heels toward the throne today, the men had wanted to take back the "throne" is not impossible. Cone with, and ankle boots, this year's men's high heels in no way inferior to women. Prada's design has taken the attitude of compromise than "Hentian high" in height and bizarre Christian Louboutin Wedges, shoes like normal people more likely to be accepted, with the Prada shoes of complex designs, for men high-heeled shoes decorated in simple style brings out the man's masculinity. If you're really not satisfied with height, then select pairs of high heels like a man now!

Hello, nice site. Had myself signed up. Nice

Hice unos avances en este proyecto, implemente la parte de movimiento turtle.

Turtle, es un lenguaje para generar recorridos. Basicamente turtle tiene un estado y comandos a ejecutar sobre el estado.

El estado es la posicion (x,y) del objeto, la distacia a recorrer y un angulo que guia la direccion.

Los comando son:
F  -> avanzar adelante y dibujar una linea entre el punto del estado y el nuevo generado por la distancia y angulo.
f  -> avanzar adelante pero sin dibujar ninguna linea.
+ -> incrementar el angulo de estado con otro angulo constante.
- -> decrementar el angulo del estado con otro angulo constante.

Entonces, la anterior version generaba el resultado de un sistema L, ahora en esta nueva version, genero elementos del lenguaje turtle. Y una ves generados estos elementos, los interpreto con una libreria grafica, wxhaskell.

Les dejo algunas imagenes de los resultados obtenidos:

Despues de entender Phantom Types, me puse a ver la manera de hacerlo con AGs (Attribute Grammar), y la verdad no es cosa de otro mundo. Pero veamoslo paso a paso.

Un Phantom Type, es una tecnica que nos permite hacer chequeo de tipos en tiempo de compilacion manteniendo una gramatica abstracta sencilla y comprensible.

Veamoslo con el ejemplo de la pagina fuente, tenemos un evaluador de expresiones, el cual es reescrito usando gramatica de attributos de esta manera:

DATA Expr
    | Val Int
    | Add le,lr : Expr
    | LE e1, e2 : Expr
    | Cond ex, iex, eex : Expr

DERIVING * : Show

ATTR Expr [ | | value : {Res}]

SEM Expr
    | Val lhs.value  = ResI @int
    | Add lhs.value  = case (@le.value, @lr.value) of
                               (ResI x, ResI y) -> ResI (x + y)
                               _                    -> error "Bad Arguments to Add"
    | LE lhs.value   = case (@e1.value, @e2.value) of
                               (ResI x, ResI y)  -> ResB (x <= y)
                               _                     -> error "Bad Arguments to LE"
    | Cond lhs.value = case (@ex.value) of
                               ResB b -> if b then @iex.value else @eex.value
                               _        -> error "Bad Arguments to Cond"

{
data Res = ResI Int | ResB Bool  deriving Show

main :: IO()
main = print e1
    where e1 = sem_Expr (Cond (LE (Val 3) (Val 5)) (Add (Val 1) (Val 2)) (Val 0)) t;br />             e2 = sem_Expr (Cond (Val 1) (Val 1) (Val 1))
}

Para probarlo, hacemos "uuagc -mdfcs AExpr.ag", y luego lo cargamos con "ghci AExpr.hs" y lo ejecutamos con "main", y el resultado sera "ResI 3".

Hasta aqui, todo anda bien, pero que pasa si en el ag cambiamos "e1", por "e2" en el "main"?despues ejecutarlo nos da un error de "Bad arguments to Cond", asi como lo esperabamos. Pero que pasaria si no queremos obtener estos errores, y que si quisieramos capturar estos errores en tiempo de compilacion?, una forma comun de hacerlo seria cambiando nuestro tipo algebraico y escribiendo una gramatica abstracta que tenga expresiones booleanas, enteras y demas cosas. Pero una forma es usando la tecnica de Phantom Type, como lo mensionamos mas antes, mantenemos una gramatica sencilla y nos permite usar el chequeo de tipos de Haskell.

Entonces, lo reescribimos de esta manera:

DATA Expr'
    | Val Int
    | Add le,lr : Expr'
    | LE e1, e2 : Expr'
    | Cond ex, iex, eex : Expr'

DERIVING * : Show

ATTR Expr' [ | | value : {Res}]
SEM Expr'
    | Val lhs.value  = ResI @int
    | Add lhs.value  = case (@le.value, @lr.value) of
                            (ResI x, ResI y) -> ResI (x + y)
                            _                    -> error "Bad Arguments to Add"
    | LE lhs.value   = case (@e1.value, @e2.value) of
                            (ResI x, ResI y)  -> ResB (x <= y)
                            _                     -> error "Bad Arguments to LE"
    | Cond lhs.value = case (@ex.value) of
                            ResB b -> if b then @iex.value else @eex.value
                            _        -> error "Bad Arguments to Cond"

{
data Res = ResI Int | ResB Bool  deriving Show

newtype Expr a = E Expr'
    deriving (Show)

-- wrappers
val :: Int -> Expr Int
val = E . Val

add :: Expr Int -> Expr Int -> Expr Int
add (E x) (E y) = E $ Add x y

le :: Expr Int -> Expr Int -> Expr Bool
le (E x) (E y) = E $ LE x y

cond :: Expr Bool -> Expr a -> Expr a -> Expr a
cond (E c) (E x) (E y) = E $ Cond c x y

eval :: Expr a -> Res
eval (E e) = sem_Expr' e

main :: IO()
main = print e1
    where e1 = eval (cond (le (val 3) (val 5)) (add (val 1) (val 2)) (val 0))
             --e2 = eval (cond (val 1) (val 1) (val 1))
}

Y ahora, ejecutamos lo mismo que la ultima ves y obtenemos el mismo resultado. Pero si cambiamos "e1" por "e2" en el "main", descomentamos "e2" e intentamos compilarlo, obtendremos un error de tipos en tiempo de compilacion, asi podremos contruir solo expresiones validas para nuestro evaluador.

Donde esta la tecnica de Phantom Type?, los hacemos atraves de "newtype Expr a = E Expr' ", el cual crea un nuevo tipo parametrizando el tipo deseado, el cual es controlado por el type chequer de Haskell. Este nuevo tipo, tiene en su contructor de datos algo asi como un tipo fantasma (Phantom Type), esto pienso asi porque:

-- el tipo del contructor de datos de Expr seria
E :: Expr' -> Expr a

-- por ejemplo el tipo de val, es
val :: Int -> Expr Int

Asi el tipo de "Expr a" no refleja el contenido que tiene empaquetado, por eso pienso que el tipo de adentro es el fantasma.

Volviendo al tema, el siguiente paso despues de crear el tipo fantasma, es escribir las funciones wrapper, los cuales se encargan de contruir el "Expr' " que queremos. Y tambien es aqui donde detallamos el chequeo de tipos para Haskell.

En el AG podemos borrar los casos erroneos de los expresiones case, sin afectar los resultados. Y para una mejor presentacion y cuidado, podemos exportar junto con el modulo, solo las funciones wrappers y tipos necesarios.

Bueno, esta es la manera en que implemente Phantom Types con AGs. Si ves el documento fuente, te preguntaras como implemetar GADTs con AGs, pues es algo que yo aun sigo preguntandome, y la verdad no se si habra una manera de hacerlo con AGs, pero como al autor de decia, Phantom Types es una solucion elegante, relativamente sencilla y estandard de Haskell en comparacion con GADTs.

Despues de entender Phanton Types, me puse a ver la manera de hacerlo con AGs (Attribute Grammar), y la verdad no es cosa de otro mundo. Pero veamoslo paso a paso.

Un Phanton Type, es una tecnica que nos permite hacer chequeo de tipos en tiempo de compilacion manteniendo una gramatica abstracta sencilla y comprensible.

Veamoslo con el ejemplo de la pagina fuente, tenemos un evaluador de expresiones, el cual es reescrito usando gramatica de attributos de esta manera:

DATA Expr
    | Val Int
    | Add le,lr : Expr
    | LE e1, e2 : Expr
    | Cond ex, iex, eex : Expr

DERIVING * : Show

ATTR Expr [ | | value : {Res}]

SEM Expr
    | Val lhs.value  = ResI @int
    | Add lhs.value  = case (@le.value, @lr.value) of
                               (ResI x, ResI y) -> ResI (x + y)
                               _                    -> error "Bad Arguments to Add"
    | LE lhs.value   = case (@e1.value, @e2.value) of
                               (ResI x, ResI y)  -> ResB (x <= y)
                               _                     -> error "Bad Arguments to LE"
    | Cond lhs.value = case (@ex.value) of
                               ResB b -> if b then @iex.value else @eex.value
                               _        -> error "Bad Arguments to Cond"

{
data Res = ResI Int | ResB Bool  deriving Show

main :: IO()
main = print e1
    where e1 = sem_Expr (Cond (LE (Val 3) (Val 5)) (Add (Val 1) (Val 2)) (Val 0))

t;br />             e2 = sem_Expr (Cond (Val 1) (Val 1) (Val 1))
}

Para probarlo, hacemos "uuagc -mdfcs AExpr.ag", y luego lo cargamos con "ghci AExpr.hs" y lo ejecutamos con "main", y el resultado sera "ResI 3".

Hasta aqui, todo anda bien, pero que pasa si en el ag cambiamos "e1", por "e2" en el "main"?despues ejecutarlo nos da un error de "Bad arguments to Cond", asi como lo esperabamos. Pero que pasaria si no queremos obtener estos errores, y que si quisieramos capturar estos errores en tiempo de compilacion?, una forma comun de hacerlo seria cambiando nuestro tipo algebraico y escribiendo una gramatica abstracta que tenga expresiones booleanas, enteras y demas cosas. Pero una forma es usando la tecnica de Phanton Type, como lo mensionamos mas antes, mantenemos una gramatica sencilla y nos permite usar el chequeo de tipos de Haskell.

Entonces, lo reescribimos de esta manera:

DATA Expr'
    | Val Int
    | Add le,lr : Expr'
    | LE e1, e2 : Expr'
    | Cond ex, iex, eex : Expr'

DERIVING * : Show

ATTR Expr' [ | | value : {Res}]
SEM Expr'
    | Val lhs.value  = ResI @int
    | Add lhs.value  = case (@le.value, @lr.value) of
                            (ResI x, ResI y) -> ResI (x + y)
                            _                    -> error "Bad Arguments to Add"
    | LE lhs.value   = case (@e1.value, @e2.value) of
                            (ResI x, ResI y)  -> ResB (x <= y)
                            _                     -> error "Bad Arguments to LE"
    | Cond lhs.value = case (@ex.value) of
                            ResB b -> if b then @iex.value else @eex.value
                            _        -> error "Bad Arguments to Cond"

{
data Res = ResI Int | ResB Bool  deriving Show

newtype Expr a = E Expr'
    deriving (Show)

-- wrappers
val :: Int -> Expr Int
val = E . Val

add :: Expr Int -> Expr Int -> Expr Int
add (E x) (E y) = E $ Add x y

le :: Expr Int -> Expr Int -> Expr Bool
le (E x) (E y) = E $ LE x y

cond :: Expr Bool -> Expr a -> Expr a -> Expr a
cond (E c) (E x) (E y) = E $ Cond c x y

eval :: Expr a -> Res
eval (E e) = sem_Expr' e

main :: IO()
main = print e1
    where e1 = eval (cond (le (val 3) (val 5)) (add (val 1) (val 2)) (val 0))
             --e2 = eval (cond (val 1) (val 1) (val 1))
}

Y ahora, ejecutamos lo mismo que la ultima ves y obtenemos el mismo resultado. Pero si cambiamos "e1" por "e2" en el "main", descomentamos "e2" e intentamos compilarlo, obtendremos un error de tipos en tiempo de compilacion, asi podremos contruir solo expresiones validas para nuestro evaluador.

Donde esta la tecnica de Phanton Type?, los hacemos atraves de "newtype Expr a = E Expr' ", el cual crea un nuevo tipo parametrizando el tipo deseado, el cual es controlado por el type chequer de Haskell. Este nuevo tipo, tiene en su contructor de datos algo asi como un tipo fantasma (Phanton Type), esto pienso asi porque:

-- el tipo del contructor de datos de Expr seria
E :: Expr' -> Expr a

-- por ejemplo el tipo de val, es
val :: Int -> Expr Int

Asi el tipo de "Expr a" no refleja el contenido que tiene empaquetado, por eso pienso que el tipo de adentro es el fantasma.

Volviendo al tema, el siguiente paso despues de crear el tipo fantasma, es escribir las funciones wrapper, los cuales se encargan de contruir el "Expr' " que queremos. Y tambien es aqui donde detallamos el chequeo de tipos para Haskell.

En el AG podemos borrar los casos erroneos de los expresiones case, sin afectar los resultados. Y para una mejor presentacion y cuidado, podemos exportar junto con el modulo, solo las funciones wrappers y tipos necesarios.

Bueno, esta es la manera en que implemente Phanton Types con AGs. Si ves el documento fuente, te preguntaras como implemetar GADTs con AGs, pues es algo que yo aun sigo preguntandome, y la verdad no se si habra una manera de hacerlo con AGs, pero como al autor de decia, Phanton Types es una solucion elegante, relativamente sencilla y estandard de Haskell en comparacion con GADTs.

En esta oportunidad quiero compartir una traduccion de una de los subtitulos del libro: Purely Functional Data Structure [Chris Okasaki], que me parecio muy buena.

Estructuras de Datos Funcionales vs. Imperativas

Los beneficios metodologicos de los lenguajes funcionales son bien conocidos, pero aun la mayoria de los programas son escritos en lenguajes imperativos como C. Esta aparente contradiccion es facilmente explicado por el hecho de que los lenguajes funcionales han sido historicamente mas lentos que sus mas tradicionales primos, pero esta brecha se esta reduciendo. Se han hecho impresionantes avances desde un amplio frente, desde tecnologias basicas de compiladores a analisis sofisticados y optimizaciones. Sin embargo, hay un aspecto de la programacion funcional que todo escritor de compiladores debe mitigar - el uso de estructuras de datos inapropiadas o inferiores.

Porque las estructuras de datos funcionales son mas dificultuosas para diseñar e implementar que las imperativas? Hay 2 problemas basicos. Primero, desde el punto de vista de diseño e implementacion de estructuras de datos eficientes, la estructura de la programacion funcional contra actualizaciones destructivas (ej. asignaciones) es una desventaja asombrosa, equivalente a confiscar los cuchillos de un chef master. Al igual que los cuchillos, las actualizaciones destructivas pueden ser dañinas cuando son mal usadas, pero tremendamente efectivas cuando son usadas apropiadamente. Las estructuras de datos imperativas a menudo confian en la asignacion de una forma crucial, y por eso se encuentran diferentes soluciones para los programas funcionales.

La segunda dificultad es que se espera que las estructuras de datos funcionales sean mas flexibles que sus contrapartes imperativas. En particular, cuando actualizamos una estructura de datos imperativa, tipicamente aceptamos que la version antigua de la estructura de datos ya no estara disponible, pero cuando actualizamos una estructura de datos funcional, esperamos que la antigua y nueva version de la estructura de datos estara disponible para futuros procesamientos. Una estructura de datos que soporta multiples versiones es llamado persistente [persistent], mientras que una estrutura de datos que permite solo una simple version en un tiempo es llamado efimera [ephemeral]. Los lenguajes de programacion funcional tienen la propiedad curiosa de que todas las estructuras de datos son auntomaticamente persistentes. 
Las estructuras de datos imperativas son tipicamente efimeras, pero cuando una estructura de datos persistente es requerida, los programadores imperativos no se sorprenden si la estructura de datos persistente es mas complicada y talves incluso asintoticamente menos eficiente que una equivalente estructura de datos efimera.

Ademas, los teoricos han establecido limites inferiores sugeriendo que los lenguajes de programacion funcional podrian ser fundamentalmente menos eficientes que los lenguajes imperativos en algunas situaciones. En vista de todos estos puntos, las estructuras de datos funcionales se parecen algunas veces al oso que baila, de quien se dice, "lo maravilloso no es que el danza muy bien, sino de que el danza de alguna manera!". En la practica, sin embargo, la situacion no es tan triste. Como podremos ver, es a menudo posible eleborar estructuras de datos funcionales que son asintoticamente tan eficientes como las mejores soluciones imperativas.

Eso de que pongan en diferentes lados este codigo pero en cada sitio versiones diferentes es grrrraaave!!

pero por fin encontre el bueno:

http://code.haskell.org/~dons/code/hs-plugins/

http://hackage.haskell.org/package/plugins

En Haskell podemos tambien hacer setters y getters de una forma sencilla.

Tenemos este codigo:

module Main where

data Persona = Persona { ci       :: CI
                      , nombre   :: Name
                      , apellido :: LastName
                      , edad     :: Edad
                      } deriving Show

type CI       = Int
type Name     = String
type LastName = String
type Edad     = Int

-- instancias
juan :: Persona
juan = Persona 14322 "juan" "block" 35

pepe :: Persona
pepe = Persona 44533 "pepe" "torrez" 15

Entonces podemos obtener los datos de cada instancia llamando a la funcion constructora de cada elemento de Persona.

Ejemplo:

*Main> ci pepe

nos retornaria el CI de 'pepe', tambien podemos usar nombre, apellido o edad.

Para setear un valor, podemos hacer

*Main> juan {nombre = "juanes"}
Persona {ci = 14322, nombre = "juanes", apellido = "block", edad = 35}

En la parte de modificar un valor de la instancia es diferente, porque lo que en realidad hace es modificar el valor en una nueva instancia sin tocar su parametro entrante. Solo toma de esté la informacion que no se modifica. Ejemplo:

*Main> juan {edad = 0}
Persona {ci = 14322, nombre = "juan", apellido = "block", edad = 0}
*Main> juan
Persona {ci = 14322, nombre = "juan", apellido = "block", edad = 35}

Un problema muy interesante

s = "λ"

main = do

    writeFile "test.txt" s

    s2 <- readFile "test.txt"

    print (s == s2)

Si analizamos y hacemos correr este pequeño programa el resultado deberia ser True por logica, pero el resultado real es False.

Segun Christian creador del blog Luke Plant's

El problema es con la biblioteca estándar Haskell - muchas de las funciones previstas por el Prelud, System.IO, System.Posix y muchos otros son completamente roto (por diseño).  leer mas

Don Stewart dio la siguiente solucion para este problema

    import Prelude hiding (writeFile, readFile, print)

    import System.IO.UTF8

    s = "λ"

    main = do

        writeFile "test.txt" s

        s2 <- readFile "test.txt"

        print (s == s2)

Si hacemos correr este ejemplo el resultado sera True.