The-Go-Programming-Language_es.morg

..title   > El lenguaje de programacion Go
..author  > Alan A. A. Donovan
..author  > Brian W. Kernighan
..date    > 29/09/2015
..id      > isbn-13 978-0-13-419044-0
..id      > isbn-10 0-13-419044-0
..style   > worg-data/worg.css
..options > fancyCode toc

@ revision 3b600c, date 29 Sep 2015

..center >
  Para Leila y Meg
< center..

* Prefacio

  ..quote >
    @"(Go es un lenguaje de programacion de codigo abierto, que facilita la
    creacion de software simple, confiable y eficiente.)

    --(Desde el sitio web de Go en @l(https://golang.org/<>golang.org))
  < quote..

  Go fue concebido en septiembre de 2007 por Robert Griesemer, Rob Pike y Ken
  Thompson, todos de Google, y fue anunciado en noviembre de 2009. La meta del
  lenguaje y sus herramientas acompañantes es ser expresivos, eficientes en la
  compilacion y ejecucion, y eficaz en la escritura de programas fiables y
  robustos.

  Go tiene una similitud superficial con C y, como C, es una herramienta para
  programadores profesionales, logrando el maximo efecto con un minimo de
  medios. Pero es mucho mas que una version actualizada de C. Toma prestadas y
  adapta buenas ideas de muchos otros lenguajes, evitando caracteristicas que
  han llevado a la complejidad y a un codigo poco confiable. Sus comodidades
  para la concurrencia son nuevas y eficientes, y su enfoque hacia la
  abstraccion de datos y la programacion orientada a objetos es inusualmente
  flexible. Tambien cuenta con gestion automatica de memoria o @e(recoleccion de
  basura).

  Go es especialmente adecuado para la construccion de infraestructura como
  servidores en red, y herramientas y sistemas para programadores, pero es
  realmente un lenguaje de uso general y se utiliza en dominios tan diversos
  como graficos, aplicaciones moviles y aprendizaje automatico. Se ha vuelto
  popular como un reemplazo para los lenguajes de scripting no tipados porque
  equilibra la expresividad con la seguridad: Los programas Go suelen funcionar
  mas rapido que los programas escritos en lenguajes dinamicos y sufren muchos
  menos accidentes debido a errores de tipado.

  Go es un proyecto de codigo abierto, por lo que el codigo fuente de su
  compilador, librerias y herramientas esta disponible gratuitamente para
  cualquiera. Las contribuciones al proyecto provienen de una activa comunidad
  mundial. Go se ejecuta en sistemas tipo Unix–GNU/Linux, FreeBSD, OpenBSD,
  Mac OS X–y en Plan 9 y Microsoft Windows. Los programas escritos en uno de
  estos entornos generalmente funcionan sin modificacion en los otros.

  Este libro esta diseñado para ayudarle a comenzar a usar Go efectivamente, de
  inmediato y utilizarlo bien, aprovechando al maximo las caracteristicas
  lingüisticas de Go y las librerias estandar para escribir programas claros,
  idiomaticos y eficientes.

** Los Origenes de Go

   Como las especies biologicas, los lenguajes exitosos engendran hijos que
   incorporan las ventajas de sus antepasados; el entrecruzamiento a veces
   conduce a fortalezas sorprendentes; y, muy ocasionalmente, surge un nuevo
   rasgo radical sin precedentes. Podemos aprender mucho sobre por que un
   lenguaje es como es y a que entorno se ha adaptado para ver estas
   influencias.

   La siguiente figura muestra las influencias mas importantes de los lenguajes
   de programacion anteriores en el diseño de Go.

   ..img > img/go-influences.jpg

   En ocaciones Go se describe como un @"(lenguaje de tipo C), o como @"(C para
   el siglo 21). De C, Go heredo su sintaxis de expresiones, instrucciones de
   flujo de control, tipos de datos basicos, paso de parametros por valor, punteros
   y, sobre todo, el enfasis de C en programas que compilan codigo maquina
   eficiente y cooperan naturalmente con las abstracciones de los sistemas
   operativos actuales.

   Pero hay otros antepasados en el arbol genealogico de Go. Una importante
   corriente de influencia proviene de los lenguajes de Niklaus Wirth, comenzando
   con Pascal. Modula-2 inspiro el concepto de paquete. Oberon elimino la
   distincion entre los archivos de interfaz del modulo y los archivos de
   implementacion del modulo. Oberon-2 influyo en la sintaxis de importacion y
   declaracion de paquetes, y proporciono la sintaxis para la declararcion de
   metodos.

   Otro linaje entre los antepasados de Go, y uno que hace a Go distinto entre
   los lenguajes de programacion mas recientes, es una secuencia de lenguajes de
   investigacion poco conocidos desarrollados en los Laboratorios Bell, todos
   ellos inspiradas en el concepto de comunicacion de procesos secuenciales
   (CSP) del seminal articulo de 1978 de Tony Hoare en los cimientos de la
   concurrencia. En CSP, un programa es una composicion paralela de procesos que
   no tienen estado compartido; los procesos se comunican y sincronizan
   utilizando canales. Pero el CSP de Hoare era un lenguaje formal para
   describir los conceptos fundamentales de la concurrencia, no un lenguaje de
   programacion para escribir programas ejecutables.

   Rob Pike y otros comenzaron a experimentar con implementaciones CSP como
   lenguajes reales. El primero fue llamado Squeak @%"(Un Lenguaje para
   comunicarce con ratones), que proporcionaron un lenguaje para el manejo de
   eventos de raton y teclado, con canales estaticamente creados. Esto fue
   seguido por Newsqueak, que ofrecia declaraciones y sintaxis de expresion como
   C y la notacion de tipo Pascal. Se trataba de un lenguaje puramente funcional
   con recoleccion de basura, dirigido nuevamente a administrar eventos de
   teclado, raton y ventanas. Los canales se convirtieron en valores de primera
   clase, creados dinamicamente y almacenados en variables.

   El sistema operativo Plan 9 llevo adelante estas ideas en un lenguaje llamado
   Alef. Alef trato de hacer de Newsqueak un lenguaje viable para la
   programacion de sistemas, pero su omision de un recoleccion de basura hizo
   que la concurrencia fuera demasiado dolorosa.

   Otras construcciones en Go muestran la influencia de genes no ancestrales
   aqui y alla; por ejemplo @c(iota) es tomado libremente de APL, y el ambito
   lexico con funciones anidadas es de Scheme (y la mayoria de lenguajes desde
   entonces). Aqui tambien encontramos mutaciones novedosas. Go innova
   proporcionando slices (arreglos dinamicos) con acceso aleatorio eficiente,
   pero tambien permite sofisticados arreglos compartidos que recuerdan a las
   listas enlazadas. Y la declaracion @c(defer) es nueva con Go.

** El Proyecto Go

   Todos los lenguajes de programacion reflejan la filosofia de programacion de
   sus creadores, que a menudo incluye un componente significativo de reaccion a
   las deficiencias percibidas de los lenguajes anteriores. El proyecto Go nacio de
   la frustracion con varios sistemas de software de Google que sufrian una
   explosion de complejidad. (Este problema no es exclusivo de Google.)

   Como Rob Pike dijo, @"(la complejidad es multiplicativa): solucionar un
   problema al hacer una parte del sistema mas compleja, lentamente pero con
   seguridad añade complejidad a otras partes. Con la presion constante de
   agregar caracteristicas y opciones y configuraciones, y de enviar codigo
   rapidamente, es facil olvidar la sencillez, aunque a la larga la simplicidad
   es la clave para un buen software.

   La simplicidad requiere mas trabajo al comienzo de un proyecto para reducir
   una idea a su esencia y mas disciplina durante la vida de un proyecto para
   distinguir los buenos cambios, de los malos o perniciosos. Con un esfuerzo
   suficiente, un buen cambio se puede acomodar sin comprometer lo que Fred
   Brooks llamo la @"(integridad conceptual) del diseño, pero un mal cambio no
   puede, y un cambio pernicioso negocia la sencillez por una conveniencia
   superficial. Solo a traves de la simplicidad del diseño un sistema puede
   permanecer estable, seguro y coherente a medida que crece.

   El proyecto Go incluye el lenguaje mismo, sus herramientas y librerias
   estandar, y por ultimo, pero no menos importante, una agenda cultural de
   simplicidad radical. Como un lenguaje reciente de alto nivel, Go tiene el
   beneficio de la retrospeccion, y lo basico esta bien hecho: tiene recoleccion
   de basura, un sistema de paquetes, funciones de primera clase, alcance
   lexico, una interfaz de llamadas al sistema y cadenas inmutables en las que
   el texto esta generalmente codificado en UTF-8. Pero tiene comparativamente
   pocas caracteristicas y es poco probable que agregue mas. Por ejemplo, no
   tiene conversiones numericas implicitas, no hay constructores o destructores,
   no hay sobrecarga de operadores, no hay valores de parametros
   predeterminados, ni herencia, ni genericos, ni excepciones, ni macros, ni
   anotaciones de funcion, ni almacenamiento local de hilos. El lenguaje es
   maduro y estable y garantiza la compatibilidad con versiones anteriores: los
   programas Go mas antiguos se pueden compilar y ejecutar con versiones mas
   recientes de compiladores y librerias estandar.

   Go tiene un sistema de tipado para evitar la mayoria de los errores por
   descuido que afectan a los programadores en lenguajes dinamicos, pero tiene
   un sistema de tipado mas simple que los lenguajes tipados comparables. Este
   enfoque puede conducir en ocaciones a baches de programacion @"(sin tipado)
   dentro de un marco mas amplio de tipos, y los programadores de Go no hacen lo
   que los programadores de C++ o Haskell para expresar las propiedades de
   seguridad como pruebas basadas en tipos. Pero en la practica, Go da a los
   programadores gran parte de los beneficios de seguridad y rendimiento en
   tiempo de ejecucion de un sistema de tipado relativamente fuerte sin la carga
   de complejidad.

   Go fomenta una conciencia del diseño de sistemas informaticos contemporaneos,
   particularmente la importancia de la localidad. Sus tipos de datos
   incorporados y la mayoria de las estructuras de datos de la libreria estan
   diseñados para funcionar naturalmente sin inicializacion explicita o
   constructores implicitos, por lo que relativamente pocas asignaciones de
   memoria y escrituras de memoria estan ocultas en el codigo. Los tipos
   agregados de Go (estructuras y matrices) mantienen sus elementos
   directamente, requiriendo menos almacenamiento y menos asignaciones e
   indireccion de punteros, que los lenguajes que utilizan campos indirectos. Y
   como la computadora moderna es una maquina paralela, Go tiene caracteristicas
   de concurrencia basadas en CSP, como se menciono anteriormente. Las pilas de
   tamaño variable de los hilos ligeros de Go o @e(gorutinas) son inicialmente
   lo suficientemente pequeñas como para que crear una gorutina sea barato y
   crear un millon sea practico.

   La libreria estandar de Go, a menudo descrita como con @"(baterias
   incluidas,) proporciona bloques de construccion limpios y APIs de E/S,
   procesamiento de texto, graficos, criptografia, redes y aplicaciones
   distribuidas, con soporte para muchos formatos de archivos y protocolos
   estandar. Las librerias y las herramientas hacen uso extensivo de la
   convencion para reducir la necesidad de configuracion y explicaciones,
   simplificando asi la logica del programa y haciendo que diversos programas Go
   sean mas similares entre si y, por lo tanto, mas faciles de aprender. Los
   proyectos creados con la herramienta @$(go) solo utilizan nombres de archivos
   e identificadores y un comentario especial ocasional para determinar todas
   las librerias, ejecutables, pruebas, referencias, ejemplos, variantes
   especificas de la plataforma y documentacion para un proyecto; el codigo
   fuente de Go contiene en si la especificacion de compilacion.

** Organizacion del Libro

   Asumimos que usted ha programado en uno o mas lenguajes, ya sea compilados como C,
   C++ y Java, o interpretados como Python, Ruby y JavaScript, por lo que no
   solemos explicar todo como si fuera un completo principiante. La sintaxis
   superficial sera familiar, al igual que variables y constantes, expresiones,
   flujo de control y funciones.

   El Capitulo 1 es un tutorial sobre las construcciones basicas de Go,
   introducido a traves de una docena de programas para tareas cotidianas como
   leer y escribir archivos, formatear texto, crear imagenes y comunicarse con
   clientes y servidores de Internet.

   El Capitulo 2 describe los elementos estructurales de un programa
   Go–declaraciones, variables, nuevos tipos, paquetes y archivos, y alcance. El
   Capitulo 3 analiza numeros, booleanos, cadenas y constantes, y explica como
   procesar Unicode. El Capitulo 4 describe los tipos compuestos, es decir, los
   tipos construidos a partir de los mas sencillos utilizando arreglos, mapas,
   estructuras y slices, la aproximacion de Go para listas dinamicas. El
   Capitulo 5 cubre las funciones y discute el manejo de errores,
   @c(panic) y @c(recover), y la sentencia @c(defer).

   Los Capitulos 1 a 5 son por lo tanto, lo basico, las cosas que forman
   parte de cualquier lenguaje imperativo popular. La sintaxis y el estilo de Go
   a veces difieren de otros lenguajes, pero la mayoria de los programadores los
   captan rapidamente. Los capitulos restantes se centran en temas en los que
   el enfoque de Go es menos convencional: metodos, interfaces, concurrencia,
   paquetes, pruebas y reflexion.

   Go tiene un acercamiento inusual a la programacion orientada a objetos. No
   hay jerarquias de clase, o de hecho ninguna clase; los comportamientos de
   objetos complejos se crean a partir de los mas simples por composicion, no
   por herencia. Los metodos pueden ser asociados con cualquier tipo definido
   por el usuario, no solo las estructuras, y la relacion entre tipos concretos
   y tipos abstractos (las @e(interfaces)) son implicitas, por lo que un tipo
   concreto puede satisfacer una interfaz que el diseñador del tipo desconocia.
   Los metodos estan cubiertos en el Capitulo 6, las interfaces en el Capitulo 7.

   El Capitulo 8 presenta el enfoque de Go sobre la concurrencia, que se basa en la
   idea de comunicar procesos secuenciales (CSP), incorporados por gorutinas y
   canales. El Capitulo 9 explica los aspectos mas tradicionales de la
   concurrencia basada en variables compartidas.

   El Capitulo 10 describe los paquetes, el mecanismo para organizar las
   librerias. Este capitulo tambien muestra como hacer un uso efectivo de la
   herramienta @$(go), provista para la compilacion, pruebas, benchmarking,
   formateo del programa, documentacion y muchas otras tareas, todo dentro de un
   solo comando.

   El Capitulo 11 trata de las pruebas, donde Go adopta un enfoque notablemente
   ligero, evitando framewoks cargados de abstraccion en favor de librerias y
   herramientas simples. Las librerias de pruebas proporcionan una base sobre
   la que se pueden construir abstracciones mas complejas si es necesario.

   El Capitulo 12 discute la reflexion, la capacidad de un programa para
   examinar su propia representacion durante la ejecucion. La reflexion es una
   herramienta poderosa, aunque debe ser usada con cuidado; este capitulo
   explica como encontrar el equilibrio correcto, mostrando como se utiliza para
   implementar algunas librerias importantes en Go. El Capitulo 13 explica los
   detalles morbosos de programacion a bajo nivel que utiliza el paquete
   @c(unsafe) para dar un paso alrededor del sistema de tipado de Go, y cuando
   eso es apropiado.

   Cada capitulo tiene una serie de ejercicios que puedes usar para probar tu
   comprension de Go, y para explorar extensiones y alternativas a los ejemplos
   del libro.

   Todos menos los ejemplos de codigo, exepto los mas triviales estan
   disponibles para su descarga desde un repositorio publico Git en
   @l(http://www.gopl.io/<>gopl.io). Cada ejemplo se identifica por su ruta de
   importacion de paquete y puede ser convenientemente localizado, construido e
   instalado utilizando el comando @$(go get). Tendras que elegir un directorio
   para que sea tu espacio de trabajo y establecer la variable de entorno
   @c(GOPATH) apuntando a el. La herramienta @$(go) creara el directorio si es
   necesario. Por iejemplo:

   ..srci > sh
     > export GOPATH=$HOME/gobook        # Elegir el directorio de trabajo
     > go get gopl.io/ch1/helloworld     # buscar, construir, instalar
     > $GOPATH/bin/helloworld            # ejecutar
     Hello, 世界
   < srci..

   Para ejecutar los ejemplos, necesitara al menos la version 1.5 de Go.

   ..srci > sh
     > go version
     go version go1.5 linux/amd64
   < srci..

   Siga las instrucciones en @l(https://golang.org/doc/install) si en su equipo
   la herramienta @$(go) esta ausente o es antigua.

** Donde Encontrar Mas Informacion

   La mejor fuente para obtener mas informacion sobre Go es el sitio web
   oficial, @l(https://golang.org), que proporciona acceso a la documentacion,
   incluyendo la @e(Especificacion del Lenguaje de Programacion Go), los
   paquetes estandar, y similares. Tambien hay tutoriales sobre como escribir Go
   y como escribirlo bien, y una amplia variedad de recursos de texto y video en
   linea que seran valiosos complementos para este libro. El Blog de Go se
   encuentra en @l(https://blog.golang.org<>blog.golang.org) donde se publican
   algunos de los mejores escritos de Go, con articulos sobre el estado del
   lenguaje, los planes a futuro, los informes sobre conferencias y
   explicaciones en profundidad de una amplia variedad de temas relacionados.

   Uno de los aspectos mas utiles del acceso en linea a Go (y una limitacion
   lamentable de un libro de papel) es la capacidad de ejecutar programas Go
   desde las paginas web que los describen. Esta funcionalidad es proporcionada
   por Go Playground en @l(https://play.golang.org<>play.golang.org), y puede
   incrustarse dentro de otras paginas, como la pagina de inicio en
   @l(https://golang.org<>golang.org) o las paginas de documentacion provistas
   por la herramienta @$(godoc).

   Playground hace que sea conveniente llevar a cabo experimentos sencillos para
   comprobar la propia comprension de la sintaxis, la semantica, o paquetes de
   librerias con programas cortos, y en muchos sentidos toma el lugar de un
   @e(bucle de leectura-evaluacion-impresion) (@e(read-eval-print loop) o REPL) de otros
   lenguajes. Sus URLs persistentes son excelentes para compartir fragmentos de
   codigo con otros, para informar sobre errores o hacer sugerencias.

   Construido sobre Playground, el Tour Go en @l(https://tour.golang.org<>tour.golang.org)
   es una secuencia de breves lecciones interactivas sobre las ideas y construcciones
   basicas de Go, un paseo ordenado atraves del lenguaje.

   El principal inconveniente de Playground y el Tour es que permiten que solo
   se importen librerias estandar, y muchas funciones de la libreria–por
   ejemplo, redes–estan restringidas por razones practicas o de seguridad.
   Tambien requiere de acceso a Internet para compilar y ejecutar cada programa.
   Asi que para experimentos mas elaborados, tendra que ejecutar programas Go en
   su propia computadora. Afortunadamente, el proceso de descarga es sencillo,
   por lo que no debe tomar mas de unos minutos obtener la distribucion Go
   desde @l(https://golang.org<>golang.org) y empezar a escribir y ejecutar
   programas por su cuenta.

   Ya que Go es un proyecto de codigo abierto, se puede leer el codigo fuente de
   cualquier tipo o funcion en la libreria estandar en @l(https://golang.org/pkg);
   el mismo codigo forma parte de la distribucion descargada. Utilicelo para
   averiguar como funciona algo, o para responder a preguntas sobre los
   detalles, o simplemente para ver como los expertos escriben buen Go.

** Agradecimientos

   Rob Pike y Russ Cox, miembros principales del equipo de Go, leyeron el
   manuscrito varias veces con mucho cuidado; sus comentarios sobre todo, desde
   la eleccion de palabras hasta la estructura general y la organizacion han
   sido invaluables. Mientras preparaba la traduccion japonesa, Yoshiki Shibata
   iba mucho mas alla del llamado del deber; su ojo meticuloso observo numerosas
   inconsistencias en el texto ingles y errores en el codigo. Apreciamos
   grandemente revisiones completas y comentarios criticos en el manuscrito
   entero de Brian Goetz, Corey Kosak, Arnold Robbins, Josh Bleecher Snyder, y
   Peter Weinberger.

   Agradecemos a Sameer Ajmani, Ittai Balaban, David Crawshaw, Billy Donohue,
   Jonathan Feinberg, Andrew Gerrand, Roberto Griesemer, John Linderman, Minux
   Ma, Bryan Mills, Bala Natarajan, Cosmos Nicolaou, Paul Staniforth, Nigel Tao,
   y a Howard Trickey por muchas sugerencias utiles. Tambien damos las gracias
   a David Brailsford y Raph Levien por sus consejos sobre composicion
   tipografica.

   Nuestro redactor Greg Doench de Addison-Wesley puso a girar la rueda
   originalmente y ha sido de continua ayuda desde entonces. El equipo de
   produccion de AW–John Fuller, Dayna Isley, Julie Nahil, Chuti Prasertsith y
   Barbara Wood–ha sido excepcional; los autores no podrian esperar un mejor
   apoyo.

   Alan Donovan desea agradecer a: Sameer Ajmani, Chris Demetriou, Walt
   Drummond, y Reid Tatge de Google por haberle dado tiempo para escribir; a Stephen
   Donovan, por su consejo y oportuno estimulo; y sobre todo a su esposa Leila
   Kazemi, por su entusiasmo y apoyo inquebrantable a este proyecto, a pesar de
   las largas horas de distraccion y ausentismo de la vida familiar que ello
   implicaba.

   Brian Kernighan esta profundamente agradecido a sus amigos y colegas por su
   paciencia y autodominio mientras avanzaba lentamente por el camino hacia la
   comprension, y especialmente a su esposa Meg, que ha sido infaliblemente
   favorable a la escritura de libros y muchas otras cosas.

   ..quote >
     --Nueva York
     --Octubre 2015
   < quote..

* Capitulo 1 <> Tutorial

  Este capitulo es un recorrido por los componentes basicos de Go. Esperamos
  proporcionar suficiente informacion y ejemplos para que puedas ponerte en
  marcha y hacer cosas utiles lo mas rapido posible. Los ejemplos aqui, y de
  hecho en todo el libro, estan dirigidos a tareas que usted podria tener que
  hacer en el mundo real. En este capitulo intentaremos darle una muestra de la
  diversidad de programas que uno podria escribir en Go, que van desde el simple
  procesamiento de archivos y un poco de graficos, a clientes y servidores de
  Internet concurrentes. Ciertamente no vamos a explicar todo en el primer
  capitulo, pero el estudio de estos programas en un nuevo lenguaje puede ser
  una manera eficaz de empezar.

  Cuando estas aprendiendo un nuevo lenguaje, hay una tendencia natural a
  escribir codigo como lo habrias escrito en un lenguaje que ya conoces. Se
  consciente de este sesgo a medida que aprendes Go y trata de evitarlo. Hemos
  tratado de ilustrar y explicar como escribir buen Go, asi que usa el
  codigo aqui como guia cuando escribas.

** Seccion 1.1 <> Hola, Mundo

   Empezaremos con el ya tradicional ejemplo del @"(hola, mundo), que
   aparece al comienzo de @e(El lenguaje de programacion C), publicado
   en 1978. C es una de las influencias mas directas sobre Go, y @"(hola, mundo)
   ilustra una serie de ideas centrales.

   ..figure > @l(gopl.io/ch1/helloworld/main.go<>gopl.io/ch1/helloworld)

     ..src > go
       package main

       import "fmt"

       func main() {
         fmt.Println("Hello, 世界")
       }
     < src..

   Go es un lenguaje compilado. El conjunto de herramientas de Go convierte el
   codigo fuente de un programa y las cosas de las que depende, en instrucciones
   en el lenguaje maquina nativo de una computadora. Se puede acceder a estas
   herramientas a traves de un unico comando llamado @$(go) que tiene una serie
   de subcomandos. El mas simple de estos subcomandos es @$(run), que compila
   el codigo fuente de uno o mas archivos de origen cuyos nombres terminan en
   @f(.go), lo enlaza con las librerias, y luego, ejecuta el archivo
   ejecutable resultante. (Utilizaremos @$($) como el simbolo del sistema en
   todo el libro.)

   ..srci > sh
     > go run helloworld.go
   < srci..

   No es sorprendente que esto imprima

   ..srci > sh
     Hello, 世界
   < srci..


   Go maneja Unicode de forma nativa, por lo que puede procesar texto en todos
   los idiomas del mundo.

   Si el programa es mas que un experimento de una sola vez, es probable que
   quieras compilarlo una vez y guardar el resultado compilado para su uso
   posterior. Esto se hace con @$(go build):

   ..srci > sh
     > go build helloworld.go
   < srci..

   Esto crea un archivo binario ejecutable llamado @$(helloworld) que se pueden
   ejecutar en cualquier momento sin procesamiento adicional:

   ..srci > sh
     > ./helloworld
     Hello, 世界
   < srci..

   Hemos etiquetado cada ejemplo significativo como un recordatorio de que
   se puede obtener el codigo fuente del libro desde el repositorio
   @l(http://www.gopl.io/<>gopl.io): @l(http://www.gopl.io/ch1/helloworld<>gopl.io/ch1/helloworld)

   Si ejecutas @$(go get gopl.io/ch1/helloworld), obtendra el codigo fuente y
   lo colocara en el directorio correspondiente. Hay mas informacion sobre este
   tema en la @l(#Seccion 2.6) y la @l(#Seccion 10.7).

   Hablemos ahora del programa en si. El codigo Go esta organizado en paquetes,
   que son similares a librerias o modulos en otros lenguajes. Un paquete se
   compone de uno o mas archivos de codigo @f(.go) en un unico directorio que
   definen lo que hace el paquete. Cada archivo de codigo inicia con una
   declaracion del paquete, aqui es @c(package main), que declara a que paquete
   pertenece el archivo, seguido de una lista de otros paquetes que importa, y
   luego las declaraciones del programa que se almacenan en ese archivo.

   La libreria estandar de Go tiene mas de 100 paquetes para tareas comunes como
   entrada y salida, clasificacion y manipulacion de texto. Por ejemplo, el
   paquete @c(fmt) contiene funciones para la impresion y entrada de datos con
   formato. @c(Println) es una de las funciones basicas de salida en @c(fmt);
   imprime uno o mas valores, separados por espacios, con un caracter de
   nueva linea al final para que los valores aparezcan como una sola linea de
   salida.

   El paquete @c(main) es especial. Define un programa ejecutable independiente,
   no una libreria. Dentro del paquete @c(main) la @e(funcion) @c(main) tambien
   es especial–es donde comienza la ejecucion del programa. Cualquier cosa que
   haga @c(main) es lo que hara el programa. Por supuesto, @c(main) sera
   normalmente un llamado a las funciones de otros paquetes que hacen gran parte
   del trabajo, como la funcion @c(fmt.Println).

   Debemos decirle al compilador que paquetes son necesarios para este archivo
   de codigo fuente; ese es el papel de la declaracion @c(import) seguida por la
   declaracion del @c(paquete). El programa @"(hola, mundo) utiliza solo una
   funcion de otro paquete, pero en la mayoria de los programas se importaran mas
   paquetes.

   Debes importar exactamente los paquetes que necesitas. Un programa no compilara
   si hay importaciones que faltan o si son innecesarias. Este estricto
   requisito impide que las referencias a paquetes no utilizados se acumulen a
   medida que los programas evolucionan.

   Las declaraciones @c(import) deben ir luego de la declaracion @c(package).
   Despues de eso, un programa consiste en la declaracion de funciones,
   variables, constantes y tipos (introducidos por las palabras clave @c(func),
   @c(var), @c(const), y @c(type)); en su mayor parte, el orden de las
   declaraciones no importa. Este programa es lo mas corto posible, ya que
   declara solo una funcion, que a su vez solo llama a otra funcion. Para
   ahorrar espacio en la presentacion de ejemplos, a veces no mostramos las
   declaraciones @c(package) e @c(import), pero estaran en el codigo del archivo
   y deben estar ahi para compilar el codigo.

   Una declaracion de funcion consiste en la palabra clave @c(func), el nombre
   de la funcion, una lista de parametros (vacia para @c(main)), una lista de
   resultados (aqui tambien vacia), y el cuerpo de la funcion–las declaraciones
   que definen lo que hace–encerradas entre llaves. Vamos a echar un vistazo mas
   de cerca a las funciones en el @l(#Capitulo 5).

   Go no requiere punto y coma al final de las sentencias o declaraciones,
   excepto donde aparecen dos o mas en la misma linea. En efecto, las nuevas
   lineas que siguen ciertas palabras se convierten en punto y coma, por lo que
   cuando se colocan nuevas lineas se colocan en funcion del correcto analisis
   del codigo Go. Por ejemplo, la llave de apertura @c({) de la funcion, debe
   estar en la misma linea, que el final de la declaracion @c(func), no en una
   linea distinta, y en la expresion @c(x + y), se permite un salto de linea
   despues, pero no antes del operador @c(+).

   Go toma una fuerte postura sobre el formato del codigo. La herramienta @$(gofmt)
   reescribe el codigo en el formato estandar, y el subcomando @$(fmt) de la
   herramienta @$(go) aplica @$(gofmt) a todos los archivos en el paquete
   especificado, o por defecto, a los que estan en el directorio actual. Se ha
   ejecutado @$(gofmt) sobre todos los archivos de codigo fuente en el libro, y
   usted debe optener el habito de hacer lo mismo con su propio codigo. Declarar
   un formato estandar por mandato elimina un monton de debate inutil sobre
   trivialidades y, lo que es mas importante, permite una variedad de
   transformaciones automatizadas de codigo fuente que serian imposibles si se
   permitiera el formato arbitrario.

   Muchos editores de texto pueden ser configurados para ejecutar @$(gofmt) cada
   vez que se guarda un archivo, por lo que su codigo fuente siempre tendra el
   formato apropiado. Una herramienta relacionada, @$(goimports), ademas,
   gestiona la insercion y extraccion de las declaraciones de importacion, segun
   sea necesario. No es parte de la distribucion estandar pero se puede obtener
   con este comando:

   ..srci > sh
     > go get golang.org/x/tools/cmd/goimports
   < srci..

   Para la mayoria de los usuarios, la forma habitual de descargar y construir
   paquetes, ejecutar pruebas, mostrar su documentacion, y asi sucesivamente, es
   con la herramienta @$(go), que veremos en la @l(#Seccion 10.7).

** Seccion 1.2 <> Argumentos de Linea de Comandos

   La mayoria de los programas procesan alguna entrada para producir alguna
   salida; que es mas o menos la definicion de computacion. Pero, ¿como un
   programa obtiene datos de entrada sobre los que operar? Algunos programas
   generan sus propios datos, pero mas a menudo, la entrada proviene de una
   fuente externa: un archivo, una conexion de red, la salida de otro programa,
   un usuario en un teclado, argumentos de linea de comandos o similares. En los
   siguientes ejemplos se discutiran algunas de estas alternativas, comenzando con
   argumentos de linea de comandos.

   El paquete @c(os) proporciona funciones y otros valores para relacionarse con
   el sistema operativo de una manera independiente de la plataforma. Los
   argumentos de linea de comandos estan disponibles para un programa en una
   variable denominada @c(Args) que forma parte del paquete @c(os); por lo tanto
   su nombre en cualquier lugar fuera del paquete @c(os) es @c(os.Args).

   La variable @c(os.Args) es un @e(slice) de @c(strings). Los slices son una
   nocion fundamental en Go, y hablaremos mucho mas sobre ellos pronto. Por
   ahora, piensa en un slice como una secuencia @c(s) de elementos de un arreglo
   de tamaño dinamico, donde los elementos individuales pueden accederse como
   @c(s[i]) y una subsecuencia contigua como @c(s[m:n]). El numero de elementos esta
   dado por @c[len(s)]. Como en la la mayoria de los otros lenguajes de
   programacion, toda  indexacion en Go utiliza intervalos @e(semiabiertos)
   que incluyen el primer indice, pero no incluyen el ultimo, ya que simplifica
   la logica. Por ejemplo, el slice  @c(s[m:n]), donde @c[0 ≤ m ≤ n ≤ len(s)],
   contiene @c(n-m) elementos.

   El primer elemento de @c(os.Args), @c(os.Args[0]), es el nombre del comando
   en si; los otros elementos son los argumentos que se ofresieron al programa
   cuando se inicio la ejecucion. Una expresion de la forma @c(s[m:n]) produce
   un slice que hace referencia a los elementos entre @c(m) y @c(n-1), por lo
   que los elementos que necesitamos para nuestro siguiente ejemplo corresponden
   al slice @c{os.Args[1:len(os.Args)]}. Si @c(m) o @c(n) se omite, el valor
   predeterminado es 0 o @c[len(s)], respectivamente, por lo que se puede
   abreviar el slice deseado como @c(os.Args[1:]).

   Aqui esta una implementacion del comando @$(echo) de Unix, que imprime sus
   argumentos de linea de comandos en una sola linea. Importa dos paquetes, que
   se dan como una lista entre parentesis en lugar de como declaraciones de
   importacion individuales. Cualquiera de las formas es legal, pero
   convencionalmente se utiliza el formato de lista. El orden de las
   importaciones no importa; la herramienta @$(gofmt) ordena los nombres de los
   paquetes en orden alfabetico. (Cuando hay varias versiones de un ejemplo, a
   menudo las numeraremos para que pueda estar seguro de cual estamos hablando.)

   ..figure > @l(gopl.io/ch1/echo1/main.go<>gopl.io/ch1/echo1)

     ..src > go
       // Echo1 imprime sus argumentos de linea de comandos
       package main

       import (
         "fmt"
         "os"
       )

       func main() {
         var s, sep string
         for i := 1; i < len(os.Args); i++ {
           s += sep + os.Args[i]
           sep = " "
         }
         fmt.Println(s)
       }
     < src..


   Los comentarios comienzan con @c(//). Todo el texto desde @c(//) hasta el
   final de la linea es el comentario para los programadores y es ignorado por
   el compilador. Por convencion, describimos cada paquete en un comentario
   inmediatamente anterior a su declaracion del paquete; para un paquete
   @c(main), este comentario es una o varias frases completas que describen el
   programa en su conjunto.

   La declaracion @c(var) declara dos variables @c(s) y @c(sep), de tipo
   @c(string). Una variable se puede inicializar como parte de su declaracion.
   Si no se inicia de forma explicita, se inicializa de forma implicita al
   @e(valor cero) para su tipo, que es @c(0) para los tipos numericos y la cadena
   vacia @c("") para strings. Asi, en este ejemplo, la declaracion implicita
   inicializa @c(s) y @c(sep) como cadenas vacias. Tendremos mas que decir
   acerca de las variables y las declaraciones en el @l(#Capitulo 2).

   Para los numeros, Go proporciona los operadores aritmeticos y logicos
   habituales. Sin embargo, cuando se aplica a las cadenas, el operador @c(+)
   @e(concatena) los valores, por lo que la expresion

   ..src > go
     sep + os.Args[i]
   < src..

   representa la concatenacion de las cadenas @c(sep) y @c(os.Args[i]). La
   declaracion que usamos en el programa,

   ..src > go
     s += sep + os.Args[i]
   < src..

   es una @e(sentencia de asignacion) que concatena el antiguo valor de @c(s) con @c(sep)
   y @c(os.Args[i]) y lo asigna de nuevo a @c(s); es equivalente a

   ..src > go
     s = s + sep + os.Args[i]
   < src..

   El operador @c(+=) es un @e(operador de asignacion). Cada operador aritmetico y
   logico como @c(+) o @c(*) tiene un operador de asignacion correspondiente.

   El programa @$(echo) podria haber impreso su salida en un bucle de una sola
   pieza a la vez, pero en esta version, en su lugar se acumula una cadena
   añadiendo repetidamente nuevo texto hasta el final. La cadena de @c(s)
   comienza su vida vacia, es decir, con el valor @c(""), y cada ciclo a traves
   del bucle añade un poco de texto a ella; despues de la primer iteracion,
   tambien se inserta un espacio para que cuando el bucle termine, haya
   un espacio entre cada argumento. Este es un proceso cuadratico que podria ser
   costoso si el numero de argumentos es grande, pero para @$(echo), eso es poco
   probable. Vamos a mostrar una serie de versiones mejoradas de @$(echo) en
   este capitulo y el siguiente para hacer frente a cualquier ineficiencia real.

   La variable de indice @c(i) del bucle se declara en la primer parte del bucle
   @c(for). El simbolo @c(:=) es parte de una @e(declaracion de variables
   compacta), una sentencia que declara una o mas variables y les da los tipos
   apropiados basados en los valores del inicializador; hay mas informacion al
   respecto en el proximo capitulo.

   La declaracion de incremento @c(i++) añade 1 a @c(i); que es equivalente a
   @c(i += 1), que es a su vez equivalente a @c(i = i + 1). Hay una declaracion
   de decremento correspondiente @c(i--) que resta 1. Estas son declaraciones,
   no expresiones como lo son en la mayoria de los lenguajes en la familia C,
   por lo que @c(j = i++) es ilegal, y solamente son de sufijo, asi @c(--i)
   tampoco es legal.

   El bucle @c(for) es la unica sentencia de bucle en Go. Tiene varias formas,
   una de las cuales se ilustra aqui:

   ..src > go
     for inicializacion; condicion; incremento {
         // cero o mas declaraciones
     }
   < src..

   Los parentesis no se utilizan nunca alrededor de los tres componentes de un
   bucle @c(for). Sin embargo, las llaves son obligatorias, y la llave de apertura
   deben estar en la misma linea que la declaracion @c(incremento).

   La declaracion opcional @c(inicializacion) se ejecuta antes de que comience
   el bucle. Si esta presente, debe ser una simple declaracion, es decir, una
   declaracion de variables compacta, una declaracion de incremento o asignacion, o
   una llamada a funcion. La @c(condition) es una expresion booleana que se
   evalua en al inicio de cada iteracion del bucle; si se evalua como @c(true),
   las declaraciones controladas por el bucle se ejecutan. La declaracion
   @c(incremento) se ejecuta despues del cuerpo del bucle, luego la
   @c(condicion) se evalua de nuevo. El bucle termina cuando la condicion se
   convierte en falsa.

   Cualquiera de estas partes puede omitirse. Si no hay @c(inicializacion) y
   ningun @c(incremento), el punto y coma tambien pueden omitirse:

   ..src > go
     // un tradicional bucle "while"
     for condicion {
         // ...
     }
   < src..

   Si la condicion se omite por completo en cualquiera de estas formas, por
   ejemplo en

   ..src > go
     // un tradicional bucle infinito
     for {
         // ...
     }
   < src..

   el bucle es infinito, aunque los bucles de esta forma se pueden terminar de
   alguna otra manera, como una declaracion @c(break) o @c(return).

   Otra forma en que el bucle @c(for) itera, es sobre un @e(rango) de valores de
   un tipo de datos como un string o un slice. Para ilustrar esto, he aqui una
   segunda version de @$(echo):

   ..figure > @l(gopl.io/ch1/echo2/main.go<>gopl.io/ch1/echo2)

     ..src > go
       // Echo2 imprime sus argumentos de linea de comandos
       package main

       import (
         "fmt"
         "os"
       )

       func main() {
         s, sep := "", ""
         for _, arg := range os.Args[1:] {
           s += sep + arg
           sep = " "
         }
         fmt.Println(s)
       }
     < src..


   En cada iteracion del bucle, @c(range) produce un par de valores: el indice y
   el valor del elemento en ese indice. En este ejemplo, no necesitamos el
   indice, pero la sintaxis de un bucle @c(range) requiere que si tratamos con
   el elemento, debemos tratar tambien con el indice. Una idea seria asignar el
   indice a una variable temporal, como @c(temp) y pasar por alto su valor, pero
   Go no permite tener variables locales sin utilizar, por lo que esto daria
   lugar a un error de compilacion.

   La solucion es utilizar el @e(identificador en blanco), cuyo nombre es @c(_)
   (esto es, un guion bajo). El identificador en blanco puede utilizarse siempre
   que la sintaxis requiera un nombre de variable, pero la logica del programa
   no lo haga, por ejemplo para descartar un indice no deseado del bucle cuando
   solo necesitamos el valor del elemento. La mayoria de los programadores Go
   probablemente usarian @c(range) y @c(_) para escribir el programa @$(echo)
   anterior, ya que la indexacion sobre @c(os.Args) es implicita, no explicita,
   y por lo tanto mas facil de hacerlo bien.

   Esta version del programa utiliza una declaracion compacta de variables para
   declarar e inicializar @c(s) y @c(sep), pero podria igualmente haber declarado las
   variables por separado. Hay varias maneras de declarar una variable string;
   Todas estas son equivalentes:

   ..src > go
     s := ""
     var s string
     var s = ""
     var s string = ""
   < src..

   Por que preferirias una forma sobre otra? El primer formato, una
   declaracion de variable compacta, es la mas breve, pero solo puede utilizarse
   dentro de una funcion, no para variables de nivel de paquete. La segunda
   forma se basa en la inicializacion por defecto al valor cero para strings,
   que es @c(""). La tercera forma se utiliza raramente excepto cuando se
   declaran multiples variables. La cuarta forma es explicita sobre el tipo de
   la variable, que es redundante cuando es el mismo que el del valor inicial
   pero necesario en otros casos donde no son del mismo tipo. En la practica,
   generalmente debe utilizar una de las dos primeras formas, con inicializacion
   explicita para decir que el valor inicial es importante e implicita para
   decir que el valor inicial no importa.

   Como se señalo anteriormente, cada iteracion alrededor del bucle, la cadena
   @c(s) obtiene contenidos completamente nuevos. La declaracion @c(+=) crea una
   nueva cadena mediante la concatenacion de la cadena antigua, un caracter de
   espacio, y el siguiente argumento, a continuacion, asigna la nueva cadena a
   @c(s). El contenido antiguo del @c(s) ya no estan en uso, por lo que sera
   recolectado por el recolector de basura a su debido tiempo.

   Si la cantidad de datos involucrados es grande, esto podria ser costoso. Una
   solucion mas simple y mas eficiente seria utilizar la funcion @c(Join) del
   paquete @c(strings):

   ..figure > @l(gopl.io/ch1/echo3/main.go<>gopl.io/ch1/echo3)

     ..src > go
       func main() {
         fmt.Println(strings.Join(os.Args[1:], " "))
       }
     < src..


   Por ultimo, si no nos interesa el formato, y solo queremos ver los valores,
   tal vez para depuracion, podemos dejar que @c(Println) formatee el resultado por
   nosotros:

   ..src > go
     fmt.Println(os.Args[1:])
   < src..

   El resultado de esta sentencia es como la que se puede conseguir mediante
   @c(strings.Join), pero con corchetes al rededor. Cualquier slice se puede
   imprimir de esta manera.

   @b(Ejercicio 1.1): Modifica el programa @$(echo) para imprimir tambien
   @c(os.Args[0]), el nombre del comando que lo invoco.

   @b(Ejercicio 1.2): Modifica el programa @$(echo) para imprimir el indice y el
   valor de cada uno de sus argumentos, uno por linea.

   @b(Ejercicio 1.3): Experimenta para medir la diferencia en el tiempo de
   funcionamiento entre nuestras versiones potencialmente ineficientes y el que
   utiliza @c(strings.Join). (La @l(#Seccion 1.6) ilustra parte del paquete
   @c(time), y la @l(#Seccion 11.4) muestra como escribir pruebas de referencia
   para la evaluacion sistematica del rendimiento.)

** Seccion 1.3 <> Encontrar lineas duplicadas

   Los programas para copiar archivos, imprimir, buscar, clasificar, contar y
   similares tienen una estructura parecida: un bucle sobre la entrada, algun
   calculo sobre cada elemento y generacion de salida al vuelo o al final.
   Mostraremos tres variantes de un programa llamado @$(dup); se inspira en
   parte por el comando Unix @$(uniq), que mira las lineas duplicadas
   adyacentes. Las estructuras y paquetes utilizados son modelos que se pueden
   adaptar facilmente.

   La primer version de @$(dup) imprime cada linea que aparece mas de una vez en
   la entrada estandar, precedido por su recuento. Este programa presenta la
   declaracion @c(if), el tipo de datos @c(map) y el paquete @c(bufio).

   ..figure > @l(gopl.io/ch1/dup1/main.go<>gopl.io/ch1/dup1)

     ..src > go
       // Dup1 imprime el texto de cada linea que aparece mas de
       // una vez en la entrada estandar, precedida por su recuento.
       package main

       import (
         "bufio"
         "fmt"
         "os"
       )

       func main() {
         counts := make(map[string]int)
         input := bufio.NewScanner(os.Stdin)
         for input.Scan() {
           counts[input.Text()]++
         }
         // NOTA: ignorando posibles errores de input.Err ()
         for line, n := range counts {
           if n > 1 {
             fmt.Printf("%d\t%s\n", n, line)
           }
         }
       }
     < src..


   Al igual que con @c(for), nunca se usan parentesis alrededor de la
   declaracion de la condicion @c(if), pero se requieren llaves para el
   cuerpo. Puede haber una parte @c(else) opcional que se ejecute si la
   condicion es falsa.

   Un @e(mapa) contiene un conjunto de pares clave/valor y proporciona
   operaciones de tiempo constante para almacenar, recuperar, o comprobar un
   elemento en el conjunto. La clave puede ser de cualquier tipo cuyos valores
   puedan compararse con @c(==), siendo strings el ejemplo mas comun; el valor
   puede ser de cualquier tipo en absoluto. En este ejemplo, las claves son
   @c(string)s, y los valores son @c(int)s. La funcion incorporada @c(make) crea
   un nuevo mapa vacio; tiene otros usos tambien. Los mapas se discuten
   extensamente en la @l(#Seccion 4.3).

   Cada vez que @$(dup) lee una linea de entrada, la linea se utiliza como una
   clave en el mapa y se incrementa el valor correspondiente. La declaracion
   @c{counts[input.Text()]++} es equivalente a estas dos afirmaciones:

   ..src > go
     line := input.Text()
     counts[line] = counts[line] + 1
   < src..

   No es un problema, si el mapa aun no contiene esa clave. La primera vez que
   se ve una nueva linea, la expresion @c(counts[line]) en el lado derecho se
   evalua al valor cero para su tipo, que es 0 para @c(int).

   Para imprimir los resultados, utilizamos otro bucle de repeticion @c(for)
   basado en @c(range), esta vez sobre el mapa @c(counts). Como antes, cada
   iteracion produce dos resultados, una clave y el valor del elemento del mapa
   para esa clave. El orden de la iteracion del mapa no es especifico, en la
   practica es aleatorio, variando de una ejecucion a otra. Este diseño es
   intencional, ya que impide que los programas se basen en cualquier orden
   particular donde no se garantiza ninguno.

   El paquete @c(bufio), ayuda a que la entrada y salida sea eficiente y
   conveniente. Una de sus caracteristicas mas utiles es un tipo llamado
   @c(Scanner) que lee la entrada y la rompe en lineas o palabras; a menudo es
   la manera mas facil de procesar la entrada que llega naturalmente en lineas.

   El programa utiliza una breve declaracion de variables para crear una nueva
   variable de entrada que hace referencia a @c(bufio.Scanner):

   ..src > go
     input := bufio.NewScanner(os.Stdin)
   < src..

   El escaner lee de la entrada estandar del programa. Cada llamada a
   @c[input.Scan()] lee la siguiente linea y elimina el caracter de nueva linea
   al final; el resultado puede ser recuperado llamando a @c[input.Text()]. La
   funcion @c(Scan) devuelve @c(true) si hay una linea y @c(false) cuando no hay
   mas entrada.

   La funcion @c(fmt.Printf), como @c(printf) en C y otros lenguajes, produce
   una salida con formato de una lista de expresiones. Su primer argumento es
   una cadena de formato que especifica como deben formatearse los argumentos
   posteriores. El formato de cada argumento esta determinado por un caracter de
   conversion, una letra siguiendo un signo de porcentaje. Por ejemplo, @c(%d)
   formatea un operando entero usando la notacion decimal, y @c(%s) se expande
   para el valor de un operando de cadena.

   @c(Printf) tiene mas de una docena de estas conversiones, que los
   programadores de Go llaman @e(verbos). Esta tabla esta lejos de ser una
   especificacion completa, pero ilustra muchas de las caracteristicas que estan
   disponibles:

   +------------------------+--------------------------------------------------------------------+
   | @c(%d)                 | entero decimal                                                     |
   +------------------------+--------------------------------------------------------------------+
   | @c(%x), @c(%o), @c(%b) | entero en hexadecimal, octal, binario                              |
   +------------------------+--------------------------------------------------------------------+
   | @c(%f), @c(%g), @c(%e) | numero de coma flotante: 3.141593 3.141592653589793 3.141593e + 00 |
   +------------------------+--------------------------------------------------------------------+
   | @c(%t)                 | booleano: @c(true) o @c(false)                                     |
   +------------------------+--------------------------------------------------------------------+
   | @c(%c)                 | runa (punto de codigo Unicode)                                     |
   +------------------------+--------------------------------------------------------------------+
   | @c(%s)                 | string                                                             |
   +------------------------+--------------------------------------------------------------------+
   | @c(%q)                 | citar string @c("abc") o runa @c('c')                              |
   +------------------------+--------------------------------------------------------------------+
   | @c(%v)                 | cualquier valor en un formato natural                              |
   +------------------------+--------------------------------------------------------------------+
   | @c(%T)                 | cualquier tipo de valor                                            |
   +------------------------+--------------------------------------------------------------------+
   | @c(%%)                 | signo literal de porcentaje (sin operando)                         |
   +------------------------+--------------------------------------------------------------------+

   El formato de cadena en @c(dup1) tambien contiene una tabulacion @c(\t) y un
   salto de linea @c(\n). Los literales de cadena pueden contener tales
   @e(secuencias de escape) para la representacion de caracteres de otra manera
   invisibles. @c(Printf) no escribe una nueva linea por defecto. Por
   convencion, las funciones de formato cuyos nombres terminan en @c(f), tales
   como @c(log.Printf) y @c(fmt.Errorf), utilizan las reglas de formato de
   @c(fmt.Printf), mientras que aquellas cuyos nombres terminan en @c(ln) como
   @c(Println), formatean sus argumentos con @c(%v), seguido por una nueva
   linea.

   Muchos programas leen ya sea a partir de su entrada estandar, como
   arriba, o de una secuencia de archivos con nombre. La proxima version
   de @$(dup) puede leer desde la entrada estandar o manejar una lista de
   nombres de archivos, utilizando @c(os.Open) para abrir cada uno de ellos:

   ..figure > @l(gopl.io/ch1/dup2/main.go<>gopl.io/ch1/dup2)

     ..src > go
       // Dup2 imprime el recuento y el texto de las lineas que aparecen mas de una vez
       // en la entrada. Se lee desde stdin o desde una lista de archivos con nombre.
       package main

       import (
         "bufio"
         "fmt"
         "os"
       )

       func main() {
         counts := make(map[string]int)
         files := os.Args[1:]
         if len(files) == 0 {
           countLines(os.Stdin, counts)
         } else {
           for _, arg := range files {
             f, err := os.Open(arg)
             if err != nil {
               fmt.Fprintf(os.Stderr, "dup2: %v\n", err)
               continue
             }
             countLines(f, counts)
             f.Close()
           }
         }
         for line, n := range counts {
           if n > 1 {
             fmt.Printf("%d\t%s\n", n, line)
           }
         }
       }

       func countLines(f *os.File, counts map[string]int) {
         input := bufio.NewScanner(f)
         for input.Scan() {
           counts[input.Text()]++
         }
         // NOTE: Ignora errores potenciales de input.Err()
       }
     < src..


   La funcion @c(os.Open) devuelve dos valores. El primero es un archivo abierto
   @%c(*os.File) que se utiliza en lecturas posteriores por @c(Scanner).

   El segundo resultado de @c(os.Open) es un valor del tipo nativo @c(error). Si
   @c(err) es igual al valor especial nativo @c(nil), el archivo fue abierto
   correctamente. El archivo se lee, y cuando se llega al final de la entrada,
   @c(Close) cierra el archivo y libera cualquier recurso. Por otro lado, si
   @c(err) no es @c(nil), algo salio mal. En ese caso, el valor de error
   describe el problema. Nuestro sencillo manejo de errores imprime un mensaje
   en el flujo de error estandar utilizando @c(Fprintf) y el verbo @c(%v), que
   muestra un valor de cualquier tipo en un formato predeterminado, y luego
   @c(dup) continua con el siguiente archivo; la instruccion @c(continue) va a
   la siguiente iteracion del bucle @c(for).

   Con el fin de mantener los ejemplos de codigo de un tamaño razonable,
   nuestros primeros ejemplos son intencionalmente un tanto descuidados en el
   manejo de errores. Es evidente que hay que comprobar si hay un error de parte
   de @c(os.Open); sin embargo, estamos ignorando la menos probable posibilidad
   de que pueda producirse un error al leer el archivo con @c(input.Scan).
   Anotaremos los lugares donde hemos omitido la comprobacion de errores,
   entraremos en detalles sobre el manejo de errores en la @l(#Seccion 5.4).

   Observe que la llamada a @c(countLines) precede a su declaracion. Las
   funciones y otras entidades a nivel de paquete se pueden declarar en
   cualquier orden.

   Un mapa es una referencia a la estructura de datos creada por @c(make).
   Cuando un mapa se pasa a una funcion, la funcion recibe una copia de la
   referencia, De modo que cualquier cambio que haga la funcion llamada en la
   estructura de datos subyacente, sera tambien visible a traves de la
   referencia del mapa del llamante. En nuestro ejemplo, los valores insertados
   en el mapa @c(counts) por @c(countLines) son vistos por @c(main).

   Las versiones anteriores de @$(dup) operan en un modo de @"(streaming) en el que
   la entrada se lee y divide en lineas segun sea necesario, por lo que, en
   principio, estos programas pueden manejar una cantidad arbitraria de
   entrada. Un enfoque alternativo es leer la entrada entera en la memoria de un
   solo trago, dividirlo en lineas a la vez, y luego procesar las lineas. La
   siguiente version, @$(dup3), funciona de esa manera. Se introduce la funcion
   @c(ReadFile) (del paquete @c(io/ioutil)), que lee todo el contenido de un
   archivo, y @c(strings.Split), que divide una cadena en un slice de
   subcadenas. (@c(Split) es lo contrario de @c(strings.Join), que vimos
   anteriormente.)

   Hemos simplificado un poco @$(dup3). En primer lugar, solo lee archivos por
   su nombre, no la entrada estandar, ya que @c(ReadFile) requiere como
   argumento un nombre de archivo. En segundo lugar, se paso el conteo de las
   lineas de nuevo a @c(main), ya que ahora solo es necesario un solo lugar.

   ..figure > @l(gopl.io/ch1/dup3/main.go<>gopl.io/ch1/dup3)

     ..src > go
       package main

       import (
         "fmt"
         "io/ioutil"
         "os"
         "strings"
       )

       func main() {
         counts := make(map[string]int)
         for _, filename := range os.Args[1:] {
           data, err := ioutil.ReadFile(filename)
           if err != nil {
             fmt.Fprintf(os.Stderr, "dup3: %v\n", err)
             continue
           }
           for _, line := range strings.Split(string(data), "\n") {
             counts[line]++
           }
         }
         for line, n := range counts {
           if n > 1 {
             fmt.Printf("%d\t%s\n", n, line)
           }
         }
       }
     < src..


   @c(ReadFile) devuelve un slice de @c(byte)s que se debe convertirse en un
   @c(string) para que pueda ser dividido por @c(strings.Split). Vamos a
   discutir los strings y slices de bytes en detalle en la @l(#Seccion 3.5.4).

   Bajo la cubierta, @c(bufio.Scanner), @c(ioutil.ReadFile) y
   @c(ioutil.WriteFile) utilizan los metodos @c(Read) y @c(Write) de
   @c(*os.File), pero es raro que la mayoria de los programadores necesiten
   acceder directamente a las rutinas de bajo nivel. Las funciones de nivel
   superior como @c(bufio) e @c(io/ioutil) son mas faciles de usar.

   @b(Ejercicio 1.4): Modificar @$(dup2) para imprimir los nombres de todos los
   archivos en los que se produce cada linea duplicada.

** Seccion 1.4 <> GIF animados

   El siguiente programa demuestra el uso basico de los paquetes de imagenes
   estandar en Go, que usaremos para crear una secuencia de imagenes de mapa de
   bits y luego codificar la secuencia como una animacion GIF. Las imagenes,
   llamadas @e(figuras de Lissajous), eran un efecto visual basico en peliculas
   de ciencia ficcion de la decada de 1960. Son las curvas parametricas
   producidas por oscilacion armonica en dos dimensiones, tales como dos ondas
   sinusoidales alimentadas en las entradas @m(x) e @m(y) de un osciloscopio. La
   Figura 1.1 muestra algunos ejemplos.

   ..figure > Figura 1.1. Cuatro figuras de Lissajous.

     ..img > img/Figure-1.1.jpg


   Hay varias nuevas construcciones en este codigo, incluyendo declaraciones
   @c(const), tipos de estructura, y literales compuestos. A diferencia de la
   mayoria de nuestros ejemplos, este tambien implica calculos de punto
   flotante. Aqui vamos a discutir estos temas solo brevemente, desplazando la
   mayoria de los detalles a los capitulos posteriores, ya que el objetivo
   principal en este momento es dar una idea de como es Go y el tipo de
   cosas que se pueden hacer facilmente con el lenguaje y sus librerias.

   ..figure > @l(gopl.io/ch1/lissajous/main.go<>gopl.io/ch1/lissajous)

     ..src > go
       // Lissajous genera GIF animados de figuras Lissajous aleatorias.
       package main

       import (
         "image"
         "image/color"
         "image/gif"
         "io"
         "math"
         "math/rand"
         "os"
         "time"
       )

       var palette = []color.Color{color.White, color.Black}

       const (
         whiteIndex = 0 // primer color en la paleta
         blackIndex = 1 // siguiente color en la paleta
       )

       func main() {
         // La secuencia de imagenes es determinista a menos que sembremos
         // el generador de numeros pseudo-aleatorios usando la hora actual.
         rand.Seed(time.Now().UTC().UnixNano())

         lissajous(os.Stdout)
       }

       func lissajous(out io.Writer) {
         const (
           cycles  = 5     // numero de revoluciones completas del oscilador x
           res     = 0.001 // resolucion angular
           size    = 100   // dimencion de la imagen [-size..+size]
           nframes = 64    // numero de cuadros de animacion
           delay   = 8     // retardo entre fotogramas en unidades de 10ms
         )
         freq := rand.Float64() * 3.0 // frecuencia relativa del oscilador y
         anim := gif.GIF{LoopCount: nframes}
         phase := 0.0                 // diferencia de fase
         for i := 0; i < nframes; i++ {
           rect := image.Rect(0, 0, 2*size+1, 2*size+1)
           img := image.NewPaletted(rect, palette)
           for t := 0.0; t < cycles*2*math.Pi; t += res {
             x := math.Sin(t)
             y := math.Sin(t*freq + phase)
             img.SetColorIndex(size+int(x*size+0.5), size+int(y*size+0.5),
               blackIndex)
           }
           phase += 0.1
           anim.Delay = append(anim.Delay, delay)
           anim.Image = append(anim.Image, img)
         }
         gif.EncodeAll(out, &anim) // NOTA: ignorando errores de codificacion
       }
     < src..


   Despues de importar un paquete cuya ruta tiene multiples componentes, como
   @c(image/color), nos referimos al paquete con el nombre que procede del
   ultimo componente. Por lo tanto la variable @c(color.White) pertenece al
   paquete @c(image/color) y @c(gif.GIF) pertenece a @c(image/gif).

   Una declaracion @c(const) @%l(#Seccion 3.6<>§3.6) da nombres a las
   constantes, es decir, valores que se establecen en tiempo de compilacion,
   como los parametros numericos para ciclos, cuadros, y el retardo. Igual que las
   declaraciones @c(var), las declaraciones @c(const) pueden aparecer a nivel de
   paquete (por lo que los nombres son visibles en todo el paquete) o dentro de
   una funcion (por lo que los nombres son visibles solo dentro de esa
   funcion). El valor de una constante debe ser un numero, una cadena o un
   booleano.

   Las expresiones @c([]color.Color{...}) y @c(gif.GIF{...}) son @e(literales
   compuestos) (@l(#Seccion 4.2<>§4.2), @l(#Seccion 4.4.1<>§4.4.1)), una
   notacion compacta de Go para instanciar cualquiera de los tipos compuestos de
   una secuencia de valores de los elementos. Aqui, la primera es un slice y
   la segunda es una @e(estructura).

   El tipo @c(gif.GIF) es de tipo estructura @%l(#Seccion 4.4<>§4.4). Una
   estructura es un grupo de valores denominados @e(campos), a menudo de
   diferentes tipos, que se recogen juntos en un unico objeto que puede tratarse
   como una unidad. La variable @c(anim) es una estructura de tipo @c(gif.GIF).
   La estructura literal crea un valor estructura cuyo campo @c(LoopCount) se
   establece en @c(nframes); todos los demas campos tienen el valor cero para su
   tipo. Se puede acceder a los campos individuales de una estructura usando la
   notacion de punto, al igual que en las dos ultimas asignaciones que actualizan
   de forma explicita los campos @c(Delay) e @c(Image) de @c(anim).

   La funcion @c(lissajous) tiene dos bucles anidados. El bucle exterior se
   ejecuta 64 iteraciones, cada uno produciendo un solo fotograma de la
   animacion. Crea una nueva imagen de 201x201 con una paleta de dos colores,
   blanco y negro. Todos los pixeles se ajustan inicialmente al valor cero de la
   paleta (el color cero de la paleta), que se establece en blanco. Cada paso a
   traves del bucle externo genera una nueva imagen estableciendo algunos
   pixeles en negro. El resultado se añade a una lista de cuadros en @c(anim)
   utilizando la funcion nativa @c(append) @%l(#Seccion 4.2.1<>§4.2.1), junto
   con un retardo especificado de 80ms. Por ultimo, la secuencia de cuadros y
   los retrasos se codifican en formato GIF y se escribe en la salida de flujo
   @c(out). El tipo de @c(out) es @c(io.Writer), lo que nos permite escribir a
   una amplia gama de posibles destinos, como vamos a mostrar pronto.

   El bucle interno ejecuta los dos osciladores. El oscilador @c(x) es
   simplemente la funcion sinusoidal. El oscilador @c(y) es tambien
   sinusoide, pero su frecuencia es relativa a la del oscilador @c(x) un numero
   aleatorio entre 0 y 3, y su fase relativa al oscilador @c(x) es inicialmente
   cero, pero aumenta con cada fotograma de la animacion. El bucle se ejecuta
   hasta que el oscilador @c(x) ha completado cinco ciclos completos. En cada
   paso, se llama a @c(SetColorIndex) para colorear el pixel (@c(x), @c(y))
   correspondiente en negro, que es en la posicion 1 de la paleta.

   La funcion @c(main) llama a la funcion @c(lissajous), dirigiendola a escribir
   en la salida estandar, por lo que este comando produce un GIF animado con
   cuadros como los de la Figura 1.1:

   ..srci > sh
     > go build gopl.io/ch1/lissajous
     > ./lissajous >out.gif
   < srci..

   @b(Ejercicio 1.5): Cambiar la paleta de colores del programa Lissajous a
   verde sobre negro, para mayor autenticidad. Para crear el color web
   @c(#RRGGBB), utilice @c(color.RGBA{0xRR, 0xGG, 0xBB, 0xff}), donde cada par
   de digitos hexadecimales representa la intensidad del componente de color
   rojo, verde o azul del pixel.

   @b(Ejercicio 1.6): Modificar el programa Lissajous para producir imagenes de
   multiples colores mediante la adicion de mas valores a la paleta y luego
   mostrarlos cambiando el tercer argumento de @c(SetColorIndex) de alguna
   manera interesante.

** Seccion 1.5 <> Obtener una URL

   Para muchas aplicaciones, el acceso a la informacion de Internet es tan
   importante como el acceso al sistema de archivos local. Go ofrece una
   coleccion de paquetes, agrupados bajo @c(net), que hacen que sea facil de
   enviar y recibir informacion a traves de Internet, realizar conexiones de red
   de bajo nivel, y configurar servidores, por lo que las caracteristicas de
   concurrencia de Go (introducidas en el @l(#Capitulo 8)) son particularmente
   utiles.

   Para ilustrar el minimo necesario para recuperar informacion a traves de
   HTTP, aqui hay un simple programa llamado @$(fetch) que recupera el
   contenido de cada URL y lo imprime como texto sin interpretar; esta inspirado
   en la invaluable utilidad @$(curl). Obviamente, uno normalmente haria mas con
   tales datos, pero esto muestra la idea basica. Usaremos este programa con
   frecuencia en el libro.

   ..figure > @l(gopl.io/ch1/fetch/main.go<>gopl.io/ch1/fetch)

     ..src > go
       // Fetch imprime el contenido que se encuantra en cada URL especificado.
       package main

       import (
         "fmt"
         "io/ioutil"
         "net/http"
         "os"
       )

       func main() {
         for _, url := range os.Args[1:] {
           resp, err := http.Get(url)
           if err != nil {
             fmt.Fprintf(os.Stderr, "fetch: %v\n", err)
             os.Exit(1)
           }
           b, err := ioutil.ReadAll(resp.Body)
           resp.Body.Close()
           if err != nil {
             fmt.Fprintf(os.Stderr, "fetch: reading %s: %v\n", url, err)
             os.Exit(1)
           }
           fmt.Printf("%s", b)
         }
       }
     < src..


   Este programa introduce funciones a partir de dos paquetes, @c(net/http) e
   @c(io/ioutil). La funcion @c(http.Get) realiza una peticion HTTP y, si no hay
   error, devuelve el resultado en la estructura @c(resp). El campo @c(Body) de
   @c(resp) contiene la respuesta del servidor como un flujo legible. A
   continuacion, @c(ioutil.ReadAll) lee toda la respuesta; el resultado se
   almacena en @c(b). El flujo @c(Body) es cerrado para evitar la fuga de recursos
   y @c(Printf) escribe la respuesta en la salida estandar.

   ..srci > sh
     > go build gopl.io/ch1/fetch
     > ./fetch http://gopl.io
     <html>
     <head>
     <title>The Go Programming Language</title>
     ...
   < srci..

   Si la solicitud HTTP falla, en su lugar, @$(fetch) reportara el error:

   ..srci > sh
     > ./fetch http://bad.gopl.io
     fetch: Get http://bad.gopl.io: dial tcp: lookup bad.gopl.io: no such host
   < srci..

   En cualquiera de los casos de error, @c[os.Exit(1)] hace que el proceso
   termine con un codigo de estado de valor 1.

   @b(Ejercicio 1.7): La funcion @c[io.Copy(dst, src)] lee desde @c(src) y
   escribe en @c(dst). Utilicelo en lugar de @c(ioutil.ReadAll) para copiar el
   cuerpo de la respuesta a @c(os.Stdout) sin requerir un buffer lo
   suficientemente grande como para contener todo el flujo de datos. Asegurese
   de comprobar el resultado del error de @c(io.Copy).

   @b(Ejercicio 1.8): Modificar @$(fetch) para agregar el prefijo @c(http://) a
   cada argumento URL si este no se proporciona. Es posible que desee utilizar
   @c(strings.HasPrefix).

   @b(Ejercicio 1.9): Modificar @$(fetch) para imprimir tambien el codigo de
   estado HTTP, que se encuentra en @c(resp.Status).

** Seccion 1.6 <> Obtener URLs Concurrentemente

   Uno de los aspectos mas interesantes y novedosos de Go es su soporte para la
   programacion concurrente. Este es un tema muy amplio, al que se dedican el
   @l(#Capitulo 8) y el @l(#Capitulo 9), asi que por ahora le daremos solo una
   muestra de los principales mecanismos de la concurrencia en Go, @e(gorutinas)
   y @e(canales).

   El siguiente programa, @$(fetchall), realiza la misma busqueda del contenido
   de una URL como en el ejemplo anterior, pero obtiene muchas URL, todas al
   mismo tiempo, de modo que el proceso no tardara mas que la busqueda mas
   prolongada en lugar de la suma de todos los tiempos de busqueda. Esta version
   de @$(fetchall) descarta las respuestas, pero indica el tamaño y el tiempo
   transcurrido de cada una:

   ..figure > @l(gopl.io/ch1/fetchall/main.go<>gopl.io/ch1/fetchall)

     ..src > go
       // Fetchall busca URLs en paralelo e informa de sus tiempos y tamaños.
       package main

       import (
         "fmt"
         "io"
         "io/ioutil"
         "net/http"
         "os"
         "time"
       )

       func main() {
         start := time.Now()
         ch := make(chan string)
         for _, url := range os.Args[1:] {
           go fetch(url, ch) // inicia una gorutina
         }
         for range os.Args[1:] {
           fmt.Println(<-ch) // recibir desde el canal ch
         }
         fmt.Printf("%.2fs elapsed\n", time.Since(start).Seconds())
       }

       func fetch(url string, ch chan<- string) {
         start := time.Now()
         resp, err := http.Get(url)
         if err != nil {
           ch <- fmt.Sprint(err) // enviar al canal ch
           return
         }

         nbytes, err := io.Copy(ioutil.Discard, resp.Body)
         resp.Body.Close() // no pierdas recursos
         if err != nil {
           ch <- fmt.Sprintf("while reading %s: %v", url, err)
           return
         }
         secs := time.Since(start).Seconds()
         ch <- fmt.Sprintf("%.2fs  %7d  %s", secs, nbytes, url)
       }
     < src..


   He aqui un ejemplo:

   ..srci > sh
     > go build gopl.io/ch1/fetchall
     > ./fetchall https://golang.org http://gopl.io https://godoc.org
     0.14s     6852 https://godoc.org
     0.16s     7261 https://golang.org
     0.48s     2475 http://gopl.io
     0.48s elapsed
   < srci..

   Una @e(gorutina) es una funcion de ejecucion concurrente. Un @e(canal) es un
   mecanismo de comunicacion que permite a una @e(gorutina) pasar valores
   de un tipo especificado a otra @e(gorutina). La funcion @e(main) se ejecuta
   en una gorutina y la sentencia @c(go) crea gorutinas adicionales.

   La funcion @c(main) crea un canal de strings utilizando @c(make). Para cada
   argumento de linea de comandos, la sentencia @c(go) en el primer bucle inicia
   una nueva gorutina que llama a @c(fetch) asincronamente para buscar la URL
   usando @c(http.Get). La funcion @c(io.Copy) lee el cuerpo de la respuesta y
   lo descarta escribiendo en el flujo de salida @c(ioutil.Discard). @c(Copy)
   devuelve el numero de bytes, junto con cualquier error prodicido. A medida
   que llega cada resultado, @c(fetch) envia una linea de resumen en el canal
   @c(ch). El segundo bucle en @c(main) recibe e imprime esas lineas.

   Cuando una gorutina intenta enviar o recibir en un canal, se bloquea hasta
   que otra gorutina intente la operacion correspondiente de recepcion o envio,
   momento en el cual se transfiere el valor y ambas gorutinas continuan. En
   este ejemplo, cada @c(fetch) envia un valor (@e(expresion) @c(ch <-)) en el
   canal @c(ch), y @c(main) recibe todos ellos (@c(<-ch)). Tener a @c(main)
   haciendo toda la impresion, asegura que la salida de cada gorutina se procesa
   como una unidad, sin peligro de entrelazado si dos gorutinas terminan al
   mismo tiempo.

   @b(Ejercicio 1.10): Encontrar un sitio web que produce una gran cantidad de
   datos. Investiga el almacenamiento en cache mediante la ejecucion de
   @$(fetchall) dos veces consecutivas para ver si el tiempo reportado cambia
   mucho. ¿Obtienes el mismo contenido cada vez? Modificar @$(fetchall) para
   imprimir su salida a un archivo para que pueda ser examinado.

   @b(Ejercicio 1.11): Pruebe @$(fetchall) con listas de argumentos mas
   extensas, como muestras de los mejores sitios web disponibles en
   @l(http://www.alexa.com/<>alexa.com). ¿Como se comporta el programa si un
   sitio web simplemente no responde? (La @l(#Seccion 8.9) describe los
   mecanismos para hacer frente en estos casos.)

** Seccion 1.7 <> Un Servidor Web

   La libreria de Go hace que sea facil escribir un servidor web que responde a
   las solicitudes de los clientes, como las realizadas por @$(fetch). En esta
   seccion, mostraremos un servidor minimo que devuelve el componente de ruta de
   la URL utilizada para acceder al servidor. Es decir, si la solicitud es
   @c(http://localhost:8000/hello), la respuesta sera @c(URL.Path = "/hello").

   ..figure > @l(gopl.io/ch1/server1/main.go<>gopl.io/ch1/server1)

     ..src > go
       // Server1 es un servidor de "eco" minimo.
       package main

       import (
         "fmt"
         "log"
         "net/http"
       )

       func main() {
         http.HandleFunc("/", handler) // cada solicitud llama a handler
         log.Fatal(http.ListenAndServe("localhost:8000", nil))
       }

       // handler hace eco del componente Path de la URL solicitida.
       func handler(w http.ResponseWriter, r *http.Request) {
         fmt.Fprintf(w, "URL.Path = %q\n", r.URL.Path)
       }
     < src..


   El programa esta formado por solo un puñado de lineas, porque las funciones
   de la libreria hacen la mayor parte del trabajo. La funcion @c(main) conecta
   una funcion de manejo a las direcciones URL entrantes que comienzan con
   @c(/), que son todas las direcciones URL, e inicia un servidor que escucha
   las peticiones entrantes en el puerto 8000. La solicitud se representa como
   una estructura de tipo @c(http.Request), que contiene una serie de campos
   relacionados, uno de los cuales es la URL de la solicitud entrante. Cuando
   llega una peticion, se le da a la funcion de manejo, que extrae el componente
   de ruta (@c(/hello)) a partir de la URL de solicitud y la envia de vuelta
   como la respuesta, utilizando @c(fmt.Fprintf). Los servidores web se
   explicaran en detalle en la @l(#Seccion 7.7).

   Iniciemos el servidor en segundo plano. En Mac OS X o GNU/Linux, añadir un
   simbolo ampersand @%c(&) al comando; en Microsoft Windows, necesitara
   ejecutar el comando sin el signo ampersand en una ventana de comandos
   distinta.

   ..srci > sh
     > go run src/gopl.io/ch1/server1/main.go &
   < srci..

   A continuacion, podemos hacer solicitudes desde la linea de comandos:

   ..srci > sh
     > go build gopl.io/ch1/fetch
     > ./fetch http://localhost:8000
     URL.Path = "/"
     > ./fetch http://localhost:8000/help
     URL.Path = "/help"
   < srci..

   Como alternativa, podemos acceder al servidor desde un navegador web, como se
   muestra en la Figura 1.2.

   ..figure > Figura 1.2. Una respuesta del servidor de eco.

     ..img > img/Figure-1.2.jpg


   Es facil agregar funciones al servidor. Una adicion util es una URL
   especifica que devuelve un estado de algun tipo. Por ejemplo, esta version
   hace eco, pero tambien cuenta el numero de peticiones; una peticion a la URL
   @c(/count) devuelve el recuento hasta el momento, excluyendo las propias
   salicitudes de @c(/count):

   ..figure > @l(gopl.io/ch1/server2/main.go<>gopl.io/ch1/server2)

     ..src > go
       // Server2 es un servidor de eco y conteo minimo
       package main

       import (
         "fmt"
         "log"
         "net/http"
         "sync"
       )

       var mu sync.Mutex
       var count int

       func main() {
         http.HandleFunc("/", handler)
         http.HandleFunc("/count", counter)
         log.Fatal(http.ListenAndServe("localhost:8000", nil))
       }

       // handler hace eco del componente Path de la URL solicitida.
       func handler(w http.ResponseWriter, r *http.Request) {
         mu.Lock()
         count++
         mu.Unlock()
         fmt.Fprintf(w, "URL.Path = %q\n", r.URL.Path)
       }

       // counter hace eco del numero de lamadas hasta ahora.
       func counter(w http.ResponseWriter, r *http.Request) {
         mu.Lock()
         fmt.Fprintf(w, "Count %d\n", count)
         mu.Unlock()
       }
     < src..


   El servidor tiene dos manejadores, y la URL de la solicitud determina cual se
   llama: una solicitud de @c(/count) invoca a @c(counter) y todas los demas
   invocan a @c(handler). Un patron de manejo que termina con una barra diagonal
   coincide con cualquier URL que tenga el patron como prefijo. Detras de
   escena, el servidor ejecuta el controlador para cada solicitud entrante en
   una gorutina separada para que pueda servir multiples solicitudes
   simultaneamente. Sin embargo, si dos solicitudes simultaneas intentan
   actualizar @c(count) al mismo tiempo, es posible que no se incremente
   consistentemente; el programa tendria un error grave llamado @e(condicion de
   carrera) @%l(#Seccion 9.1<>§9.1). Para evitar este problema, debemos
   asegurarnos de que a lo sumo solo una gorutina accede a la variable a la vez,
   que es el proposito de las llamadas a @c[mu.Lock()] y @c[mu.Unlock()] que
   rodean el acceso a @c(count). Examinaremos mas de cerca a la concurrencia con
   variables compartidas en el @l(#Capitulo 9).

   Como un ejemplo mas rico, la funcion de manejo puede informar sobre los
   encabezados y datos de formulario que recibe, haciendo que el servidor sea
   util para inspeccionar y depurar las peticiones:

   ..figure > @l(gopl.io/ch1/server3/main.go<>gopl.io/ch1/server3)

     ..src > go
       // handler responde a la peticion HTTP.
       func handler(w http.ResponseWriter, r *http.Request) {
         fmt.Fprintf(w, "%s %s %s\n", r.Method, r.URL, r.Proto)
         for k, v := range r.Header {
           fmt.Fprintf(w, "Header[%q] = %q\n", k, v)
         }
         fmt.Fprintf(w, "Host = %q\n", r.Host)
         fmt.Fprintf(w, "RemoteAddr = %q\n", r.RemoteAddr)
         if err := r.ParseForm(); err != nil {
           log.Print(err)
         }
         for k, v := range r.Form {
           fmt.Fprintf(w, "Form[%q] = %q\n", k, v)
         }
       }
     < src..


   Este utiliza los campos de la estructura @c(http.Request) para producir una
   salida como esta:

   ..pre >
     GET /?q=query HTTP/1.1
     Header["Accept-Encoding"] = ["gzip, deflate, sdch"]
     Header["Accept-Language"] = ["en-US,en;q=0.8"]
     Header["Connection"] = ["keep-alive"]
     Header["Accept"] = ["text/html,application/xhtml+xml,application/xml;..."]
     Header["User-Agent"] = ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)..."]
     Host = "localhost:8000"
     RemoteAddr = "127.0.0.1:59911"
     Form["q"] = ["query"]
   < pre..

   Observe como la llamada a @c(ParseForm) esta anidada dentro de una sentencia
   @c(if). Go permite una declaracion simple, como una declaracion de variable
   local para preceder la sentencia @c(if), lo que es particularmente util para
   el tratamiento de errores como en este ejemplo. Podriamos haberlo escrito
   como

   ..src > go
     err := r.ParseForm()
     if err != nil {
       log.Print(err)
     }
   < src..

   pero la combinacion de las sentencias es mas corta y reduce el alcance de la
   variable @c(err), lo cual es una buena practica. Vamos a definir el alcance en la
   @l(#Seccion 2.7).

   En estos programas, hemos visto tres tipos muy diferentes utilizados como
   flujos de salida. El programa @$(fetch) copio los datos de la respuesta HTTP
   a @c(os.Stdout), un archivo, al igual que el programa @$(lissajous). El
   programa @$(fetchall) arroja la respuesta copiando el flujo (mientras cuenta
   su longitud) de forma trivial en @c(ioutil.Discard). Y el anterior servidor
   web utiliza @c(fmt.Fprintf) para escribir a @c(http.ResponseWriter) que
   representa el navegador web.

   Aunque estos tres tipos difieren en los detalles de lo que hacen, todos ellos
   satisfacen una interfaz comun, permitiendo que cualquiera de ellos se utilice
   cuando se necesite un flujo de salida. Esa interfaz, llamada @c(io.Writer),
   se discute en la @l(#Seccion 7.1).

   El mecanismo de la interfaz de Go es el tema del @l(#Capitulo 7), pero para dar
   una idea de lo que es capaz de hacer, vamos a ver lo facil que es combinar el
   servidor web con la funcion @c(lissajous) para que los archivos GIF animados
   se escriban no en la salida estandar, sino en el cliente HTTP. Solo hay que
   añadir estas lineas al servidor web:

   ..src > go
     handler := func(w http.ResponseWriter, r *http.Request) {
       lissajous(w)
     }
     http.HandleFunc("/", handler)
   < src..

   o su equivalente:

   ..src > go
     http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
       lissajous(w)
     })
   < src..

   El segundo argumento de la funcion @c(HandleFunc) se conoce como una
   @e(funcion literal), es decir, una funcion anonima definida en su punto de
   uso. Lo explicaremos con mas detalle en la @l(#Seccion 5.6).

   Una vez que haya realizado este cambio, visite @l(http://localhost:8000) en su
   navegador. Cada vez que cargue la pagina, vera una nueva animacion como la de
   la Figura 1.3.

   @b(Ejercicio 1.12): Modificar el servidor de Lissajous para leer valores de
   los parametros de la URL. Por ejemplo, es posible disponer de forma que una
   URL como @c(http://localhost:8000/?cycles=20) establezca el numero de ciclos a
   20 en lugar del predeterminado 5. Utilice la funcion @c(strconv.Atoi) para
   convertir el parametro de una cadena a un entero. Puede ver su documentacion
   con @$(go doc strconv.Atoi).

   ..figure > Figura 1.3. Figuras animadas de Lissajous en un navegador.

     ..img > img/Figure-1.3.jpg

** Seccion 1.8 <> Cabos sueltos

   Hay mucho mas en Go de lo que hemos cubierto en esta introduccion rapida.
   Aqui hay algunos temas que apenas hemos tocado u omitido por completo, con
   tratamiento suficiente para empezar a familiarizarse con ellos antes del
   tratamiento completo.

   - Control de Flujo :: Cubrimos los dos estados de control de flujo
     fundamentales, @c(if) y @c(for), pero no la sentencia @c(switch), que es
     una via de multiples ramas. Aqui hay un pequeño ejemplo:

     ..src > go
       switch lanzarmoneda() {
       case "cara":
         caras++
       case "cruz":
         cruces++
       default:
         fmt.Println("aterrizo de borde!")
       }
     < src..

     El resultado de llamar a @c(lanzarmoneda) se compara con el valor de cada
     caso. Los casos se evaluan de arriba a abajo, por lo que se ejecuta la
     primera coincidencia. El caso opcional @c(default) coincide si ninguno de
     los otros casos lo hace; puede colocarse en cualquier lugar. Los casos no
     caen uno sobre otro, como en lenguajes tipo C (aunque hay una declaracion
     @c(fallthrough) raramente utilizada que anula este comportamiento).

     Un @c(switch) no necesita un operando; solo puede enumerar los casos, cada
     uno de los cuales es una expresion booleana:

     ..src > go
       func Signum(x int) int {
         switch {
         case x > 0:
           return +1
         default:
           return 0
         case x < 0:
           return -1
         }
       }
     < src..

     Esta forma se llama @e(switch sin etiquetas); que es equivalente a
     @c(switch true).

     Al igual que las sentencias @c(for) e @c(if), un @c(switch) puede incluir
     una declaracion simple opcional–una declaracion de variables compacta, una
     declaracion de incremento o asignacion, o una funcion de llamada–que se
     puede utilizar para establecer un valor antes de ser puesto a prueba.

     Las declaraciones @c(break) y @c(continue) modifican el flujo de control.
     Un @c(break) hace que el control se reanude en la siguiente sentencia despues
     de la secuenca @c(for), @c(switch), o @c(select) (que veremos mas adelante)
     mas anidada, y como hemos visto en la @l(#Seccion 1.3), un @c(continue)
     proboca que el bucle @c(for) mas interno inicie su siguiente iteracion. Las
     declaraciones pueden etiquetarse de forma que un @c(break) y @c(continue)
     pueden referirse a ellos, por ejemplo, para salir de varios bucles anidados
     a la vez o para iniciar la siguiente iteracion del bucle mas externo. Hay
     incluso una sentencia @c(goto), aunque esta destinada para el codigo
     generado por la maquina, no para el uso regular por los programadores.

   - Tipos con nombre :: Una declaracion @c(type) permite dar un
     nombre a un tipo existente. Puesto que los tipos de estructura suelen
     ser extensos, se nombran casi siempre. Un ejemplo conocido es la
     definicion de un tipo @c(Point) para un sistema grafico 2-D:

     ..src > go
       type Point struct {
         X, Y int
       }
       var p Point
     < src..

     Las declaracion de tipos y tipos con nombre se trata en el @l(#Capitulo 2).

   - Punteros :: Go proporciona punteros, es decir, los valores que contienen
     la direccion de una variable. En algunos lenguajes, notablemente C, los
     punteros carecen relativamente de restricciones. En otros lenguajes, los
     punteros se disfrazan como @"(referencias), y no hay mucho que se pueda
     hacer con ellos, excepto pasarlos a alrededor. Go toma una posicion en
     algun lugar en el medio. Los punteros son explicitamente visibles. El operador
     @c(&) obtiene la direccion de una variable, y el operador @c(*) recupera la
     variable a la que se refiere el puntero, pero no hay aritmetica de
     punteros. Explicaremos los punteros en la @l(#Seccion 2.3.2).

   - Metodos e interfaces :: Un metodo es una funcion asociada a un tipo de
     dato; Go es inusual en el sentido que los metodos se pueden vincular a casi
     cualquier tipo con nombre. Los metodos son cubiertos en el @l(#Capitulo
     6). Las interfaces son tipos abstractos que nos permiten tratar de la misma
     manera a diferentes tipos concretos en base a los metodos que tienen, no a
     como se representan o implementan. Las interfaces son el tema del
     @l(#Capitulo 7).

   - Paquetes :: Go viene con una extensa libreria estandar de paquetes utiles,
     y la comunidad Go ha creado y compartido muchas mas. La programacion es a
     menudo mas sobre el uso de paquetes existentes que sobre la escritura de
     codigo original propio. A lo largo del libro, vamos a señalar un par de
     docenas de los paquetes estandar mas importantes, pero hay muchos mas que
     no tenemos espacio de mencionarlos, y no podemos proporcionar nada
     remotamente cercano a una referencia completa para cualquier paquete.

     Antes de embarcarse en cualquier programa nuevo, es una buena idea ver si
     ya existen paquetes que podrian ayudar a hacer el trabajo mas facilmente.
     Puedes encontrar un indice de paquetes de la libreria estandar en
     @l(https://golang.org/pkg) y los paquetes aportados por la comunidad en
     @l(https://godoc.org). La herramienta @$(go doc) hace que estos documentos
     sean facilmente accesibles desde la linea de comandos:

     ..srci > sh
       > go doc http.ListenAndServe
       package http // import "net/http"

       func ListenAndServe(addr string, handler Handler) error
           ListenAndServe listens on the TCP network address addr and then
           calls Serve with handler to handle requests on incoming connections.
       ...
     < srci..

   - Comentarios :: Ya hemos mencionado los comentarios de documentacion al
     inicio de un programa o paquete. Tambien es un buen estilo escribir un
     comentario antes de la declaracion de cada funcion para especificar su
     comportamiento. Estas convenciones son importantes, ya que se utilizan por
     herramientas como @$(go doc) y @$(godoc) para localizar y monstrar la
     documentacion en pantalla @%l(#Seccion 10.7.4<>§10.7.4).

     Para los comentarios que abarcan varias lineas o aparecen dentro de una
     expresion o declaracion, tambien existe la conocida notacion @c(/* ... */)
     de otros lenguajes. Este tipo de comentarios se utilizan a veces al
     principio de un archivo en un gran bloque de texto explicativo para evitar
     un @c(//) en cada linea. Dentro de un comentario, @c(//) y @c(/*) no tienen
     ningun significado especial, por que los comentarios no se anidan.

* Capitulo 2 <> Estructura del Programa

  En Go, como en cualquier otro lenguaje de programacion, se construyen grandes
  programas a partir de un pequeño conjunto de construcciones basicas. Las
  variables almacenan los valores. Las expresiones simples se combinan en otras
  mas grandes con operaciones como la suma y la resta. Los tipos basicos se reunen en
  agregados como arreglos y estructuras. Las expresiones se utilizan en
  declaraciones cuyo orden de ejecucion es determinado por instrucciones de
  control de flujo como @c(if) y @c(for). Las declaraciones se agrupan en
  funciones para su aislamiento y reutilizacion. Las funciones se agrupan en
  archivos de codigo fuente y paquetes.

  Vimos ejemplos de la mayoria de estos en el capitulo anterior. En este
  capitulo, vamos a entrar en mas detalles sobre los elementos estructurales
  basicos de un programa Go. Los programas de ejemplo son intencionalmente
  simples, por lo que podemos centrarnos en el lenguaje sin desviarnos por
  complicados algoritmos o estructuras de datos.

** Seccion 2.1 <> Nombres

   En Go los nombres de las funciones, variables, constantes, tipos, etiquetas de
   instrucciones y paquetes siguen una regla simple: un nombre comienza con una
   letra (es decir, cualquier cosa que Unicode considera una letra) o un guion
   bajo y puede tener cualquier numero de letras adicionales, digitos y giones
   bajos. Las mayusculas importan: @c(heapSort) y @c(Heapsort) son nombres
   diferentes.

   Go tiene 25 @e(palabras claves) como @c(if) y @c(switch) que solo pueden
   utilizarse cuando la sintaxis lo permita; no pueden usarse como nombres.

   ..pre >
     break      default       func     interface   select
     case       defer         go       map         struct
     chan       else          goto     package     switch
     const      fallthrough   if       range       type
     continue   for           import   return      var
   < pre..

   Ademas, hay cerca de tres docenas de nombres @e(predeclarados) como @c(int) y
   @c(true) para las constantes, tipos y funciones nativas:

   - Constantes ::

     ..pre >
       true    false    iota    nil

   - Tipos ::

     ..pre >
       int         int8       int16      int32    int64
       uint       uint8      uint16     uint32   uint64   uintptr
       float32  float64  complex128  complex64
       bool        byte        rune     string    error

   - Funciones ::

     ..pre >
       make       len   cap   new   append   copy   close   delete
       complex   real  imag
       panic  recover


   Estos nombres no estan reservados, por lo que puede utilizarlos en
   declaraciones. Vamos a ver un puñado de lugares donde redeclarar uno de
   ellos tiene sentido, pero tenga cuidado con la potencial confusion.

   Si se declara una entidad dentro de una funcion, esta es @e(local) a esa
   funcion. Si se declara fuera de una funcion, sin embargo, es visible en todos
   los archivos del paquete al que pertenece. La primer letra de un nombre
   determina su visibilidad a traves de los limites del paquete. Si el nombre
   comienza con una letra mayuscula, se exporta, lo que significa que es visible
   y accesible fuera de su propio paquete y puede hacer referencia a otras
   partes del programa, al igual que con @c(Printf) en el paquete @c(fmt). Los
   nombres de los paquetes estan siempre en minusculas.

   No hay limite en la longitud del nombre, pero la convencion y el estilo en
   los programas de Go se inclinan hacia nombres cortos, especialmente para
   variables locales con ambitos pequeños; es mucho mas probable ver variables
   con nombre @c(i) que @c(indiceDelBucle). Generalmente, cuanto mayor es el
   alcance de un nombre, mas largo y mas significativo debe ser.

   Estilisticamente, los programadores Go utilizan la @"(notacion camello)
   cuando se forman nombres mediante la combinacion de palabras; es decir, las
   letras mayusculas internas se prefieren sobre los subrayados interiores. Por
   lo tanto las librerias estandar tienen funciones con nombres como
   @c(QuoteRuneToASCII) y @c(parseRequestLine) pero nunca @c(quote_rune_to_ASCII)
   o @c(parse_request_line). Las letras de acronimos y siglas como @A(ASCII) y
   @A(HTML) siempre se prestan en el mismo tipo, por lo que una funcion sera
   llamada @c(htmlEscape), @c(HTMLEscape) o @c(escapeHTML), pero no
   @c(escapeHtml).

** Seccion 2.2 <> Declaraciones

   Una @e(declaracion) nombra una entidad del programa y especifica algunas o
   todas sus propiedades. Hay cuatro tipos principales de declaraciones:
   @c(var), @c(const), @c(type) y @c(func). Hablaremos sobre variables y tipos
   en este capitulo, constantes en el @l(#Capitulo 3), y funciones en el
   @l(#Capitulo 5).

   Un programa Go se almacena en uno o mas archivos cuyos nombres terminan en
   @f(.go). Cada archivo comienza con una declaracion @c(package) que indica de
   que paquete forma parte el archivo. La declaracion @c(package) es seguida por
   cualquier numero de declaraciones @c(import), y luego una secuencia de
   declaraciones a nivel de paquete, como tipos, variables, constantes y funciones,
   en cualquier orden. Por ejemplo, este programa declara una constante, una
   funcion y un par de variables:

   ..figure > @l(gopl.io/ch2/boiling/main.go<>gopl.io/ch2/boiling)

     ..src > go
       // Boiling imprime el punto de ebullicion del agua.
       package main

       import "fmt"

       const boilingF = 212.0

       func main() {
         var f = boilingF
         var c = (f - 32) * 5 / 9
         fmt.Printf("punto de ebullicion = %g°F o %g°C\n", f, c)
         // Salida:
         // punto de ebullicion = 212°F o 100°C
       }
     < src..


   La constante @c(boilingF) es una declaracion de nivel de paquete (como lo es
   @c(main)), mientras que las variables @c(f) y @c(c) son locales a la funcion
   @c(main). El nombre de cada entidad de nivel de paquete es visible no solo en
   todo el archivo de origen que contiene su declaracion, sino en todos los
   archivos del paquete. Por el contrario, las declaraciones locales son
   visibles solo dentro de la funcion en la que se declaran y tal vez solo
   dentro de una pequeña parte de ella.

   Una declaracion de funcion tiene un nombre, una lista de parametros (las
   variables cuyos valores se proporcionan por quien llama a la funcion), una
   lista opcional de resultados y el cuerpo de la funcion, que contiene las
   sentencias que definen lo que hace la funcion. La lista de resultados se
   omite si la funcion no devuelve nada. La ejecucion de la funcion comienza con
   la primer instruccion y continua hasta que encuentra una instruccion de
   retorno o llega al final de una funcion que no tiene resultados. El control y
   los resultados se devuelven a quien hiso la llamada.

   Hemos visto un buen numero de funciones ya y hay muchas mas por venir,
   incluyendo un extenso tratamiento en el @l(#Capitulo 5), asi que esto es
   solo un esbozo. La funcion @c(fToC) a continuacion, encapsula la logica de
   conversion de temperatura de manera que se define solo una vez, pero puede
   utilizarse desde multiples lugares. Aqui @c(main) la llama dos veces,
   utilizando los valores de dos constantes locales diferentes:

   ..figure > @l(gopl.io/ch2/ftoc/main.go<>gopl.io/ch2/ftoc)

     ..src > go
       // Ftoc imprime dos conversiones de Fahrenheit a Celsius.
       package main

       import "fmt"

       func main() {
         const freezingF, boilingF = 32.0, 212.0
         fmt.Printf("%g°F = %g°C\n", freezingF, fToC(freezingF)) // "32°F = 0°C"
         fmt.Printf("%g°F = %g°C\n", boilingF, fToC(boilingF))   // "212°F = 100°C"
       }

       func fToC(f float64) float64 {
         return (f - 32) * 5 / 9
       }
     < src..

** Seccion 2.3 <> Variables

   Un declaracion @c(var) crea una variable de un tipo particular, le da un
   nombre y establece su valor inicial. Cada declaracion tiene la forma general

   ..src > go
     var nombre tipo = expresion
   < src..

   Puede omitirse el tipo o la parte @c(= expresion), pero no ambas. Si
   se omite el tipo, se determina por la expresion inicializadora. Si se
   omite la expresion, el valor inicial es el @e(valor cero) para el tipo, que
   es @c(0) para los numeros, @c(false) para booleanos, @c("") para string, y
   @c(nil) para interfaces y tipos de referencia (slice, puntero, mapa, canal,
   funcion). El valor cero de un tipo agregado como una matriz o una estructura
   tiene el valor cero de todos sus elementos o campos.

   El mecanismo de valor cero asegura que una variable siempre tenga un valor
   bien definido de su tipo; en Go no hay tal cosa como una variable no
   inicializada. Esto simplifica el codigo y, a menudo, asegura un
   comportamiento sensato de las condiciones limite sin trabajo extra. Por
   ejemplo,

   ..src > go
     var s string
     fmt.Println(s) // ""
   < src..

   Imprime una cadena vacia, en lugar de causar algun tipo de error o
   comportamiento impredecible. Los programadores de Go, a menudo se esfuerzan
   por hacer que el valor cero de un tipo mas complicado tenga sentido, por lo
   que las variables comienzan su vida en un estado util.

   Es posible declarar e inicializar opcionalmente un conjunto de variables en
   una sola declaracion, con una lista de expresiones correspondiente. Omitir el
   tipo permite la declaracion de multiples variables de diferentes tipos:

   ..src > go
     var i, j, k int                 // int, int, int
     var b, f, s = true, 2.3, "four" // bool, float64, string
   < src..

   Los inicializadores pueden ser valores literales o expresiones arbitrarias.
   Las variables a nivel de paquete se inicializan antes del inicio de @c(main)
   @%l(#Seccion 2.6.2<>§2.6.2), y las variables locales se inicializan a medida
   que se encuentran sus declaraciones durante la ejecucion de la funcion.

   Tambien se puede inicializar un conjunto de variables llamando a una funcion
   que devuelve valores multiples:

   ..src > go
     var f, err = os.Open(name) // os.Open devuelve un fichero y un error
   < src..

*** Seccion 2.3.1 <> Declaracion de Variables Compacta

    Dentro de una funcion, se puede utilizar una forma alternativa llamada
    @e(declaracion de variables compacta) para declarar e inicializar variables
    locales. Toma la forma @c(nombre := expresion), y el tipo de @c(nombre) esta
    determinada por el tipo de @c(expresion). Aqui estan tres de las muchas
    declaraciones de variables compacta en la funcion @c(lissajous) @%l(#Seccion
    1.4<>§1.4):

    ..src > go
      anim := gif.GIF{LoopCount: nframes}
      freq := rand.Float64() * 3.0
      t := 0.0
    < src..

    Debido a su brevedad y flexibilidad, la declaracion de variables compacta se
    utiliza para declarar e inicializar la mayoria de las variables locales. Una
    sentencia @c(var) tiende a reservarse para las variables locales que
    necesitan un tipo explicito que difiere del de la expresion inicializadora,
    o para cuando a la variable se le asignara un valor mas adelante y su valor
    inicial no es importante.

    ..src > go
      i := 100                  // un int
      var boiling float64 = 100 // un float64

      var names []string
      var err error
      var p Point
    < src..

    Como con las sentencias @c(var), pueden declararse y ser inicializadas
    multiples variables en la misma declaracion compacta,

    ..src > go
      i, j := 0, 1
    < src..

    pero las declaraciones con multiples expresiones de inicializacion deben
    utilizarse solo cuando ayudan a la legibilidad, como en el caso de agrupaciones
    cortas y naturales, como la parte de inicializacion de un bucle @c(for).

    Tenga en cuenta que @c(:=) es una declaracion, mientras que @c(=) es una
    asignacion. Una declaracion de multiples variables no debe confundirse con
    una asignacion de tuplas @%l(#Seccion 2.4.1<>§2.4.1), en la que a cada
    variable del lado izquierdo se le asigna el valor correspondiente del lado
    derecho:

    ..src > go
      i, j = j, i // intercambiar valores de i y j
    < src..

    Al igual que las declaraciones @c(var) ordinarias, la declaracion de
    variables compacta se puede utilizar para las llamadas a funciones como
    @c(os.Open) que devuelven dos o mas valores:

    ..src > go
      f, err := os.Open(name)
      if err != nil {
        return err
      }
      // ...usar f...
      f.Close()
    < src..

    Un punto sutil pero importante: una declaracion de variables compacta no
    declara necesariamente todas las variables en su lado izquierdo. Si algunas
    de ellas ya fueron declaradas en el @e(mismo) bloque lexico @%l(#Seccion
    2.7<>§2.7), entonces, la declaracion de variables compacta se comporta como
    una asignacion a esas variables.

    En el codigo siguiente, la primera sentencia declara tanto @c(in) como
    @c(err). El segundo declara @c(out) pero solo asigna un valor a la variable
    @c(err) existente.

    ..src > go
      in, err := os.Open(infile)
      // ...
      out, err := os.Create(outfile)
    < src..

    Sin embargo, una declaracion de variables compacta debe declarar al menos una
    variable nueva, por lo que este codigo no compilara:

    ..src > go
      f, err := os.Open(infile)
      // ...
      f, err := os.Create(outfile) // error de compilacion: no hay nuevas variables
    < src..


    La correccion consiste en utilizar una asignacion ordinaria para la segunda
    instruccion.

    Una declaracion de variable compacta actua como una asignacion solo a
    variables que ya estaban declaradas en el mismo bloque lexico; las
    declaraciones en un bloque externo se ignoran. Veremos ejemplos de esto al
    final del capitulo.

*** Seccion 2.3.2 <> Punteros

    Una variable es una pieza de almacenamiento que contiene un valor. Las
    variables creadas por declaraciones se identifican por un nombre, como
    @c(x), pero muchas variables se idientifican solo por expresiones como
    @c(x[i]) o @c(x.f). Todas estas expresiones leen el valor de una variable,
    excepto cuando aparecen en el lado izquierdo de una asignacion, en cuyo caso
    se asigna un nuevo valor a la variable.

    El valor de un @e(puntero) es la @e(direccion) de una variable. Un puntero
    es, por tanto, la ubicacion en la que se almacena un valor. No todos los
    valores tienen una direccion, pero todas las variables si. Con un puntero,
    podemos leer o actualizar el valor de una variable @e(indirectamente), sin
    utilizar o incluso saber el nombre de la variable, si es que tiene un
    nombre.

    Si se declara una variable @c(var x int), la expresion @c(&x) @%"(direccion
    de @c(x)) produce un puntero a una variable de tipo entero, es decir, un
    valor de tipo @c(*int), que se pronuncia @"(puntero a int.) Si este valor se
    llama @c(p), decimos @"(@c(p) apunta a @c(x),) o equivalentemente @"(@c(p)
    contiene la direccion de @c(x).) La variable a la que @c(p) apunta se
    escribe @c(*p). La expresion @c(*p) produce el valor de dicha variable, un
    @c(int), pero ya que @c(*p) indica una variable, tambien puede aparecer en la
    parte izquierda de una asignacion, en cuyo caso la asignacion actualiza la
    variable.

    ..src > go
      x := 1
      p := &x         // p, de tipo *int, apunta a x
      fmt.Println(*p) // "1"
      *p = 2          // equivalente a x = 2
      fmt.Println(x)  // "2"
    < src..

    Cada componente de una variable de tipo agregado–un campo de una estructura
    o un elemento de una arreglo–es tambien una variable y por lo tanto tiene tambien
    una direccion.

    Las variables se describen a veces como valores @e(direccionables).
    Las expresiones que denotan variables son las unicas expresiones a las que se
    puede aplicar el operador de direccion @c(&).

    El valor cero de un puntero de cualquier tipo es @c(nil). La prueba de @c(p
    != nil) es verdadera si @c(p) apunta a una variable. Los punteros son
    comparables; dos punteros son iguales si y solo si apuntan a la misma
    variable o ambos son @c(nil).

    ..src > go
      var x, y int
      fmt.Println(&x == &x, &x == &y, &x == nil) // "true false false"
    < src..

    Es perfectamente seguro que una funcion devuelva la direccion de una
    variable local. Por ejemplo, en el codigo siguiente, la variable local @c(v)
    creada por la llamada a @c(f) seguira existiendo incluso despues de devolver
    la llamada, y el puntero @c(p) todavia se referira a ella:

    ..src > go
      var p = f()

      func f() *int {
        v := 1
        return &v
      }
    < src..

    Cada llamada a @c(f) devuelve un valor distinto:

    ..src > go
      fmt.Println(f() == f()) // "false"
    < src..

    Debido a que un puntero contiene la direccion de una variable, pasar un
    argumento de puntero a una funcion hace posible que la funcion actualice la
    variable que se paso indirectamente. Por ejemplo, esta funcion incrementa la
    variable a la que apunta su argumento y devuelve el nuevo valor de la
    variable para que pueda ser utilizada en una expresion:

    ..src > go
      func incr(p *int) int {
        *p++ // incrementa a lo que apunta p; no cambia p
        return *p
      }

      v := 1
      incr(&v)              // efecto secundario: ahora v es 2
      fmt.Println(incr(&v)) // "3" (y v es 3)
    < src..

    Cada vez que se toma la direccion de una variable o copiamos un puntero,
    creamos nuevos @e(alias) o formas de identificar a la misma variable. Por
    ejemplo, @c(*p) es un alias para @c(v). Los punteros como alias son utiles
    porque nos permite acceder a una variable sin usar su nombre, pero esto es
    una espada de doble filo: para encontrar todas las sentencias que acceden a
    una variable, tenemos que conocer todos sus alias. No son solo los punteros
    los que crean alias; los alias tambien se crean cuando copiamos valores de otros
    tipos de referencia como slices, mapas y canales, e incluso estructuras,
    arreglos e interfaces que contienen estos tipos.

    Los punteros son clave para el paquete @c(flag), que utiliza los argumentos
    de linea de comandos de un programa para establecer los valores de ciertas
    variables distribuidas a lo largo del programa. Para ilustrarlo, esta
    variacion del anterior comando @$(echo) toma dos indicadores opcionales:
    @c(-n) hace que @$(echo) omita el salto de linea final que normalmente se
    imprime, y @c(-s sep) hace que se separe los argumentos de salida por el
    contenido de la cadena @c(sep) en lugar del espacio unico por defecto.
    Como esta es nuestra cuarta version, el paquete se llama @f(gopl.io/ch2/echo4).

    ..figure > @l(gopl.io/ch2/echo4/main.go<>gopl.io/ch2/echo4)

      ..src > go
        // Echo4 imprime sus argumentos de linea de comandos.
        package main

        import (
          "flag"
          "fmt"
          "strings"
        )

        var n = flag.Bool("n", false, "omitir linea nueva de salida")
        var sep = flag.String("s", " ", "separador")

        func main() {
          flag.Parse()
          fmt.Print(strings.Join(flag.Args(), *sep))
          if !*n {
            fmt.Println()
          }
        }
      < src..


    La funcion @c(flag.Bool) crea una nueva variable bandera de tipo @c(bool).
    Toma tres argumentos: el nombre de la bandera @%c("n"), el valor por
    defecto de la variable @%c(false), y un mensaje que se imprimira si el
    usuario proporciona un argumento invalido, una bandera invalida, o @c(-h) o
    @c(-help). Del mismo modo, @c(flag.String) toma un nombre, un valor por
    defecto, y un mensaje, y crea una variable @c(string). Las variables @c(sep)
    y @c(n) son punteros a las variables de la bandera, que deben accederse
    indirectamente como @c(*sep) y @c(*n).

    Cuando se ejecuta el programa, debe llamar a @c(flag.Parse) antes de
    utilizar las banderas, para actualizar las variables bandera de sus valores
    por defecto. Los argumentos que no sean banderas estan disponibles mediante
    @c[flag.Args()] como un slice de strings. Si @c(flag.Parse) encuentra un
    error, se imprime un mensaje sobre el uso y llama a @c[os.Exit(2)] para terminar
    el programa.

    Hagamos algunas pruebas a @$(echo):

    ..srci > sh
      > go build gopl.io/ch2/echo4
      > ./echo4 a bc def
      a bc def
      > ./echo4 -s / a bc def
      a/bc/def
      > ./echo4 -n a bc def
      a bc def$
      > ./echo4 -help
      Usage of ./echo4:
        -n    omit trailing newline
        -s string
              separator (default " ")
    < srci..

*** Seccion 2.3.3 <> La Funcion @c(new)

    Otra forma de crear una variable es utilizar la funcion nativa @c(new). La
    expresion @c[new(T)] crea una @e(variable sin nombre) del tipo @c(T), la
    inicializa al valor cero de @c(T), y devuelve su direccion, que es un valor
    de tipo @c(*T).

    ..src > go
      p := new(int)   //  p, de tipo *int, apunta a una varible int sin nombre
      fmt.Println(*p) //  "0"
      *p = 2          //  establece el int sin nombre a 2
      fmt.Println(*p) //  "2"
    < src..

    Una variable creada con @c(new) no es diferente a tomar la direccion de una
    variable local, excepto que no hay necesidad de inventar (y declarar) un
    nombre ficticio, y podemos usar @c[new(T)] en una expresion. De este modo
    @c(new) es solo una conveniencia sintactica, no una nocion fundamental:

    las dos funciones @c(newInt) a continuacion tienen comportamientos
    identicos.

    ..cols >

      ..src > go
        func newInt() *int {
          return new(int)
        }
      < src..

    <>

      ..src > go
        func newInt() *int {
          var dummy int
          return &dummy
        }
      < src..

    Cada llamada a @c(new) devuelve una variable distinta con una direccion
    unica:

    ..src > go
      p := new(int)
      q := new(int)
      fmt.Println(p == q) // "false"
    < src..

    Hay una excepcion a esta regla: dos variables cuyo tipo no lleva ninguna
    informacion y por lo tanto es de tamaño cero, como @c(struct{}) o
    @c([0]int), puede, dependiendo de la aplicacion, tener la misma direccion.

    La funcion @c(new) se utiliza relativamente poco porque las variables
    sin nombre mas comunes son de tipo estructura, para las cuales la sintaxis
    literal @c(struct) @%l(#Seccion 4.4.1<>§4.4.1) es mas flexible.

    Dado que @c(new) es una funcion nativa, no una palabra clave, es posible
    redefinir el nombre para algo distinto dentro de una funcion, por ejemplo:

    ..src > go
      func delta(old, new int) int { return new - old }
    < src..

    Por supuesto, dentro de @c(delta), la funcion nativa @c(new) no esta
    disponible.

*** Seccion 2.3.4 <> Vida Util de las Variables

    La @e(vida util) de una variable es el intervalo de tiempo durante el cual
    existe a medida que el programa se ejecuta. La duracion de una variable a
    nivel de paquete, es la ejecucion completa del programa. Por el contrario,
    las variables locales tienen una vida util dinamica: una nueva instancia se
    crea cada vez que se ejecuta la instruccion de declaracion, y la variable
    vive hasta que se vuelve @e(inaccesible), momento en el que su
    almacenamiento se puede reciclar. Los parametros de funcion y los resultados
    tambien son variables locales; se crean cada vez que se llama a la funcion
    que las encierra.

    Por ejemplo, en este extracto del programa Lissajous de la @l(#Seccion 1.4),

    ..src > go
      for t := 0.0; t < cycles*2*math.Pi; t += res {
        x := math.Sin(t)
        y := math.Sin(t*freq + phase)
        img.SetColorIndex(size+int(x*size+0.5), size+int(y*size+0.5),
          blackIndex)
      }
    < src..

    la variable @c(t) se crea cada vez que comienza el bucle @c(for), y nuevas
    variables @c(x) y @c(y) se crean en cada iteracion del bucle.

    ¿Como sabe el recolector de basura que el almacenamiento de una variable
    puede ser recuperado? La historia completa es mucho mas detallada de lo que
    necesitamos aqui, pero la idea basica es que cada variable a nivel de
    paquete, y cada variable local de cada funcion actualmente activa, puede ser
    el inicio o la raiz de una ruta a la variable en cuestion, sugiendo punteros
    y otros tipos de referencias que finalmente conducen a la variable. Si no
    existe tal ruta, la variable se ha vuelto inaccesible, por lo que ya no
    puede afectar al resto del calculo.

    Dado que el tiempo de vida de una variable se determina por si es o no
    accesible, una variable local puede sobrevivir a una sola iteracion del
    bucle que la rodea. Tambien puede seguir existiendo incluso despues de que
    la funcion que la rodea haya regresado.

    Un compilador puede elegir asignar las variables locales en el monticulo o
    en la pila, pero, tal vez sorprendentemente, esta eleccion no depende de si
    se utiliza @c(var) o @c(new) para declarar la variable.

    ..cols >

      ..src > go
        var global *int

        func f() {
          var x int
          x = 1
          global = &x
        }
      < src..

    <>

      ..src > go
        func g() {
          y := new(int)
          *y = 1
        }
      < src..

    Aqui, @c(x) debe ser asignado al monticulo porque todavia es accesible desde
    la variable @c(global) despues de haber devuelto @c(f), a pesar de ser
    declarado como una variable local; decimos que @c(x) escapa de @c(f). Por el
    contrario, cuando @c(g) regresa la variable @c(*y) se vuelve inaccesible y
    se pueden reciclar. Dado que @c(*y) no escapa de @c(g), es seguro para el
    compilador asignar @c(*y) en la pila, a pesar de que se asigno con @c(new).
    En cualquier caso, la nocion de escapar no es algo de lo que tengas que
    preocuparte para escribir codigo correcto, aunque es bueno tenerlo en cuenta
    durante la optimizacion del rendimiento, ya que cada variable que escapa
    requiere una asignacion de memoria adicional.

    El recolector de basura es una tremenda ayuda para escribir programas
    correctos, pero no elimina la carga de pensar en la memoria. No es necesario
    asignar y liberar memoria de forma explicita, pero para escribir programas
    eficientes es necesario tener en cuenta la duracion de las variables. Por
    ejemplo, mantener punteros innecesarios a objetos de corta duracion dentro
    de objetos de larga vida, especialmente variables globales, evitara que el
    recolector de basura recupere los objetos de corta duracion.

** Seccion 2.4 <> Asignaciones

   El valor que posee una variable se actualiza mediante una instruccion de
   asignacion, que en su forma mas simple tiene una variable a la izquierda del
   signo @c(=) y una expresion a la derecha.

   ..src > go
     x = 1                       // variable con nombre
     *p = true                   // variable indirecta
     person.name = "bob"         // campo de estructura
     count[x] = count[x] * scale // elemento de arreglo, slice o mapa
   < src..

   Cada uno de los operadores aritmeticos y operadores binarios a nivel de bits
   tiene su correspondiente @e(operador de asignacion) permitiendo, por ejemplo,
   reescribir la ultima instruccion como

   ..src > go
     count[x] *= scale
   < src..

   Lo que nos ahorra tener que repetir (y reevaluar) la expresion de la
   variable.

   Las variables numericas tambien se pueden incrementar y disminuir con las
   declaraciones @c(++) y @c(--):

   ..src > go
     v := 1
     v++    // igual a v = v + 1; v es 2
     v--    // igual a v = v - 1; v es 1 de nuevo
   < src..

*** Seccion 2.4.1 <> Asignacion de Tuplas

    Otra forma de asignacion, conocida como @e(asignacion de tuplas), permite
    asignar varias variables a la vez. Todas las expresiones del lado derecho se
    evaluan antes de actualizar cualquiera de las variables, haciendo que este
    formato sea mas util cuando algunas de las variables aparecen en ambos lados
    de la asignacion, como sucede, por ejemplo, al intercambiar los valores de
    dos variables:

    ..src > go
      x, y = y, x
      a[i], a[j] = a[j], a[i]
    < src..

    o cuando se calcula el mayor comun divisor (MCD) de dos enteros:

    ..src > go
      func mcd(x, y int) int {
        for y != 0 {
          x, y = y, x%y
        }
        return x
      }
    < src..

    o al calcular el n-esimo numero de Fibonacci iterativamente:

    ..src > go
      func fib(n int) int {
        x, y := 0, 1
        for i := 0; i < n; i++ {
          x, y = y, x+y
        }
        return x
      }
    < src..

    La asignacion de tuplas tambien puede hacer mas compata una secuencia de
    asignaciones trivial,

    ..src > go
      i, j, k = 2, 3, 5
    < src..

    aunque como cuestion de estilo, evite la forma de tupla si las
    expresiones son complejas; una secuencia de declaraciones separadas es mas
    facil de leer.

    Ciertas expresiones, como la llamada a una funcion con resultados
    multiples, producen varios valores. Cuando se utiliza una llamada de este
    tipo en una instruccion de asignacion, el lado izquierdo debe tener tantas
    variables como la funcion tenga resultados.

    ..src > go
      f, err = os.Open("foo.txt") // la llamada de funcion devuelve dos valores
    < src..

    A menudo, las funciones utilizan estos resultados adicionales para indicar
    algun tipo de error, ya sea devolviendo un @c(error) como en la llamada a
    @c(os.Open), o un @c(bool), normalmente llamado @c(ok). Como veremos en
    capitulos posteriores, hay tres operadores que a veces se comportan de esta
    manera tambien. Si la busqueda en un mapa @%l(#Seccion 4.3<>§4.3), la
    asercion de tipo @%l(#Seccion 7.10<>§7.10), o la recepcion de un canal
    @%l(#Seccion 8.4.2<>§8.4.2) aparece en una asignacion en la que se esperan
    dos resultados, cada una produce un resultado booleano adicional:

    ..src > go
      v, ok = m[key]         // busqueda en mapa
      v, ok = x.(T)          // asercion de tipo
      v, ok = <-ch           // recepcion de canal
    < src..

    Al igual que con la declaracion de variables, podemos asignar valores no
    deseados al identificador en blanco:

    ..src > go
      _, err = io.Copy(dst, src) // descarta conteo de bytes
      _, ok = x.(T)              // comprueba el tipo pero descarta el resultado
    < src..

*** Seccion 2.4.2 <> Asignacion

    Las sentencias de asignacion son una forma explicita de asignacion, pero hay
    muchos lugares en un programa donde una asignacion se produce de forma @e(implicita):
    una llamada de funcion asigna implicitamente los valores de los argumentos a
    las variables de parametros correspondientes; una instruccion @c(return)
    asigna implicitamente los operandos de retorno a las variables de resultado
    correspondientes; y una expresion literal para un tipo compuesto
    @%l(#Seccion 4.2<>§4.2), como este slice:

    ..src > go
      medallas := []string{"oro", "plata", "bronce"}
    < src..

    asigna implicitamente cada elemento, como si se hubiera escrito asi:

    ..src > go
      medallas[0] = "oro"
      medallas[1] = "plata"
      medallas[2] = "bronce"
    < src..

    Los elementos de los mapas y canales, aunque no son variables ordinarias,
    tambien estan sujetos a asignaciones implicitas similares.

    Una asignacion, explicita o implicita, siempre es legal si el lado izquierdo
    (la variable) y el lado derecho (el valor) tienen el mismo tipo. En terminos
    mas generales, la asignacion es legal solo si el valor es @e(asignable) al
    tipo de la variable.

    La regla de @e(asignacion) tiene casos para varios tipos, por lo que
    explicaremos el caso pertinente a medida que introduzcamos cada nuevo
    tipo. Para los tipos que hemos discutido hasta ahora, las reglas son
    simples: los tipos deben coincidir exactamente, y @c(nil) puede ser asignado
    a cualquier variable de interfaz o tipo de referencia. Las constantes
    @%l(#Seccion 3.6<>§3.6) tienen reglas mas flexibles de asignacion que
    evitan la necesidad de conversiones mas explicitas.

    Si dos valores pueden compararse con @c(==) y @c(!=) esta relacionado con la
    asignacion: en cualquier comparacion, el primer operando debe ser asignable
    al tipo del segundo operando, o viceversa. Al igual que con la
    asignabilidad, explicaremos los casos relevantes para la comparabilidad
    cuando presentamos cada nuevo tipo.

** Seccion 2.5 <> Declaraciones de Tipo

   El tipo de una variable o expresion define las caracteristicas de los valores
   que puede asumir, como su tamaño (numero de bits o numero de elementos, tal
   vez), como se representan internamente, las operaciones intrinsecas que se
   pueden realizar en ellos, Y los metodos asociados a ellos.

   En cualquier programa hay variables que comparten la misma representacion
   pero que significan conceptos muy diferentes. Por ejemplo, un @c(int) podria
   ser usado para representar un indice de bucle, una marca de tiempo, un
   descriptor de archivo, o un mes; un @c(float64) podria representar una
   velocidad en metros por segundo o una temperatura en una de varias escalas; y
   un @c(string) podria representar una contraseña o el nombre de un color.

   Una declaracion @c(type) define un nuevo @e(tipo con nombre) que tiene el
   mismo @e(tipo subyacente) que un tipo existente. El tipo nombrado
   proporciona una manera de separar los diferentes usos y quizas incompatibles
   del tipo subyacente de modo que que no puedan mezclarse involuntariamente.

   ..src > go
     type nombre tipo-subyacente
   < src..

   Las declaraciones de tipo aparecen mas a menudo a nivel de paquete, donde
   el tipo nombrado es visible en todo el paquete, y si el nombre se exporta
   (inicia con una letra mayuscula), tambien es accesible desde otros paquetes.

   Para ilustrar la declaracion de tipos, vamos a convertir las diferentes
   escalas de temperatura en tipos distintos:

   ..figure > @l(gopl.io/ch2/tempconv0/celsius.go<>gopl.io/ch2/tempconv0)

     ..src > go
       // Paquete tempconv realiza calculos de temperatura Celsius y Fahrenheit.
       package tempconv

       import "fmt"

       type Celsius float64
       type Fahrenheit float64

       const (
         AbsoluteZeroC Celsius = -273.15
         FreezingC     Celsius = 0
         BoilingC      Celsius = 100
       )

       func CToF(c Celsius) Fahrenheit { return Fahrenheit(c*9/5 + 32) }
       func FToC(f Fahrenheit) Celsius { return Celsius((f - 32) * 5 / 9) }
     < src..


   Este paquete define dos tipos, @c(Celsius) y @c(Fahrenheit), para las dos
   unidades de temperatura. A pesar de que ambos tienen el mismo tipo
   subyacente, @c(float64), no son del mismo tipo, por lo que no pueden ser
   comparados o combinados en expresiones aritmeticas. Distinguir los tipos
   permite evitar errores como combinar inadvertidamente temperaturas en
   las dos escalas diferentes; se requiere una conversion de tipo explicita
   como @c[Celsius(t)] o @c[Fahrenheit(t)] para convertir desde un @c(float64).
   @c[Celsius(t)] y @c[Fahrenheit(t)] son conversiones, no llamadas a funcion.
   No cambian el valor o la representacion de ninguna manera, pero hacen que el
   cambio de significado sea explicito. Por otro lado, las funciones @c(CToF) y
   @c(FToC) realizan conversiones entre las dos escalas; estas devuelven valores
   diferentes.

   Para cada tipo @c(T), hay una operacion de conversion correspondiente
   @c[T(x)] que convierte el valor @c(x) al tipo @c(T). Se permite una
   conversion de un tipo a otro si ambos tienen el mismo tipo subyacente, o si
   ambos son de tipo puntero sin nombre que apuntan a variables del mismo tipo
   subyacente; estas conversiones cambian el tipo pero no la representacion del
   valor. Si @c(x) es asignable a @c(T), se permite una conversion, pero suele
   ser redundante.

   Tambien se permiten las conversiones entre tipos numericos, y entre tipos de cadena
   y algunos tipos de slices, como veremos en el siguiente capitulo. Estas
   conversiones pueden cambiar la representacion del valor. Por ejemplo, la
   conversion de un numero de coma flotante a un entero descarta cualquier parte
   fraccionaria, y la conversion de una cadena a un slice @c([]byte) asigna una
   copia de los datos de la cadena. En cualquier caso, una conversion nunca falla
   en tiempo de ejecucion.

   El tipo subyacente de un tipo con nombre determina su estructura y
   representacion, asi como el conjunto de operaciones intrinsecas que admite,
   que son las mismas que si el tipo subyacente se hubiera utilizado directamente.
   Eso significa que los operadores aritmeticos funcionan igual para @c(Celsius)
   y @c(Fahrenheit) que para @c(float64), como es de esperar.

   ..src > go
     fmt.Printf("%g\n", BoilingC-FreezingC)       // "100" °C
     boilingF := CToF(BoilingC)
     fmt.Printf("%g\n", boilingF-CToF(FreezingC)) // "180" °F
     fmt.Printf("%g\n", boilingF-FreezingC)       // error de compilacion: tipo incorrecto
   < src..

   Los operadores de comparacion como @c(==) y @c(<) tambien se puede utilizar
   para comparar un valor de un tipo con nombre con otro del mismo tipo, o con un
   valor de un tipo sin nombre con el mismo tipo subyacente. Pero dos valores de
   diferentes tipos con nombre no pueden compararse directamente:

   ..src > go
     var c Celsius
     var f Fahrenheit
     fmt.Println(c == 0)          // "true"
     fmt.Println(f >= 0)          // "true"
     fmt.Println(c == f)          // error de compilacion: tipo incorrecto
     fmt.Println(c == Celsius(f)) // "true"!
   < src..

   Observe cuidadosamente el ultimo caso. A pesar de su nombre, la conversion de
   tipo @c[Celsius(f)] no cambia el valor de su argumento, solo su tipo. La prueba
   es verdadera porque tanto @c(c) como @c(f) son cero.

   Un tipo con nombre puede proporcionar una conveniencia de notacion si ayuda a
   evitar escribir tipos complejos una y otra vez. La ventaja es pequeña cuando
   el tipo subyacente es tan simple como @c(float64), pero grande para los tipos
   complicados, como veremos cuando hablemos de las estructuras.

   Los tipos con nombre tambien permiten definir nuevos comportamientos para los
   valores del tipo. Estos comportamientos se expresan como un conjunto de
   funciones asociadas con el tipo, denominados @e(metodos) del tipo. Veremos los
   metodos en detalle en el @l(#Capitulo 6), pero daremos una muestra del mecanismo
   aqui.

   La siguiente declaracion, en la que el parametro @c(c) de tipo @c(Celsius)
   aparece antes del nombre de la funcion, se asocia con el tipo @c(Celsius) un
   metodo llamado @c(String) que devuelve @c(c) como un valor numerico seguido
   por @c(°C):

   ..src > go
     func (c Celsius) String() string { return fmt.Sprintf("%g°C", c) }
   < src..


   Muchos tipos declaran un metodo @c(String) de esta forma porque controla
   como aparecen los valores del tipo cuando se imprimen en una cadena por el
   paquete @c(fmt), como veremos en la @l(#Seccion 7.1).

   ..src > go
     c := FToC(212.0)
     fmt.Println(c.String()) // "100°C"
     fmt.Printf("%v\n", c)   // "100°C"; no es necesario llamar a String explicitamente
     fmt.Printf("%s\n", c)   // "100°C"
     fmt.Println(c)          // "100°C"
     fmt.Printf("%g\n", c)   // "100"; no llama a String
     fmt.Println(float64(c)) // "100"; no llama a String
   < src..

** Seccion 2.6 <> Paquetes y Ficheros

   Los paquetes en Go sirven a los mismos propositos que las librerias o los modulos
   en otros lenguajes, apoyando la modularidad, encapsulacion, compilacion
   separada y la reutilizacion. El codigo fuente de un paquete reside en uno o mas
   archivos @f(.go), por lo general en un directorio cuyo nombre termina con la
   ruta de importacion; por ejemplo, los archivos del paquete
   @c(gopl.io/ch1/helloworld) se almacenan en el directorio
   @c($GOPATH/src/gopl.io/ch1/helloworld).

   Cada paquete sirve como un @e(espacio de nombres) separado para sus
   declaraciones. Por ejemplo, dentro del paquete @c(image), el identificador
   @c(Decode) se refiere a una funcion distinta a la del mismo identificador en
   el paquete @c(unicode/utf16). Para referirnos a una funcion desde fuera
   de su paquete, debemos @e(calificar) el identificador para hacer explicito si
   nos referimos a @c(image.Decode) o @c(utf16.Decode).

   Los paquetes tambien nos permiten ocultar informacion controlando que nombres
   son visibles fuera del paquete, o @e(exportados). En Go, una regla simple
   rige que identificadores se exportan y cuales no: los identificadores
   exportados comienzan con una letra mayuscula.

   Para ilustrar los fundamentos, supongamos que nuestro software de conversion
   de temperatura se ha vuelto popular y queremos ponerlo a disposicion de la
   comunidad Go como un nuevo paquete. ¿Como lo hacemos?

   Vamos a crear un paquete llamado @c(gopl.io/ch2/tempconv), una variacion del
   ejemplo anterior. (Aqui hemos hecho una excepcion a nuestra regla habitual de
   numerar los ejemplos en secuencia, de modo que la ruta del paquete puede
   ser mas realista.) El propio paquete se almacena en dos archivos para mostrar
   como se accede a las declaraciones en archivos separados de un paquete; en la
   vida real, un pequeño paquete como este solo necesitaria un archivo.

   Hemos puesto las declaraciones de los tipos, sus constantes y sus metodos en
   @f(tempconv.go):

   ..figure > @l(gopl.io/ch2/tempconv/tempconv.go<>gopl.io/ch2/tempconv)

     ..src > go
       // El paquete tempconv realiza conversiones Celsius y Fahrenheit.
       package tempconv

       import "fmt"

       type Celsius float64
       type Fahrenheit float64

       const (
       	AbsoluteZeroC Celsius = -273.15
       	FreezingC     Celsius = 0
       	BoilingC      Celsius = 100
       )

       func (c Celsius) String() string    { return fmt.Sprintf("%g°C", c) }
       func (f Fahrenheit) String() string { return fmt.Sprintf("%g°F", f) }
     < src..


   y las funciones de conversion en @f(conv.go):

   ..src > go
     package tempconv

     // CToF convierte una temperatura Celsius a Fahrenheit.
     func CToF(c Celsius) Fahrenheit { return Fahrenheit(c*9/5 + 32) }

     // FToC convierte una temperatura Fahrenheit a Celsius.
     func FToC(f Fahrenheit) Celsius { return Celsius((f - 32) * 5 / 9) }
   < src..

   Cada archivo comienza con una declaracion @c(package) que define el nombre
   del paquete. Cuando se importa el paquete, sus miembros se conocen como
   @c(tempconv.CToF) y asi sucesivamente. Los nombres a nivel de paquete como
   los tipos y las constantes declaradas en un archivo de un paquete son
   visibles para todos los otros archivos del paquete, como si el codigo fuente
   estuviera en un solo archivo. Observe que @f(tempconv.go) importa
   @c(fmt), pero @f(conv.go) no lo hace, ya que no utiliza nada de @c(fmt).

   Debido a que los nombres @c(const) de nivel de paquete comienzan con letras
   mayusculas, tambien son accesibles con nombres calificados, por ejemplo,
   @c(tempconv.AbsoluteZeroC):

   ..src > go
     fmt.Printf("Brrrr! %v\n", tempconv.AbsoluteZeroC) // "Brrrr! -273.15°C"
   < src..

   Para convertir una temperatura Celsius a Fahrenheit en un paquete que importa
   @c(gopl.io/ch2/tempconv), podemos escribir el siguiente codigo:

   ..src > go
     fmt.Println(tempconv.CToF(tempconv.BoilingC)) // "212°F"
   < src..

   El @c(comentario de documentacion) @%l(#Seccion 10.7.4<>§10.7.4)
   inmediatamente anterior a la declaracion del paquete, documenta el paquete en
   su conjunto. Convencionalmente, debe comenzar con una oracion resumida en
   el estilo ilustrado. Solo un archivo de cada paquete debe tener un comentario
   de documentacion del paquete. Los comentarios de documentacion extensos, a
   menudo se colocan en un archivo propio, convencionalmente llamado @f(doc.go).

   @b(Ejercicio 2.1): Añadir tipos, constantes y funciones a @c(tempconv) para
   el procesamiento de temperaturas en la escala Kelvin, donde cero Kelvin es
   -273,15°C y una diferencia de 1K tiene la misma magnitud de 1°C.

*** Seccion 2.6.1 <> Importaciones

    Dentro de un programa Go, cada paquete se identifica por una cadena unica
    llamada @e(ruta de importacion). Estas son las cadenas que aparecen en
    una declaracion @c(import) como @c("gopl.io/ch2/tempconv"). La
    especificacion del lenguaje no define de donde provienen estas cadenas o lo
    que significan; depende de las herramientas para interpretarlas. Cuando se
    utiliza la herramienta @$(go) @%l(#Capitulo 10), una ruta de importacion
    denota un directorio que contiene uno o mas archivos de codigo fuente Go que
    juntos componen el paquete.

    Ademas de su ruta de importacion, cada paquete tiene un @e(nombre de paquete),
    que es corto (y no necesariamente unico) que aparece en su
    declaracion @c(package). Por convencion, el nombre de un paquete coincide
    con el ultimo segmento de la ruta de importacion, por lo que es facil
    predecir que el nombre del paquete de @c(gopl.io/ch2/tempconv) es
    @c(tempconv).

    Para utilizar @c(gopl.io/ch2/tempconv), hay que importarlo:

    ..figure > @l(gopl.io/ch2/cf/main.go<>gopl.io/ch2/cf)

      ..src > go
        // Cf conviente su argumento numerico en Celsius y Fahrenheit.
        package main

        import (
          "fmt"
          "os"
          "strconv"

          "gopl.io/ch2/tempconv"
        )

        func main() {
          for _, arg := range os.Args[1:] {
            t, err := strconv.ParseFloat(arg, 64)
            if err != nil {
              fmt.Fprintf(os.Stderr, "cf: %v\n", err)
              os.Exit(1)
            }
            f := tempconv.Fahrenheit(t)
            c := tempconv.Celsius(t)
            fmt.Printf("%s = %s, %s = %s\n",
              f, tempconv.FToC(f), c, tempconv.CToF(c))
          }
        }
      < src..

    La declaracion de importacion vincula un nombre corto al paquete importado
    que se puede utilizar para referirse a su contenido en todo el archivo. El
    @c(import) anterior nos permite referimos a nombres dentro de
    @c(gopl.io/ch2/tempconv) mediante el uso de un identificador calificado como
    @c(tempconv.CToF). Por defecto, el nombre corto es el nombre del paquete–en
    este caso @c(tempconv), pero una declaracion de importacion puede
    especificar un nombre alternativo para evitar un conflicto @%l(#Seccion
    10.4<>§10.4).

    El programa @$(cf) convierte un unico argumento numerico de la linea de
    comandos a su valor en grados Celsius y Fahrenheit:

    ..srci > sh
      > go build gopl.io/ch2/cf
      > ./cf 32
      32°F = 0°C, 32°C = 89.6°F
      > ./cf 212
      212°F = 100°C, 212°C = 413.6°F
      > ./cf -40
      -40°F = -40°C, -40°C = -40°F
    < srci..

    Es un error importar un paquete y luego no hacer referencia a el. Esta
    comprobacion ayuda a eliminar las dependencias que se hacen innecesarias
    a medida que el codigo evoluciona, aunque puede ser una molestia durante la
    depuracion, ya que al comentar una linea de codigo como @c[log.Print("got
    here!")] puede eliminar la unica referencia al nombre de paquete @c(log),
    probocando que el compilador emita un error. En esta situacion, es necesario
    comentar o eliminar el @c(import) innecesario.

    Mejor aun, utilice la herramienta @c(golang.org/x/tools/cmd/goimports), que
    inserta y elimina paquetes de la declaracion de importacion, segun sea
    necesario de forma automatica; la mayoria de los editores pueden
    configurarse para ejecutar @$(goimports) cada vez que se guarda un fichero.
    Al igual que la herramienta @$(gofmt), tambien imprime bonitos ficheros de
    codigo fuene en el formato canonico.

   @b(Ejercicio 2.2): Escribir un programa de proposito general para conversion
   de unidades analogo a @$(cf) que leea los numeros de sus argumentos de linea
   de comando o de la entrada estandar si no hay argumentos, y convierta cada
   numero en unidades como la temperatura en grados Celsius y Fahrenheit,
   longitud en Pies y metros, peso en libras y kilogramos y similares.

*** Seccion 2.6.2 <> Inicializacion del paquete

    La inicializacion de los paquetes comienza con la inicializacion de las
    variables a nivel de paquete en el orden en que se declaran, excepto que las
    dependencias se resuelven primero:

    ..src > go
      var a = b + c      // a inicializado tercero, a 3
      var b = f()        // b inicializado segundo, a 2, llamando a f
      var c = 1          // c inicializado primero, a 1

      func f() int { return c + 1 }
    < src..

    Si el paquete tiene multiples ficheros @f(.go), se inicializan en el orden
    en que se dan los archivos al compilador; la herramienta @$(go) ordena los
    ficheros @f(.go) por nombre antes de invocar al compilador.

    Cada variable declarada en el nivel del paquete comienza su vida con el
    valor de su expresion inicializadora, pero para algunas variables, como
    las tablas de datos, una expresion inicializadora puede no ser la manera mas
    simple de establecer su valor inicial. En ese caso, el mecanismo de la
    funcion @c(init) puede ser mas simple. Cualquier archivo puede contener
    cualquier numero de funciones cuya declaracion sea

    ..src > go
      func init() { /* ... */ }
    < src..

    No se puede llamar o hacer referencia a estas funciones @c(init), pero por
    lo demas son funciones normales. Dentro de cada archivo, las funciones
    @c(init) se ejecutan automaticamente cuando se inicia el programa, en el
    orden en que se declaran.

    Los paquetes se inicializan uno a la vez, en el orden de las importaciones en el
    programa, las dependencias en primer lugar, por lo que un paquete @c(p) que
    importa a @c(q) puede estar seguro de que @c(q) se inicializa completamente
    antes de la inicialiacion de @c(p). La inicializacion procede de abajo hacia
    arriba; el paquete @c(main) es el ultimo en ser inicializado. De esta
    manera, todos los paquetes se inicializan completamente antes de que inicie
    la funcion @c(main).

    El paquete a continuacion define una funcion @c(PopCount) que devuelve el
    numero de bits establecidos, es decir, los bits cuyo valor es 1, en un valor
    @c(uint64), que se llama @e(conteo de poblacion). Utiliza una funcion
    @c(init) para calcular previamente una tabla de resultados, @c(pc), para
    cada posible valor de 8 bits de modo que la funcion @c(PopCount) no necesite
    tomar 64 pasos, sino que puede devolver la suma de ocho consultas en la
    tabla. (Esto definitivamente no es el algoritmo mas rapido para el recuento
    de bits, pero es conveniente para ilustrar las funciones @c(init), y para
    mostrar como calcular previamente una tabla de valores, que a menudo es una
    tecnica de programacion util).

    ..figure > @l(gopl.io/ch2/popcount/main.go<>gopl.io/ch2/popcount)

      ..src > go
        package popcount

        // pc[i] es el recuento de poblacion de i.
        var pc [256]byte

        func init() {
          for i := range pc {
            pc[i] = pc[i/2] + byte(i&1)
          }
        }

        // PopCount regresa el conteo de la poblacion (numero de bist establecidos) de x.
        func PopCount(x uint64) int {
          return int(pc[byte(x>>(0*8))] +
            pc[byte(x>>(1*8))] +
            pc[byte(x>>(2*8))] +
            pc[byte(x>>(3*8))] +
            pc[byte(x>>(4*8))] +
            pc[byte(x>>(5*8))] +
            pc[byte(x>>(6*8))] +
            pc[byte(x>>(7*8))])
        }
      < src..


    Observe que el rango del bucle en @c(init) utiliza solo el indice; el valor
    es innecesario y por lo tanto no necesita ser incluido. El bucle tambien
    podria haber sido escrito como

    ..src > go
      i, _ := range pc {
    < src..

    Veremos otros usos de funciones @c(init) en la siguiente seccion y en la
    @l(#Seccion 10.5).

    @b(Ejercicio 2.3): Vuelve a escribir @c(PopCount) para utilizar un bucle en
    lugar de una sola expresion. Compare el rendimiento de las dos versiones. (La
    @l(#Seccion 11.4) muestra como comparar el rendimiento de diferentes
    implementaciones de forma sistematica.)

    @b(Ejercicio 2.4): Escribe una version de @c(PopCount) que cuente los bits
    desplazando su argumento a traves de posiciones de 64 bits, poniendo a
    prueba el bit mas a la derecha cada vez. Compare su rendimiento con la
    version de buesqueda por tabla.

    @b(Ejercicio 2.5): La expresion @c[x&(x-1)] despeja el bit mas a la derecha
    no-cero de @c(x). Escribe una version de @c(PopCount) que cuente bits
    mediante este hecho, y evalua su rendimiento.

** Seccion 2.7 <> Alcance

   Una declaracion asocia un nombre a una entidad de programa, como una funcion
   o una variable. El @e(alcance) de una declaracion es la parte del codigo
   fuente, donde el uso de un nombre declarado hace referencia a esa
   declaracion.

   No confunda el alcance con el tiempo de vida. El alcance de una declaracion
   es una region del texto del programa; es una propiedad de tiempo de
   compilacion. La vida util de una variable es el intervalo de tiempo durante
   la ejecucion cuando la variable puede ser referida por otras partes del
   programa; es una propiedad en tiempo de ejecucion.

   Un @e(bloque) sintactico es una secuencia de sentencias encerradas entre
   llaves como las que rodean el cuerpo de una funcion o bucle. Un nombre
   declarado dentro de un bloque sintactico no es visible fuera de ese
   bloque. El bloque incluye sus declaraciones y determina su alcance. Podemos
   generalizar esta nocion de bloques para incluir otras agrupaciones de
   declaraciones que no estan explicitamente rodeadas por llaves en el codigo
   fuente; los llamaremos a todos @e(bloques lexicos). Hay un bloque lexico para
   todo el codigo fuente, llamado @e(bloque del universo); para cada paquete;
   para cada archivo; para cada sentencia @c(for), @c(if), y @c(switch); para
   cada caso en una sentencia @c(switch) o @c(select); y, por supuesto, para
   cada bloque sintactico explicito.

   El bloque lexico de una declaracion determina su alcance, que puede ser
   grande o pequeño. Las declaracion de tipos nativos, funciones y constantes,
   por ejemplo @c(int), @c(len), y @c(true) estan en el bloque universo y pueden
   ser referidos a lo largo de todo el programa. Las declaraciones fuera de
   cualquier funcion, es decir, a @e(nivel de paquete), puede ser refenciadas en
   cualquier archivo en el mismo paquete. Los paquetes importados, como @c(fmt) en
   el ejemplo @c(tempconv), se declaran a @e(nivel de archivo), por lo que se
   puede hacer referencia a ellos desde el mismo archivo, pero no desde otro archivo
   en el mismo paquete sin otro @c(import). Muchas declaraciones, como la de la
   variable @c(c) en la funcion @c(tempconv.CToF), son @e(locales), por lo que
   solo se pude hacer referencia a ellas desde dentro de la misma funcion o tal vez
   solo en una parte de ella.

   El alcance de una etiqueta de flujo de control, tal como se usa en las
   sentencias @c(break), @c(continue), y @c(goto), es toda la funcion que la
   rodea.

   Un programa puede contener varias declaraciones del mismo nombre, siempre y
   cuando cada declaracion este en un bloque lexico diferente. Por ejemplo,
   puede declarar una variable local con el mismo nombre que una variable a
   nivel de paquete. O, como se muestra en la @l(#Seccion 2.3.3), se puede
   declarar un parametro de funcion llamado @c(new), a pesar de tener una
   funcion con este nombre declarada con anterioridad en el bloque universo. No
   exagere, cuanto mayor sea el alcance de la redeclaracion, mas probable es que
   sorprenda al lector.

   Cuando el compilador encuentra una referencia a un nombre, busca una
   declaracion, comenzando con el bloque lexico interno mas cercano y explorando
   hasta el bloque universo. Si el compilador no encuentra ninguna declaracion,
   se informa de un error de @"(nombre no declarado.) Si se declara un nombre
   tanto en un bloque externo como en un bloque interno, se encontrara primero
   la declaracion interna. En ese caso, se dice que la declaracion interna
   @e(obscurese) u @e(oculta) la exterior, haciendola inaccesible:

   ..src > go
     func f() {}
     var g = "g"
     func main() {
       f := "f"
       fmt.Println(f) // "f"; la variable f local oculta la funcion f a nivel de paquete
       fmt.Println(g) // "g"; variable a nivel de paquete
       fmt.Println(h) // error de compilacion: sin definir: h
     }
   < src..

   Dentro de una funcion, los bloques lexicos pueden anidarse a una profundidad
   arbitraria, por lo que una declaracion local puede ensombrecer a otra. La
   mayoria de los bloques son creados por construcciones de flujo de control,
   como las declaraciones @c(if) y los bucles @c(for). El programa siguiente
   tiene tres variables distintas llamadas @c(x), ya que cada declaracion
   aparece en un bloque lexico diferente. (Este ejemplo ilustra las reglas de
   alcance, no un buen estilo de programacion!)

   ..src > go
     func main() {
       x := "hello!"
       for i := 0; i < len(x); i++ {
         x := x[i]
         if x != '!' {
           x := x + 'A' - 'a'
           fmt.Printf("%c", x) // "HELLO" (una letra por iteracion)
         }
       }
     }
   < src..

   Las expresiones @c(x[i]) y @c(x + 'A' - 'a') se refieren cada una a una
   declaracion de @c(x) a partir de un bloque exterior; lo explicaremos en un
   momento. (Tenga en cuenta que esta ultima expresion @e(no) es equivalente a
   @c(unicode.ToUpper)).

   Como se menciono anteriormente, no todos los bloques lexicos corresponden con
   secuencias delimitadas explicitamente por llaves; algunos simplemente son
   implicitos. El bucle @c(for) anterior crea dos bloques lexicos: el bloque
   explicito para el cuerpo del bucle, y un bloque implicito que adicionalmente
   encierra las variables declaradas por la clausula de inicializacion, como
   @c(i). El alcance de una variable declarada en el bloque implicito es la
   condicion, la post-declaracion @%c(i++), y el cuerpo del la sentencia @c(for).

   El siguiente ejemplo tambien tiene tres variables con nombre @c(x), cada una
   declarada en un bloque distinto–una en el cuerpo de la funcion, una en un
   bloque de sentencia @c(for) y otra en el cuerpo del bucle–pero solo dos de los
   bloques son explicitos:

   ..src > go
     func main() {
       x := "hello"
       for _, x := range x {
         x := x + 'A' - 'a'
         fmt.Printf("%c", x) // "HELLO" (una letra por iteracion)
       }
     }
   < src..

   Al igual que en el bucle @c(for), las declaraciones @c(if) y @c(switch) tambien
   crean un bloque implicito ademas del cuerpo de sus bloques. El codigo en la
   siguiente cadena @c(if)-@c(else) muestra el alcance de @c(x) y @c(y):

   ..src > go
     if x := f(); x == 0 {
       fmt.Println(x)
     } else if y := g(x); x == y {
       fmt.Println(x, y)
     } else {
       fmt.Println(x, y)
     }
     fmt.Println(x, y) // error de compilacion: x y y no son visibles aqui
   < src..

   La segunda declaracion @c(if) se anida dentro de la primera, de modo que
   las variables declaradas dentro de la primera declaracion
   son visibles dentro de la segunda. Reglas similares se aplican a cada caso de
   una sentencia @c(switch): hay un bloque para la condicion y un bloque para
   cada cuerpo del caso.

   A nivel de paquete, el orden en que aparecen las declaraciones no
   tiene ningun efecto en su alcance, por lo que una declaracion puede referirse
   a si misma, o a otra que le sigua, permitiendonos declarar tipos y funciones
   recursivos o mutuamente recursivos. Sin embargo, el compilador reportara un
   error si una declaracion constante o variable se refiere a si misma.

   En este programa:

   ..src > go
     if f, err := os.Open(fname); err != nil { // error de compilacion: sin usar: f
       return err
     }
     f.ReadByte() // error de compilacion: f sin definir
     f.Close()    // error de compilacion: f sin definir
   < src..

   el alcance de @c(f) es solo la sentencia @c(if), por lo que @c(f) no es
   accesible a las declaraciones despues de esta, lo que resulta en errores de
   compilacion. Dependiendo del compilador, puede obtener un informe de errores
   adicional informando que la variable local @c(f) nunca fue utilizada.

   Por lo tanto, a menudo es necesario declarar @c(f) antes de la condicion de modo
   que sea accesible mas tarde:

   ..src > go
     f, err := os.Open(fname)
     if err != nil {
       return err
     }
     f.ReadByte()
     f.Close()
   < src..

   Es posible sentirse tentado a evitar declarar @c(f) y @c(err) en el
   bloque externo moviendo las llamadas a @c(ReadByte) y @c(Close) dentro del
   bloque @c(else):

   ..src > go
     if f, err := os.Open(fname); err != nil {
       return err
     } else {
       // f y err son visibles aqui tambien
       f.ReadByte()
       f.Close()
     }
   < src..

   pero una practica normal en Go es lidiar con el error en el bloque @c(if) y
   luego regresar, de modo que la ruta de ejecucion exitosa no se indente.

   Las declaracion de variables compacta exige un conocimiento del
   alcance. Considere el siguiente programa, que comienza obteniendo su
   directorio de trabajo actual y guardandolo en una variable a nivel de
   paquete. Esto podria hacerse llamando a @c(os.Getwd) en la funcion @c(main),
   pero podria ser mejor separar esta preocupacion de la logica primaria,
   especialmente si no podemos obtener el directorio producir un error fatal. La funcion
   @c(log.Fatalf) imprime un mensaje y llama a @c[os.Exit(1)].

   ..src > go
     var cwd string

     func init() {
       cwd, err := os.Getwd() // error de compilacion: sin usar: cwd
       if err != nil {
         log.Fatalf("os.Getwd failed: %v", err)
       }
     }
   < src..

  Dado que ni @c(cwd) ni @c(err) se declaran en el bloque de la funcion
  @c(init), la sentencia @c(:=) declara ambas como variables locales. La
  declaracion interna de @c(cwd) hace que la externa sea inaccesible, por lo que
  la sentencia no actualiza la variable @c(cdw) de nivel de paquete como se
  pretende.

  Los compiladores actuales de Go detectan que la variable local @c(cwd) nunca
  se utilza y lo reporta como un error, pero no estan estrictamente
  obligados a realizar esta comprobacion. Por otra parte, un cambio
  menor, como la adicion de una declaracion de registro que hace referencia al
  @c(cwd) local, anularia la comprobacion.

   ..src > go
     var cwd string

     func init() {
       cwd, err := os.Getwd() // NOTA: incorrecto!
       if err != nil {
         log.Fatalf("os.Getwd failed: %v", err)
       }
       log.Printf("Working directory = %s", cwd)
     }
   < src..

   La variable global @c(cwd) permanece sin inicializar, y la salida del
   registro aparentemente normal ofusca el fallo.

   Hay varias maneras de lidiar con este problema potencial. La mas
   directa es evitar @c(:=) declarando @c(err) en una declaracion @c(var)
   separada:

   ..src > go
     var cwd string

     func init() {
       var err error
       cwd, err = os.Getwd()
       if err != nil {
         log.Fatalf("os.Getwd failed: %v", err)
       }
     }
   < src..

   Hemos visto como los paquetes, archivos, declaraciones y sentencias
   expresan la estructura de los programas. En los proximos dos capitulos,
   veremos la estructura de los datos.

* Capitulo 3 <> Tipos de Datos Basicos

  En el fondo todo son solo bits, por supuesto, pero las computadoras operan
  fundamentalmente en numeros de tamaño fijo llamados @e(palabras), que se
  interpretan como numeros enteros, numeros de punto flotante, conjuntos de
  bits, o direcciones de memoria, que luego se combinan en agregados mas grandes
  que representan paquetes, pixeles, carteras, poesia y todo lo demas. Go ofrece
  una variedad de formas de organizar los datos, con un espectro de tipos de
  datos que en un extremo coinciden con las caracteristicas del hardware y en el
  otro proporcionan lo que los programadores necesitan para representar
  convenientemente estructuras de datos complicadas.

  Los tipos de datos de Go se dividen en cuatro categorias: @e(tipos basicos),
  @e(tipos de agregados), @e(tipos de referencia), y @e(tipos de interfaz). Los
  tipos basicos, el tema de este capitulo, incluyen numeros, cadenas y
  booleanos. Los tipos agregados–arreglos @%l(#Seccion 4.1<>§4.1) y estructuras
  @%l(#Seccion 4.4<>§4.4)–forma tipos de datos mas complejos mediante la
  combinacion de otros valores mas simples. Los tipos de referencia son un grupo
  diverso, que incluye punteros @%l(#Seccion 2.3.2<>§2.3.2), slices
  @%l(#Seccion 4.2<>§4.2), mapas @%l(#Seccion 4.3<>§4.3), funciones
  @%l(#Capitulo 5), y canales @%l(#Capitulo 8), pero lo que tienen en comun es
  que todos ellos se refieren a variables del programa o estados
  @e(indirectamente), por lo que el efecto de una operacion que se aplica a una
  referencia es observado por todas las copias de esa referencia. Por ultimo,
  hablaremos de los tipos de interfaz en el @l(#Capitulo 7).

** Seccion 3.1 <> Enteros

   Los tipos de datos numericos de Go incluyen varios tamaños de enteros,
   numeros de coma flotante y numeros complejos. Cada tipo numerico determina el
   tamaño y la firma de sus valores. Comencemos con los numeros enteros.

   Go proporciona aritmetica de numeros enteros con y sin signo. Hay cuatro
   tamaños distintos de numeros enteros–8, 16, 32 y 64 bits–representados por
   los tipos @c(int8), @c(int16), @c(int32), y @c(int64), y las correspondientes
   versiones sin signo @c(uint8), @c(uint16), @c(uint32), y @c(uint64).

   Tambien hay dos tipos llamados simplemente @c(int) y @c(uint) que son del
   tamaño natural o mas eficiente para los numeros enteros con y sin signo en
   una plataforma en particular; @c(int) es con mucho, el tipo numerico mas
   utilizado. Ambos tipos tienen el mismo tamaño, 32 o 64 bits, pero uno no debe
   hacer suposiciones sobre cual es; diferentes compiladores pueden tomar
   diferentes opciones incluso en hardware identico.

   El tipo @c(rune) es un sinonimo de @c(int32) y convencionalmente indica que
   un valor es un punto de codigo Unicode. Los dos nombres pueden utilizarse
   indistintamente. Del mismo modo, el tipo @c(byte) es un sinonimo de
   @c(uint8), y hace hincapie en que el valor es una pieza de datos en bruto mas
   que una pequeña cantidad numerica.

   Por ultimo, existe un tipo entero sin signo @c(uintptr), cuya anchura no se
   especifica, pero es suficiente para contener todos los bits de un valor de
   puntero. El tipo @c(uintptr) solo se utiliza para la programacion a bajo
   nivel, por ejemplo, en el limite de un programa Go con una libreria C o un
   sistema operativo. Veremos ejemplos de esto cuando nos ocupemos del paquete
   @c(unsafe) en el @l(#Capitulo 13).

   Independientemente de su tamaño, @c(int), @c(uint) y @c(uintptr) son
   diferentes tipos de sus hermanos de tamaño de forma explicita. Por lo tanto
   @c(int) no es el mismo tipo que @c(int32), incluso si el tamaño natural de
   enteros es de 32 bits, y se requiere una conversion explicita para utilizar
   un valor @c(int) donde se necesita un @c(int32), y viceversa.

   Los numeros con signo se representan en forma de complemento a 2, en el que el
   bit de orden superior esta reservado para el signo del numero y la gama de
   valores de un numero de @m(n) bits es de -2ⁿ⁻¹ a 2ⁿ⁻¹-1. Los numeros enteros
   sin signo usan el rango completo de bits para valores no negativos y por lo
   tanto tienen el rango de 0 a 2ⁿ-1. Por ejemplo, la gama de @c(int8) es de
   -128 a 127, mientras que la gama de @c(uint8) es de 0 a 255.

   Aqui se enumeran en orden decreciente de precedencia los operadores binarios
   de Go para aritmetica, logica y comparacion:

   ..pre >
     *   /   %  <<  >>  &   &^
     +   -   |  ^
     ==  !=  <  <=  >   >=
     &&
     ||
   < pre..

   Solo hay cinco niveles de precedencia para los operadores binarios. Los
   operadores en el mismo nivel se asocian a la izquierda, por lo que pueden ser
   necesarios parentesis, para mayor claridad, o para hacer que los operadores
   se evaluen en el orden deseado en una expresion como @c[mask & (1 << 28)].

   Cada operador en las dos primeras lineas de la tabla anterior, por ejemplo
   @c(+), tiene un operador de asignacion correspondiente, como @c(+=) que pueden
   utilizarse para abreviar una declaracion de asignacion.

   Los operadores aritmeticos @c(+), @c(-), @c(*), y @c(/) pueden aplicarse a
   numeros enteros, de coma flotante, y numeros complejos, pero el operador
   @c(%) solo se aplica a numeros enteros. El comportamiento de @c(%) para los
   numeros negativos varia en los distintos lenguajes de programacion. En Go, el
   signo del resto es siempre el mismo que el signo del dividendo, por lo que
   @c(-5%3) y @c(-5%-3) son ambos @c(-2). El comportamiento de @c(/) depende de
   si sus operandos son numeros enteros, por lo que @c(5.0/4.0) es @c(1.25),
   pero @c(5/4) es @c(1) porque la division entera trunca el resultado hacia
   cero.

   Si el resultado de una operacion aritmetica, ya sea con o sin signo, tiene
   mas bits de los que pueden ser representados en el tipo del resultado, se
   dice que se @e(desborda). Los bits de orden superior que no encajan se
   descartan silenciosamente. Si el numero original es un tipo con signo, el
   resultado podria ser negativo si el bit mas a la izquierda es un 1, como en
   el siguiente ejemplo:

   ..src > go
     var u uint8 = 255
     fmt.Println(u, u+1, u*u) // "255 0 1"

     var i int8 = 127
     fmt.Println(i, i+1, i*i) // "127 -128 1"
   < src..

   Dos numeros enteros del mismo tipo pueden compararse usando los siguientes
   operadores de comparacion binarios; el tipo de una expresion de comparacion es
   un booleano.

   +--------+---------------------+
   | @c(==) | igual a             |
   +--------+---------------------+
   | @c(!=) | no igual a          |
   +--------+---------------------+
   | @c(<)  | menor que           |
   +--------+---------------------+
   | @c(<=) | menor que o igual a |
   +--------+---------------------+
   | @c(>)  | mayor que           |
   +--------+---------------------+
   | @c(>=) | mayor que o igual a |
   +--------+---------------------+

   De hecho, todos los valores de tipo basico–booleanos, numeros y cadenas–son
   comparables, lo que significa que dos valores del mismo tipo pueden ser
   comparados con los operadores @c(==) y @c(!=). Por otra parte, los numeros
   enteros, numeros de punto flotante y cadenas son @e(ordenados) por los
   operadores de comparacion. Los valores de muchos otros tipos no son
   comparables y no se ordenan otros tipos. A medida que nos encontremos cada
   tipo, presentaremos las reglas que rigen la comparacion de sus valores.

   Tambien hay operadores unarios de suma y resta:

   +-------+------------------------------+
   | @c(+) | unario positivo (sin efecto) |
   +-------+------------------------------+
   | @c(-) | negacion unaria              |
   +-------+------------------------------+

   Para enteros, @c(+x) es una abreviatura de @c(0+x) y @c(-x) es la
   abreviatura de @c(0-x); para los numeros de punto flotante y complejos,
   @c(+x) es @c(x) y @c(-x) es la negacion de @c(x).

   Go tambien proporciona los siguientes operadores binarios a nivel de bits,
   cuyos cuatro primeros tratan sus operandos como patrones de bits sin ningun
   concepto de arrastre o signo:

   +--------+-------------------------------+
   | @c(&)  | AND bit a bit                 |
   +--------+-------------------------------+
   | @c(|)  | OR bit a bit                  |
   +--------+-------------------------------+
   | @c(^)  | XOR bit a bit                 |
   +--------+-------------------------------+
   | @c(&^) | AND NOT                       |
   +--------+-------------------------------+
   | @c(<<) | desplazamiento a la izquierdo |
   +--------+-------------------------------+
   | @c(>>) | desplazamiento a la derecha   |
   +--------+-------------------------------+

   El operador bit a bit @c(^) es un OR exclusivo (XOR) cuando se utiliza como
   un operador binario (coloca un uno en cada posicion en donde sus operandos
   tienen bits distintos, y un cero en donde son iguales), pero cuando se
   utiliza como un operador de prefijo unario es el complemento a uno; es decir,
   devuelve un valor con cada bit en su operando invertido. El operador @c(&^)
   es para lipiar bits (AND NOT): en la expresion @c(z = x &^ y), cada bit de
   @c(z) es 0 si el bit correspondiente de @c(y) es 1; de lo contrario es igual
   al bit correspondiente de @c(x).

   El siguiente codigo muestra como se pueden utilizar las operaciones a nivel
   de bit para interpretar un valor @c(uint8) como un conjunto compacto y
   eficiente de 8 bits independientes. Se utiliza el verbo @c(%b) de @c(Printf)
   para imprimir los digitos binarios de un numero; @c(08) modifica @c(%b) (un
   adverbio!)  para rellenar el resultado con ceros hasta exactamente 8 digitos.

   ..src > go
     package main

     import "fmt"

     func main(){
       var x uint8 = 1<<1 | 1<<5
       var y uint8 = 1<<1 | 1<<2

       fmt.Printf("%08b\n", x)    // "00100010", el conjunto {1, 5}
       fmt.Printf("%08b\n", y)    // "00000110", el conjunto {1, 2}
       fmt.Printf("%08b\n", x&y)  // "00000010", la interseccion {1}
       fmt.Printf("%08b\n", x|y)  // "00100110", la union {1, 2, 5}
       fmt.Printf("%08b\n", x^y)  // "00100100", la diferencia simetrica {2, 5}
       fmt.Printf("%08b\n", x&^y) // "00100000", la diferencia {5}

       for i := uint(0); i < 8; i++ {
         if x&(1<<i) != 0 { // prueba de pertenencia
           fmt.Println(i)   // "1", "5"
         }
       }

       fmt.Printf("%08b\n", x<<1) // "01000100", el conjunto {2, 6}
       fmt.Printf("%08b\n", x>>1) // "00010001", el conjunto {0, 4}
     }
   < src..

   (La @l(#Seccion 6.5) muestra una implementacion de conjuntos de numeros
   enteros que pueden ser mucho mas grandes que un byte).

   En las operaciones de desplazamiento @c(x<<n) y @c(x>>n), el operando @c(n)
   determina el numero de posiciones de bits a cambiar y debe ser sin signo; el
   operando @c(x) puede tener o no signo. Aritmeticamente, el desplazamiento a
   la izquierda @c(x<<n) es equivalente a la multiplicacion por 2ⁿ y un
   desplazamiento a la derecha @c(x>>n) es equivalente a dividir por 2ⁿ.

   Los desplazamientos a la izquierda o derecha en enteros sin singno llenan los
   bits desocupados con ceros, pero los desplazamientos a la derecha de numeros
   con signo llenan los bits desocupados con copias del bit de signo. Por esta
   razon, es importante utilizar aritmetica sin signo cuando se trata un
   entero como un patron de bits.

   Aunque Go proporciona aritmetica y numeros sin signo, se tiende a utilizar un
   @c(int) con signo incluso para cantidades que no pueden ser negativas, como
   la longitud de un arreglo, aunque @c(uint) puede parecer una eleccion mas
   obvia. De hecho, la funcion nativa @c(len) devuelve un @c(int) con signo,
   como en este bucle que anuncia las medallas de premio en el orden inverso:

   ..src > go
     medallas := []string{"oro", "plata", "bronce"}
     for i := len(medallas) - 1; i >= 0; i-- {
       fmt.Println(medallas[i]) // "bornce", "plata", "oro"
     }
   < src..

   La alternativa seria calamitosa. Si @c(len) devuelve un numero sin signo,
   entonces @c(i) tambien seria un @c(uint), y la condicion @c(i >= 0) siempre
   seria verdadera por definicion. Despues de la tercera iteracion, en la cual
   @c(i == 0), la instruccion @c(i--) no haria que @c(i) se volviera -1, en
   cambio seria el valor maximo de @c(uint) (es decir, 2⁶⁴-1), y la evaluacion
   de @c(medallas[i]) fallaria en tiempo de ejecucion, o entraria en @e(panico)
   @%l(#Seccion 5.9<>§5.9), al tratar de acceder a un elemento fuera de los
   limites del slice.

   Por esta razon, los numeros sin signo tienden a utilizarse solo cuando se
   requieren sus operadores bit a bit u operadores aritmeticos peculiares, como
   cuando se implementan conjuntos de bits, se analizan formatos binarios de
   archivos o se usan hash y criptografia. Normalmente no se usan para
   cantidades meramente no negativas.

   En general, se requiere una conversion explicita para convertir un valor de
   un tipo a otro, y los operadores binarios de aritmetica y logica (excepto
   los desplazamientos) deben tener operandos del mismo tipo. Aunque esto
   resulta ocasionalmente en expresiones mas largas, tambien elimina toda una
   clase de problemas y facilita la comprension de los programas.

   Como un ejemplo familiar de otros contextos, considere esta secuencia:

   ..src > go
     var manzanas int32 = 1
     var naranjas int16 = 2
     var compota int = manzanas + naranjas // Error de compiacion
   < src..

   Intentar compilar estas tres declaraciones genera un mensaje de error:

   ..pre >
     invalid operation: manzanas + naranjas (mismatched types int32 and int16)
   < pre..

   Este tipo de incompatibilidad se puede corregir de varias maneras, mas
   directamente convirtiendo todo a un tipo comun:

   ..src > go
     var compota = int(manzanas) + int(naranjas)
   < src..

   Como se describe en la @l(#Seccion 2.5), para cada tipo @c(T), la operacion
   de conversion @c[T(x)] convierte el valor @c(x) a tipo @c(T) si se permite la
   conversion. Muchas conversiones de entero a entero no implican ningun cambio
   en el valor; solo le dicen al compilador como interpretar un valor. Pero una
   conversion que reduce un entero grande a uno mas pequeño o una conversion de
   entero a punto flotante o viceversa, puede cambiar el valor o perder
   precision:

   ..src > go
     f := 3.141          // un float64
     i := int(f)
     fmt.Println(f, i)   // "3.141 3"
     f = 1.99
     fmt.Println(int(f)) // "1"
   < src..

   La conversion de float a entero descarta cualquier parte fraccional,
   truncando hacia cero. Debe evitar las conversiones en las que el operando
   este fuera del rango del tipo destino, ya que el comportamiento depende de la
   implementacion:

   ..src > go
     f := 1e100  // un float64
     i := int(f) // el resultado depende de la implementacion
   < src..

   Los literales enteros de cualquier tamaño y tipo se pueden escribir como
   numeros decimales ordinarios, o bien con numeros octales si comienzan con
   @c(0), como en @c(0666), o como hexadecimal si comienzan con @c(0x) o @c(0X),
   como en @c(0xdeadbeef). Los digitos hexadecimales pueden ser mayusculas o
   minusculas. Hoy en dia los numeros octales parecen ser utilizados para
   exactamente un proposito–permisos de archivo en sistemas POSIX–pero los
   numeros hexadecimales se utilizan ampliamente para enfatizar el patron de
   bits de un numero sobre su valor numerico.

   Al imprimir numeros usando el paquete @c(fmt), podemos controlar la base y el
   formato con los verbos @c(%d), @c(%o), y @c(%x), como se muestra en este
   ejemplo:

   ..src > go
     o := 0666
     fmt.Printf("%d %[1]o %#[1]o\n", o) // "438 666 0666"
     x := int64(0xdeadbeef)
     fmt.Printf("%d %[1]x %#[1]x %#[1]X\n", x)
     // Salida:
     // 3735928559 deadbeef 0xdeadbeef 0XDEADBEEF
   < src..

   Observe el uso de dos trucos de @c(fmt). Por lo general, una cadena de
   formato @c(Printf) que contiene multiples verbos @c(%) requeriria el mismo
   numero de operandos adicionales, pero los @"(adverbios) @c([1]) despues de
   @c(%) le indican a @c(Printf) utilizar el primer operando una y otra vez. En
   segundo lugar, el adverbio @c(#) en @c(%o) o @c(%x) o @c(%X) indica a
   @c(Printf) emitir un prefijo @c(0) o @c(0x) o @c(0X) respectivamente.

   Las literales de runa se escriben como un caracter entre comillas simples.
   El ejemplo mas simple es un caracter ASCII como @c('a'), pero es posible
   escribir cualquier punto de codigo Unicode directamente o con escapes
   numericos, como veremos en breve.

   Las runas se imprimen con @c(%c), o con @c(%q) si se desea citar:

   ..src > go
     ascii := 'a'
     unicode := '𢉩'
     newline := '\n'
     fmt.Printf("%d %[1]c %[1]q\n", ascii)   // "97 a 'a'"
     fmt.Printf("%d %[1]c %[1]q\n", unicode) // "22269 𢉩 '𢉩'"
     fmt.Printf("%d %[1]q\n", newline)       // "10 '\n'"
   < src..

** Seccion 3.2 <> Numeros de punto flotante

   Go ofrece dos tamaños de numeros de punto flotante, @c(float32) y
   @c(float64). Sus propiedades aritmeticas se rigen por el estandar IEEE 754
   implementado por todas las CPUs modernas.

   Los valores de estos tipos numericos varian de pequeño a enorme. Los limites
   de los valores de coma flotante se pueden encontrar en el paquete @c(math). La
   constante @c(math.MaxFloat32), el mayor valor de @c(float32), es cerca de
   @c(3.4e38) y @c(math.MaxFloat64) es @c(1.8e308). Los valores positivos mas
   pequeños son @c(1.4e-45) y @c(4.9e-324), respectivamente.

   Un @c(float32) proporciona aproximadamente seis digitos decimales de
   precision, mientras que un @c(float64) proporciona alrededor de 15 digitos;
   @c(float64) debe ser preferido para la mayoria de los propositos porque los
   calculos sobre @c(float32) acumulan errores rapidamente a menos que sea
   bastante cuidadoso, y el numero entero positivo mas pequeño que no se puede
   representar exactamente como @c(float32) no es grande:

   ..src > go
     var f float32 = 16777216 // 1 << 24
     fmt.Println(f == f+1)    // "true"!
   < src..

   Los numeros de punto flotante se pueden escribir literalmente usando
   decimales, asi:

   ..src > go
     const e = 2.71828 // (aproximadamente)
   < src..

   Pueden omitirse los digitos antes del punto decimal @%c(.707) o despues de
   el @%c(1.). Es mejor escribir numeros muy pequeños o muy grandes en notacion
   cientifica, con la letra @c(e) o @c(E) precediendo al exponente decimal:

   ..src > go
     const Avogadro = 6.02214129e23
     const Planck   = 6.62606957e-34
   < src..

   Los Valores de coma flotante se imprimen convenientemente con el verbo @c(%g)
   de @c(Printf), que elige la representacion mas compacta con la precision
   adecuada, pero para las tablas de datos, es mas adecuado el formato @c(%e)
   (exponente) o %f (sin exponente). Los tres verbos permiten controlar el ancho
   del campo y la precision numerica.

   ..src > go
     for x := 0; x < 8; x++ {
       fmt.Printf("x = %d eˣ = %8.3f\n", x, math.Exp(float64(x)))
     }
   < src..

   El codigo anterior imprime las potencias de @e(e) con tres digitos decimales
   de precision, alineados en un campo de ocho caracteres:

   ..pre >
     x = 0 eˣ =    1.000
     x = 1 eˣ =    2.718
     x = 2 eˣ =    7.389
     x = 3 eˣ =   20.086
     x = 4 eˣ =   54.598
     x = 5 eˣ =  148.413
     x = 6 eˣ =  403.429
     x = 7 eˣ = 1096.633

   Ademas de una gran coleccion de las funciones matematicas comunes, el paquete
   @c(math) tiene funciones para crear y detectar los valores especiales
   definidos por IEEE 754: los infinitos positivo y negativo, que representan
   los numeros de magnitud excesiva y el resultado de la division por cero; y
   NaN @%"(not a number), el resultado de operaciones matematicamente dudosas
   como @c(0/0) o @c[Sqrt(-1)].

   ..src > go
     var z float64
     fmt.Println(z, -z, 1/z, -1/z, z/z) // "0 -0 +Inf -Inf NaN"
   < src..

   La funcion @c(math.IsNaN) prueba si su argumento es un valor no-numerico, y
   @c(math.NaN) devuelve ese valor. Es tentador utilizar NaN como un valor
   centinela en un calculo numerico, pero probar si el resultado de un calculo
   especifico es igual a NaN esta lleno de peligros, ya que cualquier comparacion
   con NaN @e(siempre) produce @c(false) (exepto @c(!=), que es siempre la
   negacion de @c(==)):

   ..src > go
     nan := math.NaN()
     fmt.Println(nan == nan, nan < nan, nan > nan) // "false false false"
   < src..

   Si una funcion que devuelve un resultado de coma flotante puede fallar, es
   mejor informar el error por separado, como aqui:

   ..src > go
     func compute() (value float64, ok bool) {
       // ...
       if failed {
         return 0, false
       }
       return result, true
     }
   < src..

   El siguiente programa ilustra el calculo de graficos en coma flotante. Se
   traza una funcion de dos variables @c[z = f(x, y)] como una superficie de
   malla de alambre 3-D, utilizando graficos vectoriales escalables (SVG), en
   notacion XML estandar para dibujos lineales. La Figura 3.1 muestra un ejemplo
   de salida de la funcion @c[sin(r)/r], donde @c(r) es @c[sqrt(x*x+y*y)].

   ..figure > Figura 3.1. Un grafico superficial de la funcion @c[sin(r)/r].

     ..img > img/Figure-3.1.jpg

   ..figure > @l(gopl.io/ch3/surface/main.go<>gopl.io/ch3/surface)

     ..src > go
       // Surface calcula una representacion SVG de una funcion de superficie 3D
       package main

       import (
         "fmt"
         "math"
       )

       const (
         width, height = 600, 320            // tamaño de la superficie en pixeles
         cells         = 100                 // numero de celdas de la cuadricula
         xyrange       = 30.0                // ejes (-xyrange..+xyrange)
         xyscale       = width / 2 / xyrange // pixeles por unidad x o y
         zscale        = height * 0.4        // pixeles por unidad z
         angle         = math.Pi / 6         // angulo de ejes x, y (=30°)
       )

       var sin30, cos30 = math.Sin(angle), math.Cos(angle) // sin(30°), cos(30°)

       func main() {
         fmt.Printf("<svg xmlns='http://www.w3.org/2000/svg' "+
           "style='stroke: grey; fill: white; stroke-width: 0.7' "+
           "width='%d' height='%d'>", width, height)
         for i := 0; i < cells; i++ {
           for j := 0; j < cells; j++ {
             ax, ay := corner(i+1, j)
             bx, by := corner(i, j)
             cx, cy := corner(i, j+1)
             dx, dy := corner(i+1, j+1)
             fmt.Printf("<polygon points='%g,%g %g,%g %g,%g %g,%g'/>\n",
               ax, ay, bx, by, cx, cy, dx, dy)
           }
         }
         fmt.Println("</svg>")
       }

       func corner(i, j int) (float64, float64) {
         // Hallar el punto (x,y) en la esquina de la celda (i,j).
         x := xyrange * (float64(i)/cells - 0.5)
         y := xyrange * (float64(j)/cells - 0.5)

         // Calcular la altura de la superficie z.
         z := f(x, y)

         // Proyeccion isometrica (x,y,z) sobre superficie SVG 2-D (sx,sy).
         sx := width/2 + (x-y)*cos30*xyscale
         sy := height/2 + (x+y)*sin30*xyscale - z*zscale
         return sx, sy
       }

       func f(x, y float64) float64 {
         r := math.Hypot(x, y) // distancia de (0,0)
         return math.Sin(r) / r
       }
     < src..


   Observe que la funcion @c(corner) devuelve dos valores, las coordenadas de la
   esquina de la celda.

   La explicacion de como funciona el programa requiere solo geometria basica,
   pero esta bien pasarla por alto, ya que el punto es ilustrar el calculo
   de coma flotante. La esencia del programa es el mapeo entre tres sistemas de
   coordenadas diferentes, como se muestra en la Figura 3.2. La primera es una
   red en 2D de 100 y 100 celdas identificadas por coordenadas enteras @m[(i,
   j)], a partir de @m[(0, 0)] en la esquina posterior. Trazamos de atras hacia
   adelante para que los poligonos del fondo puedan ser oscurecidos por los
   de primeros plano.

   El segundo sistema de coordenadas es una malla de coordenadas 3-D de punto
   flotante @m[(x, y, z)], donde @m(x) e @m(y) son funciones lineales de @m(i) y
   @m(j), traducido de manera que el origen esta en el centro, y escalado por la
   constante @c(xyrange). La altura @m(z) es el valor de la funcion de
   superficie @m[ƒ(x, y)].

   El tercer sistema de coordenadas es la superficie 2-D de la imagen, con
   @m[(0, 0)] en la esquina superior izquierda. Los puntos en este plano se
   denotan @m[(sx, sy)]. Utilizamos una proyeccion isometrica para mapear
   cada punto en 3D

   ..figure > Figura 3.2. Tres sistemas de coordenadas diferentes.

     ..img > img/Figure-3.2.jpg


   @m[(x, y, z)] sobre la superficie 2-D. Un punto aparece mas a la derecha en
   la superficie cuanto mayor sea su valor @m(x) o menor sea su valor @m(y). Y
   un punto aparece mas abajo en la superficie cuanto mayor sera su valor @m(x)
   o el valor @m(y), y cuanto menor sea su valor @m(z). Los factores de escala
   horizontal o vertical para @m(x) y @m(y) se derivan del seno y coseno de un
   angulo de 30°. El factor de escala para @m(z), 0.4, es un parametro
   arbitrario.

   Para cada celda de la cuadricula 2-D, la funcion principal calcula las
   coordenadas en la superficie de imagen de las cuatro esquinas del poligono
   ABCD, donde B corresponde a @m[(i, j)] y A, C, y D son sus vecinos, entonces
   imprime una instruccion SVG para dibujarlo.

   @b(Ejercicio 3.1): Si la funcion @c(f) devuelve un valor @c(float64)
   no-finito, el archivo SVG contendra elementos @c(<polygon>) no validos
   (aunque muchos procesadores SVG manejan esto con gracia). Modifique el
   programa para omitir poligonos no validos.

   @b(Ejercicio 3.2): Experimente con visualizaciones de otras funciones del
   paquete @c(math). ¿Puede usted producir una caja de huevos, moguls, o una
   montura?

   @b(Ejercicio 3.3): Coloree cada poligono en funcion de su altura, por lo que
   los picos son de color rojo (@c(#ff0000)) y los valles azul (@c(#0000ff)).

   @b(Ejercicio 3.4): Siguiendo el enfoque del ejemplo Lissajous en la
   @l(#Seccion 1.7), construya un servidor web que calcule superficies y escriba
   los datos SVG al cliente. El servidor debe establecer el encabezado
   @c(Content-Type) de esta manera:

   ..src > go
     w.Header().Set("Content-Type", "image/svg+xml")
   < src..

   (Este paso no era necesario en el ejemplo Lissajous porque el servidor
   utiliza la heuristica estandar para reconocer formatos comunes como PNG de
   los primeros 512 bytes de la respuesta y generar el encabezado
   adecuado.) Permitir al cliente especificar valores como altura, ancho y color
   como parametros de la peticion HTTP.

** Seccion 3.3 <> Numeros complejos

   Go proporciona dos tamaños de numeros complejos, @c(complex64) y
   @c(complex128), cuyos componentes son @c(float32) y @c(float64)
   respectivamente. La funcion nativa @c(complex) crea un numero complejo a
   partir de sus componentes real e imaginario, e incorpora las funciones
   @c(real) e @c(imag) para extraer estos componentes:

   ..src > go
     var x complex128 = complex(1, 2) // 1+2i
     var y complex128 = complex(3, 4) // 3+4i
     fmt.Println(x*y)                 // "(-5+10i)"
     fmt.Println(real(x*y))           // "-5"
     fmt.Println(imag(x*y))           // "10"
   < src..

   Si un literal de punto flotante entero o decimal literal es seguido
   inmediatamente por @c(i), como @c(3.141592i) o @c(2i), se convierte en un
   literal imaginario, que denota un numero complejo con un componente real
   cero:

   ..src > go
     fmt.Println(1i * 1i) // "(-1+0i)", i² = -1
   < src..

   Bajo las reglas de la aritmetica de constantes, las constantes complejas pueden
   sumarse a otras constantes (enteras o de coma flotante, real o imaginarias),
   lo que nos permite escribir numeros complejos de forma natural, como
   @c(1+2i), o equivalentemente, @c(2i+1). Las declaraciones anteriores @c(x) y
   @c(y) pueden simplificarse:

   ..src > go
     x := 1 + 2i
     y := 3 + 4i
   < src..

   Los numeros complejos se pueden comparar por igualdad con @c(==) y @c(!=).
   Dos numeros complejos son iguales si sus partes reales son iguales y sus
   partes imaginarias son iguales.

   El paquete @c(math/cmplx) proporciona funciones de libreria para trabajar con
   numeros complejos, como la raiz cuadrada compleja y funciones de
   exponenciacion.

   ..src > go
     fmt.Println(cmplx.Sqrt(-1)) // "(0+1i)"
   < src..

   El siguiente programa utiliza aritmetica @c(complex128) para generar un
   conjunto de Mandelbrot.

   ..figure > @l(gopl.io/ch3/mandelbrot/main.go<>gopl.io/ch3/mandelbrot)

     ..src > go
       // Mandelbrot emite una imagen PNG del fractal de Mandelbrot.
       package main

       import (
         "image"
         "image/color"
         "image/png"
         "math/cmplx"
         "os"
       )

       func main() {
         const (
           xmin, ymin, xmax, ymax = -2, -2, +2, +2
           width, height          = 1024, 1024
         )

         img := image.NewRGBA(image.Rect(0, 0, width, height))
         for py := 0; py < height; py++ {
           y := float64(py)/height*(ymax-ymin) + ymin
           for px := 0; px < width; px++ {
             x := float64(px)/width*(xmax-xmin) + xmin
             z := complex(x, y)
             // El punto de imagen (px, py) representa el valor complejo z.
             img.Set(px, py, mandelbrot(z))
           }
         }
         png.Encode(os.Stdout, img) // NOTA: ignorando errores
       }

       func mandelbrot(z complex128) color.Color {
         const iterations = 200
         const contrast = 15

         var v complex128
         for n := uint8(0); n < iterations; n++ {
           v = v*v + z
           if cmplx.Abs(v) > 2 {
             return color.Gray{255 - contrast*n}
           }
         }
         return color.Black
       }
     < src..


   Los dos bucles anidados iteran sobre cada punto en una imagen rasterizada en
   escala de grises de 1024x1024 que representa la porcion de -2 a +2 del plano
   complejo. El programa prueba repetidamente si al cuadrar y sumar el numero
   que ese punto representa eventualmente @"(escapa) del circulo de radio 2. Si
   es asi, el punto es sombreado por el numero de iteraciones que se tardo en
   escapar. Si no, el valor pertenece al conjunto de Mandelbrot, y el punto
   permanece negro. Finalmente, el programa escribe en su salida estandar la
   imagen codificada en PNG del iconico fractal, que se muestra en la Figura
   3.3.

   ..figure > Figura 3.3. El conjunto de Mandelbrot.

     ..img > img/Figure-3.3.jpg


   @b(Ejercicio 3.5): Implementar a todo color el cojunto de Mandelbrot usando
   la funcion @c(image.NewRGBA) y el tipo @c(color.RGBA) o @c(color.YCbCr).

   @b(Ejercicio 3.6): Supermuestreo es una tecnica para reducir el efecto de
   pixelacion calculando el valor del color en varios puntos dentro de cada
   pixel y tomando el promedio. El metodo mas simple consiste en dividir cada
   pixel en cuatro @"(subpixeles). Implementalo.

   @b(Ejercicio 3.7): Otro fractal sencillo utiliza el metodo Newton para
   encontrar soluciones complejas a una funcion como @m(z⁴-1 = 0). Sombrea cada
   punto de partida por el numero de iteraciones necesarias para acercarse a una
   de las cuatro raices. Colorea cada punto por la raiz que se aproxime.

   @b(Ejercicio 3.8): La representacion de fractales con altos niveles de zoom
   exige una gran precision aritmetica. Implementa el mismo fractal utilizando
   cuatro representaciones diferentes de numeros: @c(complex64), @c(complex128),
   @c(big.Float), y @c(big.Rat). (Los ultimos dos tipos se encuentran en el
   paquete @c(math/big). @c(Float) utiliza precision arbitraria, pero delimitada
   de punto flotante; @c(Rat) utiliza numeros racionales sin limites de
   precision.)  ¿Como se comparan en el rendimiento y uso de memoria? ¿A que
   niveles de zoom se hacen visibles los artefactos de renderizacion?

   @b(Ejercicio 3.9): Escriba un servidor web que procese fractales y escriba
   los datos de imagen al cliente. Permita que el cliente especifique las
   coordenadas @c(x), @c(y), y los valores de zoom como parametros en la
   peticion HTTP.

** Seccion 3.4 <> Booleanos

   Un valor de tipo @c(bool), o @e(booleano), tiene solo dos valores posibles,
   @c(true) y @c(false). Las condiciones en @c(if) y @c(for) son declaraciones
   booleanas, y los operadores de comparacion como @c(==) y @c(<) producen un
   resultado booleano. El operador unario @c(!) es la negacion logica, de modo
   que @c(!true) es @c(false), o, por decirlo asi, @c[(!true==false)==true],
   aunque por cuestion de estilo, siempre simplificamos las expresiones
   booleanas redundantes como @c(x==true) a @c(x).

   Los valores booleanos pueden ser combinados con los operadores @c(&&) (AND) y
   @c(||) (OR), que tienen un comportamiento de @e(cortocircuito): si la
   respuesta ya esta determinada por el valor del operando de la izquierda, el
   operando de la derecha no se evalua, por lo que es seguro escribir
   expresiones como esta:

   ..src > go
     s != "" && s[0] == 'x'
   < src..

   donde @c(s[0]) produciria un panico si se aplica a una cadena vacia.

   Ya que @c(&&) tiene mayor precedencia que @c(||) (mnemotecnico: @c(&&) es la
   multiplicacion booleana, @c(||) es la suma boolean), no se requieren
   parentesis para las condiciones de esta forma:

   ..src > go
     if 'a' <= c && c <= 'z' ||
        'A' <= c && c <= 'Z' ||
        '0' <= c && c <= '9' {
        // ...letra o digito ASCII...
     }
   < src..

   No hay una conversion implicita de un valor booleano a un valor numerico como
   0 o 1, o viceversa. Es necesario utilizar un @c(if) explicito, como

   ..src > go
     i := 0
     if b {
       i = 1
     }
   < src..

   Podria valer la pena escribir una funcion de conversion si esta operacion se
   necesitara a menudo:

   ..src > go
     // btoi regresa 1 si b es verdadero y 0 sy es falso.
     func btoi(b bool) int {
       if b {
         return 1
       }
       return 0
     }
   < src..

   La operacion inversa es tan simple que no necesita una funcion, pero por
   simetria aqui esta:

   ..src > go
     // itob informa cuando i no es cero.
     func itob(i int) bool { return i != 0 }
   < src..

** Seccion 3.5 <> Cadenas

   Una cadena es una secuencia inmutable de bytes. Las cadenas pueden contener
   datos arbitrarios, incluyendo bytes con valor 0, pero normalmente contienen
   texto legible por humanos. Las cadenas de texto se interpretan de forma
   convencional como secuencias codificadas en UTF-8 de puntos de codigo Unicode
   (runas), que exploraremos en detalle muy pronto.

   La funcion nativa @c(len) devuelve el numero de bytes (no runas) en una
   cadena, y la operacion de indice @c(s[i]) recupera el @m(n)-esimo byte de la
   cadena @c(s), donde @c(0) ≤ @c(i) < @c[len(s)].

   ..src > go
     s := "hello, world"
     fmt.Println(len(s))     // "12"
     fmt.Println(s[0], s[7]) // "104 119"  ('h' y 'w')
   < src..

   Intentar acceder a un byte fuera de este rango produce un panico:

   ..src > go
     c := s[len(s)] // panico: indice fuera de rango
   < src..

   El @m(n)-esimo byte de una cadena no es necesariamente el @m(n)-esimo
   caracter de una cadena, porque la codificacion UTF-8 de un punto de codigo no
   ASCII requiere dos o mas bytes. Como trabajar con caracteres se discutira en
   breve.

   La operacion de subcadena @c(s[i:j]) produce una nueva cadena que consta de
   los bytes de la cadena original a partir del indice @c(i) y continua hasta,
   pero sin incluir, el byte en el indice @c(j). El resultado contiene @c(j-i)
   bytes.

   ..src > go
     fmt.Println(s[0:5]) // "hello"
   < src..

   De nuevo, se produce un panico si cualquiera de los indices esta fuera de
   limite o si @c(j) es menor que @c(i).

   Puede omitirse cualquiera o ambos operandos @c(i) y @c(j), en cuyo caso los
   valores por defecto son 0 (el inicio de la cadena) y @c[len(s)] (su final),
   respectivamente.

   ..src > go
     fmt.Println(s[:5]) // "hello"
     fmt.Println(s[7:]) // "world"
     fmt.Println(s[:])  // "hello, world"
   < src..

   El operador c(+) crea una nueva cadena concatenando dos cadenas:

   ..src > go
     fmt.Println("goodbye" + s[5:]) // "goodbye, world"
   < src..

   Las cadenas pueden compararse con los operadores de comparacion como @c(==) y
   @c(<); la comparacion se realiza byte a byte, por lo que el resultado es el
   ordenamiento lexicografico natural.

   Los valores de cadena son inmutables: la secuencia de bytes contenidos en un
   valor de cadena no se puede cambiar, aunque, por supuesto, podemos asignar un
   nuevo valor a una variable de cadena. Para añadir una cadena a otra, por
   ejemplo, podemos escribir

   ..src > go
     s := "pie izquierdo"
     t := s
     s += ", pie derecho"
   < src..

   Esto no modifica la cadena que retenia @c(s) originalmente, pero hace que
   @c(s) contenga la nueva cadena formada por la sentencia @c(+=); mientras
   tanto, @c(t) aun contiene la cadena antigua.

   ..src > go
     fmt.Println(s) // "pie izquierdo, pie derecho"
     fmt.Println(t) // "pie izquierdo"
   < src..

   Dado que las cadenas son inmutables, no se permiten las construcciones que
   intentan modificar los datos de una cadena en el lugar:

   ..src > go
     s[0] = 'L' // error de compilacion: no se puede asignar a s[0]
   < src..

   Inmutabilidad significa que es seguro que dos copias de una cadena compartan
   la misma memoria subyacente, por lo que es barato copiar cadenas de cualquier
   longitud. Del mismo modo, una cadena @c(s) y una subcadena como @c(s[7:])
   pueden compartir de forma segura los mismos datos, por lo que la operacion de
   subcadena tambien es barata. No se asigna nueva memoria en ningun
   caso. La Figura 3.4 ilustra la disposicion de una cadena y dos de sus
   subcadenas que comparten el mismo arreglo de bytes subyacente.

   ..figure > Figura 3.4. La cadena @c("hello, world") y dos subcadenas.

     ..img > img/Figure-3.4.jpg

*** Seccion 3.5.1 <> Cadenas Literales

    Un valor de cadena se puede escribir como una @e(cadena literal), una
    secuencia de bytes entre comillas dobles:

    ..src > go
      "Hello, 世界"
    < src..

    Debido a que los archivos fuente de Go siempre estan codificados en UTF-8 y
    las cadenas de texto Go son interpretadas convencionalmente como UTF-8,
    podemos incluir puntos de codigo Unicode en literales de cadena.

    Dentro de una literal de cadena entre comillas dobles, las @e(secuencias de
    escape) que comienzan con una barra invertida @c(\) se pueden utilizar para
    insertar valores arbitrarios de bytes en la cadena. Un conjunto de escape
    maneja codigos de control ASCII como nueva linea, retorno de carro y tabulacion:

    +--------+--------------------------------------------------+
    | @c(\a) | @"(alerta) o campana                             |
    +--------+--------------------------------------------------+
    | @c(\b) | retroceso                                        |
    +--------+--------------------------------------------------+
    | @c(\f) | form feed                                        |
    +--------+--------------------------------------------------+
    | @c(\n) | linea nueva                                      |
    +--------+--------------------------------------------------+
    | @c(\r) | retorno de carro                                 |
    +--------+--------------------------------------------------+
    | @c(\t) | tabulador                                        |
    +--------+--------------------------------------------------+
    | @c(\v) | tabulador vertical                               |
    +--------+--------------------------------------------------+
    | @c(\') | comilla simple (solo en la runa literal '\'')    |
    +--------+--------------------------------------------------+
    | @c(\") | comillas dobles (solo dentro de "..." literales) |
    +--------+--------------------------------------------------+
    | @c(\\) | barra invertida                                  |
    +--------+--------------------------------------------------+

    Tambien se pueden incluir bytes arbitrarios en cadenas literales usando
    escapes hexadecimales u octales. Un escape hexadecimal se escribe
    @c(\x)@e(hh), con exactamente dos digitos hexadecimales @e(h) (en mayusculas
    o minusculas). Un escape octal se escribe @e(\ooo) con exactamente tres
    digitos octales @e(o) (0 a 7) no superior a @c(\377). Ambos denotan un solo
    byte con el valor especificado. Mas adelante, veremos como codificar
    numericamente los puntos de codigo Unicode en literales de cadena.

    Una @e(literal de cadena sin formato) se escribe @c(`...`), utilizando
    comillas inversas en lugar de comillas dobles. Dentro de una literal de
    cadena sin formato, no se procesan secuencias de escape; los contenidos se
    toman literalmente, incluyendo barras invertidas y lineas nuevas, por lo que
    un literal de cadena sin formato puede extenderse por varias lineas en el
    codigo del programa. El unico procesamiento es que los retornos de carro se
    eliminan para que el valor de la cadena sea el mismo en todas las
    plataformas, incluidas aquellas que convencionalmente ponen retornos de
    carro en archivos de texto.

    Las literales de cadena sin formato son una manera conveniente de escribir
    expresiones regulares, que tienden a tener un monton de barras inversas.
    Tambien son utiles para plantillas HTML, literales JSON, mensajes de uso de
    comandos y similares, que a menudo se extienden sobre varias lineas.

    ..src > go
      const GoUsage = `Go is a tool for managing Go source code.

      Usage:
          go command [arguments]
      ...`
    < src..

*** Seccion 3.5.2 <> Unicode

    Hace mucho tiempo, la vida era simple y habia, por lo menos en una vision
    parroquial, solo un conjunto de caracteres a manejar: ASCII, el codigo
    estandar americano para el intercambio de la informacion @%e(American
    Standard Code for Information Interchange). ASCII, o mas precisamente
    US-ASCII, utiliza 7 bits para representar 128 @"(caracteres): las letras
    mayusculas y minusculas del ingles, digitos y una variedad de caracteres de
    puntuacion y control de dispositivo. Durante gran parte de los primeros dias
    de la informatica, esto fue adecuado, pero dejo a una gran parte de la
    poblacion mundial incapaz de utilizar sus propios sistemas de escritura en
    las computadoras. Con el crecimiento de Internet, los datos en innumerables
    idiomas se han vuelto mucho mas comunes. ¿Como puede manejarse esta rica
    variedad y, si es posible, de forma eficiente?

    La respuesta es Unicode @%l(http://unicode.org/<>unicode.org), que recoge
    todos los caracteres de todos los sistemas de escritura del mundo, ademas de
    acentos y otros signos diacriticos, codigos de control como tabulador y
    retorno de carro, y mucha esoterica, y asigna a cada uno un numero
    estandar denominado @e(punto de codigo Unicode) o, en la terminologia Go,
    una runa.

    Unicode version 8 define puntos de codigo para mas de 120.000 caracteres en
    mas de 100 idiomas y escrituras. ¿Como se representan en los datos y
    programas de computadora? El tipo de datos naturales para almacenar una sola
    runa es @c(int32), y eso es lo que utiliza Go; tiene el sinonimo @c(rune)
    precisamente para este proposito.

    Podriamos representar una secuencia de runas como una secuencia de valores
    @c(int32). Esta representacion, se llama UTF-32 o UCS-4, la codificacion de
    cada punto de codigo Unicode tiene el mismo tamaño, 32 bits. Esto es simple
    y uniforme, pero utiliza mucho mas espacio de lo necesario, ya que la
    mayoria del texto legible por computadora esta en ASCII, que requiere solo 8
    bits o 1 byte por caracter. Todos los caracteres de uso generalizado siguen
    siendo menos de 65.536, que cabrian en 16 bits. ¿Podemos hacerlo mejor?

*** Seccion 3.5.3 <> UTF-8

    UTF-8 es una codificacion de longitud variable de puntos de codigo Unicode
    como bytes. UTF-8 fue inventado por Ken Thompson y Rob Pike, dos de los
    creadores de Go, y ahora es un estandar Unicode. Utiliza entre 1 y 4 bytes
    para representar cada runa, pero solo 1 byte para caracteres ASCII y solo 2
    o 3 bytes para la mayoria de las runas en uso comun. Los bits de orden alto del
    primer byte de la codificacion de una runa indican cuantos bytes siguen. Un
    alto orden 0 indica ASCII de 7 bits, donde cada runa toma solo 1 byte, por
    lo que es identica a ASCII convencional. Un alto orden @c(110) indica que la
    runa toma 2 bytes; el segundo byte comienza con @c(10). Las runas mas
    grandes tienen codificaciones analogas.

    +----------------------------------------+----------------+-------------------------------+
    | @c(0xxxxxx)                            | runas 0−127    | (ASCII)                       |
    +----------------------------------------+----------------+-------------------------------+
    | @c(110xxxx 10xxxxxx)                   | 128−2047       | (valores <128 no utilizados)  |
    +----------------------------------------+----------------+-------------------------------+
    | @c(1110xxx 10xxxxxx 10xxxxxx)          | 2048−65535     | (valores <2048 no utilizados) |
    +----------------------------------------+----------------+-------------------------------+
    | @c(11110xx 10xxxxxx 10xxxxxx 10xxxxxx) | 65536−0x10ffff | (otros valores no utiliados)  |
    +----------------------------------------+----------------+-------------------------------+

    Una codificacion de longitud variable impide la indexacion directa para
    acceder al @m(n)-esimo caracter de una cadena, pero UTF-8 tiene muchas
    propiedades deseables para compensar. La codificacion es compacta,
    compatible con ASCII y auto-sincronizada: es posible encontrar el inicio de
    un caracter respaldando no mas de tres bytes. Tambien es un codigo de
    prefijo, por lo que se puede decodificar de izquierda a derecha sin ninguna
    ambigüedad o lookahead. La codificacion de una runa no es una subcadena de
    ninguna otra, ni siquiera de una secuencia de otras, por lo que puedes
    buscar una runa simplemente buscando sus bytes, sin preocuparte por el
    contexto anterior. El orden lexicografico de bytes es igual al orden de los
    puntos de codigo Unicode, por lo que la ordenacion de UTF-8 funciona de
    forma natural. No hay bytes NUL (cero) incrustados, que es conveniente
    para los lenguajes de programacion que utilizan NUL para terminar cadenas.

    Los archivos de codigo fuente de Go siempre estan codificados en UTF-8 y
    UTF-8 es la codificacion preferida para las cadenas de texto manipuladas por
    los programas Go. El paquete @c(unicode) proporciona funciones para trabajar
    con runas individuales (como distinguir letras de numeros, o la conversion
    de una letra mayuscula a una minuscula), y el paquete @c(unicode/utf8)
    proporciona funciones para codificar y decodificar runas como bytes usando
    UTF-8.

    Muchos caracteres Unicode son dificiles de escribir en un teclado o
    distinguir visualmente de otros de similar aspecto; algunos son incluso
    invisibles. Go nos permite el escape de literales Unicode en una cadena
    al especificarlos por su valor numerico. Hay dos formas, @c(\u)@e(hhhh) para
    un valor de 16 bits y @c(\U)@e(hhhhhhhh) para un valor de 32 bits, donde
    cada @e(h) es un digito hexadecimal; la necesidad de la forma de 32 bits se
    presenta con poca frecuencia. Cada uno denota la codificacion UTF-8 del
    punto de codigo especificado. Asi, por ejemplo, los siguientes literales de
    cadena representan la misma cadena de seis bytes:

    ..src > go
      "世界"
      "\xe4\xb8\x96\xe7\x95\x8c"
      "\u4e16\u754c"
      "\U00004e16\U0000754c"
    < src..

    Las tres secuencias de escape anteriores proporcionan notaciones
    alternativas para la primer cadena, pero los valores que denotan son
    identicos. Los escapes Unicode tambien se puede utilizar en runas
    literales. Estos tres literales son equivalentes:

    ..pre >
      '世' '\u4e16' '\U00004e16'

    Una runa cuyo valor es menor que 256 se puede escribir con solo un escape
    hexadecimal, por ejemplo @c('\x41') para @c('A'), pero para los valores mas
    altos, debe utilizar un escape @c(\u) o @c(\U). En consecuencia,
    @c('\xe4\xb8\x96') no es una runa literal legal, a pesar de que esos tres
    bytes son un UTF-8 valido de un unico punto de codigo.

    Gracias a las buenas propiedades de UTF-8, muchas operaciones de cadena no
    requieren decodificacion. Podemos probar si una cadena contiene otra como
    prefijo:

    ..src > go
      func HasPrefix(s, prefix string) bool {
        return len(s) >= len(prefix) && s[:len(prefix)] == prefix
      }
    < src..

    o como sufijo:

    ..src > go
      func HasSuffix(s, suffix string) bool {
        return len(s) >= len(suffix) && s[len(s)-len(suffix):] == suffix
      }
    < src..

    o como una subcadena:

    ..src > go
      func Contains(s, substr string) bool {
        for i := 0; i < len(s); i++ {
          if HasPrefix(s[i:], substr) {
            return true
          }
        }
        return false
      }
    < src..

    utilizando la misma logica para un texto codificado en UTF-8 que para bytes
    sin procesar. Esto no es cierto para otras codificaciones. (Las funciones
    anteriores se han extraido del paquete @c(strings), aunque su implementacion
    de @c(Contains) utiliza una tecnica de hash para buscar de manera mas
    eficiente.)

    Por otro lado, si realmente nos preocupamos por los caracteres Unicode
    individuales, tenemos que usar otros mecanismos. Consideremos la cadena de
    nuestro primer ejemplo, la cual incluye dos caracteres de Asia Oriental. La Figura
    3.5 ilustra su representacion en la memoria. La cadena contiene 13 bytes,
    pero interpretada como UTF-8, codifica solo nueve puntos de codigo o runas:

    ..src > go
      import "unicode/utf8"

      s := "Hello, 世界"
      fmt.Println(len(s))                    // "13"
      fmt.Println(utf8.RuneCountInString(s)) // "9"
    < src..

    Para procesar esos caracteres, necesitamos un decodificador UTF-8. El
    paquete @c(unicode/utf8) proporciona uno que podemos utilizar de la
    siguiente manera:

    ..src > go
      for i := 0; i < len(s); {
        r, size := utf8.DecodeRuneInString(s[i:])
        fmt.Printf("%d\t%c\n", i, r)
        i += size
      }
    < src..

    Cada llamada a @c(DecodeRuneInString) regresa @c(r), la runa en si, y
    @c(size), el numero de bytes ocupados por la codificacion UTF-8 de @c(r). El
    tamaño se utiliza para actualizar el indice del byte @c(i) de la siguiente
    runa en la cadena. Pero esto es torpe, y necesitamos bucles de este tipo
    todo el tiempo. Afortunadamente, Go tiene los bucles @c(range), cuando se
    aplica a una cadena, realiza decodificacion UTF-8 de forma implicita. La
    salida del bucle siguiente se muestra en la Figura 3.5; observe como el
    indice salta en mas de 1 para cada runa no ASCII.

    ..src > go
      for i, r := range "Hello, 世界" {
        fmt.Printf("%d\t%q\t%d\n", i, r, r)
      }
    < src..

    ..figure > Figura 3.5. Un bucle @c(range) descodifica una cadena UTF-8.

      ..img  > img/Figure-3.5.jpg


    Podriamos usar un simple bucle @c(range) para contar el numero de runas en
    una cadena, como aqui:

    ..src > go
      n := 0
      for _, _ = range s {
        n++
      }
    < src..

    Al igual que con las otras formas de bucle @c(range), podemos omitir las
    variables que no necesitamos:

    ..src > go
      n := 0
      for range s {
        n++
      }
    < src..

    O podemos simplemente llamar a @c[utf8.RuneCountInString(s)].

    Ya hemos mencionado que es sobre todo una cuestion de convencion en Go que
    las cadenas de texto se interpretan como secuencias codificadas en UTF-8 de
    puntos de codigo Unicode, pero para el uso correcto de bucles @c(range) de
    cadenas, mas que una convencion, es una necesidad. ¿Que sucede si aplicamos
    @c(range) en una cadena que contiene datos binarios arbitrarios o, de hecho,
    datos UTF-8 con errores?

    Cada vez que un decodificador UTF-8, ya sea explicito en una llamada a
    @c(utf8.DecodeRuneInString) o implicito en un bucle @c(range), consume un
    byte de entrada inesperado, se genera un caracter Unicode de reemplazo
    especial, @c('\uFFFD'), que generalmente se impreme como un signo de
    interrogacion dentro de un hexagono negro o en forma de diamante �. Cuando un
    programa encuentra este valor de runa, a menudo es signo de que parte del
    sistema que genero los datos de cadena ha sido descuidado en su tratamiento
    de las codificaciones de texto.

    UTF-8 es excepcionalmente conveniente como un formato de intercambio, pero
    dentro de un programa las runas puede ser mas convenientes porque son de
    tamaño uniforme y por lo tanto, de facil indexado en arreglos y slices.

    Aplicar una conversion @c([]rune) a una cadena codificada en UTF-8 devuelve
    la secuencia en codigos Unicode:

    ..src > go
      // "programa" en katakana
      s := "プログラム"
      fmt.Printf("% x\n", s) // "e3 83 97 e3 83 ad e3 82 b0 e3 83 a9 e3 83 a0"
      r := []rune(s)
      fmt.Printf("%x\n", r)  // "[30d7 30ed 30b0 30e9 30e0]"
    < src..

    (El verbo @c(% x) en el primer @c(Printf) inserta un espacio entre cada par
    de digitos hexadecimales.)

    Si un slice de runas se convierte en una cadena, produce la concatenacion de
    las codificaciones UTF-8 de cada runa:

    ..src > go
      fmt.Println(string(r)) // "プログラム"
    < src..

    Convertir un valor entero en una cadena interpreta el entero como un valor de
    runa, y produce la representacion UTF-8 de esa runa:

    ..src > go
      fmt.Println(string(65))     // "A", no "65"
      fmt.Println(string(0x4eac)) // "京"
    < src..

    Si la runa no es valida, se reemplasa por el caracter de sustitucion:

    ..src > go
      fmt.Println(string(1234567)) // "�"
    < src..

*** Seccion 3.5.4 <> Cadenas y Slices de Bytes

    Cuatro paquetes estandar son particularmente importantes para la
    manipulacion de cadenas: @c(bytes), @c(strings), @c(strconv) y
    @c(unicode). El paquete @c(strings) ofrece muchas funciones para busqueda,
    reemplazo, comparacion, recorte, division, y union en cadenas.

    El paquete @c(bytes) tiene funciones similares para manipular slices de
    bytes, de tipo @c([]byte), que comparten algunas propiedades con @c(strings).
    Ya que las cadenas son inmutables, la construccion de cadenas de forma
    incremental puede implicar una gran cantidad de asignacion y copiado. En
    tales casos, es mas eficaz utilizar el tipo @c(bytes.Buffer), que
    mostraremos en un momento.

    El paquete @c(strconv) proporciona funciones para convertir valores booleanos,
    enteros, y en coma flotante hacia y desde sus representaciones en
    cadenas, y funciones para citar y des-citar cadenas.

    El paquete @c(unicode) proporciona funciones como @c(IsDigit), @c(IsLetter),
    @c(IsUpper) e @c(IsLower) para la clasificacion de runas. Cada funcion toma
    un unico argumento de tipo runa y devuelve un booleano. Las funciones de
    conversion como @c(ToUpper) y @c(ToLower) convierten una runa en el caso
    concreto si se trata de una letra. Todas estas funciones utilizan las
    categorias estandar de Unicode para las letras, los digitos, etc. El paquete
    @c(strings) tiene funciones similares, tambien llamadas @c(ToUpper) y
    @c(ToLower), que devuelven una nueva cadena con la transformacion
    especificada aplicada a cada caracter de la cadena original.

    La siguiente funcion @c(basename) se inspiro en la utilidad del shell Unix
    del mismo nombre. En nuestra version, @c[basename(s)] elimina cualquier
    prefijo de @c(s) que paresca una ruta de sistema de archivo con componentes
    separados por barras, y elimina cualquier sufijo que parezca un tipo de
    archivo:

    ..src > go
      fmt.Println(basename("a/b/c.go")) // "c"
      fmt.Println(basename("c.d.go"))   // "c.d"
      fmt.Println(basename("abc"))      // "abc"
    < src..

    La primer version de @c(basename) hace todo el trabajo sin la ayuda de
    librerias:

    ..figure > @l(gopl.io/ch3/basename1/main.go<>gopl.io/ch3/basename1)

      ..src > go
        // basename elimina los .subfijos y componentes de directorios.
        // p.ej., a => a, a.go => a, a/b/c.go => c, a/b.c.go => b.c
        func basename(s string) string {
          // Descarta el ultimo '/' y todo lo anterior.
          for i := len(s) - 1; i >= 0; i-- {
            if s[i] == '/' {
              s = s[i+1:]
              break
            }
          }
          // Conserva todo antes del ultimo '.'.
          for i := len(s) - 1; i >= 0; i-- {
            if s[i] == '.' {
              s = s[:i]
              break
            }
          }
          return s
        }
      < src..


    Una version mas simple utiliza la funcion de libreria @c(strings.LastIndex):

    ..figure > @l(gopl.io/ch3/basename2/main.go<>gopl.io/ch3/basename2)

      ..src > go
        func basename(s string) string {
          slash := strings.LastIndex(s, "/") // -1 si no se encuentra "/"
          s = s[slash+1:]
          if dot := strings.LastIndex(s, "."); dot >= 0 {
            s = s[:dot]
          }
          return s
        }
      < src..


    Los paquetes @c(path) y @c(path/filepath) proporcionan un conjunto general
    de funciones para manipular nombres jerarquicos. El paquete @c(path)
    funciona con rutas delimitadas por barras en cualquier plataforma. No se debe
    utilizar para nombres de archivo, pero es apropiado para otros dominios,
    como los componente de ruta de una URL. Por el contrario, @c(path/filepath)
    manipula los nombres de archivos usando las reglas para la plataforma
    huesped, como @c(/foo/bar) para POSIX o @c(c:\foo\bar) en Microsoft Windows.

    Continuaremos con otro ejemplo de subcadena. La tarea es tomar una
    representacion de cadena de un entero, como @c("12345"), e insertar comas
    cada tres posiciones, como en @c("12,345"). Esta version solo funciona para
    enteros; el manejo de numeros de coma flotante se deja como ejercicio.

    ..figure > @l(gopl.io/ch3/comma/main.go<>gopl.io/ch3/comma)

      ..src > go
        // comma inserta comas en una cadena de numeros enteros decimales negativos.
        func comma(s string) string {
          n := len(s)
          if n <= 3 {
            return s
          }
          return comma(s[:n-3]) + "," + s[n-3:]
        }
      < src..


    El argumento de @c(comma) es una cadena. Si su longitud es menor o igual a
    3, no es necesaria una coma. De lo contrario, comma se llama a si misma de
    forma recursiva con una subcadena formada por todos los caracteres menos los
    tres ultimos, y añade una coma y los tres ultimos caracteres en el resultado
    de la llamada recursiva.

    Una cadena contiene un arreglo de bytes que, una vez creado, es inmutable.
    Por el contrario, los elementos de una slice de bytes se pueden modificar
    libremente.

    Las cadenas se pueden convertir en slices de bytes y viceversa:

    ..src > go
      s := "abc"
      b := []byte(s)
      s2 := string(b)
    < src..

    Conceptualmente, la conversion @c{[]byte(s)} asigna un nuevo arreglo de
    bytes que guarda una copia de bytes de @c(s), y produce un slice que hace
    referencia a la totalidad del arreglo. Un compilador optimizado puede ser
    capaz de evitar la asignacion y la copia en algunos casos, pero en general,
    la copia es necesaria para asegurar que los bytes de @c(s) se mantienen sin
    cambios incluso si los de @c(b) son modificados posteriormente. La
    conversion del slice de bytes de nuevo a una cadena con @c[string(b)]
    tambien genera una copia, para asegurar inmutabilidad de la cadena
    resultante @c(s2).

    Para evitar conversiones y asignacion de memoria innecesaria, muchas de las
    funciones de utilidad del paquete @c(bytes) son directamente paralelas a
    sus contrapartes en el paquete @c(strings). Por ejemplo, aqui hay una media
    docena de funciones en @c(strings):

    ..src > go
      func Contains(s, substr string) bool
      func Count(s, sep string) int
      func Fields(s string) []string
      func HasPrefix(s, prefix string) bool
      func Index(s, sep string) int
      func Join(a []string, sep string) string
    < src..

    y las correspondientes en @c(bytes):

    ..src > go
      func Contains(b, subslice []byte) bool
      func Count(s, sep []byte) int
      func Fields(s []byte) [][]byte
      func HasPrefix(s, prefix []byte) bool
      func Index(s, sep []byte) int
      func Join(s [][]byte, sep []byte) []byte
    < src..

    La unica diferencia es que las cadenas han sido reemplazadas por slices de
    bytes.

    El paquete @c(bytes) proporciona el tipo @c(Buffer) para la manipulacion
    eficiente de slices de byte. Un @c(Buffer) comienza vacio, pero crece a
    medida que los datos de tipos como @c(string), @c(byte), y @c([]byte) se
    escriben en el. Como muestra el siguiente ejemplo, una variable
    @c(bytes.Buffer) no requiere inicializacion porque su valor cero es
    utilizable:

    ..figure > @l(gopl.io/ch3/printints/main.go<>gopl.io/ch3/printints)

      ..src > go
        // intsToString es como fmt.Sprint(values) pero agrega comas.
        func intsToString(values []int) string {
          var buf bytes.Buffer
          buf.WriteByte('[')
          for i, v := range values {
            if i > 0 {
              buf.WriteString(", ")
            }
            fmt.Fprintf(&buf, "%d", v)
          }
          buf.WriteByte(']')
          return buf.String()
        }

        func main() {
          fmt.Println(intsToString([]int{1, 2, 3})) // "[1, 2, 3]"
        }
      < src..


    Cuando se agrega la codificacion UTF-8 de un runa arbitraria a un
    @c(bytes.Buffer), lo mejor es utilizar el metodo @c(WriteRune) de
    @c(bytes.Buffer), pero @c(WriteByte) esta bien para caracteres ASCII como
    @c('[') y @c(']').

    El tipo @c(bytes.Buffer) es extremadamente versatil, y cuando hablemos de
    interfaces en el @l(#Capitulo 7), vamos a ver como se puede utilizar como un
    sustituto de un archivo cada vez que una funcion de E/S requiere un poso de
    bytes @%c(io.Writer) como @c(Fprintf), o una fuente de bytes @%c(io.Reader).

   @b(Ejercicio 3.10): Escribir una version no recursiva de @c(comma),
   utilizando @c(bytes.Buffer) en lugar de la concatenacion de cadenas.

   @b(Ejercicio 3.11): Mejorar @c(comma) para que maneje correctamente los
   numeros de punto flotante y opcionalmente con signo.

   @b(Ejercicio 3.12): Escribir una funcion que informe de si dos cadenas son
   anagramas entre si, es decir, que contienen las mismas letras en un orden
   diferente.

*** Seccion 3.5.5 <> Conversiones entre cadenas y numeros

    Ademas de las conversiones entre cadenas, runas y bytes, a menudo es
    necesario convertir entre valores numericos y sus representaciones de
    cadena. Esto se realiza con las funciones del paquete @c(strconv).

    Para convertir un entero a una cadena, una opcion es utilizar @c(fmt.Sprintf);
    otra es utilizar la funcion @c(strconv.Itoa) @%"(integer to ASCII):

    ..src > go
      x := 123
      y := fmt.Sprintf("%d", x)
      fmt.Println(y, strconv.Itoa(x)) // "123 123"
    < src..

    @c(FormatInt) y @c(FormatUint) se pueden utilizar para dar formato a numeros
    en una base diferente:

    ..src > go
      fmt.Println(strconv.FormatInt(int64(x), 2)) // "1111011"
    < src..

    Los verbos @c(%b), @c(%d), @c(%o) y @c(%x) de @c(fmt.Printf) a menudo son
    mas conveniente que las funciones @c(Format), sobre todo si queremos incluir
    informacion adicional ademas del numero:

    ..src > go
      s := fmt.Sprintf("x=%b", x) // "x=1111011"
    < src..

    Para analizar una cadena que representa un numero entero, utilice las
    funciones de @c(strconv) como @c(Atoi) o @c(ParseInt), o @c(ParseUint) para
    enteros sin signo:

    ..src > go
      x, err := strconv.Atoi("123")             // x es un entero
      y, err := strconv.ParseInt("123", 10, 64) // base 10, hasta 64 bits
    < src..

    El tercer argumento de @c(ParseInt) da el tamaño del tipo de entero que debe
    ser el resultado; por ejemplo, 16 implica @c(int16), y el valor especial 0
    implica @c(int) . En cualquier caso, el tipo del resultado @c(y) es siempre
    @c(int64), que luego se puede convertir a un tipo mas pequeño.

    A veces es util @c(fmt.Scanf) para el analisis de entrada que consta de
    mezclas ordenadas de cadenas y numeros todo en una sola linea, pero puede
    ser inflexible, especialmente cuando se maneja una entrada incompleta o
    irregular.

** Seccion 3.6 <> Constantes

   Las constantes son expresiones cuyo valor es conocido por el compilador y
   cuya evaluacion se garantiza que se produzca en tiempo de compilacion, no en
   tiempo de ejecucion. El tipo subyacente de cada constante es un tipo basico:
   booleano, cadena o numero.

   Una declaracion @c(const) define los valores que se ven sintacticamente como
   variables con nombre pero cuyo valor es constante, lo que evita cambios
   accidentales (o nefastos) durante la ejecucion del programa. Por ejemplo, una
   constante es mas apropiada que una variable para una constante matematica
   como @c(pi), ya que su valor no cambiara:

   ..src > go
     const pi = 3.14159 // aproximadamente; math.Pi un una mejor aproximacion
   < src..

   Al igual que con las variables, una secuencia de constantes puede aparecer en
   una declaracion; esto seria apropiado para un grupo de valores relacionados:

   ..src > go
     const (
       e  = 2.71828182845904523536028747135266249775724709369995957496696763
       pi = 3.14159265358979323846264338327950288419716939937510582097494459
     )
   < src..

   Muchos calculos de constantes pueden evaluarse completamente en tiempo de
   compilacion, reduciendo el trabajo necesario en tiempo de ejecucion y
   habilitando otras optimizaciones de compilador. Los errores ordinariamente
   detectados en tiempo de ejecucion pueden ser reportados en tiempo de
   compilacion cuando sus operandos son constantes, como la division entera por
   cero, una cadena de indexacion fuera de limites y cualquier operacion de
   punto flotante que daria lugar a un valor no finito.

   Los resultados de todas las operaciones aritmeticas, logicas y de comparacion
   aplicados a operandos constantes son en si mismos constantes, como son los
   resultados de las conversiones y las llamadas a ciertas funciones nativas
   como @c(len), @c(cap), @c(real), @c(imag), @c(complex), y @c(unsafe.Sizeof)
   @%l(#Seccion 13.1<>§13.1).

   Ya que sus valores son conocidos por el compilador, las expresiones
   constantes pueden aparecer en los tipos, especificamente como la longitud de
   un tipo de arreglo:

   ..src > go
     const IPv4Len = 4

     // parseIPv4 analiza una direccion IPv4 (d.d.d.d).
     func parseIPv4(s string) IP {
       var p [IPv4Len]byte
       // ...
     }
   < src..

   Una declaracion constante puede especificar un tipo asi como un valor, pero en
   ausencia de un tipo explicito, el tipo se infiere de la expresion en el lado
   derecho. En el siguiente ejemplo, @c(time.Duration) es un tipo con nombre
   cuyo tipo subyacente es @c(int64), y @c(time.Minute) es una constante de ese
   tipo. Por lo tanto las dos constantes declaradas a continuacion tienen el
   tipo @c(time.Duration), como lo revela @c(%T):

   ..src > go
     const noDelay time.Duration = 0
     const timeout = 5 * time.Minute

     fmt.Printf("%T %[1]v\n", noDelay)     // "time.Duration 0"
     fmt.Printf("%T %[1]v\n", timeout)     // "time.Duration 5m0s"
     fmt.Printf("%T %[1]v\n", time.Minute) // "time.Duration 1m0s"
   < src..

   Cuando una secuencia de constantes se declara como un grupo, la expresion del
   lado derecho se puede omitir para todas excepto para la primera del grupo, lo
   que implica que la expresion anterior y su tipo deben ser utilizados de
   nuevo. Por ejemplo:

   ..src > go
     const (
       a = 1
       b
       c = 2
       d
     )

     fmt.Println(a, b, c, d) // "1 1 2 2"
   < src..

   Esto no es muy util si la expresion del lado derecho implicitamente copiada
   se evalua siempre con el mismo valor. Pero, ¿y si pudiera variar? Esto nos
   lleva a @c(iota).

*** Seccion 3.6.1 <> El Generador Constante @c(iota)

    Una declaracion @c(const) puede utilizar el generador de constante @c(iota),
    que se utiliza para crear una secuencia de valores relacionados sin escribir
    cada uno de forma explicita. En una declaracion @c(const), el valor de
    @c(iota) comienza en cero y se incrementa en uno en cada elemento de la
    secuencia.

    He aqui un ejemplo del paquete @c(time), que define constantes de tipo
    @c(Weekday) de los dias de la semana, a partir de cero para @c(Sunday). Los
    tipos de esta clase a menudo se conocen como @e(enumeraciones), o @e(enums),
    para abreviar.

    ..src > go
      type Weekday int

      const (
        Sunday Weekday = iota
        Monday
        Tuesday
        Wednesday
        Thursday
        Friday
        Saturday
      )
    < src..

    Esto declara que @c(Sunday) debe ser 0, @c(Monday) debe ser 1, y asi
    sucesivamente.

    Podemos utilizar @c(iota) en expresiones mas complejas, como en este ejemplo
    del paquete @c(net) en el que se le da a cada uno de los 5 bits mas bajos de
    un entero sin signo un nombre distinto e interpretacion booleana:

    ..src > go
      type Flags uint

      const (
        FlagUp Flags = 1 << iota // esta arriba
        FlagBroadcast            // soporta acceso broadcast
        FlagLoopback             // es una interface loopback
        FlagPointToPoint         // pertenece a un enlace punto-a-punto
        FlagMulticast            // soporta acceso multicast
      )
    < src..

    Como @c(iota) se incrementa, a cada constante se le asigna el valor de @c(1
    << iota), que evalua a potencias consecutivas de dos, cada una corresponde a
    un solo bit. Podemos utilizar estas constantes dentro de funciones que
    prueben, establezcan o eliminen uno o mas de estos bits:

    ..figure > @l(gopl.io/ch3/netflag/netflag.go<>gopl.io/ch3/netflag)

      ..src > go
        func IsUp(v Flags) bool     { return v&FlagUp == FlagUp }
        func TurnDown(v *Flags)     { *v &^= FlagUp }
        func SetBroadcast(v *Flags) { *v |= FlagBroadcast }
        func IsCast(v Flags) bool   { return v&(FlagBroadcast|FlagMulticast) != 0 }

        func main() {
          var v Flags = FlagMulticast | FlagUp
          fmt.Printf("%b %t\n", v, IsUp(v))   // "10001 true"
          TurnDown(&v)
          fmt.Printf("%b %t\n", v, IsUp(v))   // "10000 false"
          SetBroadcast(&v)
          fmt.Printf("%b %t\n", v, IsUp(v))   // "10010 false"
          fmt.Printf("%b %t\n", v, IsCast(v)) // "10010 true"
        }
      < src..


    Como un ejemplo mas complejo de @c(iota), esta declaracion nombra las
    potencias de 1024:

    ..src > go
      const (
        _ = 1 << (10 * iota)
        KiB // 1024
        MiB // 1048576
        GiB // 1073741824
        TiB // 1099511627776              (exede 1 << 32)
        PiB // 1125899906842624
        EiB // 1152921504606846976
        ZiB // 1180591620717411303424     (exede 1 << 64)
        YiB // 1208925819614629174706176
      )
    < src..

    El mecanismo @c(iota) tiene sus limites. Por ejemplo, no es posible generar
    las potencias mas familiares de 1000 (KB, MB, etc.) porque no hay un
    operador de exponenciacion.

   @b(Ejercicio 3.13): Escribir declaraciones @c(const) para KB, MB, hasta YB lo
   mas compacto como sea posible.

*** Seccion 3.6.2 <> Constantes Sin Tipo

    Las constantes en Go son un poco inusuales. Aunque una constante puede tener
    cualquiera de los tipos de datos basicos como @c(int) o @c(float64),
    incluyendo tipos basicos con nombre como @c(time.Duration), muchas
    constantes no estan comprometidas con un tipo particular. El compilador
    representa estas constantes no comprometidas con una precision numerica
    mucho mayor que los valores de tipos basicos, y la aritmetica en ellas es
    mas precisa que la aritmetica de la maquina; se puede suponer al menos 256 bits
    de precision. Hay seis sabores de estas constantes no comprometidas, llamadas
    booleana @e(sin tipo), entero sin tipo, runa sin tipo, punto flotante sin
    tipo, complejo sin tipo y cadena sin tipo.

    Al aplazar este compromiso, las constantes no tipificadas no solo conservan
    su mayor precision hasta mas tarde, sino que pueden participar en muchas mas
    expresiones que las constantes comprometidas sin requerir conversiones. Por
    ejemplo, los valores @c(ZiB) y @c(YiB) en el ejemplo anterior son demasiado
    grandes para almacenase en cualquier variable entera, pero son legitimas
    constantes que pueden utilizarse en expresiones como esta:

    ..src > go
      fmt.Println(YiB/ZiB) // "1024"
    < src..

    Como otro ejemplo, la constante de coma flotante @c(math.Pi) puede
    utilizarse alli donde se necesite cualquier valor de coma flotante o
    complejo:

    ..src > go
      var x float32 = math.Pi
      var y float64 = math.Pi
      var z complex128 = math.Pi
    < src..

    Si @c(math.Pi) entubiera comprometido con un tipo especifico, como
    @c(float64), el resultado no seria tan preciso, y se requerira de conversion
    de tipos para usarlo con valores @c(float32) o @c(complex128):

    ..src > go
      const Pi64 float64 = math.Pi

      var x float32 = float32(Pi64)
      var y float64 = Pi64
      var z complex128 = complex128(Pi64)
    < src..

    Para literales, la sintaxis determina el sabor. Los literales @c(0),
    @c(0.0), @c(0i), y @c('\u0000') representan constantes del mismo valor pero
    diferentes sabores: entero sin tipo, sin tipo de punto flotante, complejo
    sin tipo, y runa sin tipo, respectivamente. Del mismo modo, @c(true) y
    @c(false) son booleanos sin tipo y las literales de cadena son cadenas sin tipo.

    Recordemos que @c(/) puede representar la division entera o en punto
    flotante dependiendo de sus operandos. En consecuencia, la eleccion de
    literal puede afectar el resultado de una expresion de division constante:

    ..src > go
      var f float64 = 212
      fmt.Println((f - 32) * 5 / 9)     // "100"; (f - 32) * 5 es un float64
      fmt.Println(5 / 9 * (f - 32))     // "0";   5/9 es un entero sin tipo, 0
      fmt.Println(5.0 / 9.0 * (f - 32)) // "100"; 5.0/9.0 es un float sin tipo
    < src..

    Solo las constantes pueden no tener tipo. Cuando una constante sin tipo
    se asigna a una variable, como en la primer instruccion a continuacion, o
    aparece en el lado derecho de una declaracion de variable con un tipo
    explicito, como en las otras tres sentencias, la constante se convierte
    implicitamente en el tipo de esa variable si es posible.

    ..src > go
      var f float64 = 3 + 0i // complejo sin tipo -> float64
      f = 2                  // entero sin tipo -> float64
      f = 1e123              // punto flotante sin tipo -> float64
      f = 'a'                // runa sin tipo -> float64
    < src..

    Las afirmaciones anteriores son, pues, equivalentes a estas:

    ..src > go
      var f float64 = float64(3 + 0i)
      f = float64(2)
      f = float64(1e123)
      f = float64('a')
    < src..

    Ya sea implicita o explicitamente, la conversion de una constante de un tipo
    a otro requiere que el tipo de destino pueda representar el valor original.
    Se permite el redondeo para numeros reales y complejos de coma flotante:

    ..src > go
      const (
        deadbeef = 0xdeadbeef // int sin tipo con valor 3735928559
        a = uint32(deadbeef)  // uint32 con valor 3735928559
        b = float32(deadbeef) // float32 con valor 3735928576 (rounded up)
        c = float64(deadbeef) // float64 con valor 3735928559 (exact)
        d = int32(deadbeef)   // error de compilacion: desbordamiento constante int32
        e = float64(1e309)    // error de compilacion: desbordamiento constante float64
        f = uint(-1)          // error de compilacion: subdesbordamiento constante uint
      )
    < src..

    En una declaracion de variable sin un tipo explicito (incluyendo declaracion
    de variables compacta), el sabor de la constante sin tipo determina
    implicitamente el tipo predeterminado de la variable, como en estos
    ejemplos:

    ..src > go
      i := 0      // entero sin tipo;         int(0) implicitio
      r := '\000' // runa sin tipo;           rune('\000') implicitio
      f := 0.0    // punto flotante sin tipo; float64(0.0) implicitio
      c := 0i     // complejo sin tipo;       complex128(0i) implicitio
    < src..

    Observese la asimetria: los enteros sin tipo se convierten en @c(int), cuyo
    tamaño no esta garantizado, pero los numeros de punto flotante y numeros
    complejos se convierten a los tipos de tamaño @c(float64) y @c(complex128)
    de forma explicita. El lenguaje no cuenta con tipos @c(float) y @c(complex)
    sin tamaño, analogos a @c(int) sin tamaño, porque es muy dificil escribir
    algoritmos numericos correctos sin conocer el tamaño de uno de los tipos de
    datos de punto flotante.

    Para dar un tipo diferente a la variable, debemos convertir explicitamente
    la constante sin tipo en el tipo deseado o indicar el tipo deseado en
    la declaracion de variables, como en estos ejemplos:

    ..src > go
      var i = int8(0)
      var i int8 = 0
    < src..

    Estos valores predeterminados son particularmente importantes cuando se
    convierte una constante sin tipo a un valor de interfaz (ver @l(#Capitulo
    7)) ya que determinan su tipo dinamico.

    ..src > go
      fmt.Printf("%T\n", 0)      // "int"
      fmt.Printf("%T\n", 0.0)    // "float64"
      fmt.Printf("%T\n", 0i)     // "complex128"
      fmt.Printf("%T\n", '\000') // "int32" (runa)
    < src..

    Ahora hemos cubierto los tipos de datos basicos de Go. El siguiente paso es
    mostrar como se pueden combinar en agrupaciones mas grandes como arreglos y
    estructuras, y luego en estructuras de datos para resolver problemas de
    programacion real; ese es el tema del @l(#Capitulo 4).

* Capitulo 4 <> Tipos Compuestos

  En el @l(#Capitulo 3) hablamos de los tipos basicos que sirven como bloques de
  construccion para estructuras de datos en un programa Go; son los atomos de
  nuestro universo. En este capitulo, vamos a echar un vistazo a los tipos
  @e(compuestos), las moleculas creadas mediante la combinacion de los tipos
  basicos de diversas maneras. Hablaremos de cuatro de estos tipos–arreglos,
  slices, mapas y estructuras–y al final del capitulo mostraremos como los datos
  estructurados que utilizan estos tipos pueden ser codificados y analizados a
  partir de datos JSON y usados para generar HTML a partir de plantillas.

  Los arreglos y estructuras son tipos de @e(agregados); sus valores son
  concatenaciones de otros valores en la memoria. Los arreglos son homogeneos,
  sus elementos tienen el mismo tipo, mientras que las estructuras son
  heterogeneas. Los arreglos y las estructuras son de tamaño fijo. Por el
  contrario, slices y mapas son estructuras de datos dinamicas que crecen a
  medida que se agregan valores.

** Seccion 4.1 <> Arreglos

   Un arreglo es una secuencia de longitud fija de cero o mas elementos de un
   tipo particular. Debido a su longitud fija, en Go raramente se utilizan
   arreglos directamente. Los slices, pueden crecer y encogerse, son mucho mas
   versatiles, pero para entender los slices primero debemos entender los
   arreglos.

   Los elementos individuales de un arreglo se acceden con la notacion de
   subindices convencional, donde los subindices abarcan desde cero a uno menos
   que la longitud del arreglo. La funcion nativa @c(len) devuelve el numero de
   elementos del arreglo.

   ..src > go
     var a [3]int             // arreglo de 3 enteros
     fmt.Println(a[0])        // imprime el primer elemento
     fmt.Println(a[len(a)-1]) // imprime el ultimo elemento, a[2]

     // imprimir los indices y elementos.
     for i, v := range a {
       fmt.Printf("%d %d\n", i, v)
     }

     // imprimir solo los elementos.
     for _, v := range a {
       fmt.Printf("%d\n", v)
     }
   < src..

   Por defecto, los elementos de un nuevo arreglo de variables estan
   configurados inicialmente a el valor cero para el tipo del elemento, que es 0
   para los numeros. Podemos utilizar un @e(arreglo literal) para inicializar un
   arreglo con una lista de valores:

   ..src > go
     var q [3]int = [3]int{1, 2, 3}
     var r [3]int = [3]int{1, 2}
     fmt.Println(r[2]) // "0"
   < src..

   En un arreglo literal, si una elipsis @"c(...) aparece en lugar de la
   longitud, la longitud del arreglo se determina por el numero de
   inicializadores. La definicion de @c(q) se puede simplificar como

   ..src > go
     q := [...]int{1, 2, 3}
     fmt.Printf("%T\n", q) // "[3]int"
   < src..

   El tamaño de un arreglo es parte de su tipo, por lo que @c([3]int) y
   @c([4]int) son tipos diferentes. El tamaño debe ser una expresion constante,
   es decir, una expresion cuyo valor se puede calcular a medida que se esta
   compilando el programa.

   ..src > go
     q := [3]int{1, 2, 3}
     q  = [4]int{1, 2, 3, 4} // error de compilacion: no puede asignar [4]int a [3]int
   < src..

   Como veremos, la sintaxis literal es similar para arreglos, slices, mapas y
   estructuras. El formato especifico anterior es una lista de valores en
   orden, pero tambien es posible especificar una lista de pares de indice y
   valor, como esta:

   ..src > go
     type Currency int

     const (
       USD Currency = iota
       EUR
       GBP
       RMB
     )
     symbol := [...]string{USD: "$", EUR: "€", GBP: "£", RMB: "¥"}

     fmt.Println(RMB, symbol[RMB]) // "3 ¥"
   < src..

   En esta forma, los indices pueden aparecer en cualquier orden y algunos
   pueden ser omitidos; como antes, los valores no especificados toman el valor
   cero para el tipo de elemento. Por ejemplo,

   ..src > go
     r := [...]int{99: -1}
   < src..

   define un arreglo @c(r) con 100 elementos, todos en cero excepto para el
   ultimo, que tiene un valor -1.

   Si el tipo de los elementos de un arreglo es @e(comparable) entonces, el tipo
   del arreglo tambien es comparable, asi que podemos comparar directamente dos
   arreglos de ese tipo usando el operador @c(==), que informa de si todos los
   elementos correspondientes son iguales. El operador @c(!=) es su negacion.

   ..src > go
     a := [2]int{1, 2}
     b := [...]int{1, 2}
     c := [2]int{1, 3}
     fmt.Println(a == b, a == c, b == c) // "true false false"
     d := [3]int{1, 2}
     fmt.Println(a == d) // error de compilacion: no puede comparar [2]int == [3]int
   < src..

   Como un ejemplo mas plausible, la funcion @c(Sum256) en el paquete
   @c(crypto/sha256) produce el hash criptografico SHA256 o @e(digerido) de un
   mensaje almacenado en un slice arbitrario de bytes. El hash tiene 256 bits,
   por lo que su tipo es @c([32]byte) . Si dos hash son los mismos, es muy
   probable que los dos mensajes sean iguales; si los hash difieren, los dos
   mensajes son diferentes. Este programa imprime y compara los hash SHA256 de
   @c("x") y @c("X"):

   ..figure > @l(gopl.io/ch4/sha256/main.go<>gopl.io/ch4/sha256)

     ..src > go
       import "crypto/sha256"

       func main() {
         c1 := sha256.Sum256([]byte("x"))
         c2 := sha256.Sum256([]byte("X"))
         fmt.Printf("%x\n%x\n%t\n%T\n", c1, c2, c1 == c2, c1)
         // Output:
         // 2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881
         // 4b68ab3847feda7d6c62c1fbcbeebfa35eab7351ed5e78f4ddadea5df64b8015
         // false
         // [32]uint8
       }
     < src..


   Las dos entradas difieren por un solo bit, pero aproximadamente la mitad de
   los bits son diferentes en los hash. Note las verbos @c(Printf): @c(%x) para
   imprimir todos los elementos de un arreglo o una slice de bytes en
   hexadecimal, @c(%t) para mostrar un valor booleano, y @c(%T) para mostrar el
   tipo de un valor.

   Cuando se llama a una funcion, se asigna una copia de cada valor de argumento
   a la variable de parametro correspondiente, por lo que la funcion recibe una
   copia, no el original. Pasar grandes arreglos de esta manera puede ser
   ineficiente, y cualquier cambio que la funcion haga en los elementos del arreglo
   afecta solo a la copia, no al original. En este sentido, Go trata a los
   arreglos como a cualquier otro tipo, pero este comportamiento es diferente de
   otros lenguajes que implicitamente pasan los arreglos por referencia.

   Por supuesto, podemos pasar explicitamente un puntero a un arreglo para que
   cualquier modificacion que la funcion haga a los elementos del arreglo sea
   visibles para quien llama a la funcion. Esta funcion pone a cero el contenido
   de un arreglo @c([32]byte):

   ..src > go
     func zero(ptr *[32]byte) {
       for i := range ptr {
         ptr[i] = 0
       }
     }
   < src..

   El arreglo literal @c([32]byte{}) produce un arreglo de 32 bytes. Cada
   elemento del arreglo tiene el valor cero para @c(byte), que es cero. Podemos
   utilizar este hecho para escribir una version diferente de zero:

   ..src > go
     func zero(ptr *[32]byte) {
       *ptr = [32]byte{}
     }
   < src..

   El uso de un puntero a un arreglo es eficiente y permite que la funcion
   llamada mute la variable de quien la llama, pero los arreglos son
   intrinsecamente inflexibles debido a su tamaño fijo. La funcion @c(zero) no
   aceptara un puntero a una variable @c([16]byte), por ejemplo, ni hay ninguna
   manera de añadir o eliminar elementos del arreglo. Por estas razones, aparte
   de casos especiales como el hash SHA256 de tamaño fijo, rara vez se usan
   arreglos como parametros o resultados de funcion; en su lugar, utilizamos slices.

   @b(Ejercicio 4.1): Escribir una funcion que cuente el numero de bits que son
   diferentes en dos hash SHA256. (Ver @c(PopCount) en la @l(#Seccion o2.6.2).)

   @b(Ejercicio 4.2): Escribir un programa que imprima el hash SHA256 de su
   entrada estandar por defecto, pero que accepte una bandera de linea de
   comando para imprimir tambien los hash SHA384 o SHA512.

** Seccion 4.2 <> Slices

   Los slices representan secuencias de longitud variable cuyos elementos tienen
   todos el mismo tipo. Un tipo slice se escribe @c([]T), donde los elementos
   tienen el tipo @c(T); es como un tipo arreglo pero sin tamaño.

   Arreglos y slices estan intimamente conectados. Un slice es una estructura de
   datos ligera que da acceso a una subsecuencia de (o tal vez a todos) los
   elementos de un arreglo, que se conoce como @e(arreglo subyacente) del
   slice. Un slice tiene tres componentes: un puntero, una longitud y una
   capacidad. El puntero apunta al primer elemento del arreglo que se puede
   acceder a traves del slice, que no es necesariamente el primer elemento del
   arreglo. La longitud es el numero de elementos del slice; no puede exceder la
   capacidad, que suele ser el numero de elementos entre el inicio del slice
   y el final del arreglo subyacente. Las funciones nativas @c(len) y
   @c(cap) devuelven esos valores.

   Multiples slices pueden compartir el mismo arreglo subyacente y pueden
   referirse a partes superpuestas de ese arreglo. La Figura 4.1 muestra un
   arreglo de cadenas para los meses del año, y dos slices superpuestos del
   mismo. El arreglo se declara como

   ..src > go
     meses := [...]string{1: "Enero", /* ... */, 12: "Diciembre"}
   < src..

   asi Enero es @c(meses[1]) y Diciembre es @c(meses[12]). Normalmente, el
   elemento de arreglo en el indice 0 contendria el primer valor, pero como los
   meses siempre estan numerados apartir de 1, podemos dejarlo fuera de la
   declaracion y se inicializara en una cadena vacia.

   ..figure > Figura 4.1. Dos slices superpuestos de un arreglo de meses.

     ..img > img/Figure-4.1.jpg

   El @e(operador de slice) @c(s[i:j]), donde @c(0) ≤ @c(i) ≤ @c(j) ≤
   @c[cap(s)], crea un nuevo segmento que se refiere a los elementos de @c(i) a
   @c(j-1) de la secuencia @c(s), que puede ser una variable del arreglo, un
   puntero a un arreglo u otro slice. El slice resultante tiene @c(j-i)
   elementos. Si @c(i) se omite, es 0, y si @c(j) se omite, es @c[len(s)]. Asi,
   el slice @c(meses[1:13]) se refiere a todo el rango de meses validos, como lo
   hace el slice @c(meses[1:]); el slice @c(meses[:]) se refiere a todo el
   arreglo. Vamos a definir slices superpuestos para el segundo trimestre y el
   verano boreal:

   ..src > go
     Q2 := meses[4:7]
     verano := meses[6:9]
     fmt.Println(Q2)     // ["Abril" "Mayo" "Junio"]
     fmt.Println(verano) // ["Junio" "Julio" "Augosto"]
   < src..

   Junio se incluye en ambos y es la unica salida de esta (ineficiente) prueba
   para los elementos comunes:

   ..src > go
     for _, s := range verano {
       for _, q := range Q2 {
         if s == q {
           fmt.Printf("%s aparece en ambos\n", s)
         }
       }
     }
   < src..

   Seccionar mas alla de @c[cap(s)] causa un panico, pero seccionar mas alla
   @c[len(s)] extiende el slice, por lo que el resultado puede ser mas largo que
   el original:

   ..src > go
     fmt.Println(verano[:20])    // panico: fuera de rango

     veranoSinFin := verano[:5] // ampliar slice (dentro de la capacidad)
     fmt.Println(veranoSinFin)  // "[Junio Julio Augosto Septiembre Octubre]"
   < src..

   Como anotacion, observe la similitud de la operacion de subcadena en las
   cadenas con el operador slice en slices de @c([]byte). Ambos se escriben
   @c(x[m:n]), y ambos devuelven una subsecuencia de los bytes originales,
   compartiendo la representacion subyacente de modo que ambas operaciones toman
   tiempo constante. La expresion @c(x[m:n]) produce una cadena si @c(x) es una
   cadena, o un @c([]byte) si @c(x) es un @c([]byte).

   Dado que un slice contiene un puntero a un elemento de un arreglo, el paso de
   un slice a una funcion permite a la funcion modificar los elementos del
   arreglo subyacente. En otras palabras, la copia de una slice crea un alias
   @%l(#Seccion 2.3.2<>§2.3.2) para el arreglo subyacente. La funcion
   @c(reverse) invierte los elementos de un slice @c([]int) en su lugar, y se
   puede aplicar a slices de cualquier longitud.

   ..figure > @l(gopl.io/ch4/rev/main.go<>gopl.io/ch4/rev)

     ..src > go
       // reverse invierte un slice de enteros en su posicion.
       func reverse(s []int) {
         for i, j := 0, len(s)-1; i < j; i, j = i+1, j-1 {
           s[i], s[j] = s[j], s[i]
         }
       }
     < src..

   Aqui invertimos todo el arreglo @c(a):

   ..src > go
     a := [...]int{0, 1, 2, 3, 4, 5}
     reverse(a[:])
     fmt.Println(a) // "[5 4 3 2 1 0]"
   < src..

   Una forma sencilla de @e(rotar) un slice a la izquierda @m(n) elementos es
   aplicar la funcion @c(reverse) tres veces, primero a los @m(n) elementos
   iniciales, luego a los elementos restantes, y finalmente a todo el slice.
   (Para rotar a la derecha, primero haga la tercer llamada.)

   ..src > go
     s := []int{0, 1, 2, 3, 4, 5}
     // rotar s a la izquierda dos posiciones.
     reverse(s[:2])
     reverse(s[2:])
     reverse(s)
     fmt.Println(s) // "[2 3 4 5 0 1]"
   < src..

   Observe como la expresion que inicializa el slice @c(s) difiere de la del
   arreglo de @c(a). Un @e(slice literal) se ve similar a un arreglo literal,
   una secuencia de valores separados por comas y rodeada por llaves, pero el
   tamaño no se proporciona. Esto crea implicitamente una variable de arreglo
   del tamaño correcto y produce una division que apunta a el. Al igual que con
   los arreglos literales, los slices literales pueden especificar los valores
   en orden, o dar sus indices explicitamente, o usar una mezcla de los dos
   estilos.

   A diferencia de los arreglos, los slices no son comparables, por lo que no
   podemos usar @c(==) para probar si dos slices contienen los mismos elementos.
   La libreria estandar proporciona la funcion @c(bytes.Equal) altamente
   optimizada para comparar dos slices de bytes (@c([]byte)), pero para otros
   tipos de slice, tenemos que hacer la comparacion nosotros mismos:

   ..src > go
     func equal(x, y []string) bool {
       if len(x) != len(y) {
         return false
       }
       for i := range x {
         if x[i] != y[i] {
           return false
         }
       }
       return true
     }
   < src..

   Dado lo natural que es esta prueba de igualdad @"(profundida),
   y que no es mas costosa en tiempo de ejecucion que el operador @c(==) para
   arreglos de cadenas, puede ser desconcertante que la comparacion de slices no
   funcionen tambien de esta manera. Hay dos razones por las cuales la
   equivalencia profunda es problematica. En primer lugar, a diferencia de
   los elementos del arreglo, los elementos de un slice son indirectos, lo que
   hace posible que un slice se contenga a si mismo. Aunque hay maneras de
   tratar con tales casos, ninguno es simple, eficiente, y lo mas importante,
   obvio.

   En segundo lugar, debido a que los elementos del slice son indirectos, un
   valor fijo del slice puede contener diferentes elementos en momentos
   diferentes a medida que se modifican los contenidos del arreglo
   subyacente. Dado que una tabla hash como el tipo de mapa de Go solo hace
   copias poco profundas de sus claves, requiere que la igualdad para cada clave
   permanezca igual durante toda la vida de la tabla hash. La equivalencia
   profunda haria asi que los slices no fueran adecuados para ser utilizados
   como claves de mapas. Para los tipos de referencia como punteros y canales,
   el operador @c(==) prueba la @e(identidad de la referencia), es decir, si las
   dos entidades se refieren a la misma cosa. Una prueba de igualdad
   @"(superficial) similar para slices podria ser util, y resolveria el problema
   con los mapas, pero el tratamiento inconsistente de slices y arreglos por el
   operador @c(==) seria confuso. La opcion mas segura es no permitir las
   comparaciones de slices por completo.

   La unica comparacion legal en slices es contra @c(nil), como en

   ..src > go
     if verano == nil { /* ... */ }
   < src..

   El valor cero de un tipo slice es @c(nil). Un slice nil no tiene un arreglo
   subyacente. El slice nil tiene longitud y capacidad cero, pero tambien hay
   slices no nulos de longitud y capacidad cero, como @c([]int{}) o
   @c{make([]int, 3)[3:]}. Como con cualquier tipo que puede tener valores
   nulos, el valor nulo de un tipo de slice particular puede ser escrito
   utilizando una expresion de conversion como @c{[]int(nil)}.

   ..src > go
     var s []int    // len(s) == 0, s == nil
     s = nil        // len(s) == 0, s == nil
     s = []int(nil) // len(s) == 0, s == nil
     s = []int{}    // len(s) == 0, s != nil
   < src..

   Por lo tanto, si usted necesita probar si un slice esta vacio, utilice
   @c[len(s) == 0], no @c(s == nil). Ademas de comparar la igualdad con @c(nil),
   una slice nil se comporta como cualquier otro slice de longitud cero; por
   ejemplo, @c[reverse(nil)] es perfectamente seguro. A menos que se demuestre
   claramente lo contrario, las funciones de Go deben tratar todos los slices de
   longitud cero de la misma manera, sea o no nil.

   La funcion nativa @c(make) crea un slice de un tipo de elemento con longitud
   y capacidad especifico. Se puede omitir el argumento capacidad, en cuyo caso
   la capacidad es igual a la longitud.

   ..src > go
     make([]T, len)
     make([]T, len, cap) // igual que make([]T, cap)[:len]
   < src..

   Bajo el capo, @c(make) crea una variable de arreglo sin nombre y devuelve un
   slice de este; el arreglo es accesible solo a traves del slice devuelto. En
   la primer forma, el slice es una vista de todo el arreglo. En la segunda, el
   slice es una vista de solo los primeros @c(len) elementos, pero su capacidad
   incluye todo el arreglo. Los elementos adicionales se reservan para el futuro
   crecimiento.

*** Seccion 4.2.1 <> La Funcion @c(append)

    La funcion nativa @c(append) agrega elementos a slices:

    ..src > go
      var runes []rune
      for _, r := range "Hello, 世界" {
        runes = append(runes, r)
      }
      fmt.Printf("%q\n", runes) // "['H' 'e' 'l' 'l' 'o' ',' ' ' '世' '界']"
    < src..

    El bucle utiliza @c(append) para construir el slice codificado de nueve
    runas literales, aunque este problema especifico se resuelve mas
    convenientemente mediante el uso de la conversion nativa @c{[]rune("Hello,
    世界")}.

    La funcion @c(append) es crucial para entender como trabajan los
    slices, asi que vamos a echar un vistazo a lo que esta pasando. Aqui hay una
    version llamada @c(appendInt) que se especializa en slices @c([]int):

    ..figure > @l(gopl.io/ch4/append/main.go<>gopl.io/ch4/append)

      ..src > go
        func appendInt(x []int, y int) []int {
          var z []int
          zlen := len(x) + 1
          if zlen <= cap(x) {
            // Hay espacio para crecer. Extiende el slice
            z = x[:zlen]
          } else {
            // No hay suficiente espacio. Asigna un nuevo arreglo.
            // Crecer al doble, para compenzar la complejidad lineal.
            zcap := zlen
            if zcap < 2*len(x) {
              zcap = 2 * len(x)
            }
            z = make([]int, zlen, zcap)
            copy(z, x) // una funcion nativa; ver texto
          }
          z[len(x)] = y
          return z
        }
      < src..


    Cada llamada a @c(appendInt) debe comprobar si el slice tiene capacidad
    suficiente para contener los nuevos elementos en el arreglo existente. Si es
    asi, se extiende el slice mediante la definicion de un slice mas grande
    (todavia dentro de la arreglo original), copia el elemento @c(y) en el nuevo
    espacio, y devuelve el slice. La entrada @c(x) y el resultado @c(z)
    comparten el misma arreglo subyacente.

    Si no hay espacio suficiente para el crecimiento, @c(appendInt) debe asignar
    un nuevo arreglo lo bastente grande para contener el resultado,
    copiar los valores de @c(x) en el, y a continuacion, añadir el nuevo
    elemento @c(y). Ahora el resultado @c(z) hace referencia a un arreglo
    subyacente diferente al que referia el arreglo @c(x).

    Seria facil copiar los elementos con bucles explicitos, pero es mas facil
    utilizar la funcion nativa @c(copy), que copia los elementos de un slice a
    otro del mismo tipo. Su primer argumento es el destino y el segundo es la
    fuente, parecido al orden de los operandos de una asignacion como @c(dst =
    src). Los slices pueden referirse al mismo arreglo subyacente; incluso
    pueden superponerse. Aunque no lo usamos aqui, @c(copy) devuelve el numero
    de elementos copiados realmente, que es la longitud del menor de los slices,
    por lo que no hay peligro de se acabe o sobreescriba algo fuera del rango.

    Por eficiencia, el nueva arreglo es generalmente algo mayor que el minimo
    necesario para almacenar @c(x) y @c(y). Expandir el arreglo duplicando su
    tamaño en cada expansion evita un numero excesivo de asignaciones y asegura
    que anexar un solo elemento tome un tiempo constante en promedio. Este
    programa demuestra el efecto:

    ..src > go
      func main() {
        var x, y []int
        for i := 0; i < 10; i++ {
          y = appendInt(x, i)
          fmt.Printf("%d cap=%d\t%v\n", i, cap(y), y)
          x = y
        }
      }
    < src..

    Cada cambio de capacidad indica una asignacion y una copia:

    ..pre >
      0  cap=1     [0]
      1  cap=2     [0 1]
      2  cap=4     [0 1 2]
      3  cap=4     [0 1 2 3]
      4  cap=8     [0 1 2 3 4]
      5  cap=8     [0 1 2 3 4 5]
      6  cap=8     [0 1 2 3 4 5 6]
      7  cap=8     [0 1 2 3 4 5 6 7]
      8  cap=16    [0 1 2 3 4 5 6 7 8]
      9  cap=16    [0 1 2 3 4 5 6 7 8 9]
    < pre..


    Echemos un vistazo mas cercano a la iteracion @c(i=3). El slice @c(x)
    contiene tres elementos @c([0 1 2]), pero tiene la capacidad de 4, por lo
    que hay un solo elemento de holgura al final, y agrerar el elemento 3 con
    @c(appendInt) procede sin reasignacion. El slice @c(y) resultante tiene
    longitud y capacidad 4, y tiene el mismo arreglo subyacente que el slice
    @c(x) original, como lo muestra la Figura 4.2.

    ..figure > Figura 4.2. Adicion con espacio para crecer.

      ..img > img/Figure-4.2.jpg

    En la siguiente iteracion, @c(i=4), no hay ninguna holgura, por lo que
    @c(appendInt) asigna un nueva arreglo de tamaño 8, copia los cuatro
    elementos de @c(x) (@c([0 1 2 3])), y agrega 4, el valor de @c(i). El slice
    resultante @c(y) tiene una longitud de 5, pero una capacidad de 8; la
    holgura de 3 ahorrara la necesidad de reasignar en las tres siguientes
    iteraciones. Las slices @c(y) y @c(x) son vistas de diferentes arreglos.
    Esta operacion se muestra en la Figura 4.3.

    ..figure > Figura 4.3. Adicion sin crear espacio.

      ..img > img/Figure-4.3.jpg

    La funcion nativa @c(append) puede utilizar una estrategia de crecimiento
    mas sofisticado que la simplista @c(appendInt). Por lo general, no sabemos
    si una llamada a @c(append) provocara una reasignacion, asi que no podemos
    asumir que el slice original se refiere al mismo arreglo que el slice
    resultante, ni que este se refiere a uno diferente. Del mismo modo, no
    debemos suponer que las operaciones sobre los elementos del antiguo slice se
    reflejaran (o no) en la nuevo slice. Como resultado de ello, es habitual
    asignar el resultado de una llamada a @c(append) al mismo slice cuyo valor
    pasamos a @c(append):

    ..src > go
      runes = append(runes, r)
    < src..

    La actualizacion de la variable slice es necesaria no solo al llamar a
    @c(append), sino tambien a cualquier funcion que pueda cambiar la longitud o
    la capacidad de un slice o hacer que se refiera a un arreglo subyacente
    diferente. Para usar los slices correctamente, es importante tener en cuenta
    que aunque los elementos del arreglo subyacente son indirectos, el puntero,
    la longitud y la capacidad del slice no lo son. Para actualizarlos se
    requiere una asignacion como la anterior. En este sentido, los slices no son
    tipos de referencia @"(puros), sino que se asemejan a un tipo de agregado
    como esta estructura:

    ..src > go
      type IntSlice struct {
        ptr      *int
        len, cap int
      }
    < src..

    Nuestra funcion @c(appendInt) añade un elemento a un slice, pero el
    @c(append) nativo nos permite añadir mas de un elemento nuevo, o incluso
    todo un slice de ellos.

    ..src > go
      var x []int
      x = append(x, 1)
      x = append(x, 2, 3)
      x = append(x, 4, 5, 6)
      x = append(x, x...) // añade el slice x
      fmt.Println(x)      // "[1 2 3 4 5 6 1 2 3 4 5 6]"
    < src..

    Con la pequeña modificacion que se muestra a continuacion, podemos hacer
    coincidir el comportamiento con el @c(append) nativo. Los puntos suspensivos
    @"c("...") en la declaracion de @c(appendInt) crean una funcion
    @e(variadic): acepta cualquier numero de argumentos finales. Los puntos
    suspensivos en la llamada @c(append) anterior muestran como suministrar una
    lista de argumentos apartir de un slice. Vamos a explicar este mecanismo en
    detalle en la @l(#Seccion 5.7).

    ..src > go
      func appendInt(x []int, y ...int) []int {
        var z []int
        zlen := len(x) + len(y)
        // ...expandir z al menos zlen...
        copy(z[len(x):], y)
        return z
      }
    < src..

    La logica para expandir el arreglo @c(z) subyacente, se mantiene sin
    cambios y no se muestra.

*** Seccion 4.2.2 <> Tecnicas de Slices In Situ

    Veamos mas ejemplos de funciones que, como @c(rotate) y @c(reverse), modifican
    los elementos de un slice en su lugar. Dada una lista de cadenas, la
    funcion @c(nonempty) devuelve las que no estan vacias:

    ..figure > @l(gopl.io/ch4/nonempty/main.go<>gopl.io/ch4/nonempty)

      ..src > go
        // Nonempty es un ejemplo de algoritmo para slices in situ.
        package main

        import "fmt"

        // nonempty regresa un slice que contiene solo las cadenas no vacias.
        // El arreglo subyacente se modifica durante la llamada.
        func nonempty(strings []string) []string {
          i := 0
          for _, s := range strings {
            if s != "" {
              strings[i] = s
              i++
            }
          }
          return strings[:i]
        }
      < src..


    La parte sutil es que el slice de entrada y el slice de salida comparten el
    mismo arreglo subyacente. Esto evita la necesidad de asignar otro arreglo,
    aunque por supuesto los contenidos de datos se sobrescriben en parte, como
    lo demuestra la segunda instruccion de impresion:

    ..src > go
      data := []string{"uno", "", "tres"}
      fmt.Printf("%q\n", nonempty(data)) // `["uno" "tres"]`
      fmt.Printf("%q\n", data)           // `["uno" "tres" "tres"]`
    < src..

    Por lo tanto normalmente escribiriamos: @c[data = nonempty(data)].

    La funcion @c(nonempty) tambien se puede escribir utilizando @c(append):

    ..src > go
      func nonempty2(strings []string) []string {
        out := strings[:0] // slice del original con longitud cero
        for _, s := range strings {
          if s != "" {
            out = append(out, s)
          }
        }
        return out
      }
    < src..

    Cualquiera que sea la variante que utilicemos, la reutilizacion de un
    arreglo de este modo requiere que se produzca como maximo un valor de salida
    para cada valor de entrada, lo que es cierto para muchos algoritmos que
    filtran elementos de una secuencia o combinan elementos adyacentes. Este uso
    intrincado de un slice es la excepcion, no la regla, pero puede ser clara,
    eficiente y util en ocasiones.

    Se puede usar un slice para implementar una pila. Dado que tenemos un slice
    vacio @c(stack), podemos empujar un nuevo valor en el extremo del slice con
    @c(append):

    ..src > go
      stack = append(stack, v) // push v
    < src..

    La parte superior del stack es el ultimo elemento:

    ..src > go
      top := stack[len(stack)-1] // parte superior del stack
    < src..

    y para  sacar el elemento del stack es

    ..src > go
      stack = stack[:len(stack)-1] // sacar
    < src..

    Para eliminar un elemento a la mitad de un slice, preservando el orden de
    los elementos restantes, utilice @c(copy) para deslizar los elementos de
    numeros mas altos hacia abajo por uno, para llenar el hueco:

    ..src > go
      func remove(slice []int, i int) []int {
        copy(slice[i:], slice[i+1:])
        return slice[:len(slice)-1]
      }
      func main() {
        s := []int{5, 6, 7, 8, 9}
        fmt.Println(remove(s, 2)) // "[5 6 8 9]"
      }
    < src..

    Y si no necesitamos preservar el orden, podemos solo mover el ultimo
    elemento al hueco:

    ..src > go
      func remove(slice []int, i int) []int {
        slice[i] = slice[len(slice)-1]
        return slice[:len(slice)-1]
      }
      func main() {
        s := []int{5, 6, 7, 8, 9}
        fmt.Println(remove(s, 2)) // "[5 6 9 8]
      }
    < src..

   @b(Ejercicio 4.3): Reescribir @c(reverse) para utilizar un puntero a
   un arreglo en lugar de un slice.

   @b(Ejercicio 4.4): Escribir una version de @c(rotate) que opere en una sola
   pasada.

   @b(Ejercicio 4.5): Escribir una funcion in situ para eliminar duplicados
   adyacentes en un slice @c([]string).

   @b(Ejercicio 4.6): Escribir una funcion in situ que en un slice @c([]byte)
   codificado en UTF-8, aplaste cada sequencia Unicode de espacios adyacentes
   (ver @c(unicode.IsSpace)) a un solo espacio ASCII.

   @b(Ejercicio 4.7): Modificar @c(reverse) para invertir in situ los caracteres
   de un slice @c([]byte) que represente una cadena codificada en UTF-8.
   ¿Puedes hacerlo sin asignar nueva memoria?

** Seccion 4.3 <> Mapas

   La tabla hash es una de las mas ingeniosas y versatiles de todas las
   estructuras de datos. Es una coleccion desordenada de pares clave/valor en la
   que todas las claves son distintas, y el valor asociado con una clave dada
   puede ser recuperado, actualizado o eliminado, usando un numero constante de
   comparaciones clave en promedio, no importa cuan grande sea el tamaño de la
   tabla hash.

   En Go, un @e(mapa) es una referencia a una tabla hash, y un tipo de mapa se
   escribe como @c(map[K]V), en donde @c(K) y @c(V) son los tipos de sus claves
   y valores. Todas las claves en un mapa son del mismo tipo, y todos los
   valores son del mismo tipo, pero las claves no necesitan ser del mismo tipo
   que los valores. El tipo de la clave @c(K) debe ser comparable usando @c(==), de
   modo que el mapa puede probar si una clave dada es igual a una que ya esta
   dentro de el. Aunque los numeros de punto flotante son comparables, es una
   mala idea comparar floats por igualdad y, como mencionamos en el @l(#Capitulo
   3), es especialmente malo si NaN es un valor posible. No hay restricciones
   en el tipo de valor @c(V).

   Se puede utilizar la funcion nativa @c(make) para crear un mapa:

   ..src > go
     edades := make(map[string]int) // mapeo de cadenas a ints
   < src..

   Tambien podemos usar un @e(mapa literal) para crear un nuevo mapa poblado con
   algunos pares clave/valor iniciales:

   ..src > go
     edades := map[string]int{
       "alice":   31,
       "charlie": 34,
     }
   < src..

   Esto es equivalente a

   ..src > go
     edades := make(map[string]int)
     edades["alice"] = 31
     edades["charlie"] = 34
   < src..

   por lo que una expresion alternativa para un nuevo mapa vacio es
   @c(map[string]int{}).

   Los elementos del mapa se acceden a traves de la notacion de subindice usual:

   ..src > go
     edades["alice"] = 32
     fmt.Println(edades["alice"]) // "32"
   < src..

   y se eliminan con la funcion nativa @c(delete):

   ..src > go
     delete(edades, "alice") // remover elemento ages["alice"]
   < src..

   Todas estas operaciones son seguras incluso si el elemento no esta en el
   mapa; una busqueda en el mapa utulizando una clave que no esta presente
   devuelve el valor cero para su tipo, por ejemplo, lo siguiente funciona
   incluso cuando @c("bob") aun no es una clave en el mapa, por lo que el valor
   de @c(edades["bob"]) sera 0.

   ..src > go
     edades["bob"] = edades["bob"] + 1 // feliz cumpleaños!
   < src..

   Las formas de asignacion abreviada @c(x += y) y @c(x++) tambien funcionan
   para elementos del mapa, asi que podemos rescribir la sentencia anterior como

   ..src > go
     edades["bob"] += 1
   < src..

   O incluso mas conciso como

   ..src > go
     edades["bob"]++
   < src..

   Pero un elemento del mapa no es una variable, y no podemos tomar su
   direccion:

   ..src > go
     _ = &ages["bob"] // error de compilacion: no puede tomar la direccion del elemento mapa
   < src..

   Una de las razones por las que no podemos tomar la direccion de un elemento
   de un mapa es que el crecimiento de un mapa podria provocar la reorganizacion
   de elementos existentes en nuevas ubicaciones de almacenamiento, lo que
   podria invalidar la direccion.

   Para enumerar todos los pares clave/valor en el mapa, se utiliza un bucle
   @c(for) basado en @c(range) similar al que vimos para los slices. Las
   iteraciones sucesivas del bucle hacen que las variables @c(nonmbre) y
   @c(edad) se establescan en el siguiente par clave/valor:

   ..src > go
     for nombre, edad := range edades {
       fmt.Printf("%s\t%d\n", nombre, edad)
     }
   < src..

   El orden de iteracion del mapa no se especifica, y las diferentes
   implementaciones pueden utilizar una funcion de hash diferente, lo que
   conduce a un orden diferente. En la practica, el orden es aleatorio, variando
   de una ejecucion a la siguiente. Esto es intencional; haciendo que la
   secuencia varie ayuda a obligar a los programas a ser robustos en todas las
   implementaciones. Para enumerar los pares clave/valor en orden, hay que
   ordenar las claves de forma explicita, por ejemplo, mediante la funcion
   @c(Strings) del paquete @c(sort) si las claves son cadenas. Este es un patron
   comun:

   ..src > go
     import "sort"

     var nombres []string
     for nombre := range edades {
       nombres = append(nombres, nombre)
     }

     sort.Strings(nombres)
     for _, nombre := range nombres {
       fmt.Printf("%s\t%d\n", nombre, edades[nombre])
     }
   < src..

   Dado que sabemos el tamaño final de @c(nombres) desde el principio, es mas
   eficiente asignar un arreglo del tamaño requerido por adelantado. La
   siguiente declaracion crea un slice que esta inicialmente vacio, pero tiene
   la capacidad suficiente para contener todas las llaves del mapa @e(edades):

   ..src > go
     nombres := make([]string, 0, len(edades))
   < src..

   En el primer @c(range) del bucle anterior, solo necesitamos las llaves claves
   del mapa @c(edades), por lo que se omite la segunda variable de bucle. En el
   segundo bucle, se requieren solo los elementos del slice @c(nombres), por lo
   que se utiliza el identificador en blanco @c(_) para ignorar la primer
   variable, el indice.

   El valor cero para el tipo de un mapa es @c(nil), es decir, una referencia a
   ninguna tabla hash en absoluto.

   ..src > go
     var edades map[string]int
     fmt.Println(edades == nil)    // "true"
     fmt.Println(len(edades) == 0) // "true"
   < src..

   La mayoria de las operaciones en los mapas, incluyendo las operaciones de
   busqueda, @c(delete), @c(len) y bucles @c(range), son seguras de llevar a
   cabo en un mapa que referencia a @c(nil), ya que se comporta como un mapa
   vacio. Pero almacenar en un mapa nil provoca un panico:

   ..src > go
     ages["carol"] = 21 // panic: assignment to entry in nil map
   < src..

   Se debe asignar el mapa antes de poder almacenar en el.

   Acceder a un elemento del mapa mediante subindice siempre produce un
   valor. Si la clave esta presente en el mapa, se obtiene el valor
   correspondiente; si no, se obtiene el valor cero para el tipo de elemento,
   como hemos visto con @c(edades["bob"]). Para muchos propositos eso esta bien,
   pero a veces necesitas saber si el elemento estaba realmente ahi o no. Por
   ejemplo, si el tipo de elemento es numerico, puede que tengas que
   distinguir entre un elemento inexistente y un elemento que tiene el valor
   cero, mediante una prueba como esta:

   ..src > go
     edad, ok := edades["bob"]
     if !ok { /* "bob" no es una clave en este mapa; edad == 0. */ }
   < src..

   Es frecuente ver estas dos declaraciones combinadas, como aqui:

   ..src > go
     if age, ok := ages["bob"]; !ok { /* ... */ }
   < src..

   El subindice de un mapa en este contexto produce dos valores; el segundo es
   un booleano que informa si el elemento estaba presente. La variable booleana
   a menudo se nombra @c(ok), especialmente si se usa inmediatamente en
   una condicion @c(if).

   Como con los slices, los mapas no pueden compararse uno con otro; la unica
   comparacion legal es con @c(nil). Para probar si dos mapas contienen las
   mismas claves y los mismos valores asociados, debemos escribir un bucle:

   ..src > go
     func equal(x, y map[string]int) bool {
       if len(x) != len(y) {
         return false
       }
       for k, xv := range x {
         if yv, ok := y[k]; !ok || yv != xv {
           return false
         }
       }
       return true
     }
   < src..

   Observe como se utiliza @c(!ok) para distinguir los casos @"(que faltan) y
   los @"(presentes, pero en cero). Si hubieramos escrito ingenuamente @c(xv !=
   y[k]), la llamada de abajo reportaria incorrectamente sus argumentos como
   iguales:

   ..src > go
     // Verdadero si equal esta escrito incorrectamente.
     equal(map[string]int{"A": 0}, map[string]int{"B": 42})
   < src..

   Go no proporciona un tipo @c(set), pero ya que las claves de un mapa son
   distintas, un mapa puede servir a este proposito. Para ilustrarlo, el
   programa @$(dedup) lee una secuencia de lineas e imprime solo la primera
   ocurrencia de cada linea distinta. (Es una variante del programa @$(dup) que
   mostramos en la @l(#Seccion 1.3)). El programa @$(dedup) utiliza un mapa
   cuyas claves representan el conjunto de lineas que ya han aparecido para
   asegurar que las ocurrencias posteriores no se impriman.

   ..figure > @l(gopl.io/ch4/dedup/main.go<>gopl.io/ch4/dedup)

     ..src > go
       func main() {
         consulta := make(map[string]bool) // un conjunto de cadenas
         entrada  := bufio.NewScanner(os.Stdin)
         for entrada.Scan() {
           linea := entrada.Text()
           if !consulta[linea] {
             consulta[linea] = true
             fmt.Println(linea)
           }
         }

         if err := entrada.Err(); err != nil {
           fmt.Fprintf(os.Stderr, "dedup: %v\n", err)
           os.Exit(1)
         }
       }
     < src..


   Los programadores de Go a menudo describen un mapa de esta manera
   utilizandolo como un @"(conjunto de cadenas) sin mas, pero
   cuidado, no todos los valores @c(map[string]bool) son conjuntos simples;
   algunos pueden contener valores tanto @c(true) y @c(false).

   A veces necesitamos un mapa o un conjunto cuyas claves sean slices, pero ya que
   las claves de un mapa deben ser comparables, esto se no puede expresar
   directamente. Sin embargo, se puede hacer en dos pasos. Primero definimos una
   funcion auxiliar @c(k) que mapea cada clave en una cadena, con la
   caracteristica que @c[k(x) == k(y)] si y solo si consideramos @c(x) y @c(y)
   equivalentes. Luego creamos un mapa cuyas claves son cadenas, aplicando la
   funcion auxiliar a cada clave antes de acceder al mapa.

   El siguiente ejemplo utiliza un mapa para registrar el numero de veces que se
   ha llamado a @c(Add) con una lista determinada de cadenas. Utiliza @c(fmt.Sprintf)
   para convertir un slice de cadenas en una unica cadena que es una clave de
   mapa adecuada, citando cada elemento del slice con @c(%q) para registrar fielmente
   los limites de las cadena:

   ..src > go
     var m = make(map[string]int)

     func k(list []string) string  { return fmt.Sprintf("%q", list) }

     func Add(list []string)       { m[k(list)]++ }
     func Count(list []string) int { return m[k(list)] }
   < src..

   El mismo enfoque se puede utilizar para cualquier tipo de clave no
   comparable, no solo para slices. Incluso es util para este tipo de claves
   comparables cuando se desea una definicion de igualdad distinta de @c(==),
   como en el caso de comparacion de cadenas que no tienen en cuenta las
   mayusculas y minusculas. Y el tipo de @c[k(x)] no necesita ser una cadena;
   cualquier tipo comparable con la propiedad de equivalencia deseada servira,
   como enteros, arreglos o estructuras.

   Aqui hay otro ejemplo de mapas en accion, un programa que cuenta las
   apariciones de cada punto de codigo Unicode distinto en su entrada. Puesto
   que hay un gran numero de caracteres posibles, solo una pequeña fraccion de
   ellos aparecera en cualquier documento en particular, un mapa es una manera
   natural de hacer un seguimiento de solo los que se han visto y su conteo
   correspondiente.

   ..figure > @l(gopl.io/ch4/charcount/main.go<>gopl.io/ch4/charcount)

     ..src > go
       // Charcount calcula la cuenta de caracteres Unicode.
       package main

       import (
         "bufio"
         "fmt"
         "io"
         "os"
         "unicode"
         "unicode/utf8"
       )

       func main() {
         counts := make(map[rune]int)    // cuenta de caracteres Unicode
         var utflen [utf8.UTFMax + 1]int // cuenta de longitudes de codificaciones UTF-8
         invalid := 0                    // cuenta de caracteres UTF-8 invalidos

         in := bufio.NewReader(os.Stdin)
         for {
           r, n, err := in.ReadRune()    // regresa runa, nbytes, error
           if err == io.EOF {
             break
           }
           if err != nil {
             fmt.Fprintf(os.Stderr, "charcount: %v\n", err)
             os.Exit(1)
           }
           if r == unicode.ReplacementChar && n == 1 {
             invalid++
             continue
           }
           counts[r]++
           utflen[n]++
         }
         fmt.Printf("rune\tcount\n")
         for c, n := range counts {
           fmt.Printf("%q\t%d\n", c, n)
         }
         fmt.Print("\nlen\tcount\n")
         for i, n := range utflen {
           if i > 0 {
             fmt.Printf("%d\t%d\n", i, n)
           }
         }
         if invalid > 0 {
           fmt.Printf("\n%d invalid UTF-8 characters\n", invalid)
         }
       }
     < src..

   El metodo @c(ReadRune) realiza la decodificacion UTF-8 y devuelve tres
   valores: la runa decodificada, la longitud en bytes de su codificacion UTF-8,
   y un valor de error. El unico error que esperamos es el fin de archivo. Si la
   entrada no fue una codificacion UTF-8 legal de una runa, la runa devuelta es
   @c(unicode.ReplacementChar) y la su longitud es 1.

   El programa @$(charcount) tambien imprime un recuento de las longitudes de
   las codificaciones UTF-8 de las runas que aparecieron en la entrada. Un mapa
   no es la mejor estructura de datos para eso; ya que las longitudes de
   codificacion varian solo de 1 a utf8.UTFMax (que tiene el valor 4), un
   arreglo es mas compacto.

   Como experimento, en un momento ejecutamos @$(charcount) en este libro. Aunque
   (originalmente) esta principalmente en Ingles, por supuesto, tiene un buen
   numero de caracteres no ASCII. Aqui estan los diez primeros:

   ..pre >
     ° 27 世 15 界 14 é 13 ˣ 10 ≤ 5 × 5 𢉩 4 � 4 □ 3

   Y aqui esta la distribucion de las longitudes de todas las codificaciones
   UTF-8:

   ..pre >
     len  count
     1    765391
     2    60
     3    70
     4    0
   < pre..

   El tipo de valor de un mapa puede ser un tipo compuesto, como un mapa o un
   slice. En el siguiente codigo, el tipo de la clave de @c(graph) es @c(string)
   y el tipo de valor es @c(map[string]bool), lo que representa un conjunto de
   cadenas. Conceptualmente, @c(graph) asigna una cadena a un conjunto de cadenas
   relacionadas, sus sucesores en un grafo dirigido.

   ..figure > @l(gopl.io/ch4/graph/main.go<>gopl.io/ch4/graph)

     ..src > go
       var graph = make(map[string]map[string]bool)

       func addEdge(from, to string) {
         edges := graph[from]
         if edges == nil {
           edges = make(map[string]bool)
           graph[from] = edges
         }
         edges[to] = true
       }

       func hasEdge(from, to string) bool {
         return graph[from][to]
       }
     < src..


   La funcion @c(addEdge) muestra la forma idiomatica para poblar un mapa
   perezosamente, es decir, para inicializar cada valor como su clave cuando
   aparece por primera vez. La funcion @c(hasEdge) muestra como el valor cero de
   una entrada del mapa que falta se pone a trabajar: incluso si no estan
   precentes ni @c(from) ni @c(to), @c(graph[from][to]) siempre dara un
   resultado significativo.

   @b(Ejercicio 4.8): Modificar @$(charcount) para contar letras, digitos, y
   demas en sus categorias Unicode, utilizando funciones como
   @c(unicode.IsLetter).

   @b(Ejercicio 4.9): Escribir un programa @$(wordfreq) para reportar la
   frecuencia de cada palabra en un archivo de texto de entrada. Llamar a
   @c[input.Split(bufio.ScanWords)] antes de la primer llamada a @c(Scan) para
   romper la entrada en palabras en lugar de lineas.

** Seccion 4.4 <> Estructuras

   Una @e(estructura) es un tipo de datos agregados que agrupa de cero a mas
   valores con nombre de tipos arbitrarios como una entidad unica. Cada valor se
   denomina @e(campo). El ejemplo clasico de una estructura de procesamiento de
   datos es el registro de un empleado, cuyos campos son un identificador unico,
   el nombre del empleado, direccion, fecha de nacimiento, posicion, salario,
   gerente y similares. Todos estos campos se recopilan en una sola entidad que
   puede ser copiada como una unidad, pasada a funciones y devuelta por ellas,
   almacenada en arreglos, y demas.

   Estas dos declaraciones declaran un tipo de estructura llamada @c(Empleado) y una
   variable llamada @c(dilbert) que es una instancia de un @c(Empleado):

   ..src > go
     type Empleado struct {
       ID        int
       Nombre    string
       Direccion string
       DoB       time.Time
       Posicion  string
       Salario   int
       GerenteID int
     }

     var dilbert Empleado
   < src..

   Los campos individuales de @c(dilbert) se accede usando la notacion de punto
   como @c(dilbert.Nombre) y @c(dilbert.DoB). Debido a que @c(dilbert) es una
   variable, sus campos son variables tambien, por lo que podemos asignarlos a un
   campo:

   ..src > go
     dilbert.Salario -= 5000 // Rebajado, por escribir muy pocas lineas de codigo
   < src..

   o tomar su direccion y acceder a ella a traves de un puntero:

   ..src > go
     posicion := &dilbert.Posicion
     *posicion = "Senior " + *posicion // promovido, por la subcontrata a Elbonia
   < src..

   La notacion de punto tambien funciona con un puntero a una estructura:

   ..src > go
     var empleadoDelMes *Empleado = &dilbert
     empleadoDelMes.Posicion += " (proactive team player)"
   < src..

   La ultima sentencia es equivalente a

   ..src > go
     (*empleadoDelMes).Posicion += " (proactive team player)"
   < src..

   Ya que un empleado tiene un ID unico, la funcion @c(EmpleadoPorID) devuelve
   un puntero a una estructura @c(Empleado). Podemos usar la notacion de punto
   para acceder a sus campos:

   ..src > go
     func EmpleadoPorID(id int) *Empleado { /* ... */ }

     fmt.Println(EmpleadoPorID(dilbert.GerenteID).Posicion) // "Jefe de pelo puntiagudo"

     id := dilbert.ID
     EmpleadoPorID(id).Salario = 0 // despedido por... ninguna razon real
   < src..

   La ultima instruccion actualiza la estructura @c(Empleado) a la que apunta el
   resultado de la llamada a @c(EmpleadoPorID). Si el tipo de resultado de
   @c(EmpleadoPorID) se cambiara a @c(Empleado) en lugar de @c(*Empleado), la
   instruccion de asignacion no compilara ya que su lado izquierdo no
   identificaria a una variable.

   Generalmente, se escribe un campo por linea, con el nombre del campo que
   precede a su tipo, pero pueden combinarse los campos consecutivos del mismo
   tipo, como con @c(Nombre) y @c(Direccion):

   ..src > go
     type Empleado struct {
       ID                int
       Nombre, Direccion string
       DoB               time.Time
       Posicion          string
       Salario           int
       GerenteID         int
     }
   < src..

   El orden del campo es significativo para identificar el tipo. Si hubieramos
   combinado tambien la declaracion del campo @c(Posicion) (tambien una cadena),
   o intercambiado @c(Nombre) y @c(Direccion), estariamos definiendo un tipo de
   estructura diferente. Normalmente solo combinamos la declaracion de campos
   relacionados.

   El nombre de un campo en la estructura se exporta si comienza con una letra
   mayuscula; este es el mecanismo principal de control de acceso en Go. Una
   estructura puede contener una mezcla de campos exportados y no exportados.

   Los tipos de estructura tienden a ser detallados porque a menudo implican una
   linea para cada campo. Aunque podriamos escribir todo el tipo cada vez que
   sea necesario, la repeticion cansaria. En cambio, los tipos estructura suelen
   aparecer dentro de la declaracion de un tipo con nombre como @c(Empleado).

   Un tipo de estructura con nombre @c(S) no puede declarar un campo del mismo
   tipo @c(S): un valor agregado no puede contenerse a si mismo. (Una
   restriccion analoga se aplica a los arreglos.) Pero @c(S) puede declarar un
   campo del tipo puntero @c(*S), lo que nos permite crear estructuras de datos
   recursivas como listas enlazadas y arboles. Esto se ilustra en el siguiente
   codigo, que utiliza un arbol binario para implementar un tipo de insercion
   ordenada:

   ..figure > @l(gopl.io/ch4/treesort/sort.go<>gopl.io/ch4/treesort)

     ..src > go
       type tree struct {
         value       int
         left, right *tree
       }

       // Sort ordena los valores en su lugar.
       func Sort(values []int) {
         var root *tree
         for _, v := range values {
           root = add(root, v)
         }
         appendValues(values[:0], root)
       }

       // appendValues agrega los elementos de t a los valores en orden
       // y devuelve el slice resultante.
       func appendValues(values []int, t *tree) []int {
         if t != nil {
           values = appendValues(values, t.left)
           values = append(values, t.value)
           values = appendValues(values, t.right)
         }
         return values
       }

       func add(t *tree, value int) *tree {
         if t == nil {
           // Equivalente a regresar &tree{value: value}.
           t = new(tree)
           t.value = value
           return t
         }
         if value < t.value {
           t.left = add(t.left, value)
         } else {
           t.right = add(t.right, value)
         }
         return t
       }
     < src..


   El valor cero de una estructura se compone de los valores cero de cada uno de
   sus campos. Por lo general, es deseable que el valor cero sea un valor predeterminado
   natural o razonable. Por ejemplo, en @c(bytes.Buffer), el valor inicial de la
   estructura es un buffer vacio listo para su uso, y el valor cero de
   @c(sync.Mutex), que veremos en el @l(#Capitulo 9), es un mutex desbloqueado
   listo para usar. A veces este comportamiento inicial razonable ocurre de
   forma gratuita, pero a veces el diseñador de tipo tiene que trabajar en ello.

   El tipo de una estructura sin campos se denomina @e(estructura vacia), se
   escribe @c(struct{}). Tiene un tamaño cero y no lleva ninguna informacion,
   sin embargo puede ser util. Algunos programadores lo utilizan en lugar de
   @c(bool) como el tipo de valor de un mapa que representa un conjunto, para
   enfatizar que solo las claves son significativas, pero el ahorro de espacio
   es marginal y la sintaxis es mas engorrosa, por lo que generalmente lo
   evitamos.

   ..src > go
     seen := make(map[string]struct{}) // conjunto de strings
     // ...
     if _, ok := seen[s]; !ok {
       seen[s] = struct{}{}
       // ...primera ves viendo s...
     }
   < src..

*** Seccion 4.4.1 <> Estructuras Literales

    Un valor de un tipo de estructura se puede escribir usando una estructura
    literal que especifique los valores de sus campos.

    ..src > go
      type Point struct{ X, Y int }

      p := Point{1, 2}
    < src..

    Hay dos formas de estructura literal. La primer forma, mostrada arriba, requiere
    que se especifique un valor para @e(cada) campo, en el orden correcto. Se
    carga al escritor (y al lector) el recordar exactamente cuales son los
    campos, y hace que el codigo sea fragil si el conjunto de campos crece mas
    tarde o se reordena. En consequencia, esta forma tiende a ser utilizado solo
    dentro del paquete que define el tipo de estructura o con tipos de
    estructuras mas pequeños para los cuales existe una convencion de ordenacion
    de campos obvia, como @c(image.Point{x, y}) o @c(color.RGBA{red, green,
    blue, alpha}).

    Mas a menudo, se utiliza la segunda forma, en la que una estructura se
    inicia haciendo una lista de todos o algunos de los nombres de los campos y
    sus valores correspondientes, como en esta declaracion del programa
    Lissajous de la @l(#Seccion 1.4):

    ..src > go
      anim := gif.GIF{LoopCount: nframes}
    < src..

    Si se omite un campo en este tipo de literal, se establece en el valor cero
    para su tipo. Ya que los nombres se proporcionan, el orden de los campos no
    importa.

    Las dos formas no se pueden mezclar en el mismo literal. Tampoco se puede
    usar la primer forma de literal (basada en ordenes) para colarse alrededor
    de la regla de que los identificadores no exportados no pueden ser referidos
    desde otro paquete.

    ..src > go
      package p
      type T struct{ a, b int } // no se exportan a y b
    < src..

    ..src > go
      package q
      import "p"
      var _ = p.T{a: 1, b: 2} // error de compilacion: no se puede referenciar a, b
      var _ = p.T{1, 2}       // error de compilacion: no se puede referenciar a, b
    < src..

    Aunque la ultima linea no menciona los identificadores de campo no
    exportados, realmente los esta usando implicitamente, asi que no esta
    permitido.

    Los valores de una estructura se pueden pasar como argumentos a funciones y
    ser devueltos de ellas. Por ejemplo, esta funcion escala un @c(Point) por un factor
    especificado:

    ..src > go
      func Scale(p Point, factor int) Point {
        return Point{p.X * factor, p.Y * factor}
      }

      fmt.Println(Scale(Point{1, 2}, 5)) // "{5 10}"
    < src..

    Por eficiencia, las estructuras mas grandes normalmente se pasan a las
    funciones o se devuelven indirectamente mediante un puntero,

    ..src > go
      func Bonus(e *Empleado, porcentage int) int {
        return e.Salario * porcentage / 100
      }
    < src..

    Y esto es necesario si la funcion debe modificar su argumento, ya que en un
    lenguaje de llamada por valor como Go, la funcion llamada recibe solo una
    copia, no una referencia al argumento original.

    ..src > go
      func PremioAnualAumento(e *Empleado) {
        e.Salario = e.Salario * 105 / 100
      }
    < src..

    Debido a que las estructuras se manejan tan comunmente a traves de punteros, es
    posible utilizar esta notacion compacta para crear e inicializar una
    estructura y obtener su direccion:

    ..src > go
      pp := &Point{1, 2}
    < src..

    Es exactamente equivalente a

    ..src > go
      pp := new(Point)
      *pp = Point{1, 2}
    < src..

    pero @c(&Point{1, 2}) se puede utilizar directamente dentro de una
    expresion, como una llamada de funcion.

*** Seccion 4.4.2 <> Comparacion de Estructuras

    Si todos los campos de una estructura son comparables, la estructura en si
    es comparable, por lo que dos expresiones de ese tipo pueden ser comparadas
    usando @c(==) o @c(!=). La operacion @c(==) compara los campos
    correspondientes de las dos estructuras en orden, por lo que las dos
    expresiones a continuacion son equivalentes:

    ..src > go
      type Point struct{ X, Y int }

      p := Point{1, 2}
      q := Point{2, 1}
      fmt.Println(p.X == q.X && p.Y == q.Y) // "false"
      fmt.Println(p == q)                   // "false"
    < src..

    Las estructuras de tipos comparables, al igual que otros tipos comparables,
    se pueden utilizar como la clave de un mapa.

    ..src > go
      type address struct {
        hostname string
        port     int
      }

      hits := make(map[address]int)
      hits[address{"golang.org", 443}]++
    < src..

*** Seccion 4.4.3 <> Estructura Enbebida y Campos Anonimos

    En esta seccion, veremos como utilizar el inusual mecanismo de @e(estructura
    enbebida) de Go que nos permite usar una estructura como un @e(campo
    anonimo) de otra estructura, proporcionando un acceso directo,
    sintacticamente conveniente para que una simple expresion de punto como
    @c(x.f) pueda representar una cadena de campos como @c(x.d.e.f).

    Considere un programa de dibujo 2-D que proporciona una libreria de formas,
    como rectangulos, elipses, estrellas y ruedas. Aqui hay dos de los tipos que
    podria definir:

    ..src > go
      type Circulo struct {
        X, Y, Radio int
      }
      type Rueda struct {
        X, Y, Radio, Rayos int
      }
    < src..

    Un @c(Circulo) tiene campos para las coordenadas de su centro @c(X) y @c(Y),
    y un @c(Radio). Una @c(Rueda) tiene todas las caracteristicas de un
    @c(Circulo), ademas de @c(Rayos), el numero de radios radiales inscritos.
    Vamos a crear una rueda:

    ..src > go
      var r Rueda
      r.X = 8
      r.Y = 8
      r.Radio = 5
      r.Rayos = 20
    < src..

    A medida que el conjunto de formas crece, estamos obligados a notar
    semejanzas y repeticiones entre ellos, por lo que puede ser conveniente
    factorizar sus partes comunes:

    ..src > go
      type Punto struct {
        X, Y int
      }

      type Circulo struct {
        Centro Punto
        Radio  int
      }

      type Rueda struct {
        Circulo Circulo
        Rayos   int
      }
    < src..

    Con esto la aplicacion puede ser mas clara, pero este cambio hace que el
    acceso a los campos de una Rueda sea mas detallado:

    ..src > go
      var r Rueda
      r.Circulo.Centro.X = 8
      r.Circulo.Centro.Y = 8
      r.Circulo.Radio = 5
      r.Rayos = 20
    < src..

    Go nos permite declarar un campo con un tipo pero sin nombre; estos campos
    se denominan campos anonimos. El tipo del campo debe ser un tipo con nombre
    o un puntero a un tipo con nombre. Debajo, @c(Circulo) y @c(Rueda) tienen un
    campo anonimo cada uno. Se dice que un @c(Punto) esta enbebido dentro del
    @c(Circulo), y un @c(Circulo) esta enbebido dentro de la @c(Rueda).

    ..src > go
      type Circulo struct {
        Punto
        Radio int
      }

      type Rueda struct {
        Circulo
        Rayos   int
      }
    < src..

    Gracias al embebido, podemos referirnos a los nombres en las hojas
    del arbol implicitamente sin dar los nombres intermedios:

    ..src > go
      var r Rueda
      r.X = 8        // equivalente a r.Circulo.Punto.X = 8
      r.Y = 8        // equivalente a r.Circulo.Punto.Y = 8
      r.Radio = 5    // equivalente a r.Circulo.Radio = 5
      r.Rayos = 20
    < src..

    Las formas explicitas que se muestran en los comentarios anteriores siguen
    siendo validas, sin embargo, demuestra que @"(campo anonimo) es un termino
    inapropiado. Los campos @c(Circulo) y @c(Punto) tienen nombres–del tipo
    nombrado–pero esos nombres son opcionales en las expresiones de punto.
    Podemos omitir cualquiera o todos los campos anonimos al seleccionar sus
    subcampos.

    Desafortunadamente, no hay una sintaxis compacta correspondiente para una
    estructura literal, por lo que ninguna de ellas compilara:

    ..src > go
      r = Rueda{8, 8, 5, 20}                       // error de compilacion: campos desconocidos
      r = Rueda{X: 8, Y: 8, Radius: 5, Spokes: 20} // error de compilacion: campos desconocidos
    < src..

    La estructura literal debe seguir el formato de la declaracion del tipo, por
    lo que debemos utilizar una de las siguientes dos formas, que son
    equivalentes entre si:

    ..figure > @l(gopl.io/ch4/embed/main.go<>gopl.io/ch4/embed)

      ..src > go
          r = Rueda{Circulo{Punto{8, 8}, 5}, 20}

          r = Rueda{
            Circulo: Circulo{
              Punto: Punto{X: 8, Y: 8},
              Radio: 5,
            },
            Rayos: 20, // NOTA: comma necesaria aqui (y en Radio)
          }

          fmt.Printf("%#v\n", r)
          // Salida:
          // Rueda{Circulo:Circulo{Punto:Punto{X:8, Y:8}, Radio:5}, Rayos:20}

          r.X = 42

          fmt.Printf("%#v\n", r)
          // Salida:
          // Rueda{Circulo:Circulo{Punto:Punto{X:42, Y:8}, Radio:5}, Rayos:20}
      < src..

    Observe como el adverbio @c(#) hace que el verbo @c(%v) de @c(Printf)
    muestre los valores en una forma similar a la sintaxis Go. Para los valores
    de estructura, este formato incluye el nombre de cada campo.

    Dado que los campos @"(anonimos) tienen nombres implicitos, no se puede
    tener dos campos anonimos del mismo tipo, ya que sus nombres entran en
    conflicto. Y debido a que el nombre del campo esta implicitamente
    determinado por su tipo, tambien lo es la visibilidad del campo. En los
    ejemplos anteriores, se exportan los campos anonimos @c(Punto) y
    @c(Circulo). Si no se hubieran exportado (@c(punto) y @c(circulo)),
    tadavia podriamos utilizar la forma compacta

    ..src > go
      r.X = 8 // equivalente a r.circulo.punto.X = 8
    < src..

    pero el fomato explicito que se muestra en el comentario estaria prohibido
    fuera del paquete porque @c(circulo) y @c(punto) serian inaccesibles.

    Lo que hemos visto hasta ahora sobre las estructuras enbebidas es solo una pisca
    de azucar sintactico en la notacion de punto utilizada para seleccionar los
    campos de la estructura. Mas adelante, veremos que los campos anonimos no
    necesitan ser de tipo estructura; puede ser cualquier tipo con nombre o
    puntero a un tipo con nombre. Pero, ¿para que querrias incorporar un tipo
    que no tiene subcampos?

    La respuesta tiene que ver con los metodos. La notacion compacta utilizada
    para seleccionar los campos de un tipo enbebido funciona tambien para seleccionar
    sus metodos. En efecto, el tipo de estructura externa gana no solo
    los campos del tipo enbebido sino tambien sus metodos. Este mecanismo es la
    forma principal en que los comportamientos de objetos complejos se componen
    de los mas simples. La composicion es fundamental para la programacion
    orientada a objetos en Go, y la exploraremos mas adelante en la @l(#Seccion
    6.3).

** Seccion 4.5 <> JSON

   JavaScript Object Notation (JSON) es una notacion estandar para enviar y
   recibir informacion estructurada. JSON no es la unica notacion. XML
   @%l(#Seccion 7.14<>§7.14), ASN.1, y Google’s Protocol Buffers sirven a
   propositos similares y cada uno tiene su nicho, pero debido a su simplicidad,
   facilidad de lectura, y un apoyo universal, JSON es el mas utilizado.

   Go tiene un excelente soporte para la codificacion y decodificacion de estos
   formatos, proporcionado por los paquetes de las librerias estandar
   @c(encoding/json), @c(encoding/xml), @c(encoding/asn1), etc., y todos
   estos paquetes tienen APIs similares. En esta seccion se presenta una breve
   descripcion de las partes mas importantes del paquete @c(encoding/json).

   JSON es una codificacion de valores JavaScript–cadenas, numeros, booleanos,
   arreglos y objetos–como texto Unicode. Es una representacion eficiente pero
   legible para los tipos de datos basicos del @l(#Capitulo 3) y los tipos
   compuestos de este capitulo–arreglos, slices, estructuras, y mapas.

   Los tipos basicos de JSON son numeros (en notacion decimal o cientifica),
   booleanos (@c(true) o @c(false)), y cadenas, que son secuencias de puntos de
   codigo Unicode entre comillas dobles, con escapes mediante la barra invertida
   utilizando una notacion similar a Go, aunque los escapes JSON @c(\u)@e(hhhh)
   denotan codigos UTF-16, no runas.

   Estos tipos basicos se pueden combinar recursivamente utilizando arreglos
   y objetos JSON. Un arreglo JSON es una secuencia ordenada de valores, escrita
   como una lista separada por comas entre corchetes; los arreglos JSON se
   utilizan para codificar arreglos Go y slices. Un objeto JSON es un mapeo de
   cadenas a valores, escrito como una secuencia de pares @c(nombre:valor)
   separados por comas y rodeados por llaves; los objetos JSON se usan para
   codificar mapas Go (con claves de tipo cadena) y estructuras. Por ejemplo:

   +--------------+------------------------------------------+
   | @c(booleano) | @c(true)                                 |
   +--------------+------------------------------------------+
   | @c(numero)   | @c(-273.15)                              |
   +--------------+------------------------------------------+
   | @c(cadena)   | @c("She said \"Hello,  世界\"")            |
   +--------------+------------------------------------------+
   | @c(arreglo)  | @c(["gold", "silver", "bronze"])         |
   +--------------+------------------------------------------+
   | @c(objeto)   | @c({"year": 1980,                        |
   |              | "event": "archery",                      |
   |              | "medals": ["gold", "silver", "bronze"]}) |
   +--------------+------------------------------------------+


   Considere una aplicacion que reuna reseñas de peliculas y ofrezca
   recomendaciones. A continuacion se declara un tipo de datos @c(Movie) y luego
   una lista de estos valores. (Los literales de cadena despues de las
   declaraciones @c(Year) y @c(Color) son etiquetas de campo; las explicaremos
   en un momento.)

   ..figure > @l(gopl.io/ch4/movie/main.go<>gopl.io/ch4/movie)

     ..src > go
       type Movie struct {
         Title  string
         Year   int  `json:"released"`
         Color  bool `json:"color,omitempty"`
         Actors []string
       }

       var movies = []Movie{
         {Title: "Casablanca", Year: 1942, Color: false,
           Actors: []string{"Humphrey Bogart", "Ingrid Bergman"}},
         {Title: "Cool Hand Luke", Year: 1967, Color: true,
           Actors: []string{"Paul Newman"}},
         {Title: "Bullitt", Year: 1968, Color: true,
           Actors: []string{"Steve McQueen", "Jacqueline Bisset"}},
         // ...
       }
     < src..


   Las estructuras de datos como esta son un excelente ajuste para JSON, y es
   facil de convertir en ambas direcciones. Convertir una estructura de datos Go
   como @c(movies) a JSON se denomina @e(marshaling). El marshaling se realiza
   con @c(json.Marshal):

   ..src > go
     data, err := json.Marshal(movies)
     if err != nil {
       log.Fatalf("JSON marshaling failed: %s", err)
     }
     fmt.Printf("%s\n", data)
   < src..

   @c(Marshal) produce un slice de bytes que contiene una cadena muy grande sin
   ningun espacio en blanco:

   ..src > go
     [{"Title":"Casablanca","released":1942,"Actors":["Humphrey Bogart","Ingrid Bergman"]},{"Title":"Cool Hand Luke","released":1967,"color":true,"Actors":["Paul Newman"]},{"Title":"Bullitt","released":1968,"color":true,"Actors":["Steve McQueen","Jacqueline Bisset"]}]
   < src..

   Esta representacion compacta contiene toda la informacion, pero es dificil de
   leer. Para el consumo humano, una variante llamada @c(json.MarshalIndent)
   produce una salida perfectamente indentada. Dos argumentos adicionales
   definen un prefijo para cada linea de salida y una cadena para cada nivel de
   indentacion:

   ..src > go
     data, err := json.MarshalIndent(movies, "", "    ")
     if err != nil {
       log.Fatalf("JSON marshaling failed: %s", err)
     }
     fmt.Printf("%s\n", data)
   < src..

   El codigo anterior imprime

   ..src > go
     [
         {
             "Title": "Casablanca",
             "released": 1942,
             "Actors": [
                 "Humphrey Bogart",
                 "Ingrid Bergman"
             ]
         },
         {
             "Title": "Cool Hand Luke",
             "released": 1967,
             "color": true,
             "Actors": [
                 "Paul Newman"
             ]
         },
         {
             "Title": "Bullitt",
             "released": 1968,
             "color": true,
             "Actors": [
                 "Steve McQueen",
                 "Jacqueline Bisset"
             ]
         }
     ]
   < src..

   Marshaling utiliza los nombres de los campos en la estructura Go como los
   nombres de campo de los objetos JSON (mediante @e(reflexion), como veremos en
   la @l(#Seccion 12.6)). Solo se exportan los campos exportables, por lo que
   elegimos nombres en mayusculas para todos los nombres de campo.

   Habra notado que el nombre del campo @c(Year) cambia a @c(released) en la
   salida, y @c(Color) cambia a @c(color). Eso es debido a las etiquetas de los
   campos. Una etiqueta de campo es una cadena de metadatos asociados en tiempo
   de compilacion con el campo de una estructura:

   ..src > go
     Year  int  `json:"released"`
     Color bool `json:"color,omitempty"`
   < src..

   Una etiqueta de campo puede ser cualquier cadena literal, pero se interpreta
   convencionalmente como una lista separada por espacios de pares
   @c(clave:"valor"); ya que contiene comillas dobles, las etiquetas de campo
   normalmente se escriben con literales de cadena sin formato. La clave
   @c(json) controla el comportamiento del paquete @c(encoding/json), y otros
   paquetes @c(encoding/...) siguen esta convencion. La primera parte de la
   etiqueta de campo @c(json) especifica un nombre JSON alternativo para el
   campo Go. Las etiquetas de los campos a menudo se utilizan para especificar
   un nombre JSON idiomatico como @c(total_count) para un campo Go llamado
   @c(TotalCount). La etiqueta @c(Color) tiene una opcion adicional,
   @c(omitempty), lo que indica que no se debe producir ninguna salida JSON si
   el campo tiene el valor cero para su tipo (@c(false), aqui) o esta
   vacia. Efectivamente, la salida JSON para Casablanca, una pelicula en blanco
   y negro, no tiene el campo @c(color).

   La operacion inversa de marshaling, decodificar JSON y poblar
   una estructura de datos Go, se denomina @e(unmarshaling), y se realiza con
   @c(json.Unmarshal). El codigo de abajo aplica unmarshaling sobre los datos de
   las peliculas JSON en un slice de estructuras cuyo unico campo es @c(Title). De
   esta manera, al definir estructuras de datos Go adecuadas, podemos
   seleccionar que partes de la entrada JSON se deben descifrar y cuales
   descartar. Cuando @c(Unmarshal) regresa, se ha llenado el slice con la
   informacion de @c(Title); otros nombres en el JSON se ignoran.

   ..src > go
     var titles []struct{ Title string }
     if err := json.Unmarshal(data, &titles); err != nil {
       log.Fatalf("JSON unmarshaling failed: %s", err)
     }
     fmt.Println(titles) // "[{Casablanca} {Cool Hand Luke} {Bullitt}]"
   < src..

   Muchos servicios web proporcionan una interfaz JSON–se hace una solicitud con
   HTTP y devuelve la informacion deseada en formato JSON. Para ilustrarlo,
   vamos a consultar el seguimiento de problemas en GitHub con su interfaz de
   servicio web. Primero definiremos los tipos y constantes necesarios:

   ..figure > @l(gopl.io/ch4/github/github.go<>gopl.io/ch4/github)

     ..src > go
       // El paquete github proporciana una API en Go para el seguimiento de issues.
       // Ver https://developer.github.com/v3/search/#search-issues.
       package github

       import "time"

       const IssuesURL = "https://api.github.com/search/issues"

       type IssuesSearchResult struct {
         TotalCount int `json:"total_count"`
         Items      []*Issue
       }

       type Issue struct {
         Number    int
         HTMLURL   string `json:"html_url"`
         Title     string
         State     string
         User      *User
         CreatedAt time.Time `json:"created_at"`
         Body      string    // En formato Markdown
       }

       type User struct {
         Login   string
         HTMLURL string `json:"html_url"`
       }
     < src..


   Como antes, los nombres de todos los campos de estructura deben estar en
   mayuscula incluso si sus nombres JSON no. Sin embargo, el proceso de
   coincidencia que asocia los nombres de JSON con los nombres de una estructura
   de Go durante el unmarshaling no distingue entre mayusculas y minusculas, por
   lo que solo es necesario utilizar una etiqueta de campo cuando hay un
   guion bajo en el nombre JSON pero no en el nombre Go. Una vez mas, estamos
   siendo selectivos acerca de que campos decodificar; la respuesta de busqueda
   de GitHub contiene considerablemente mas informacion de la que mostramos
   aqui.

   La funcion @c(SearchIssues) realiza una peticion HTTP y decodifica el
   resultado como JSON. Puesto que los terminos de consulta presentados por un
   usuario pueden contener caracteres como @c(?) y @c(&) que tienen un
   significado especial en una URL, usamos @c(url.QueryEscape) para asegurarnos de
   que se toman literalmente.

   ..figure > @l(gopl.io/ch4/github/search.go<>gopl.io/ch4/github)

     ..src > go
       package github

       import (
         "encoding/json"
         "fmt"
         "net/http"
         "net/url"
         "strings"
       )

       // SearchIssues consulta el seguimiento de problemas de GitHub.
       func SearchIssues(terms []string) (*IssuesSearchResult, error) {
         q := url.QueryEscape(strings.Join(terms, " "))
         resp, err := http.Get(IssuesURL + "?q=" + q)
         if err != nil {
           return nil, err
         }

         // Debemos cerrar resp.Body en todas las rutas de ejecucion.
         // (El Capitulo 5 presenta 'defer', lo que simplifica esto.)
         if resp.StatusCode != http.StatusOK {
           resp.Body.Close()
           return nil, fmt.Errorf("search query failed: %s", resp.Status)
         }

         var result IssuesSearchResult
         if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
           resp.Body.Close()
           return nil, err
         }
         resp.Body.Close()
         return &result, nil
       }
     < src..


   Los ejemplos anteriores utilizaron @c(json.Unmarshal) para decodificar todo
   el contenido de un slice de bytes como una sola entidad JSON. Para variar,
   este ejemplo utiliza el decodificador de @e(flujo), @c(json.Decoder), que
   permite que varias entidades JSON sean decodificados en secuencia desde el
   mismo flujo, aunque aqui no necesitamos esa caracteristica. Como era de
   esperar, hay un codificador de flujo correspondiente llamado @c(json.Encoder).

   La llamada a @c(Decode) rellena la variable @c(result). Hay varias maneras en
   que podemos dar un formato agradable a su valor. A continuacion mostramos el
   mas simple, con el commando @c(issues), es como una tabla de texto con
   columnas de ancho fijo, pero en la siguiente seccion vamos a ver un enfoque
   mas sofisticado basado en plantillas.

   ..figure > @l(gopl.io/ch4/issues/main.go<>gopl.io/ch4/issues)

     ..src > go
       // Issues imprime una tabla de coincidencia de problemas que coinciden
       // con los terminos de busqueda
       package main

       import (
         "fmt"
         "log"
         "os"

         "gopl.io/ch4/github"
       )

       func main() {
         result, err := github.SearchIssues(os.Args[1:])
         if err != nil {
           log.Fatal(err)
         }
         fmt.Printf("%d issues:\n", result.TotalCount)
         for _, item := range result.Items {
           fmt.Printf("#%-5d %9.9s %.55s\n",
             item.Number, item.User.Login, item.Title)
         }
       }
     < src..


   Los argumentos de linea de comandos especifican los terminos de busqueda. El
   comando siguiente consulta el rastreador de problemas del proyecto Go para la
   lista de errores abiertos relacionados con la descodificacion JSON:

   ..srci > sh
     > go build gopl.io/ch4/issues
     > ./issues repo:golang/go is:open json decoder
     13 issues:
     #5680    eaigner encoding/json: set key converter on en/decoder
     #6050  gopherbot encoding/json: provide tokenizer
     #8658  gopherbot encoding/json: use bufio
     #8462  kortschak encoding/json: UnmarshalText confuses json.Unmarshal
     #5901        rsc encoding/json: allow override type marshaling
     #9812  klauspost encoding/json: string tag not symmetric
     #7872  extempora encoding/json: Encoder internally buffers full output
     #9650    cespare encoding/json: Decoding gives errPhase when unmarshalin
     #6716  gopherbot encoding/json: include field name in unmarshal error me
     #6901  lukescott encoding/json, encoding/xml: option to treat unknown fi
     #6384    joeshaw encoding/json: encode precise floating point integers u
     #6647    btracey x/tools/cmd/godoc: display type kind of each named type
     #4237  gjemiller encoding/base64: URLEncoding padding is optional
   < srci..

   La interfaz de servicio web en GitHub @l(https://developer.github.com/v3/)
   tiene muchas mas funciones de las que tenemos espacio para mostrar aqui.

   @b(Ejercicio 4.10): Modificar @c(issues) para reportar los resultados en
   categorias de edad, es decir menos de un mes de edad, menos de un año de
   edad, y mas de un año de edad.

   @b(Ejercicio 4.11): Construir una herramienta que permite a los usuarios
   crear, leer, actualizar y eliminar los problemas de GitHub desde la linea de
   comandos, invocando su editor de texto preferido cuando se requiera la
   introduccion de texto sustancial.

   @b(Ejercicio 4.12): El popular comic web @e(xkcd) tiene una interfaz
   JSON. Por ejemplo, una solicitud a @l(https://xkcd.com/571/info.0.json)
   produce una descripcion detallada del comic 571, uno de mis muchos
   favoritos. Descargue cada URL (una vez) y construya un indice sin
   conexion. Escriba una herramienta @$(xkcd) que, utilizando este indice,
   imprima la URL y transcripcion de cada comic que coincida con un termino de
   busqueda proporcionado en la linea de comandos.

   @b(Ejercicio 4.13): El servicio web basado en JSON de Open Movie Database le
   permite buscar en @l(https://omdbapi.com/) una pelicula por su nombre y
   descargar su imagen de poster. Escriba una herramienta @$(poster) que
   descargue la imagen del poster de la pelicula que se nombre en la linea de
   comandos.

** Seccion 4.6 <> Plantillas de Texto y HTML

   El ejemplo anterior muestra como hacer el formato lo mas simple posible, para
   lo cual @c(Printf) es totalmente adecuado. Pero a veces el formato debe
   ser mas elaborado, y es deseable separar el formato del codigo completamente.
   Esto se puede hacer con los paquetes @c(text/template) y @c(html/template),
   que proporcionan un mecanismo para sustituir los valores de las
   variables en una plantilla de texto o HTML.

   Una plantilla es una cadena o un archivo que contiene una o mas partes
   encerradas entre llaves dobles, @c({{...}}), llamadas @e(acciones). La mayor
   parte de la cadena se imprime literalmente, pero las acciones desencadenan
   otros comportamientos. Cada accion contiene una expresion en el lenguaje de
   la plantilla, una notacion sencilla pero poderosa para imprimir valores,
   seleccionar campos de la estructura, llamar a funciones y metodos, expresar
   el flujo de control, como las sentencias @c(if)-@c(else) y bucles @c(range),
   e instanciar otras plantillas. A continuacion se muestra una cadena de
   plantilla simple:

   ..figure > @l(gopl.io/ch4/issuesreport/main.go<>gopl.io/ch4/issuesreport)

     ..src > go
       const templ = `{{.TotalCount}} issues:
       {{range .Items}}----------------------------------------
       Number: {{.Number}}
       User:   {{.User.Login}}
       Title:  {{.Title | printf "%.64s"}}
       Age:    {{.CreatedAt | daysAgo}} days
       {{end}}`
     < src..


   Esta plantilla primero imprime el numero de problemas encontrados, luego
   imprime el numero, usuario, titulo y edad en dias de cada uno. Dentro de una
   accion, hay una nocion del valor actual, denominado como @"(punto) y escrita
   como @"c(.), un punto. El punto se refiere inicialmente al parametro de la
   plantilla, que sera en este ejemplo @c(github.IssuesSearchResult). La accion
   @c({{.TotalCount}}) expande al valor del campo @c(TotalCount), que se imprime
   en la forma habitual. Las acciones @c({{range .Items}}) y @c({{end}}) crean
   un bucle, por lo que el texto entre ellos se expande varias veces, con el
   punto ligado a elementos sucesivos de @c(Items).

   Dentro de una accion, la notacion @c(|) hace que el resultado de una
   operacion sea el argumento de otra, analoga a una tuberia del shell
   Unix. En el caso de @c(Title), la segunda operacion es la funcion @c(printf),
   que es un sinonimo nativo para @c(fmt.Sprintf) en todas las plantillas. Para
   @c(Age), la segunda operacion es la funcion, @c(daysAgo), que convierte el
   campo @c(CreatedAt) en el tiempo transcurrido, utilizando @c(time.Since):

   ..src > go
     func daysAgo(t time.Time) int {
       return int(time.Since(t).Hours() / 24)
     }
   < src..

   Observe que el tipo de @c(CreatedAt) es @c(time.Time), no @c(string). Del
   mismo modo que un tipo puede controlar su formato de cadena @%l(#Seccion
   2.5<>§2.5) mediante la definicion de ciertos metodos, un tipo puede definir
   tambien metodos para controlar su comportamiento para el marshaling y
   unmarshaling JSON. El valor marshaling JSON de un @c(time.Time) es una cadena
   en un formato estandar.

   Producir la salida con una plantilla es un proceso de dos pasos. Primero
   debemos analizar la plantilla en una representacion interna adecuada, y luego
   ejecutarla con entradas especificas. El analisis se debe hacer solo una
   vez. El siguiente codigo crea y analiza la plantilla @c(templ) definida
   anteriormente. Observe el encadenamiento de llamadas a metodos:
   @c(template.New) crea y devuelve una plantilla; @c(Funcs) añade @c(daysAgo)
   al conjunto de funciones accesibles dentro de esta plantilla, luego, devuelve
   esa plantilla; por ultimo, se llama a @c(Parse) sobre el resultado.

   ..src > go
     report, err := template.New("report").
       Funcs(template.FuncMap{"daysAgo": daysAgo}).
       Parse(templ)
     if err != nil {
       log.Fatal(err)
     }
   < src..

   Dado que las plantillas suelen fijarse en tiempo de compilacion, la falta de
   analisis de una plantilla indica un error fatal en el programa. La funcion
   auxiliar @c(template.Must) hace que el manejo de errores sea mas conveniente:
   acepta una plantilla y un error, comprueba que el error es nil (y entra en
   panico de lo contrario) y, luego devuelve la plantilla. Volveremos a esta
   idea en la @l(#Seccion 5.9).

   Una vez la plantilla ha sido creada, aumentada con @c(daysAgo), analizada y
   comprobada, podemos ejecutarla utilizando como fuente de datos
   @c(github.IssuesSearchResult) y @c(os.Stdout) como destino:

   ..src > go
     var report = template.Must(template.New("issuelist").
       Funcs(template.FuncMap{"daysAgo": daysAgo}).
       Parse(templ))

     func main() {
       result, err := github.SearchIssues(os.Args[1:])
       if err != nil {
         log.Fatal(err)
       }
       if err := report.Execute(os.Stdout, result); err != nil {
         log.Fatal(err)
       }
     }
   < src..

   El programa imprime un informe en texto plano como este:

   ..srci > sh
     > go build gopl.io/ch4/issuesreport
     > ./issuesreport repo:golang/go is:open json decoder
     13 issues:
     ---------------------------------------
     Number: 5680
     User:   eaigner
     Title:  encoding/json: set key converter on en/decoder
     Age:    750 days
     ---------------------------------------
     Number: 6050
     User:   gopherbot
     Title:  encoding/json: provide tokenizer
     Age:    695 days
     ---------------------------------------
     ...
   < srci..

   Ahora pasemos al paquete @c(html/template). Utiliza el mismo API y el mismo
   lenguaje de expresion que @c(text/template) pero añade caracteristicas para
   el escape automatico y apropiado de cadanes que aparecen dentro de HTML,
   JavaScript, CSS o URLs. Estas caracteristicas pueden ayudar a evitar un
   problema de seguridad perenne de la generacion de HTML, un @e(ataque de
   inyeccion), en el que un adversario crea un valor de cadena como el titulo de
   un tema, para incluir codigo malicioso, que cuando se escapa indebidamente
   por una plantilla, le da control sobre la pagina.

   La plantilla siguiente imprime la lista de problemas como una tabla HTML.
   Observe la diferente importacion:

   ..figure > @l(gopl.io/ch4/issueshtml/main.go<>gopl.io/ch4/issueshtml)

     ..src > go
       import "html/template"

       var issueList = template.Must(template.New("issuelist").Parse(`
       <h1>{{.TotalCount}} issues</h1>
       <table>
       <tr style='text-align: left'>
         <th>#</th>
         <th>State</th>
         <th>User</th>
         <th>Title</th>
       </tr>
       {{range .Items}}
       <tr>
         <td><a href='{{.HTMLURL}}'>{{.Number}}</a></td>
         <td>{{.State}}</td>
         <td><a href='{{.User.HTMLURL}}'>{{.User.Login}}</a></td>
         <td><a href='{{.HTMLURL}}'>{{.Title}}</a></td>
       </tr>
       {{end}}
       </table>
       `))
     < src..


   El siguiente comando ejecuta la nueva plantilla sobre los resultados de una
   consulta ligeramente diferente:

   ..srci > sh
     > go build gopl.io/ch4/issueshtml
     > ./issueshtml repo:golang/go commenter:gopherbot json encoder >issues.html
   < srci..

   La Figura 4.4 muestra la apariencia de la tabla en un navegador web. Los
   enlaces se conectan a las paginas web apropiadas en GitHub.

   ..figure > Figura 4.4. Una tabla HTML de los temas del proyecto Go
     relacionados con la codificacion JSON.

     ..img > img/Figure-4.4.jpg

   Ninguno de los temas en la Figura 4.4 representan un desafio para HTML, pero
   podemos ver el efecto mas claramente con temas cuyos titulos contienen
   metacaracteres HTML como @c(&) y @c(<). Hemos seleccionado dos problemas para
   este ejemplo:

   ..srci > sh
     > ./issueshtml repo:golang/go 3133 10535 >issues2.html
   < srci..

   La Figura 4.5 muestra el resultado de esta consulta. Observe que el paquete
   @c(html/template) de forma automatica escapa los titulos HTML de modo que
   aparezcan literalmente. Si por error hubieramos usado el paquete
   @c(text/template), la cadena de cuatro caracteres "&lt;" se habria convertido
   en el caracter @c('<') y la cadena @c("<link>") se habria convertido en un
   elemento @c(link), cambiando la estructura del documento HTML y tal vez
   comprometiendo su seguridad.

   Podemos suprimir este comportamiento de auto-escape para los campos que
   contienen datos HTML confiables mediante el uso de un  tipo de cadena
   denominada @c(template.HTML) en lugar de @c(string). Existen tipos con nombres
   similares para JavaScript, CSS y URLs de confianza. El siguiente programa
   demuestra el principio usando campos con el mismo valor, pero
   con diferentes tipos: @c(A) es un @c(string) y @c(B) es un @c(template.HTML).

   ..figure > Figura 4.5. Los metacaracteres HTML del titulos de temas se
     muestran correctamente.

     ..img > img/Figure-4.5.jpg

   ..figure > @l(gopl.io/ch4/autoescape/main.go<>gopl.io/ch4/autoescape)

     ..src > go
       func main() {
         const templ = `<p>A: {{.A}}</p><p>B: {{.B}}</p>`
         t := template.Must(template.New("escape").Parse(templ))
         var data struct {
           A string        // texto sin fiavilidad
           B template.HTML // HTML confiable
         }
         data.A = "<b>Hello!</b>"
         data.B = "<b>Hello!</b>"
         if err := t.Execute(os.Stdout, data); err != nil {
           log.Fatal(err)
         }
       }
     < src..


   La Figura 4.6 muestra la salida de la plantilla tal como aparece en un
   navegador. Podemos ver que @c(A) es sujeto a escape, pero @c(B) no.

   ..figure > Figura 4.6. Los valores de cadena tinen escapes HTML,
     pero los valores @c(template.HTML) no.

     ..img > img/Figure-4.6.jpg

   Tenemos espacio aqui para mostrar solo las caracteristicas mas basicas del
   sistema de plantillas. Como siempre, para obtener mas informacion, consulte
   la documentacion del paquete:

   ..srci > sh
     > go doc text/template
     > go doc html/template
   < srci..

   @b(Ejercicio 4.14): Crear un servidor web que consulta GitHub una vez y luego
   permita la navegacion de la lista de informe de errores, hitos y usuarios.

* Capitulo 5 <> Funciones

  Una funcion nos permite envolver una secuencia de sentencias como una unidad
  que se puede llamar desde cualquier lugar de un programa, tal vez varias
  veces. Las funciones hacen posible romper un gran trabajo en pedazos mas
  pequeños que bien podrian ser escritos por diferentes personas separadas por
  el tiempo y el espacio. Una funcion oculta sus detalles de implementacion a
  sus usuarios. Por todas estas razones, las funciones son una parte critica de
  cualquier lenguaje de programacion.

  Ya hemos visto muchas funciones. Ahora tomaremos un tiempo para una discusion
  mas exhaustiva. El ejemplo de ejecucion de este capitulo es un rastreador web,
  es decir, el componente de un motor de busqueda web responsable de buscar
  paginas web, descubrir los vinculos dentro de ellas, buscar las paginas
  identificadas por dichos vinculos, etc. Un rastreador web nos da una amplia
  oportunidad para explorar la recursividad, funciones anonimas, manejo de
  errores y aspectos de funciones que son unicos de Go.

** Seccion 5.1 <> Declaracion de Funciones

   Una declaracion de funcion tiene un nombre, una lista de parametros, una
   lista opcional de resultados y un cuerpo:

   ..src > go
     func nombre(lista-de-parametros) (lista-de-resultados) {
       cuerpo
     }
   < src..

   La lista de parametros especifica los nombres y tipos de los @e(parametros)
   de la funcion, que son las variables locales cuyos valores o argumentos son
   suministrados por quien hace la llamada. La lista de resultados especifica
   los tipos de los valores que devuelve la funcion. Si la funcion devuelve un
   resultado sin nombre o ningun resultado, los parentesis son opcionales y
   normalmente se omiten. Dejar fuera la lista de resultados declara que una
   funcion que no devuelve ningun valor y se llama solo por sus efectos. En la
   funcion @c(hypot),

   ..src > go
     func hypot(x, y float64) float64 {
       return math.Sqrt(x*x + y*y)
     }

     fmt.Println(hypot(3, 4)) // "5"
   < src..

   @c(x) y @c(y) son parametros en la declaracion, @c(3) y @c(4) son argumentos
   de la llamada, y la funcion devuelve un valor @c(float64).

   Al igual que los parametros, los resultados pueden tener nombre. En ese caso,
   cada nombre declara una variable local inicializada al valor cero para su
   tipo.

   Una funcion que tiene una lista de resultados debe terminar con una
   declaracion @c(return), a menos que la ejecucion claramente no pueda llegar
   al final de la funcion, tal vez porque la funcion termina con una llamada a
   @c(panic) o un bucle @c(for) infinito sin @c(break).

   Como hemos visto con @c(hypot), una secuencia de parametros o resultados del
   mismo tipo puede ser un factor para que el propio tipo se escriba una sola
   vez. Estas dos declaraciones son equivalentes:

   ..src > go
     func f(i, j, k int, s, t string)                { /* ... */ }
     func f(i int, j int, k int, s string, t string) { /* ... */ }
   < src..

   Aqui hay cuatro formas de declarar una funcion con dos parametros y un
   resultado, todos de tipo @c(int). El identificador en blanco puede usarse
   para enfatizar que un parametro no se utiliza.

   ..src > go
     func add(x int, y int) int   { return x + y }
     func sub(x, y int) (z int)   { z = x - y; return }
     func first(x int, _ int) int { return x }
     func zero(int, int) int      { return 0 }

     fmt.Printf("%T\n", add)   // "func(int, int) int"
     fmt.Printf("%T\n", sub)   // "func(int, int) int"
     fmt.Printf("%T\n", first) // "func(int, int) int"
     fmt.Printf("%T\n", zero)  // "func(int, int) int"
   < src..

   El tipo de una funcion a veces se denomina su @e(firma). Dos funciones tienen
   el mismo tipo o firma si tienen la misma secuencia de tipos de parametros y
   la misma secuencia de tipos de resultados. Los nombres de los parametros y
   resultados no afectan al tipo, ni tampoco si se declararon utilizando el
   formto factorizado.

   Cada llamada de funcion debe proporcionar un argumento para cada parametro,
   en el orden en que se declararon los parametros. Go no tiene concepto de
   valores de parametro predeterminados, ni ninguna forma de especificar
   argumentos por nombre, por lo que los nombres de parametros y resultados no
   importan al llamador, excepto como documentacion.

   Los parametros son variables locales dentro del cuerpo de la funcion, con sus
   valores iniciales establecidos a los argumentos proporcionados por quien
   realiza la llamada. Los parametros de funcion y los resultados con nombre son
   variables en el mismo bloque lexico que las variables locales mas externas de
   la funcion.

   Los argumentos se pasan por valor, por lo que la funcion recibe una copia de
   cada argumento; las modificaciones a la copia no afectan a la persona que
   llama. Sin embargo, si el argumento contiene algun tipo de referencia, como
   un puntero, slice, mapa, funcion o canal, entonces la persona que llama puede
   verse afectada por las modificaciones que hace la funcion de las variables
   que referencian @e(indirectamente) por el argumento.

   De vez en cuando puede encontrar una declaracion de funcion sin un cuerpo, lo
   que indica que la funcion se implementa en un idioma que no es Go. Dicha
   declaracion define la firma de la funcion.

   ..src > go
     package math

     func Sin(x float64) float64 // implementado en lenguaje ensamblador
   < src..

** Seccion 5.2 <> Recursividad

   Las funciones pueden ser @e(recursivas), es decir, que pueden llamarse a si
   mismas, ya sea directa o indirectamente. La recursion es una tecnica poderosa
   para muchos problemas, y por supuesto es esencial para procesar estructuras
   de datos recursivas. En la @l(#Seccion 4.4), se utilizo la recursividad sobre
   un arbol para implementar un mecanismo de insercion sencillo. En esta
   seccion, volveremos a usarlo para procesar documentos HTML.

   El siguiente programa de ejemplo utiliza un paquete no estandar,
   @c(golang.org/x/net/html), que proporciona un analizador de HTML. Los
   repositorios @c(golang.org/x/...) tienen paquetes diseñados y mantenidos por
   el equipo de Go para aplicaciones tales como redes, procesamiento de texto
   internacionalizacion, plataformas moviles, manipulacion de imagenes,
   criptografia, y herramientas de desarrollo. Estos paquetes no estan en la
   libreria estandar porque todavia estan en desarrollo o porque son raramente
   necesarios por la mayoria de los programadores de Go.

   Las partes de  la API @c(golang.org/x/net/html) que tendremos que se muestran a
   continuacion. La funcion @c(html.Parse) lee una secuencia de bytes, los analiza,
   y devuelve la raiz del arbol del documento HTML, que es un @c(html.Node). HTML
   tiene varios tipos de nodos–texto, comentarios, etc.–pero aqui solo nos
   interesan los nodos de elementos con la forma @c(<nombre clave='valor'>).

   ..figure > @c(golang.org/x/net/html)

     ..src > go
       package html
       type Node struct {
         Type                    NodeType
         Data                    string
         Attr                    []Attribute
         FirstChild, NextSibling *Node
       }

       type NodeType int32

       const (
         ErrorNode NodeType = iota
         TextNode
         DocumentNode
         ElementNode
         CommentNode
         DoctypeNode
       )

       type Attribute struct {
         Key, Val string
       }

       func Parse(r io.Reader) (*Node, error)
     < src..


   La funcion @c(main) analiza la entrada estandar como HTML, extrae los enlaces
   usando la funcion recursiva @c(visit), e imprime cada enlace descubierto:

   ..figure > @l(gopl.io/ch5/findlinks1/main.go<>gopl.io/ch5/findlinks1)

     ..src > go
       // Findlinks1 imprime los enlaces en un documento HTML leido en la entrada estandar
       package main

       import (
         "fmt"
         "os"

         "golang.org/x/net/html"
       )

       func main() {
         doc, err := html.Parse(os.Stdin)
         if err != nil {
           fmt.Fprintf(os.Stderr, "findlinks1: %v\n", err)
           os.Exit(1)
         }
         for _, link := range visit(nil, doc) {
           fmt.Println(link)
         }
       }
     < src..


   La funcion @c(visit) atraviesa un arbol de nodos HTML, extrae el enlace desde
   el atributo @c(href) de cada elemento de @e(anclaje) @c(<a href='...'>),
   añade los enlaces a un slice de strings, y devuelve el slice resultante:

   ..src > go
     // visit agrega los enlaces de cada enlace encontrado en n y devuelve el resultado
     func visit(links []string, n *html.Node) []string {
       if n.Type == html.ElementNode && n.Data == "a" {
         for _, a := range n.Attr {
           if a.Key == "href" {
             links = append(links, a.Val)
           }
         }
       }
       for c := n.FirstChild; c != nil; c = c.NextSibling {
         links = visit(links, c)
       }
       return links
     }
   < src..

   Para descender por el arbol a un nodo @c(n), @c(visit) se llama a si misma
   recursivamente para cada uno de los hijos de @c(n), que se mantienen en la
   lista enlazada @c(FirstChild).

   Vamos a ejecutar @$(findlinks) en la pagina principal de Go, canalizando el
   resultado de @$(fetch) @%l(#Seccion 1.5<>§1.5) a la entrada de
   @$(findlinks). Hemos modificado la salida ligeramente por brevedad.

   ..srci > sh
     > go build gopl.io/ch1/fetch
     > go build gopl.io/ch5/findlinks1
     > ./fetch https://golang.org | ./findlinks1
     #
     /doc/
     /pkg/
     /help/
     /blog/
     http://play.golang.org/
     //tour.golang.org/
     https://golang.org/dl/
     //blog.golang.org/
     /LICENSE
     /doc/tos.html
     http://www.google.com/intl/en/policies/privacy/
   < srci..

   Observe la variedad de formas de enlaces que aparecen en la pagina. Mas
   adelante veremos como resolverlos con relacion al URL base,
   @c(https://golang.org), para crear URL absolutas.

   El siguiente programa utiliza la recursion sobre el arbol de nodos HTML para
   imprimir la estructura del arbol en esquema. Cuando encuentra cada elemento,
   empuja la etiqueta del elemento sobre una pila, luego imprime la pila.

   ..figure > @l(gopl.io/ch5/outline/main.go<>gopl.io/ch5/outline)

     ..src > go
       func main() {
         doc, err := html.Parse(os.Stdin)
         if err != nil {
           fmt.Fprintf(os.Stderr, "outline: %v\n", err)
           os.Exit(1)
         }
         outline(nil, doc)
       }

       func outline(stack []string, n *html.Node) {
         if n.Type == html.ElementNode {
           stack = append(stack, n.Data) // push tag
           fmt.Println(stack)
         }
         for c := n.FirstChild; c != nil; c = c.NextSibling {
           outline(stack, c)
         }
       }
     < src..


   Considere una sutileza: aunque @c(outline) @"(empuja) un elemento en el
   @c(stack), no hay ninguna extraccion correspondiente. Cuando @c(outline) se
   llama a si misma de forma recursiva, el receptor recibe una copia del
   @c(stack). Aunque el destinatario de la llamada puede añadir elementos a este
   slice, modificando de su arreglo subyacente e incluso asignando un nuevo
   arreglo, no modifica los elementos iniciales que son visibles para quien
   realiza la llamada, asi que cuando la funcion regresa, el @c(stack) del
   llamador es tal cual antes de la llamada.

   Aqui esta el esquema de @c(https://golang.org), editado nuevamente por
   razones de brevedad:

   ..srci > sh
     > go build gopl.io/ch5/outline
     > ./fetch https://golang.org | ./outline
     [html]
     [html head]
     [html head meta]
     [html head title]
     [html head link]
     [html body]
     [html body div]
     [html body div]
     [html body div div]
     [html body div div form]
     [html body div div form div]
     [html body div div form div a]
   < srci..

   Como puede ver mediante la experimentacion con @c(outline), la mayoria de los
   documentos HTML pueden ser procesados con solo unos pocos niveles de
   recursividad, pero no es dificil construir paginas web patologicas que
   requieren una recursion extremadamente profunda.

   Muchas implementaciones de los lenguajes de programacion utilizan una pila de
   tamaño fijo; son tipicos los tamaños de 64KB a 2MB. Las pilas de tamaño fijo
   imponen un limite en la profundidad de la recursividad, por lo que hay que
   tener cuidado para evitar un desbordamiento de pila cuando se atraviesa
   grandes estructuras de datos de forma recursiva; las pilas de tamaño fijo
   pueden incluso suponer un riesgo para la seguridad. En contraste, las
   implementaciones tipicas de Go usan pilas de tamaño variable que comienzan
   pequeñas y crecen segun sea necesario hasta un limite del orden de un
   gigabyte. Esto nos permite usar la recursion de forma segura y sin
   preocuparnos por el desbordamiento.

   @b(Ejercicio 5.1): Cambiar el programa @$(findlinks) para atravesar la lista
   enlazada @c(n.FirstChild) mediante llamadas recursivas a @c(visit) en lugar
   de un bucle.

   @b(Ejercicio 5.2): Escribir una funcion para rellenar un mapeo con los
   nombres de los elementos–@c(p), @c(div), @c(span), y asi sucesivamente–al
   numero de elementos con ese nombre en un arbol de documentos HTML.

   @b(Ejercicio 5.3): Escribir una funcion para imprimir el contenido de todos
   los nodos de texto en un arbol de documentos HTML. No descender dentro de
   elementos @c(<script>) o @c(<style>), ya que sus contenidos no son visibles
   en un navegador web.

   @b(Ejercicio 5.4): Extender la funcion @c(visit) para que extraiga otros
   tipos de enlace desde el documento, como imagenes, scripts y hojas de
   estilo.

** Seccion 5.3 <> Multiples Valores de Retorno

   Una funcion puede devolver mas de un resultado. Hemos visto muchos ejemplos
   de funciones de paquetes estandar que devuelven dos valores, el resultado
   computacional deseado y un valor de error o booleano que indica si el calculo
   funciono. El siguiente ejemplo muestra como escribir una nosotros mismos.

   El programa siguiente es una variacion de @$(findlinks) que hace la peticion
   HTTP por si mismo, asi que ya no necesitamos ejecutar @$(fetch). Ya que las
   operaciones de analisis y HTTP pueden fallar, @$(findLinks) declara dos
   resultados: la lista de enlaces descubiertos y un error. Por cierto, el
   analizador de HTML por lo general puede recuperarse de una entrada incorrecta
   y construir un documento que contiene nodos de error, por lo que @c(Parse)
   raramente falla; cuando lo hace, normalmente se debe a errores de E/S
   subyacentes.

   ..figure > @l(gopl.io/ch5/findlinks2/main.go<>gopl.io/ch5/findlinks2)

     ..src > go
       func main() {
         for _, url := range os.Args[1:] {
           links, err := findLinks(url)
           if err != nil {
             fmt.Fprintf(os.Stderr, "findlinks2: %v\n", err)
             continue
           }
           for _, link := range links {
             fmt.Println(link)
           }
         }
       }

       // findLinks realiza una peticion HTTP GET por la url, analiza la
       // respuesta como HTML, y extrae y regresa los enlaces.
       func findLinks(url string) ([]string, error) {
         resp, err := http.Get(url)
         if err != nil {
           return nil, err
         }
         if resp.StatusCode != http.StatusOK {
           resp.Body.Close()
           return nil, fmt.Errorf("getting %s: %s", url, resp.Status)
         }
         doc, err := html.Parse(resp.Body)
         resp.Body.Close()
         if err != nil {
           return nil, fmt.Errorf("parsing %s as HTML: %v", url, err)
         }
         return visit(nil, doc), nil
       }
     < src..


   Hay cuatro sentencias @c(return) en @c(findLinks), cada una de las cuales
   devuelve un par de valores. Los tres primeros @c(return) hacen que la funcion
   pase los errores subyacentes de los paquetes @c(http) y @c(html) al
   llamador. En el primer caso, el error se devuelve sin cambios; en el segundo
   y tercero, que expande con informacion de contexto adicional con
   @c(fmt.Errorf) @%l(#Seccion 7.8<>§7.8). Si @c(findLinks) tiene exito, la
   ultima sentencia @c(return) devuelve el slice de enlaces, sin error.

   Debemos asegurarnos de cerrar @c(resp.Body) para que los recursos de red se
   liberen adecuadamente, incluso en caso de error. El recolector de basura de
   Go recicla la memoria no utilizada, pero no asume que liberara recursos del
   sistema operativo no utilizados como archivos abiertos y conexiones de
   red. Deberan cerrarse explicitamente.

   El resultado de llamar a una funcion multi-valor es una tupla de valores. El
   llamador de tal funcion debe asignar explicitamente los valores a las
   variables si se desea utilizar alguna de ellas:

   ..src > go
     links, err := findLinks(url)
   < src..

   Para ignorar uno de los valores, asignelo al identificador en blanco:

   ..src > go
     links, _ := findLinks(url) // ignorando errores
   < src..

   El resultado de una llamada multi-valor en si, puede ser devuelto llamando a
   una funcion (multi-valor), como en esta funcion que se comporta como
   @c(findLinks) pero registra su argumento:

   ..src > go
     func findLinksLog(url string) ([]string, error) {
       log.Printf("findLinks %s", url)
       return findLinks(url)
     }
   < src..

   Una llamada multi-valor puede aparecer como el unico argumento cuando se
   llama a una funcion de multiples parametros. Aunque rara vez se utiliza en
   codigo de produccion, esta caracteristica es a veces conveniente durante la
   depuracion, ya que nos permite imprimir todos los resultados de una llamada
   utilizando una sola sentencia. Las dos instrucciones de impresion siguientes
   tienen el mismo efecto.

   ..src > go
     log.Println(findLinks(url))

     links, err := findLinks(url)
     log.Println(links, err)
   < src..

   Los nombres bien elegidos pueden documentar la importancia de los resultados
   de una funcion. Los nombres son particularmente valiosos cuando una funcion
   devuelve multiples resultados del mismo tipo, como

   ..src > go
     func Size(rect image.Rectangle) (width, height int)
     func Split(path string) (dir, file string)
     func HourMinSec(t time.Time) (hour, minute, second int)
   < src..

   Pero no siempre es necesario nombrar multiples resultados unicamente para la
   documentacion. Por ejemplo, la convencion dicta que un resultado final
   @c(bool) indica el exito; un resultado erroneo a menudo no necesita
   explicacion.

   En una funcion con resultados nombrados, se pueden omitir los operandos de
   una sentencia de devolucion. Esto se denomina @c(retorno desnudo).

   ..src > go
     // CountWordsAndImages realiza una peticion HTTP GET para la URL del
     // documento HTML y regresa el numero de palabras e imagenes que contiene.
     func CountWordsAndImages(url string) (words, images int, err error) {
       resp, err := http.Get(url)
       if err != nil {
         return
       }

       doc, err := html.Parse(resp.Body)
       resp.Body.Close()
       if err != nil {
         err = fmt.Errorf("parsing HTML: %s", err)
         return
       }
       words, images = countWordsAndImages(doc)
       return
     }

     func countWordsAndImages(n *html.Node) (words, images int) { /* ... */ }
   < src..

   Un retorno desnudo es una forma abreviada de devolver cada una de las
   variables de resultado nombradas en orden, por lo que en la funcion anterior,
   cada sentencia @c(return) es equivalente a

   ..src > go
     return words, images, err
   < src..

   En funciones como esta, con muchas declaraciones de retorno y varios
   resultados, los resultados desnudos pueden reducir la duplicacion de codigo,
   pero rara vez hacen que el codigo sea mas facil de entender. Por ejemplo, no
   es obvio a primera vista que los dos primeros resultados son equivalentes a
   @c(return 0, 0, err) (porque las variables de resultado @c(words) e
   @c(images) se inicializan con sus valores cero) y que el ultimo @c(return) es
   equivalente a @c(return words, images, nil). Por esta razon, es mejor
   utilizar los resultados desnudos con moderacion.

   @b(Ejercicio 5.5): Implementar @c(countWordsAndImages). (Ver el Ejercicio 4.9
   para la division de palabras.)

   @b(Ejercicio 5.6): Modificar la funcion @c(corner) en @c(gopl.io/ch3/surface)
   @%l(#Seccion 3.2<>§3.2) para utilizar resultados con nombre y una
   declaracion de retorno desnudo.

** Seccion 5.4 <> Errores

   Algunas funciones siempre tienen exito en su tarea. Por ejemplo,
   @c(strings.Contains) y @c(strconv.FormatBool) tienen bien definidos todos los
   posibles valores de los argumentos y no pueden fallar–salvo escenarios
   catastroficos e impredecibles como quedarse sin memoria, donde el sintoma
   esta lejos de la causa y de la cual hay poca esperanza de recuperacion.

   Otras funciones siempre tienen exito siempre y cuando se cumplan sus
   condiciones previas. Por ejemplo, la funcion @c(time.Date) siempre construye
   un @c(time.Time) a partir de sus componentes–año, mes, y asi sucesivamente–a
   menos que el ultimo argumento (la zona horaria) sea @c(nil), en cuyo caso se
   entra en panico. Este panico es un signo seguro de un error en el codigo de
   llamada y nunca debe suceder en un programa bien escrito.

   Para muchas otras funciones, incluso en un programa bien escrito, el exito no
   esta asegurado porque depende de factores ajenos al control del programador.
   Cualquier funcion que haga E/S, por ejemplo, debe enfrentarse a la
   posibilidad de error, y solo un programador ingenuo cree que una simple
   lectura o escritura no puede fallar. De hecho, es cuando las operaciones mas
   confiables fallan inesperadamente que necesitamos saber por que.

   Los errores son, por lo tanto, una parte importante de la API de un paquete o
   de la interfaz de usuario de una aplicacion, y el error es solo uno de varios
   comportamientos esperados. Este es el enfoque que Go toma respecto al manejo
   de errores.

   Una funcion cuyo fallo es un comportamiento esperado devuelve un resultado
   adicional, convencionalmente el ultimo. Si el fallo tiene solo una causa
   posible, el resultado es un valor booleano, generalmente llamado @c(ok), como
   en este ejemplo de una busqueda en la cache que siempre tiene exito a menos
   que no hubiera ninguna entrada para esa clave:

   ..src > go
     value, ok := cache.Lookup(key)
     if !ok {
       // ...cache[key] no existe...
     }
   < src..

   Mas a menudo, y especialmente para E/S, el fallo puede tener una variedad
   de causas para las cuales el llamador necesitara una explicacion. En tales
   casos, el tipo del resultado adicional es @c(error).

   El tipo nativo @c(error) es de tipo interfaz. Veremos mas de lo que esto
   significa y sus implicaciones para el manejo de errores en el @l(#Capitulo
   7). Por ahora es suficiente saber que un error puede ser o no @c(nil), que
   nil implica el exito y no-nil implica el fracaso, y que un error no-nil tiene
   una cadena del mensaje de error que se puede obtener llamando a su metodo
   @c(Error) o imprimir mediante @c[fmt.Println(err)] o @c[fmt.Printf("%v",
   err)].

   Normalmente cuando una funcion devuelve un error no-nil, sus otros resultados
   son indefinidos y se deben ignorar. Sin embargo, algunas funciones pueden
   devolver resultados parciales en casos de error. Por ejemplo, si se produce
   un error durante la lectura de un archivo, una llamada a @c(Read) devuelve el
   numero de bytes que fue capaz de leer @e(y) un valor @c(error) que describe
   el problema. Para el comportamiento correcto, algunos llamadores pueden
   necesitar procesar los datos incompletos antes de manejar el error, por lo
   que es importante que estas funciones documenten claramente sus resultados.

   El enfoque de Go lo diferencia de muchos otros lenguajes en los que se
   reportan fallos utilizando @e(excepciones), no valores normales. Aunque Go
   tiene un mecanismo de excepcion, como veremos en la @l(#Seccion 5.9), se
   utiliza solo para informar de los errores realmente inesperadas que indican
   un error, no los errores de rutina que un programa robusto deberia esperar.

   La razon de este diseño es que las excepciones tienden a enredar la
   descripcion de un error con el flujo de control requerido para manejarlo,
   conduciendo a menudo a un resultado indeseable: los errores de rutina se
   informan al usuario final en forma de un rastro de pila incomprensible, lleno
   de informacion sobre la estructura del programa pero carece de un contexto
   inteligible sobre lo que salio mal.

   Por el contrario, los programas Go utilizan mecanismos de control de flujo
   normales como @c(if) y @c(return) para responder a los errores. Este estilo
   indudablemente exige que se preste mas atencion a la logica de manejo de
   errores, pero ese es precisamente el punto.

*** Seccion 5.4.1 <> Estrategias de Manejo de Errores

    Cuando una llamada de funcion devuelve un error, es responsabilidad del
    llamador comprobarlo y tomar la accion apropiada. Dependiendo de la
    situacion, puede haber una serie de posibilidades. Echemos un vistazo a
    cinco de ellas.

    La primera y mas comun, es @e(propagar) el error, por lo que un fallo en una
    subrutina se convierte en un fracaso de la rutina de llamada. Vimos ejemplos
    de esto en la funcion @c(findLinks) de la @l(#Seccion 5.3). Si la llamada a
    @c(http.Get) falla, @c(findLinks) devuelve el error HTTP al llamador sin mas
    preambulos:

    ..src > go
      resp, err := http.Get(url)
      if err != nil {
        return nil, err
      }
    < src..

    Por el contrario, si la llamada a @c(html.Parse) falla, @c(findLinks) no
    devuelve el error del analizador de HTML directamente, porque carece de dos
    piezas cruciales de informacion: que el error se produjo en el analizador, y
    la direccion URL del documento que se esta analizando. En este caso,
    @c(findLinks) construye un nuevo mensaje de error que incluye las dos piezas
    de informacion, asi como un analisis del error subyacente:

    ..src > go
      doc, err := html.Parse(resp.Body)
      resp.Body.Close()
      if err != nil {
        return nil, fmt.Errorf("parsing %s as HTML: %v", url, err)
      }
    < src..

    La funcion @c(fmt.Errorf) da formato a un mensaje de error utilizando
    @c(fmt.Sprintf) y devuelve un nuevo valor @c(error). Lo utilizamos para
    generar errores descriptivos mediante el prefijo sucesivo de informacion de
    contexto adicional al mensaje de error original. Cuando el error es en
    ultima instancia, manejado por la funcion @c(main) del programa, se debe
    proporcionar una cadena causal clara a partir de la raiz del problema del
    fallo en su conjunto, que recuerda a una investigacion de accidentes de la
    NASA:

    ..pre >
      genesis: crashed: no parachute: G-switch failed: bad relay orientation

    Debido a que los mensajes de error con frecuencia se encadenan juntos, las
    cadenas de mensajes no deben ser mayusculas y las lineas nuevas deben
    evitarse. Los errores resultantes pueden ser largos, pero seran
    autocontenidos cuando sean encuontrados por herramientas como @$(grep).

    Cuando diseñe mensajes de error, sea deliberado, de modo que cada uno sea
    una descripcion significativa del problema con detalles suficientes y
    relevantes, y sea consistente, de modo que los errores devueltos por la
    misma funcion o por un grupo de funciones en el mismo paquete sean similares
    en forma y se puedan tratar de la misma manera.

    Por ejemplo, el paquete @c(os) garantiza que cada error devuelto por una
    operacion de archivo, como @c(os.Open) o los metodos @c(Read), @c(Write), o
    @c(Close) de un archivo abierto, no describen solo la naturaleza del fallo
    (permiso denegado, directorio erroneo, etc), sino tambien el nombre del
    archivo, por lo el que llamador no necesita incluir esta informacion en el
    mensaje de error.

    En general, la llamada @c[f(x)] es responsable de informar el intento de
    operacion @c(f) y el valor del argumento @c(x) en su relacion con el
    contexto del error. El llamador es responsable de añadir mas informacion que
    tiene, pero la llamada @c[f(x)] no, como la URL de la llamada a
    @c(html.Parse) anterior.

    Pasemos a la segunda estrategia para manejar errores. Para errores que
    representan problemas transitorios o impredecibles, puede tener sentido
    volver a intentar la operacion fallida, posiblemente con un retardo entre
    intentos, y tal vez con un limite en el numero de intentos o el tiempo
    dedicado a tratar antes de renunciar por completo.

    ..figure > @l(gopl.io/ch5/wait/wait.go<>gopl.io/ch5/wait)

      ..src > go
        // WaitForServer intenta ponerse en contacto con el servidor de una URL
        // Se intenta durante un minuto usando retroceso exponencial.
        // Informa un error si todos los intentos fallan.
        func WaitForServer(url string) error {
          const timeout = 1 * time.Minute
          deadline := time.Now().Add(timeout)
          for tries := 0; time.Now().Before(deadline); tries++ {
            _, err := http.Head(url)
            if err == nil {
              return nil // exito
            }
            log.Printf("server not responding (%s); retrying...", err)
            time.Sleep(time.Second << uint(tries)) // retroceso exponencial
          }
          return fmt.Errorf("server %s failed to respond after %s", url, timeout)
        }
      < src..


    En tercer lugar, si el progreso es imposible, el llamante puede imprimir el
    error y detener el programa con gracia, pero este curso de accion
    generalmente debe reservarse para el paquete principal de un programa. Las
    funciones de la libreria normalmente deben propagar errores al llamante, a
    menos que el error sea un signo de una inconsistencia interna, es decir, un
    error.

    ..src > go
      // (Dentro de la funcion main.)
      if err := WaitForServer(url); err != nil {
        fmt.Fprintf(os.Stderr, "Site is down: %v\n", err)
        os.Exit(1)
      }
    < src..

    Una forma mas conveniente para lograr el mismo efecto es llamar a
    @c(log.Fatalf). Al igual que con todas las funciones @c(log), por defecto se
    prefija la hora y la fecha para el mensaje de error.

    ..src > go
      if err := WaitForServer(url); err != nil {
        log.Fatalf("Site is down: %v\n", err)
      }
    < src..

    El formato predeterminado es util en un servidor de larga ejecucion, pero
    menos para una herramienta interactiva:

    ..pre >
      2006/01/02 15:04:05 Site is down: no such domain: bad.gopl.io

    Para una salida mas atractiva, podemos establecer el prefijo utilizado por
    el paquete @c(log) en el nombre del comando, y suprimir la visualizacion de la
    fecha y hora:

    ..src > go
      log.SetPrefix("wait: ")
      log.SetFlags(0)
    < src..

    En cuarto lugar, en algunos casos, basta con registrar el error y luego
    continuar, tal vez con funcionalidad reducida. Una vez mas hay una eleccion
    entre utilizar el paquete @c(log), que añade el prefijo habitual:

    ..src > go
      if err := Ping(); err != nil {
        log.Printf("ping failed: %v; networking disabled", err)
      }
    < src..

    e imprimir directamente al flujo de error estardar:

    ..src > go
      if err := Ping(); err != nil {
        fmt.Fprintf(os.Stderr, "ping failed: %v; networking disabled\n", err)
      }
    < src..

    (Todas las funciones log añaden un salto de linea si no hay uno presente).

    Y quinto y ultimo, en casos raros podemos ignorar un error completamente:

    ..src > go
      dir, err := ioutil.TempDir("", "scratch")
      if err != nil {
        return fmt.Errorf("failed to create temp dir: %v", err)
      }

      // ...usar directorio temporal...

      os.RemoveAll(dir) // ignorar errores; $TMPDIR se limpia periodicamente
    < src..

    La llamada a @c(os.RemoveAll) puede fallar, pero el programa lo ignora porque el
    sistema operativo periodicamente limpia el directorio temporal. En este
    caso, descartar el error fue intencional, pero la logica del programa seria
    la misma si hubieramos olvidado tratar con el. Adquiera el habito de
    considerar errores despues de cada llamada de funcion, y cuando
    deliberadamente ignore uno, documente claramente su intencion.

    El manejo de errores en Go tiene un ritmo particular. Despues de comprobar
    un error, el fracaso suele tratarse antes del exito. Si el fallo hace que la
    funcion regrese, la logica para el exito no se sangra dentro de un bloque
    @c(else), pero continua en el nivel externo. Las funciones tienden a exhibir
    una estructura comun, con una serie de comprobaciones iniciales para
    rechazar errores, seguidas por la esencia de la funcion al final,
    minimamente indentada.

*** Seccion 5.4.2 <> Fin de Archivo (EOF)

    Normalmente, la variedad de errores que una funcion puede devolver es
    interesante para el usuario final, pero no para la logica del programa
    intermedio. En ocasiones, sin embargo, un programa debe tomar diferentes
    acciones dependiendo del tipo de error que se ha producido. Considere un
    intento de leer @m(n) bytes de datos de un archivo. Si se elige @m(n) para
    ser la longitud del archivo, cualquier error representa un fracaso. Por otro
    lado, si el llamador trata repetidamente de leer fragmentos de tamaño fijo
    hasta que el archivo se agote, el llamador debe responder de manera
    diferente a una condicion de fin de archivo que a todos los demas
    errores. Por esta razon, el paquete @c(io) garantiza que cualquier fallo
    producido por una condicion de fin de archivo siempre informa de un error
    distinguido, @c(io.EOF), que se define de la siguiente manera:

    ..src > go
      package io

      import "errors"

      // EOF es el error devuelto por Read cuando no hay mas entrada disponible.
      var EOF = errors.New("EOF")
    < src..

    El llamador puede detectar esta condicion usando una comparacion simple,
    como en el bucle siguiente, que lee runas de la entrada estandar. (El
    programa @$(charcount) en la @l(#Seccion 4.3) ofrece un ejemplo mas
    completo.)

    ..src > go
      in := bufio.NewReader(os.Stdin)
      for {
        r, _, err := in.ReadRune()
        if err == io.EOF {
          break // lectura terminada
        }
        if err != nil {
          return fmt.Errorf("read failed: %v", err)
        }
        // ...usar r...
      }
    < src..

    Puesto que en una condicion de fin de archivo no existe informacion que
    informar ademas del hecho de que, @c(io.EOF) tiene un mensaje de error fijo,
    @c("EOF"). Para otros errores, es posible que tengamos que informar tanto la
    calidad como la cantidad del error, por asi decirlo, por lo que un valor de
    error fijo no lo hara. En la @l(#Seccion 7.11), vamos a presentar de manera
    mas sistematica como distinguir ciertos valores de error de los demas.

** Seccion 5.5 <> Valores de Funcion

   En Go las funciones son valores de primera clase: al igual que otros valores,
   los valores de funcion tienen tipos, y pueden ser asignados a variables o
   pasarse o regresar de funciones. Un valor de funcion puede ser llamado como
   cualquier otra funcion. Por ejemplo:

   ..src > go
     func square(n int) int     { return n * n }
     func negative(n int) int   { return -n }
     func product(m, n int) int { return m * n }

     f := square
     fmt.Println(f(3))     // "9"

     f = negative
     fmt.Println(f(3))     // "-3"
     fmt.Printf("%T\n", f) // "func(int) int"

     f = product // error de compilacion: no se puede asignar func(int, int) int a func(int) int
   < src..

   El valor cero para el tipo funcion es @c(nil). Llamar a un valor de funcion
   nulo produce un panico:

   ..src > go
     var f func(int) int
     f(3) // panico: llamada a funcion nil
   < src..

   Los valores de funcion pueden compararse con @c(nil):

   ..src > go
     var f func(int) int
     if f != nil {
       f(3)
     }
   < src..

   Pero no son comparables, por lo que no pueden comparse entre si o utilizarse
   como claves en un mapa.

   Los valores de las funciones nos permiten parametrizar nuestras funciones no
   solo sobre los datos sino tambien sobre el comportamiento. Las librerias
   estandar contienen muchos ejemplos. Por ejemplo, @c(strings.Map) aplica una
   funcion a cada caracter de una cadena, uniendo los resultados para formar
   otra cadena.

   ..src > go
     func add1(r rune) rune { return r + 1 }

     fmt.Println(strings.Map(add1, "HAL-9000")) // "IBM.:111"
     fmt.Println(strings.Map(add1, "VMS"))      // "WNT"

     fmt.Println(strings.Map(add1, "Admix"))    // "Benjy"
   < src..

   La funcion @c(findLinks) de la @l(#Seccion 5.2) utiliza una funcion auxiliar,
   @c(visit), para visitar todos los nodos en un documento HTML y aplicar una
   accion a cada uno. Usando el valor de una funcion, podemos separar la logica
   del recorrido del arbol de la logica para la accion a aplicar a cada nodo,
   permitiendonos reutilizar el recorrido con diferentes acciones.

   ..figure > @l(gopl.io/ch5/outline2/outline.go<>gopl.io/ch5/outline2)

     ..src > go
       // forEachNode llama a las funciones pre(x) y post(x) para cada nodo
       // x en el arbol originado en n. Ambas funciones son opcionales.
       // pre se llama antes de que los hijos sean visitados (preorden) y
       // post se llama despues (postorden).
       func forEachNode(n *html.Node, pre, post func(n *html.Node)) {
         if pre != nil {
           pre(n)
         }

         for c := n.FirstChild; c != nil; c = c.NextSibling {
           forEachNode(c, pre, post)
         }

         if post != nil {
           post(n)
         }
       }
     < src..


   La funcion @c(forEachNode) acepta dos argumentos de funcion, uno para llamar
   antes de que se visiten los hijos de un nodo y otro para llamar despues. Esta
   disposicion da al lamador una gran flexibilidad. Por ejemplo, las funciones
   @c(startElement) y @c(endElement) imprimen las etiquetas de inicio y fin de
   un elemento HTML, como @c(<b>...</b>):

   ..src > go
     var depth int

     func startElement(n *html.Node) {
       if n.Type == html.ElementNode {
         fmt.Printf("%*s<%s>\n", depth*2, "", n.Data)
         depth++
       }
     }

     func endElement(n *html.Node) {
       if n.Type == html.ElementNode {
         depth--
         fmt.Printf("%*s</%s>\n", depth*2, "", n.Data)
       }
     }
   < src..

   Las funciones tambien indentan la salida usando otro truco de
   @c(fmt.Printf). El adverbio @c(*) en @c(%*s) imprime una cadena rellena con
   un numero variable de espacios. La anchura y la cadena se proporcionan por
   los argumentos @c(depth*2) y @c("").

   Si llamamos a @c(forEachNode) en un documento HTML, de esta forma:

   ..src > go
     forEachNode(doc, startElement, endElement)
   < src..

   obtenemos una variacion mas elaborada en la salida de nuestra programa
   @$(outline) anterior:

   ..srci > sh
     > go build gopl.io/ch5/outline2
     > ./outline2 http://gopl.io
     <html>
       <head>
         <meta>
         </meta>
         <title>
         </title>
         <style>
         </style>
       </head>
     <body>
       <table>
         <tbody>
           <tr>
             <td>
               <a>
                 <img>
                 </img>
     ...
   < srci..

   @b(Ejercicio 5.7): Desarrolla @c(startElement) y @c(endElement) en una
   agradable impresora HTML general. Imprime los nodos de comentarios, nodos de
   texto y los atributos de cada elemento (@c(<a href='...'>)). Utilizar formas
   cortas como @c(<img/>) en lugar de @c(<img></img>) cuando un elemento no
   tenga hijos. Escribir una prueba para asegurarse de que la salida se puede
   analizar con exito. (Vease el @l(#Capitulo 11)).

   @b(Ejercicio 5.8): Modificar @c(forEachNode) para que las funciones @c(pre) y
   @c(post) devuelvan un resultado booleano que señale si se debe continuar el
   recorrido. Utilicelo para escribir una funcion @c(ElementByID) con la
   siguiente firma que se encuentra el primer elemento HTML con el atributo id
   especificado. La funcion debe detener el recorrido tan pronto como se
   encuentre una coincidencia.

   ..src > go
     func ElementByID(doc *html.Node, id string) *html.Node
   < src..

   @b(Ejercicio 5.9): Escribir una funcion @c[expand(s string, f func(string)
   string) string] que reemplaze cada subcadena @"c($foo) dentro de @c(s) con
   el texto devuelto por @c[f("foo")].

** Seccion 5.6 <> Funciones Anonimas

   Las funciones con nombre se pueden declarar solo a nivel de paquete, pero podemos
   utilizar un @e(literal de funcion) para denotar un valor de funcion dentro de
   cualquier expresion. Un literal de funcion se escribe como una declaracion de la
   funcion, pero sin un nombre despues de la palabra clave @c(func). Es una
   expresion, y su valor se denomina @e(funcion anonima).

   Los literales de la funcion definen una funcion en su punto de uso. A modo de
   ejemplo, la llamada anterior a @c(strings.Map) se puede reescribir como

   ..src > go
     strings.Map(func(r rune) rune { return r + 1 }, "HAL-9000")
   < src..

   Mas importante aun, las funciones definidas de esta manera tienen acceso a
   todo el entorno lexico, por lo que la funcion interna puede referirse a
   variables de la funcion que la encierra, como muestra este ejemplo:

   ..figure > @l(gopl.io/ch5/squares/main.go<>gopl.io/ch5/squares)

     ..src > go
       // squares regresa una funcion que devuelve el siguiente
       // cuadrado del numero cada ves que se llama.
       func squares() func() int {
         var x int
         return func() int {
           x++
           return x * x
         }
       }

       func main() {
         f := squares()
         fmt.Println(f()) // "1"
         fmt.Println(f()) // "4"
         fmt.Println(f()) // "9"
         fmt.Println(f()) // "16"
       }
     < src..


   La funcion @c(squares) devuelve otra funcion, de tipo @c[func() int]. Una
   llamada a @c(squares) crea una variable local @c(x) y devuelve una funcion
   anonima que, cada vez que se llama, incrementa @c(x) y devuelve su
   cuadrado. Una segunda llamada a @c(squares) crearia una segunda variable
   @c(x) y devolvera una nueva funcion anonima que incremente esa variable.

   El ejemplo @c(squares) demuestra que los valores de funcion no son solo
   codigo, sino que pueden tener estado. La funcion anonima interna puede
   acceder y actualizar las variables locales dentro de la funcion @c(squares).
   Estas referencias de variables ocultas son el por que clasificamos a las
   funciones como tipos de referencia y motivo de que los valores de las
   funciones no sean comparables. Los valores de funcion como estos se
   implementan utilizando una tecnica llamada @e(closures), y los programadores
   Go a menudo utilizan este termino para los valores de la funcion.

   Aqui de nuevo vemos un ejemplo donde el tiempo de vida de una variable no
   esta determinada por su ambito de aplicacion: la variable @c(x) existe
   despues del retorno de @c(squares) dentro de @c(main), aunque @c(x) este
   oculta dentro de @c(f).

   Como un ejemplo un tanto academico de funciones anonimas, considere el
   problema de calcular la secuencia de los cursos de ciencias de computacion
   que satisfagan los requisitos previos de cada uno. Los prerequisitos se dan
   en la tabla @c(prereqs) de abajo, que es un mapa de cada curso a la lista de
   cursos que se deben completar antes de ella.

   ..figure > @l(gopl.io/ch5/toposort/main.go<>gopl.io/ch5/toposort)

     ..src > go
       // prereqs asigna cursos de ciencia de la computacion a sus prerequisitos.
       var prereqs = map[string][]string{
         "algoritmos": {"estructura de datos"},
         "calculo":   {"algebra lineal"},

         "compiladores": {
           "estructura de datos",
           "lenguajes formales",
           "organizacion de computadoras",
         },

         "estructura de datos":       {"matematicas discretas"},
         "bases de datos":            {"estructura de datos"},
         "matematicas discretas":     {"introduccion a la programacion"},
         "lenguajes formales":        {"matematicas discretas"},
         "redes":                     {"sitemas operativos"},
         "sistemas operativos":       {"estructura de datos", "organizacion de computadoras"},
         "lenguajes de programacion": {"estructura de datos", "organizacion de computadoras"},
       }
     < src..


   Este tipo de problema se conoce como clasificacion topologica.
   Conceptualmente, la informacion de los requisitos previos forma un grafico
   dirigido con un nodo para cada curso y los bordes de cada curso a los cursos
   de los que depende. El grafico es aciclico: no hay camino de un curso que
   vuelva a si mismo. Podemos calcular una secuencia valida usando la busqueda
   de profundidad en el grafico con el siguiente codigo:

   ..src > go
     func main() {
       for i, course := range topoSort(prereqs) {
         fmt.Printf("%d:\t%s\n", i+1, course)
       }
     }

     func topoSort(m map[string][]string) []string {
       var order []string
       seen := make(map[string]bool)
       var visitAll func(items []string)

       visitAll = func(items []string) {
         for _, item := range items {
           if !seen[item] {
             seen[item] = true
             visitAll(m[item])
             order = append(order, item)
           }
         }
       }

       var keys []string
       for key := range m {
         keys = append(keys, key)
       }

       sort.Strings(keys)
       visitAll(keys)
       return order
     }
   < src..


   Cuando una funcion anonima requiere recursion, como en este ejemplo, primero
   debemos declarar una variable, y luego asignar la funcion anonima a esa
   variable. Si estos dos pasos estuvieran combinados en la declaracion, la
   funcion literal no estaria dentro del alcance de la variable @c(visitAll) por
   lo que no tendria ninguna manera de llamarse a si misma de forma recursiva:

   ..src > go
     visitAll := func(items []string) {
       // ...
       visitAll(m[item]) // compile error: undefined: visitAll
       // ...
     }
   < src..

   La salida del programa @$(toposort) se muestra a continuacion. Es
   determinista, una propiedad a menudo deseable que no siempre viene de forma
   gratuita. En este caso, los valores del mapa @c(prereqs) son slices, no mas
   mapas, por lo que su orden de iteracion es determinista, y ordenamos las
   llaves de @c(prereqs) antes de hacer las llamadas iniciales a @c(visitAll) .

   ..pre >
     1:      introduccion a la programacion
     2:      matematicas discretas
     3:      estructura de datos
     4:      algoritmos
     5:      algebra lineal
     6:      calculo
     7:      lenguajes formales
     8:      organizacion de computadoras
     9:      compiladores
     10:     bases de datos
     11:     sistemas operativos
     12:     redes
     13:     lenguajes de programacion
   < pre..

   Volvamos a nuestro ejemplo @c(findLinks). Hemos movido la funcion de
   extraccion de enlaces @c(links.Extract) a su propio paquete, ya que la
   usaremos de nuevo en el @l(#Capitulo 8). Hemos sustituido la funcion
   @c(visit) con una funcion anonima que agrega directamente los @c(links) al
   slice, y utilizamos @c(forEachNode) para manejar el recorrido. Ya que
   @c(Extract) solo necesita la funcion @c(pre), se pasa @c(nil) para el
   argumento @c(post).

   ..figure > @l(gopl.io/ch5/links/links.go<>gopl.io/ch5/links)

     ..src > go
       // El paquete links proporciona una funcion de extraccion de enlaces.
       package links

       import (
         "fmt"
         "net/http"

         "golang.org/x/net/html"
       )

       // Extract hace una peticion HTTP GET a la URL especificada, analiza
       // la respuesta como HTML, y regresa el enlace en el documento HTML.
       func Extract(url string) ([]string, error) {
         resp, err := http.Get(url)
         if err != nil {
           return nil, err
         }
         if resp.StatusCode != http.StatusOK {
           resp.Body.Close()
           return nil, fmt.Errorf("getting %s: %s", url, resp.Status)
         }

         doc, err := html.Parse(resp.Body)
         resp.Body.Close()
         if err != nil {
           return nil, fmt.Errorf("parsing %s as HTML: %v", url, err)
         }

         var links []string
         visitNode := func(n *html.Node) {
           if n.Type == html.ElementNode && n.Data == "a" {
             for _, a := range n.Attr {
               if a.Key != "href" {
                 continue
               }
               link, err := resp.Request.URL.Parse(a.Val)
               if err != nil {
                 continue // ignora URLs incorrectas
               }
               links = append(links, link.String())
             }
           }
         }
         forEachNode(doc, visitNode, nil)
         return links, nil
       }
     < src..


   En lugar de añadir el atributo @c(href) en bruto al slice @c(links), esta
   version lo analiza como una direccion URL relativa a la URL base del
   documento, @c(resp.Request.URL). El enlace resultante esta en formato
   absoluto, adecuado para su uso en una llamada a @c(http.Get).

   El rastreador web es, en su corazon, un problema de grafico transversal. El
   ejemplo @c(topoSort) mostra un recorrido en profundidad; para nuestro
   rastreador web, vamos a utilizar la anchura de primera transversal, al menos
   inicialmente. En el @l(#Capitulo 8), vamos a explorar el recorrido
   concurrente.

   La siguiente funcion encapsula la esencia de un recorrido de
   primer-anchura. El llamador proporciona una lista inicial @c(worklist) de
   elementos a visitar y un valor de la funcion @c(f) a llamar para cada
   elemento. Cada elemento se identifica mediante una cadena. La funcion @c(f)
   devuelve una lista de elementos nuevos a añadir a la lista de trabajo. La
   funcion @c(breadthFirst) regresa cuando todos los elementos han sido
   visitados. Mantiene un conjunto de cadenas para garantizar que ningun
   elemento se visita dos veces.

   ..figure > @l(gopl.io/ch5/findlinks3/findlinks.go<>gopl.io/ch5/findlinks3)

     ..src > go
       // breadthFirst llama a f para cada elemento en worklist.
       // Todos los elementos devueltos por f se agregan a worklist.
       // f se llama como maximo una vez para cada elemento.
       func breadthFirst(f func(item string) []string, worklist []string) {
         seen := make(map[string]bool)
         for len(worklist) > 0 {
           items := worklist
           worklist = nil
           for _, item := range items {
             if !seen[item] {
               seen[item] = true
               worklist = append(worklist, f(item)...)
             }
           }
         }
       }
     < src..


   Como explicamos al pasar por el @l(#Capitulo 4), el argumento de @"{@c[f(item)...]}
   hace que todos los elementos de la lista devuelta por @c(f)se añadan a la
   lista de trabajo.

   En nuestro rastreador, los elementos son URL. La funcion @c(crawl) que
   suministramos a @c(breadthFirst) imprime la URL, extrae sus enlaces, y los
   devuelve para que tambien se visiten..

   ..src > go
     func crawl(url string) []string {
       fmt.Println(url)
       list, err := links.Extract(url)
       if err != nil {
         log.Print(err)
       }
       return list
     }
   < src..

   Para iniciar el rastreador, utilizaremos los argumentos de la linea de
   comandos como las URL iniciales.

   ..src > go
     func main() {
       // Rastrear la web la primer-anchura,
       // partiendo de los argumentos de la linea de comandos.
       breadthFirst(crawl, os.Args[1:])
     }
   < src..

   Vamos a rastrear la web desde @c(https://golang.org). Estos son algunos de
   los enlaces resultantes:

   ..srci > sh
     > go build gopl.io/ch5/findlinks3
     > ./findlinks3 https://golang.org
     https://golang.org/
     https://golang.org/doc/
     https://golang.org/pkg/
     https://golang.org/project/
     https://code.google.com/p/go-tour/
     https://golang.org/doc/code.html
     https://www.youtube.com/watch?v=XCsL89YtqCs
     http://research.swtch.com/gotour
     https://vimeo.com/53221560
   < srci..

   El proceso finaliza cuando todas las paginas web alcanzables se han rastreado
   o se ha agotado la memoria del equipo.

   @b(Ejercicio 5.10): Vuelve a escribir @c(topoSort) para utilizar mapas en
   lugar de slices y eliminar la clasificacion inicial. Verifique que los
   resultados, aunque no deterministicos, sean ordenamientos topologicos
   validos.

   @b(Ejercicio 5.11): El instructor del curso de algebra lineal decide que el
   calculo ahora es un requisito previo. Extender la funcion @c(topoSort) para
   reportar ciclos.

   @b(Ejercicio 5.12): Las funciones @c(startElement) y @c(endElement) en
   @c(gopl.io/ch5/outline2) @%l(#Seccion 5.5<>§5.5) comparten una variable
   global, @c(depth). Conviertalas en funciones anonimas que compartan una
   variable local de la funcion @c(outline).

   @b(Ejercicio 5.13): Modificar @c(crawl) para hacer copias locales de las
   paginas que encuentre, creando directorios segun sea necesario. No haga
   copias de paginas que provengan de un dominio diferente. Por ejemplo, si la
   pagina original proviene de @l(https://golang.org<>golang.org), guarda todos
   los archivos de alli, pero excluir los de @l(https://vimeo.com<>vimeo.com).

   @b(Ejercicio 5.14): Usar la funcion @c(breadthFirst) para explorar una
   estructura diferente. Por ejemplo, podria utilizar las dependencias de cursos
   del ejemplo @c(topoSort) (un grafo dirigido), la jerarquia del sistema de
   archivos en el ordenador (un arbol), o una lista de rutas de autobus o de
   metro descargados desde el sitio web de su gobierno de la ciudad (un grafo no
   dirigido).

*** Seccion 5.6.1 <> Advertencia: Captura de Variables de Iteracion

    En esta seccion, veremos una trampa de las reglas de alcance lexico de Go
    que pueden causar resultados sorprendentes. Le recomendamos que comprenda el
    problema antes de proceder, porque la trampa puede atrapar incluso a
    programadores experimentados.

    Considere un programa que debe crear un conjunto de directorios y luego
    eliminarlos. Podemos usar una porcion de valores de funcion para mantener
    las operaciones de limpieza. (Para mayor brevedad, hemos omitido todo el
    manejo de errores en este ejemplo.)

    ..src > go
      var rmdirs []func()
      for _, d := range tempDirs() {
        dir := d               // NOTA: necesario!
        os.MkdirAll(dir, 0755) // tambien crea los directorios padre
        rmdirs = append(rmdirs, func() {
          os.RemoveAll(dir)
        })
      }

      // ...algo de trabajo...

      for _, rmdir := range rmdirs {
        rmdir() // clean up
      }
    < src..

    Es posible que se pregunte por que asignamos la variable de bucle @c(d) a
    una nueva variable local @c(dir) dentro del cuerpo del bucle, en lugar de
    simplemente nombrar a la variable de bucle @c(dir) como en esta variante
    sutilmente incorrecta:

    ..src > go
      var rmdirs []func()
      for _, dir := range tempDirs() {
        os.MkdirAll(dir, 0755)
        rmdirs = append(rmdirs, func() {
          os.RemoveAll(dir) // NOTA: incorrecto!
        })
      }
    < src..

    La razon es una consecuencia de las reglas de alcance para variables de
    bucle. En el programa inmediatamente anterior, el bucle @c(for) introduce un
    nuevo bloque lexico en el que se declara la variable @c(dir). Todos los
    valores de la funcion creados por este bucle @"(capturan) y comparten la
    misma variable–Un lugar de almacenamiento direccionable, no su valor en ese
    momento en particular. El valor de @c(dir) se actualiza en iteraciones
    sucesivas, de manera que cuando las funciones de limpieza son llamadas, la
    variable @c(dir) ha sido actualizada varias veces por el ahora completado
    bucle @c(for). Por lo tanto @c(dir) mantiene el valor de la iteracion final,
    y por lo tanto todas las llamadas a @c(os.RemoveAll) intentaran eliminar el
    mismo directorio.

    Con frecuencia, a la variable interna introducida para evitar este
    problema–@c(dir) en nuestro ejemplo–se le da exactamente el mismo nombre que
    la variable externa de la que es una copia, lo que lleva a las declaraciones
    de variables de aspecto extraño pero cruciales como este:

    ..src > go
      for _, dir := range tempDirs() {
        dir := dir // declara dir interno, inicializado a dir externo
        // ...
      }
    < src..

    El riesgo no es unico para bucles @c(for) basados en @c(range). El bucle en
    el siguiente ejemplo adolece del mismo problema debido a la captura no
    intencionada de la variable de indice @c(i).

    ..src > go
      var rmdirs []func()
      dirs := tempDirs()
      for i := 0; i < len(dirs); i++ {
        os.MkdirAll(dirs[i], 0755) // OK
        rmdirs = append(rmdirs, func() {
          os.RemoveAll(dirs[i])    // NOTA: incorrecto!
        })
      }
    < src..

    El problema de la iteracion de captura variable se encuentran mas a menudo
    cuando se utiliza la sentencia @c(go) @%l(#Capitulo 8) o con @c(defer) (que
    veremos en un momento), ya que ambos pueden retrasar la ejecucion de un
    valor de funcion hasta despues de que el bucle ha finalizado. Pero el
    problema no es inherente a @c(go) o @c(defer).

** Seccion 5.7 <> Funciones Variadic

   Una @e(funcion variadic) es una que se puede llamar con un numero de
   argumentos variable. Los ejemplos mas conocidos son @c(fmt.Printf) y sus
   variantes. @c(Printf) requiere un argumento fijo al principio, luego acepta
   cualquier numero de argumentos posteriores.

   Para declarar una funcion variadic, el tipo del parametro final va precedido
   por una elipsis, @"c(...), que indica que la funcion puede ser llamada con
   cualquier numero de argumentos de ese tipo.

   ..figure > @l(gopl.io/ch5/sum/main.go<>gopl.io/ch5/sum)

     ..src > go
       func sum(vals ...int) int {
         total := 0
         for _, val := range vals {
           total += val
         }
         return total
       }
     < src..


   La funcion @c(sum) anterior devuelve la suma de cero o mas argumentos
   @c(int). Dentro del cuerpo de la funcion, el tipo de @c(vals) es un slice
   @c([]int). Cuando llame a @c(sum), puede proporcionar cualquier numero de
   valores en su parametro @c(vals).

   ..src > go
     fmt.Println(sum())           // "0"
     fmt.Println(sum(3))          // "3"
     fmt.Println(sum(1, 2, 3, 4)) // "10"
   < src..

   Implicitamente, el llamador asigna un arreglo, copia los argumentos en el y
   pasa un slice de todo el arreglo a la funcion. La llamada anterior se
   comporta de la misma manera que la siguiente, que muestra como invocar una
   funcion variadica cuando los argumentos ya estan en un slice: coloca una
   elipsis despues del argumento final.

   ..src > go
     values := []int{1, 2, 3, 4}
     fmt.Println(sum(values...)) // "10"
   < src..

   Aunque el parametro @c(...int) se comporta como un slice dentro del cuerpo
   de la funcion, el tipo de una funcion variadic es distinto del tipo de una
   funcion con un parametro slice ordinario.

   ..src > go
     func f(...int) {}
     func g([]int)  {}

     fmt.Printf("%T\n", f) // "func(...int)"
     fmt.Printf("%T\n", g) // "func([]int)"
   < src..

   Las funciones variadic se utilizan a menudo para el formateo de cadenas. La
   funcion @c(errorf) a continuacion construye un mensaje de error con formato
   con un numero de linea en el principio. El sufijo @c(f) es una convencion de
   nomenclatura ampliamente seguido para funciones variadic que aceptan una
   cadena de formato de estilo @c(Printf).

   ..src > go
     func errorf(linenum int, format string, args ...interface{}) {
       fmt.Fprintf(os.Stderr, "Line %d: ", linenum)
       fmt.Fprintf(os.Stderr, format, args...)
       fmt.Fprintln(os.Stderr)
     }

     linenum, name := 12, "count"
     errorf(linenum, "undefined: %s", name) // "Linea 12: sin definir: count"
   < src..

   El tipo @c(interface{}) significa que esta funcion puede aceptar cualquier
   valor en absoluto para sus argumentos finales, como explicaremos en el
   @l(#Capitulo 7).

   @b(Ejercicio 5.15): Escribir funciones variadic @c(max) y @c(min), analoga a
   @c(sum). ¿Que deben hacer estas funciones cuando se llaman sin argumentos?
   Escribir variantes que requieren al menos un argumento.

   @b(Ejercicio 5.16): Escribir una version variadic @c(de strings.Join).

   @b(Ejercicio 5.17): Escribir una funcion variadic @c(ElementsByTagName) que, dado
   un arbol de nodos HTML y cero o mas nombres, devuelve todos los elementos que
   coinciden con uno de esos nombres. Aqui hay dos ejemplos de llamadas:

   ..src > go
     func ElementsByTagName(doc *html.Node, name ...string) []*html.Node

     images := ElementsByTagName(doc, "img")
     headings := ElementsByTagName(doc, "h1", "h2", "h3", "h4")
   < src..

** Seccion 5.8 <> Llamadas de Funcion Diferida

   Nuestros ejemplos @c(findLinks) utilizan la salida de @c(http.Get) como la
   entrada de @c(html.Parse). Esto funciona bien si el contenido de la URL
   solicitada es de hecho HTML, pero muchas paginas contienen imagenes, texto
   sin formato y otros formatos de archivo. La alimentacion de estos archivos en
   un analizador HTML podria tener efectos no deseados.

   El siguiente programa recupera un documento HTML e imprime su titulo. La
   funcion @c(title) inspecciona la cabecera @c(Content-Type) de la respuesta
   del servidor y devuelve un error si el documento no es HTML.

   ..figure > @l(gopl.io/ch5/title1/title.go<>gopl.io/ch5/title1)

     ..src > go
       func title(url string) error {
         resp, err := http.Get(url)
         if err != nil {
           return err
         }

         // Comprueba que Content-Type sea HTML (e.g., "text/html; charset=utf-8").
         ct := resp.Header.Get("Content-Type")
         if ct != "text/html" && !strings.HasPrefix(ct, "text/html;") {
           resp.Body.Close()
           return fmt.Errorf("%s has type %s, not text/html", url, ct)
         }

         doc, err := html.Parse(resp.Body)
         resp.Body.Close()
         if err != nil {
           return fmt.Errorf("parsing %s as HTML: %v", url, err)
         }

         visitNode := func(n *html.Node) {
           if n.Type == html.ElementNode && n.Data == "title" &&
             n.FirstChild != nil {
             fmt.Println(n.FirstChild.Data)
           }
         }
         forEachNode(doc, visitNode, nil)
         return nil
       }
     < src..


   Aqui esta una sesion tipica:

   ..srci > sh
     > go build gopl.io/ch5/title1
     > ./title1 http://gopl.io
     The Go Programming Language
     > ./title1 https://golang.org/doc/effective_go.html
     Effective Go - The Go Programming Language
     > ./title1 https://golang.org/doc/gopher/frontpage.png
     title: https://golang.org/doc/gopher/frontpage.png
         has type image/png, not text/html
   < srci..

   Observe la llamada duplicada @c[resp.Body.Close()], que asegura que @c(title)
   cierre la conexion de red en todas las rutas de ejecucion, incluyendo las
   fallas. A medida que las funciones se vuelven mas complejas y tienen que
   manejar mas errores, tal duplicacion de la logica de limpieza puede
   convertirse en un problema de mantenimiento. Veamos como el nuevo mecanismo
   @c(defer) de Go hace las cosas mas sencillas.

   Sintacticamente, una sentencia @c(defer) es una funcion ordinaria o una
   llamada a un metodo con la palabra clave @c(defer) como prefijo. Las
   expresiones de funcion y los argumentos se evaluan cuando se ejecuta la
   instruccion, pero la llamada real se aplaza hasta que la funcion que contiene
   la declaracion @c(defer) ha terminado, ya sea ejecutando una instruccion de
   retorno o llegando al final, o anormalmente, por un panico. Cualquier numero
   de llamadas puede ser diferido; se ejecutan en el orden inverso en que fueron
   aplazadas.

   Una sentencia @c(defer) se utiliza a menudo con operaciones pareadas como
   abrir y cerrar, conectar y desconectar o bloquear y desbloquear para
   garantizar que los recursos se liberan en todos los casos, independientemente
   de la complejidad del flujo de control. El lugar adecuado para una sentencia
   @c(defer) que libera un recurso es inmediatamente despues de que el recurso
   se ha adquirido con exito. En la funcion @c(title) a continuacion, una sola
   llamada diferida sustituye a las dos llamadas anteriores de
   @c[resp.Body.Close()]:

   ..figure > @l(gopl.io/ch5/title2/title.go<>gopl.io/ch5/title2)

     ..src > go
       func title(url string) error {
         resp, err := http.Get(url)
         if err != nil {
           return err
         }
         defer resp.Body.Close()

         ct := resp.Header.Get("Content-Type")
         if ct != "text/html" && !strings.HasPrefix(ct, "text/html;") {
           return fmt.Errorf("%s has type %s, not text/html", url, ct)
         }

         doc, err := html.Parse(resp.Body)
         if err != nil {
           return fmt.Errorf("parsing %s as HTML: %v", url, err)
         }

         // ...imprimir los elementos title del documento...

         return nil
       }
     < src..

   El mismo patron se puede utilizar para otros recursos ademas de las
   conexiones de red, por ejemplo para cerrar un archivo abierto:

   ..figure > @c(io/ioutil)

     ..src > go
       package ioutil

       func ReadFile(filename string) ([]byte, error) {
         f, err := os.Open(filename)
         if err != nil {
           return nil, err
         }
         defer f.Close()
         return ReadAll(f)
       }
     < src..


   o para desbloquear un mutex @%l(#Seccion 9.2<>§9.2):

   ..src > go
     var mu sync.Mutex
     var m = make(map[string]int)

     func lookup(key string) int {
       mu.Lock()
       defer mu.Unlock()
       return m[key]
     }
   < src..

   La sentencia @c(defer) tambien se puede utilizar para emparejar acciones de
   @"(entrada) y @"(salida) al depurar una funcion compleja. A continuacion la
   funcion @c(bigSlowOperation) llama inmediatamente a @c(trace), lo que la hace
   una accion de @"(entrada) que devuelve un valor de funcion que, cuando se le
   llama, hace la accion de @"(salida).  Al diferir una llamada a la funcion
   devuelta de esta manera, podemos instrumentar el punto de entrada y todos los
   puntos de salida de una funcion en una sola declaracion, e incluso pasar
   valores, como el tiempo de inicio @c(start), entre las dos acciones. Pero no
   se olvide de los parentesis finales en el sentencia @c(defer), o la accion de
   @"(entrada) ocurrira en la salida y la accion en la salida no ocurrira en
   absoluto!

   ..figure > @l(gopl.io/ch5/trace/main.go<>gopl.io/ch5/trace)

     ..src > go
       func bigSlowOperation() {
         defer trace("bigSlowOperation")() // no olvide los parentesis adicionales
         // ...mucho trabajo...
         time.Sleep(10 * time.Second)      // simula el funcionamiento lento durmiendo
       }

       func trace(msg string) func() {
         start := time.Now()
         log.Printf("enter %s", msg)
         return func() { log.Printf("exit %s (%s)", msg, time.Since(start)) }
       }
     < src..


   Cada vez que llama a @c(bigSlowOperation), se registra su entrada y salida y el
   tiempo transcurrido entre ello. (Utilizamos @c(time.Sleep) para simular una
   operacion lenta.)

   ..srci > sh
     > go build gopl.io/ch5/trace
     > ./trace
     2015/11/18 09:53:26 enter bigSlowOperation
     2015/11/18 09:53:36 exit bigSlowOperation (10.000589217s)
   < srci..

   Las funciones diferidas se ejecutan despues de las declaraciones de retorno
   han actualizado las variables de resultado de la funcion. Debido a que una
   funcion anonima puede acceder a las variables de su funcion de inclusion,
   incluidos los resultados con nombre, una funcion anonima diferida puede
   observar los resultados de la funcion.

   Considere la funcion @c(doble):

   ..src > go
     func doble(x int) int {
       return x + x
     }
   < src..

   Al nombrar a su variable de resultado y agregar una sentecia @c(defer),
   podemos hacer que la funcion imprima sus argumentos y resultados cada vez
   que se llame.

   ..src > go
     func doble(x int) (resultado int) {
       defer func() { fmt.Printf("doble(%d) = %d\n", x, resultado) }()
       return x + x
     }

     _ = double(4)
     // Salida:
     // "doble(4) = 8"
   < src..

   Este truco es exesivo para una funcion tan simple como @c(doble), pero puede
   ser util en funciones con muchas declaraciones de retorno.

   Una funcion anonima diferida puede incluso cambiar los valores que la funcion
   devuelve a su interlocutor:

   ..src > go
     func triple(x int) (result int) {
       defer func() { result += x }()
       return doble(x)
     }

     fmt.Println(triple(4)) // "12"
   < src..

   Dado que las funciones diferidas no se ejecutan hasta el final de la
   ejecucion de una funcion, una declaracion @c(defer) en un bucle merece un
   escrutinio adicional. El codigo siguiente podria quedar sin los descriptores
   de archivo ya que ningun archivo se cerrara hasta que todos los archivos se
   hayan procesado:

   ..src > go
     for _, filename := range filenames {
       f, err := os.Open(filename)
       if err != nil {
         return err
       }
       defer f.Close() // NOTA: arriesgado; podria quedarse sin los descriptores de archivo
       // ...procesando f...
     }
   < src..

   Una solucion es mover el cuerpo del bucle, incluyendo la declaracion
   @c(defer), a otra funcion que se llame en cada iteracion.

   ..src > go
     for _, filename := range filenames {
       if err := doFile(filename); err != nil {
         return err
       }
     }

     func doFile(filename string) error {
       f, err := os.Open(filename)
       if err != nil {
         return err
       }
       defer f.Close()
       // ...procesando f...
     }
   < src..

   El siguiente ejemplo es una mejora del programa @$(fetch) @%l(#Seccion
   1.5<>§1.5) que escribe la respuesta HTTP a un archivo local en lugar de a la
   salida estandar. Deriva el nombre del archivo del el ultimo componente de la
   ruta URL, que obtiene utilizando la funcion @c(path.Base).

   ..figure > @l(gopl.io/ch5/fetch/main.go<>gopl.io/ch5/fetch)

     ..src > go
       // Fetch descarga la URL y regresa el nombre
       // y la longitud del archivo local.
       func fetch(url string) (filename string, n int64, err error) {
         resp, err := http.Get(url)
         if err != nil {
           return "", 0, err
         }
         defer resp.Body.Close()

         local := path.Base(resp.Request.URL.Path)
         if local == "/" {
           local = "index.html"
         }
         f, err := os.Create(local)
         if err != nil {
           return "", 0, err
         }
         n, err = io.Copy(f, resp.Body)
         // Cerrar archivo, pero prefiera el error de Copy, si lo hay.
         if closeErr := f.Close(); err == nil {
           err = closeErr
         }
         return local, n, err
       }
     < src..


   La llamada diferida a @c(resp.Body.Close) deberia resultar familiar por
   ahora. Es tentador utilizar una segunda llamada diferida, a @c(f.Close), para
   cerrar el archivo local, pero esto seria sutilmente incorrecto porque
   @c(os.Create) abre un archivo para escritura, creandolo si es necesario. En
   muchos sistemas de archivos, notablemente NFS, los errores de escritura no se
   informan inmediatamente, pueden posponerse hasta que se cierre el archivo. Si
   no se comprueba el resultado de la operacion de cierre, la perdida de datos
   graves podria pasar desapercibida. Sin embargo, si ambos @c(io.Copy) y
   @c(f.Close) fallan, debemos preferir reportar el error de @c(io.Copy) desde
   que ocurre por primera vez y es mas probable que nos diga la causa raiz.

   @b(Ejercicio 5.18): Sin cambiar su comportamiento, reescriba la funcion
   @c(fetch) utilizando @c(defer) para cerrar el archivo de escritura.

** Seccion 5.9 <> Panico

   El sistema de tipado de Go captura muchos errores en tiempo de compilacion,
   pero otros, como un acceso a un arreglo fuera de limites o una desreferencia
   de puntero nulo, requieren comprobaciones en tiempo de ejecucion. Cuando go
   detecta errores en tiempo de ejecucion, entra en @e(panico).

   Durante un panico tipico, la ejecucion normal se detiene, todas las llamadas
   de funcion diferida en esa gorutina se ejecutan, y el programa se bloquea con
   un mensaje de registro. Este mensaje de registro incluye el @e(valor de
   panico), que suele ser un mensaje de error de algun tipo, y, para cada
   goroutine, un @e(seguimiento de pila) que muestra la pila de llamadas a
   funciones que estaban activas en el momento del panico. Este mensaje de
   registro a menudo tiene suficiente informacion para diagnosticar la causa
   raiz del problema sin ejecutar el programa de nuevo, por lo que siempre debe
   incluirse en un informe de error acerca de un programa de panico.

   No todos los panicos provienen del tiempo de ejecucion. La funcion nativa
   @c(panic) se puede llamar directamente; acepta cualquier valor como
   argumento. Un panico es a menudo lo mejor que puede hacer cuando ocurre
   alguna situacion @"(imposible), por ejemplo, que la ejecucion llegue a un
   caso que logicamente, no puede suceder:

   ..src > go
     switch s := suit(drawCard()); s {
     case "Spades":   // ...
     case "Hearts":   // ...
     case "Diamonds": // ...
     case "Clubs":    // ...
     default:
       panic(fmt.Sprintf("invalid suit %q", s)) // Joker?
     }
   < src..

   Es una buena practica afirmar que las precondiciones de una funcion se
   mantienen, pero esto puede hacerse facilmente en exceso. A menos que pueda
   proporcionar un mensaje de error mas informativo o detectar un error antes,
   no tiene sentido afirmar una condicion que el tiempo de ejecucion comprobara
   por usted.

   ..src > go
     func Reset(x *Buffer) {
       if x == nil {
         panic("x is nil") // innecesario!
       }
       x.elements = nil
     }
   < src..

   Aunque el mecanismo de panico de Go se parece a las excepciones de otros
   lenguajes, las situaciones en las que se utiliza el panico son muy
   diferentes. Puesto que un panico hace que el programa se bloquee,
   generalmente se usa para errores graves, como una inconsistencia logica en el
   programa; los programadores diligentes consideran cualquier accidente como
   prueba de un error en su codigo. En un programa robusto, los errores
   @"(esperados), el tipo que surgen de una entrada incorrecta, mala
   configuracion, o un defecto de E/S, deben manejarse con gracia; se tratan
   mejor con el uso de valores de @c(error).

   Considere la funcion @c(regexp.Compile), que compila una expresion regular en
   una forma eficiente para la coincidencia. Se devuelve un @c(error) si se
   llama con un patron mal formado, pero la comprobacion de este error es
   innecesaria y onerosa si la persona que llama sabe que una llamada en
   particular no puede fallar. En tales casos, es razonable que el llamador
   maneje un error con un panico, ya que se cree que es imposible.

   Como la mayoria de las expresiones regulares son literales en el codigo
   fuente del programa, la paquete @c(regexp) proporciona una funcion de
   envoltura @c(regexp.MustCompile) que hace esta comprobacion:

   ..src > go
     package regexp

     func Compile(expr string) (*Regexp, error) { /* ... */ }

     func MustCompile(expr string) *Regexp {
       re, err := Compile(expr)
       if err != nil {
         panic(err)
       }
       return re
     }
   < src..

   La funcion de envoltura hace que sea conveniente para los clientes
   inicializar una variable de nivel de paquete con una expresion regular
   compilada, como esta:

   ..src > go
     var httpSchemeRE = regexp.MustCompile(`^https?:`) // "http:" or "https:"
   < src..

   Por supuesto, @c(MustCompile) no debe ser llamada con valores de entrada no
   confiables. El prefijo @c(Must) es una convencion de nomenclatura comun para
   este tipo de funciones, como @c(template.Must) en la @l(#Seccion 4.6).

   Cuando se produce una situacion de panico, todas las funciones diferidas se
   ejecutan en orden inverso, comenzando con las funciones en lo mas alto de la
   pila y procediendo hasta @c(main), como muestra el siguiente programa:

   ..figure > @l(gopl.io/ch5/defer1/defer.go<>gopl.io/ch5/defer1)

     ..src > go
       func main() {
         f(3)
       }

       func f(x int) {
         fmt.Printf("f(%d)\n", x+0/x) // panics if x == 0
         defer fmt.Printf("defer %d\n", x)
         f(x - 1)
       }
     < src..

   Cuando se ejecuta, el programa imprime lo siguiente en la salida estandar:

   ..pre >
     f(3)
     f(2)
     f(1)
     defer 1
     defer 2
     defer 3

   Un panico se produce durante la llamada a @c[f(0)], provocando que se
   ejecuten las tres llamadas diferidas a @c(fmt.Printf). A continuacion, el
   tiempo de ejecucion finaliza el programa, imprimiendo el mensaje de panico y
   un volcado de pila en el flujo de error estandar (simplificado para mayor
   claridad):

   ..pre >
      panic: runtime error: integer divide by zero
      main.f(0)
              src/gopl.io/ch5/defer1/defer.go:14
      main.f(1)
              src/gopl.io/ch5/defer1/defer.go:16
      main.f(2)
              src/gopl.io/ch5/defer1/defer.go:16

      main.f(3)
              src/gopl.io/ch5/defer1/defer.go:16
      main.main()
              src/gopl.io/ch5/defer1/defer.go:10
   < pre..

   Como veremos mas adelante, es posible que una funcion se recupere de un
   panico para que no termine el programa.

   Por propositos de diagnostico, el paquete @c(runtime) permite al programador
   volcar la pila utilizando la misma maquinaria. Al diferir una llamada a
   @c(printStack) en @c(main),

   ..figure > @l(gopl.io/ch5/defer2/defer.go<>gopl.io/ch5/defer2)

     ..src > go
       func main() {
         defer printStack()
         f(3)
       }

       func printStack() {
         var buf [4096]byte
         n := runtime.Stack(buf[:], false)
         os.Stdout.Write(buf[:n])
       }
     < src..


   El siguiente texto adicional (simplificado de nuevo para mayor claridad) se
   imprime a la salida estandar:

   ..pre >
      goroutine 1 [running]:
      main.printStack()
        src/gopl.io/ch5/defer2/defer.go:20
      main.f(0)
        src/gopl.io/ch5/defer2/defer.go:27
      main.f(1)
        src/gopl.io/ch5/defer2/defer.go:29
      main.f(2)
        src/gopl.io/ch5/defer2/defer.go:29
      main.f(3)
        src/gopl.io/ch5/defer2/defer.go:29
      main.main()
        src/gopl.io/ch5/defer2/defer.go:15
   < pre..


   Los lectores familiarizados con excepciones en otros lenguajes pueden
   sorprenderse de que @c(runtime.Stack) pueda imprimir informacion sobre
   funciones que parecen haber sido @"(desenrolladas). El Mecanismo de panico de
   Go ejecuta las funciones diferidos antes de desenrollar la pila.

** Seccion 5.10 <> Recover

   Desistir es generalmente la respuesta correcta a un panico, pero no
   siempre. Podria ser posible recuperarse de alguna manera, o al menos limpiar
   el lio antes de marcharse. Por ejemplo, un servidor web que encuentra un
   problema inesperado podria cerrar la conexion en lugar de dejar al cliente
   colgado y, durante el desarrollo, podria informar el error al cliente
   tambien.

   Si la funcion nativa @c(recover) se llama dentro de una funcion diferida y la
   funcion que contiene la sentencia @c(defer) es presa del panico, @c(recover)
   termina el actual estado de panico y devuelve el valor del panico. La funcion
   que estaba en panico no continua donde lo dejo pero devuelve normalmente. Si
   @c(recover) se llama en cualquier otro momento, no tiene ningun efecto y
   devuelve @c(nil).

   Para ilustrar, considere el desarrollo de un analizador para un lenguaje.
   Incluso cuando parece estar funcionando bien, dada la complejidad de su
   trabajo, los bichos todavia pueden acechar en esquinas oscuras. Podriamos
   preferir que, en lugar de fallar, el analizador convierta estos panicos en
   errores comunes de analisis, quizas con un mensaje extra, exhortando al
   usuario a presentar un informe de error.

   ..src > go
     func Parse(input string) (s *Syntax, err error) {
       defer func() {
         if p := recover(); p != nil {
           err = fmt.Errorf("internal error: %v", p)
         }
       }()
       // ...analizador...
     }
   < src..

   La funcion diferida en @c(Parse) se recupera de una situacion de panico,
   utilizando el valor de panico para construir un mensaje de error; una version
   mas elegante podria incluir toda la pila de llamadas usando @c(runtime.Stack).
   Luego la funcion diferida, asigna @c(err) al resultado, que se devuelve al
   llamador.

   La recuperacion indiscriminada de los panicos es una practica dudosa porque
   el estado de las variables de un paquete despues de un panico raramente esta
   bien definido o documentado. Quizas una actualizacion critica de una
   estructura de datos estaba incompleta, se abrio una conexion de archivo o de
   red pero no se cerro o se obtuvo un bloqueo pero no se libero. Ademas, al
   reemplazar un bloqueo con, por ejemplo, una linea en un archivo de registro,
   la recuperacion indiscriminada puede hacer que los errores pasen
   desapercibidos.

   La recuperacion de un panico dentro del mismo paquete puede ayudar a
   simplificar el manejo de errores complejos o inesperados, pero como regla
   general, no debe intentar recuperarse del panico de otro paquete. Las APIs
   publicas deben informar de fallos como @c(errores). Del mismo modo, no debe
   recuperarse de un panico que puede pasar a traves de una funcion que no
   mantiene, como una llamador de devolucion de lllamada, ya que no puede
   razonar sobre su seguridad.

   Por ejemplo, el paquete @c(net/http) proporciona un servidor web que envia
   las solicitudes entrantes a funciones de controlador proporcionados por el
   usuario. En lugar de permitir que un panico en uno de estos controladores
   elimine el proceso, el servidor llama a @c(recover), imprime un seguimiento
   de la pila, y sigue atendiendo. Esto es conveniente en la practica, pero se
   corre el riesgo de perder recursos o dejar al manejador fallido en un estado
   no especificado que podria conducir a otros problemas.

   Por todas las razones anteriores, es mas seguro recuperarse selectivamente si
   es necesario. En otras palabras, recuperar solo de los panicos que estaban
   destinados a ser recuperados, lo que deberia ser raro. Esta intencion puede
   ser codificado mediante el uso de un tipo distinto, sin exportar para el
   valor de panico y probar si el valor devuelto por @c(recover) tiene ese
   tipo. (Veremos una manera de hacer esto en el siguiente ejemplo.) Si es asi,
   informamos el panico como un error ordinario; si no, llamamos a @c(panic) con
   el mismo valor para reanudar el estado de panico.

   El ejemplo siguiente es una variacion sobre el programa @$(title) que informa
   de un error si el documento HTML contiene multiples elementos @c(<title>). Si
   es asi, se aborta la recursividad llamando a @c(panic) con un valor del tipo
   especial @c(bailout).

   ..figure > @l(gopl.io/ch5/title3/title.go<>gopl.io/ch5/title3)

     ..src > go
       // soleTitle regresa el siguiente texto del primer elemento title no vacio
       // en doc, y un error si no existiera exactamente uno.
       func soleTitle(doc *html.Node) (title string, err error) {
         type bailout struct{}

         defer func() {
           switch p := recover(); p {
           case nil:
             // sin panico
           case bailout{}:
             // panico "esperado"
             err = fmt.Errorf("multiple title elements")
           default:
             panic(p) // panico inersperado; continuar el panico
           }
         }()

         // Bail out de recursion si encontramos mas de un titulo no vacio.
         forEachNode(doc, func(n *html.Node) {
           if n.Type == html.ElementNode && n.Data == "title" &&
             n.FirstChild != nil {
             if title != "" {
               panic(bailout{}) // multiples elementos titulo
             }
             title = n.FirstChild.Data
           }
         }, nil)
         if title == "" {
           return "", fmt.Errorf("no title element")
         }
         return title, nil
       }
     < src..


   La funcion diferida que llama a @c(recover), comprueba el valor de panico, e
   informa de un error ordinario si el valor era @c(bailout{}). Todos los demas
   valores no nulos indican un panico inesperados, en cuyo caso el controlador
   llama a @c(panic) con ese valor, deshace el efecto de @c(recover) y reanuda
   el estado original de panico. (Este ejemplo viola algo nuestro consejo acerca
   de no usar panicos para errores @"(esperados), pero proporciona una
   ilustracion compacta de la mecanica).

   De algunas condiciones no hay recuperacion. La falta de memoria, por ejemplo,
   provoca en tiempo de ejecucion que el programa termine con un error grave.

   @b(Ejercicio 5.19): Utilice @c(panic) y @c(recover) para escribir una funcion
   que no contenga ninguna sentencia @c(return) y devuelva un valor distinto de
   cero.

* Capitulo 6 <> Metodos

  Desde principios de los noventa, la programacion orientada a objetos (POO) ha
  sido el paradigma de programacion dominante en la industria y la educacion, y
  casi todos los lenguajes ampliamente utilizadas desarrolladas desde entonces
  han incluido soporte para ello. Go no es una excepcion.

  Aunque no existe una definicion universalmente aceptada de la programacion
  orientada a objetos, para nuestros propositos, un @e(objeto) es simplemente un
  valor o variable que tiene metodos, y un metodo es una funcion asociada a un
  tipo particular. Un programa orientado a objetos es aquel que utiliza metodos
  para expresar las propiedades y operaciones de cada estructura de datos de
  modo que los clientes no necesitan acceder directamente a la representacion
  del objeto.

  En los capitulos anteriores, hemos hecho uso regular de metodos de la libreria
  estandar, como el metodo @c(Seconds) del tipo @c(time.Duration):

  ..src > go
    const day = 24 * time.Hour
    fmt.Println(day.Seconds()) // "86400"
  < src..

  y definimos un metodo en la @l(#Seccion 2.5), una metodo @c(String) para el
  tipo @c(Celsius):

  ..src > go
    func (c Celsius) String() string { return fmt.Sprintf("%g°C", c) }
  < src..

  En este capitulo, el primero de dos en la programacion orientada a objetos,
  mostraremos como definir y utilizar metodos de manera eficaz. Tambien vamos a
  cubrir dos principios fundamentales de la programacion orientada a objetos,
  encapsulacion y composicion.

** Seccion 6.1 <> Declaracion de Metodos

   Se declara un metodo con una variante de la declaracion de funcion ordinaria
   en la que aparece un parametro extra antes del nombre de la funcion. El
   parametro asigna la funcion al tipo de ese parametro.

   Vamos a escribir nuestro primer metodo en un simple paquete de geometria
   plana:

   ..figure > @l(gopl.io/ch6/geometry/geometry.go<>gopl.io/ch6/geometry)

     ..src > go
       package geometria

       import "math"

       type Punto struct{ X, Y float64 }

       // funcion tradicional
       func Distancia(p, q Punto) float64 {
         return math.Hypot(q.X-p.X, q.Y-p.Y)
       }

       // lo mismo, pero como un metodo del tipo Punto
       func (p Punto) Distancia(q Punto) float64 {
         return math.Hypot(q.X-p.X, q.Y-p.Y)
       }
     < src..

   El parametro extra @c(p) se denomina el @e(receptor) del metodo, un legado de
   los primeros lenguajes orientados a objetos que describen la llamada a un
   metodo como @"(el envio de un mensaje a un objeto).

   En Go, no utilizamos un nombre especial como @c(this) o @c(self) para el
   receptor; elegimos los nombres de los receptores tal como lo hariamos para
   cualquier otro parametro. Pusto que el nombre del receptor se utilizara con
   frecuencia, es una buena idea elegir algo corto y ser coherente entre los
   metodos. Una opcion comun es la primer letra del nombre del tipo, como @c(p)
   por @c(Point).

   En una llamada al metodo, el argumento del receptor aparece antes del nombre
   del metodo. Esto es paralelo a la declaracion, en la que el parametro del
   receptor aparece antes del nombre del metodo.

   ..src > go
     p := Punto{1, 2}
     q := Punto{4, 6}
     fmt.Println(Distancia(p, q)) // "5", llamada a funcion
     fmt.Println(p.Distancia(q))  // "5", llamada a metodo
   < src..

   No hay conflicto entre las dos anteriores declaraciones de funcion llamadas
   @c(Distancia). La primera declara una funcion de nivel paquete llamada
   @c(geometria.Distancia). La segunda declara un procedimiento del tipo
   @c(Punto), por lo que su nombre es @c(Punto.Distancia).

   La expresion @c(p.Distancia) se denomina un @e(selector), porque selecciona
   el metodo apropiado @c(Distancia) para el receptor @c(p) de tipo @c(Punto).
   Los selectores tambien se utilizan para seleccionar los campos de un tipo
   estructura, como en @c(p.X). Dado que los metodos y campos habitan el mismo
   espacio de nombres, si declara un metodo @c(X) para el tipo de estructura
   @c(Punto) seria ambiguo y el compilador lo rechazara.

   Debido a que cada tipo tiene su propio espacio de nombres para los metodos,
   podemos usar el nombre @c(Distancia) para otros metodos, siempre y cuando
   pertenecen a diferentes tipos. Vamos a definir un tipo @c(Ruta) que
   representa una secuencia de segmentos de linea y a darle un metodo
   @c(Distancia) tambien.

   ..src > go
     // Una Ruta es un camino que conecta los puntos con lineas rectas.
     type Ruta []Punto

     // Distancia devuelve la distancia recorrida a lo largo de la Ruta.
     func (ruta Ruta) Distancia() float64 {
       sum := 0.0
       for i := range ruta {
         if i > 0 {
           sum += ruta[i-1].Distancia(ruta[i])
         }
       }
       return sum
     }
   < src..

   @c(Ruta) es un tipo de slice con nombre, no un tipo de estructura como
   @c(Punto), sin embargo, podemos definir metodos para el. Al permitir que los
   metodos se asocien con cualquier tipo, Go es diferente de muchos otros
   lenguajes orientados a objetos. A menudo es conveniente definir
   comportamientos adicionales para tipos simples como numeros, cadenas, slices,
   mapas, y a veces, incluso funciones. Los metodos pueden ser declarados en
   cualquier tipo con nombre definido en el mismo paquete, siempre y cuando su
   tipo subyacente no sea un puntero ni una interfaz.

   Las dos metodos @c(Distancia) tienen diferentes tipos. No estan relacionados
   entre si en absoluto, aunque @c(Ruta.Distancia) utiliza a @c(Punto.Distancia)
   internamente para calcular la longitud de cada segmento que une los puntos
   adyacentes.

   Vamos a llamar al nuevo metodo para calcular el perimetro de un triangulo
   rectangulo:

   ..cols >

     ..src > go
       perim := Ruta{
         {1, 1},
         {5, 1},
         {5, 4},
         {1, 1},
       }
       fmt.Println(perim.Distancia()) // "12"
     < src..

   <>

     ..img > img/perim.Distance.jpg


   En las dos llamadas anteriores a metodos con nombre @c(Distancia), el
   compilador determina que funcion debe llamar basandose tanto en el nombre del
   metodo y el tipo de receptor. En el primero, @c(ruta[i-1]) tiene tipo
   @c(Punto), asi que se llama a @c(Punto.Distancia); en el segundo, @c(perim)
   tiene el tipo @c(Ruta), por lo que se llama a @c(Ruta.Distancia).

   Todos los metodos de un tipo dado deben tener nombres unicos, pero diferentes
   tipos pueden utilizar el mismo nombre para un metodo, al igual que los
   metodos @c(Distancia) para @c(Punto) y @c(Ruta); no hay necesidad de
   calificar los nombres de funcion (por ejemplo, @c(RutaDistancia)) para
   eliminar la ambigüedad. Aqui vemos el primer beneficio al usar metodos sobre
   funciones ordinarias: los nombres de metodos pueden ser mas cortos. El
   beneficio se magnifica para las llamadas que se originan fuera del paquete,
   ya que puede utilizar el nombre mas corto y omitir el nombre del paquete:

   ..src > go
     import "gopl.io/ch6/geometry"

     perim := geometry.Path{{1, 1}, {5, 1}, {5, 4}, {1, 1}}
     fmt.Println(geometry.PathDistance(perim)) // "12", funcion independiente
     fmt.Println(perim.Distance())             // "12", metodo de geometry.Path
   < src..

** Seccion 6.2 <> Metodos con un Receptor de Puntero

   Ya que llamar a una funcion crea una copia de cada valor de argumento, si una
   funcion necesita actualizar una variable, o si un argumento es tan grande que
   queremos evitar copiarlo, debemos pasar la direccion de la variable usando un
   puntero. Lo mismo ocurre con los metodos que necesitan actualizar la variable
   del receptor: los adjudicamos al tipo como puntero, como @c(*Point).

   ..src > go
     func (p *Point) ScaleBy(factor float64) {
       p.X *= factor
       p.Y *= factor
     }
   < src..

   El nombre de este metodo es @c[(*Point).ScaleBy]. Los parentesis son necesarios;
   sin ellos, la expresion se analiza como @c[*(Point.ScaleBy)].

   En un programa realista, la convencion dicta que si cualquier metodo de
   @c(Point) tiene un receptor puntero, entonces todos los metodos de @c(Point)
   deben tener un receptor puntero, incluso los que no lo necesitan
   estrictamente. Hemos roto esta regla para @c(Point) de modo que podamos
   mostrar ambos tipos de metodo.

   Tipos con nombre @%c(Point) y punteros a ellos @c[(*Point)] son los unicos
   tipos que pueden aparecer en una declaracion receptor. Ademas, para evitar
   ambiguedades, las declaraciones de metodos no estan permitidas en tipos con
   nombre que son ellos mismos tipos de puntero:

   ..src > go
     type P *int
     func (P) f() { /* ... */ } // error de compilacion: tipo de receptor invalido
   < src..

   El metodo @c[(*Point).ScaleBy] se puede llamar al proporcionar un receptor
   @c(*Point), asi:

   ..src > go
     r := &Point{1, 2}
     r.ScaleBy(2)
     fmt.Println(*r) // "{2, 4}"
   < src..

   o asi:

   ..src > go
     p := Point{1, 2}
     pptr := &p
     pptr.ScaleBy(2)
     fmt.Println(p) // "{2, 4}"
   < src..

   o asi:

   ..src > go
     p := Point{1, 2}
     (&p).ScaleBy(2)
     fmt.Println(p) // "{2, 4}"
   < src..

   Pero los dos ultimos casos son desagradables. Afortunadamente, el lenguaje
   nos ayuda aqui. Si el receptor @c(p) es una variable de tipo @c(Point), pero
   el metodo requiere un receptor @c(*Point), podemos emplear esta abreviatura:

   ..src > go
     p.ScaleBy(2)
   < src..

   y el compilador realizara un @c(&p) implicito sobre la variable. Esto solo
   funciona para las variables, incluyendo los campos de la estructura como
   @c(p.X) y elementos de la arreglo o slice como @c(perim[0]). No podemos
   llamar a un metodo @c(*Point) en un receptor @c(Point) no direccionable,
   porque no hay manera de obtener la direccion de un valor temporal.

   ..src > go
     Point{1, 2}.ScaleBy(2) // error de compilacion: no se puede tomar la direccion de un Point literal
   < src..

   Sin embargo, podemos llamar a un metodo @c(Point) como @c(Point.Distance) con
   un receptor @c(*Point), porque hay una manera de obtener el valor de la
   direccion: solo tiene que cargar el valor apuntado por el receptor. El
   compilador inserta una operacion @c(*) implicita por nosotros. Estas dos
   llamadas de funcion son equivalentes:

   ..src > go
     pptr.Distance(q)
     (*pptr).Distance(q)
   < src..

   Vamos a resumir estos tres casos de nuevo, ya que son un punto frecuente de
   confusion. En cada expresion de llamada de metodo valida, exactamente una de
   estas tres sentencias es verdadera.

   O bien el argumento receptor tiene el mismo tipo que el parametro del
   receptor, por ejemplo ambos tienen tipo @c(T) o ambos tienen tipo @c(*T):

   ..src > go
     Point{1, 2}.Distance(q) //  Point
     pptr.ScaleBy(2)         // *Point
   < src..

   O el argumento de receptor es una variable de tipo @c(T) y el parametro receptor
   tiene tipo @c(*T). El compilador toma implicitamente la direccion de la
   variable:

   ..src > go
     p.ScaleBy(2) // implicit (&p)
   < src..

   O el argumento receptor tiene tipo @c(*T) y el parametro receptor tiene tipo
   @c(T). El compilador dereferencia implicitamente al receptor, en otras
   palabras, carga el valor:

   ..src > go
     pptr.Distance(q) // implicit (*pptr)
   < src..

   Si todos los metodos de un tipo con nombre @c(T) tienen un tipo de receptor
   @c(T) en si (no @c(*T)), es seguro copiar las instancias de ese tipo; llamar
   a cualquiera de sus metodos necesariamente hace una copia. Por ejemplo, los
   valores @c(time.Duration) se copian liberalmente, incluyendo como argumentos
   a las funciones. Pero si cualquier metodo tiene un receptor de puntero, se
   debe evitar copiar instancas de @c(T), ya que hacerlo puede violar
   invariantes internos. Por ejemplo, copiar una instancia de @c(bytes.Buffer)
   haria que el original y la copia como alias @%l(#Seccion 2.3.2<>§2.3.2)
   tubieran el mismo arreglo subyacente de bytes. Las llamadas de metodo
   subsiguientes tendrian efectos impredecibles.

*** Seccion 6.2.1 <> Nil es un Valor de Receptor Valido

    Al igual que algunas funciones permiten punteros nulos como argumentos,
    tambien lo hacen algunos metodos para su receptor, especialmente si @c(nil)
    es un valor cero significativo del tipo, al igual que con los mapas y los
    slices. En esta sencilla lista enlazada de numeros enteros, @c(nil)
    representa la lista vacia:

    ..src > go
      // Un IntList es una lista enlazada de enteros.
      // Un nil *IntList representa la lista vacia.
      type IntList struct {
        Value int
        Tail *IntList
      }

      // Sum regresa la suma de la lista de elementos.
      func (list *IntList) Sum() int {
        if list == nil {
          return 0
        }
        return list.Value + list.Tail.Sum()
      }
    < src..

    Cuando se define un tipo cuyos metodos permiten @c(nil) como valor receptor,
    vale la pena señalar esto explicitamente en su comentario de documentacion,
    como lo hicimos arriba.

    Aqui esta parte de la definicion del tipo @c(Values) del paquete @c(net/url):

    ..figure > @c(net/url)

      ..src > go
        package url

        // Values map asigna clave de cadena a una lista de valores.
        type Values map[string][]string

        // Get devuelve el primer valor asociado con la clave dada,
        // o "" si no hay nada.
        func (v Values) Get(key string) string {
          if vs := v[key]; len(vs) > 0 {
            return vs[0]
          }
          return ""
        }

        // Add agrega el valor a la clave.
        // Se añade a cualquier valor existente asociado con la clave.
        func (v Values) Add(key, value string) {
          v[key] = append(v[key], value)
        }
      < src..


    Expone su representacion como un mapa, pero tambien proporciona metodos para
    simplificar el acceso al mapa, cuyos valores son slices de cadenas–es un
    @e(mapa multiple). Sus clientes pueden utilizar sus operadores intrinsecos
    (@c(make), slice literales, @c(m[key]), etc.), o sus metodos, o ambos, como
    prefiera:

    ..figure > @l(gopl.io/ch6/urlvalues/main.go<>gopl.io/ch6/urlvalues)

      ..src > go
        m := url.Values{"lang": {"es"}} // construccion directa
        m.Add("item", "1")
        m.Add("item", "2")

        fmt.Println(m.Get("lang")) // "es"
        fmt.Println(m.Get("q"))    // ""
        fmt.Println(m.Get("item")) // "1"      (primer valor)
        fmt.Println(m["item"])     // "[1 2]"  (acceso directo al mapa)

        m = nil
        fmt.Println(m.Get("item")) // ""
        m.Add("item", "3")         // panico: asignacion a ingresar en un mapa nil
      < src..


    En la llamada final a @c(Get), el receptor @c(nil) se comporta como un mapa
    vacio. Podriamos haberlo escrito como @c[Values(nil).Get("item")], pero
    @c[nil.Get("item")] no se compilara porque el tipo @c(nil) no se ha
    determinado. Por el contrario, la llamada final a @c(Add) proboca un panico,
    ya que trata de actualizar un mapa nil.

    Debido a que @c(url.Values) es un tipo de mapa y un mapa se refiere a sus
    pares clave/valor indirectamente, las actualizaciones y supresiones que
    @c(url.Values.Add) hace a los elementos del mapa son visibles para el
    llamador. Sin embargo, al igual que con las funciones ordinarias, los
    cambios que un metodo hace a la propia referencia, como establecerlo en
    @c(nil) o hacer que se refiera a una estructura de mapa de datos diferente,
    no se reflejaran en el llamador.

** Seccion 6.3 <> Composicion de Tipos por Estructuras Enbebidas

   Considere el tipo @c(ColoredPoint):

   ..figure > @l(gopl.io/ch6/coloredpoint/main.go<>gopl.io/ch6/coloredpoint)

     ..src > go
       import "image/color"

       type Point struct{ X, Y float64 }

       type ColoredPoint struct {
         Point
         Color color.RGBA
       }
     < src..


   Podriamos haber definido @c(ColoredPoint) como una estructura de tres campos,
   pero en su lugar, @e(enbebimos) un @c(Point) para proporcionar los campos
   @c(X) e @c(Y). Como vimos en la @l(#Seccion 4.4.3), la incrustacion nos
   permite tomar un atajo sintactico para definir un tipo @c(ColoredPoint) que
   contiene todos los campos de @c(Point), ademas de un poco mas. Si queremos,
   podemos seleccionar los campos de @c(ColoredPoint) que fueron aportados por
   el @c(Point) embebido sin mencionar a @c(Point):

   ..src > go
     var cp ColoredPoint
     cp.X = 1
     fmt.Println(cp.Point.X) // "1"
     cp.Point.Y = 2
     fmt.Println(cp.Y)       // "2"
   < src..

   Un mecanismo similar se aplica a los @e(metodos) de @c(Point). Podemos llamar
   a los metodos del @c(Point) enbebido utilizando un receptor de tipo
   @c(ColoredPoint), a pesar de que @c(ColoredPoint) no tiene metodos
   declarados:

   ..src > go
     red := color.RGBA{255, 0, 0, 255}
     blue := color.RGBA{0, 0, 255, 255}
     var p = ColoredPoint{Point{1, 1}, red}
     var q = ColoredPoint{Point{5, 4}, blue}
     fmt.Println(p.Distance(q.Point)) // "5"
     p.ScaleBy(2)
     q.ScaleBy(2)
     fmt.Println(p.Distance(q.Point)) // "10"
   < src..

   Los metodos de @c(Point) han sido @e(promovidos) a @c(ColoredPoint). De esta
   manera, la incrustacion permite tipos complejos con muchos metodos que se
   construiran por la composicion de varios campos, cada uno proporcionando unos
   pocos metodos.

   Los lectores familiarizados con lenguajes orientados a objetos basados en
   clases pueden ser tentados a ver @c(Point) como una clase base y
   @c(ColoredPoint) como una subclase o clase derivada, o a interpretar la
   relacion entre estos tipos como si @c(ColoredPoint) @"(es un) @c(Point). Pero
   eso seria un error. Observe las llamadas a @c(Distance) arriba. @c(Distance)
   tiene un parametro de tipo @c(Point), ya que @c(q) no es un @c(Point), asi
   que aunque @c(q) tiene un campo enbebido de ese tipo, debemos seleccionarlo
   explicitamente. Si intenta pasar @c(q) seria un error:

   ..src > go
     p.Distance(q) // error de compilacion: no se puede utilizar q (ColoredPoint) como Point
   < src..

   Un @c(ColoredPoint) no es un @c(Point), pero @"(tiene un) @c(Point), y tiene
   dos metodos adicionales @c(Distance) y @c(ScaleBy) promocionados desde
   @c(Point). Si prefiere pensar en terminos de implementacion, el campo
   enbebido instruye al compilador a generar metodos de envoltura adicionales
   que delegan en los metodos declarados, equivalentes a los siguientes:

   ..src > go
     func (p ColoredPoint) Distance(q Point) float64 {
       return p.Point.Distance(q)
     }

     func (p *ColoredPoint) ScaleBy(factor float64) {
       p.Point.ScaleBy(factor)
     }
   < src..

   Cuando @c(Point.Distance) es llamado por el primero de estos metodos de
   envoltura, su valor receptor es @c(p.Point), no @c(p), y no hay manera de que
   el metodo accededa a @c(ColoredPoint) en el que @c(Point) esta enbebido.

   El tipo de un campo anonimo puede ser un @e(puntero) a un tipo con nombre, en
   cuyo caso los campos y metodos se promueven indirectamente del puntero al
   objeto. Agregar otro nivel de indireccion nos permite compartir estructuras
   comunes y variar las relaciones entre los objetos dinamicamente. La
   declaracion de @c(ColoredPoint) a continuacion incorpora un @c(*Point):

   ..src > go
     type ColoredPoint struct {
       *Point
       Color color.RGBA
     }

     p := ColoredPoint{&Point{1, 1}, red}
     q := ColoredPoint{&Point{5, 4}, blue}
     fmt.Println(p.Distance(*q.Point)) // "5"
     q.Point = p.Point                 // ahora p y q comparten el mismo Point
     p.ScaleBy(2)
     fmt.Println(*p.Point, *q.Point)   // "{2 2} {2 2}"
   < src..

   Un tipo de estructura puede tener mas de un campo anonimo. Si hubieramos
   declarado @c(ColoredPoint) como

   ..src > go
     type ColoredPoint struct {
       Point
       color.RGBA
     }
   < src..

   entonces un valor de este tipo tendria todos los metodos de @c(Point), todos
   los metodos de @c(RGBA), y cualesquiera otros metodos declarados en
   @c(ColoredPoint) directamente. Cuando el compilador resuelve un selector como
   @c(p.ScaleBy) a un metodo, primero se busca un metodo llamado directamente
   declarada @c(ScaleBy), luego, para los metodos promovidos de campos
   incrustados en @c(ColoredPoint), luego, para los metodos promovidos dos veces
   de campos incrustados dentro @c(Point) y @c(RGBA), y asi sucesivamente. El
   compilador informa de un error si el selector es ambiguo porque se
   promocionaron dos metodos desde el mismo rango.

   Los metodos pueden ser declarados solo en tipos con nombre (como @c(Point)) y
   punteros a ellos (@c(*Point)), pero gracias al embedido, es posible y, a
   veces util que los tipos de estructura @e(sin nombre) tambien tengan metodos.

   Aqui hay un buen truco para ilustrarlo. Este ejemplo muestra parte de una
   cache simple implementada usando dos variables a nivel de paquete, un mutex
   @%l(#Seccion 9.2<>§9.2) y el mapa que protege:

   ..src > go
     var (
       mu sync.Mutex // protege a mapping
       mapping = make(map[string]string)
     )

     func Lookup(key string) string {
       mu.Lock()
       v := mapping[key]
       mu.Unlock()
       return v
     }
   < src..

   La version de abajo es funcionalmente equivalente pero agrupa a las dos
   variables relacionadas en una unica variable de nivel de paquete, @c(cache):

   ..src > go
     var cache = struct {
       sync.Mutex
       mapping map[string]string
     } {
       mapping: make(map[string]string),
     }

     func Lookup(key string) string {
       cache.Lock()
       v := cache.mapping[key]
       cache.Unlock()
       return v
     }
   < src..

   La nueva variable da nombres mas expresivos a las variables relacionadas con
   la @c(cache), y debido a que el campo @c(sync.Mutex) esta enbebido dentro de
   ella, su metodos @c(Lock) y @c(Unlock) se promueven al tipo de estructura sin
   nombre, lo que nos permite bloquear la @c(cache) con una sintaxis auto
   explicativa.

** Seccion 6.4 <> Valores y Expresiones de los Metodos

   Normalmente seleccionamos y llamamos a un metodo en la misma expresion, como
   en @c[p.Distance()], pero es posible separar estas dos operaciones. El
   selector @c(p.Distance) produce un @e(valor de metodo), una funcion une un
   metodo (@c[Point.Distance]) a un valor de receptor especifico @c(p). Esta
   funcion puede entonces ser invocada sin un valor de receptor; solo necesita
   los argumentos del no receptor.

   ..src > go
     p := Point{1, 2}
     q := Point{4, 6}

     distanceFromP := p.Distance        // valor del metodo
     fmt.Println(distanceFromP(q))      // "5"
     var origin Point                   // {0, 0}
     fmt.Println(distanceFromP(origin)) // "2.23606797749979", √5

     scaleP := p.ScaleBy // valor del metodo
     scaleP(2)           // p se vuelve (2, 4)
     scaleP(3)           //       luego (6, 12)
     scaleP(10)          //       luego (60, 120)
   < src..

   Los valores de metodo son utiles cuando la API de un paquete solicita un
   valor de funcion y el comportamiento deseado del cliente para esa funcion es
   llamar a un metodo en un receptor especifico. Por ejemplo, la funcion
   @c(time.AfterFunc) llama a un valor de funcion despues de un retardo
   especificado. Este programa lo utiliza para lanzar el cohete @c(r) despues de
   10 segundos:

   ..src > go
     type Rocket struct { /* ... */ }
     func (r *Rocket) Launch() { /* ... */ }

     r := new(Rocket)
     time.AfterFunc(10 * time.Second, func() { r.Launch() })
   < src..

   La sintaxis del valor del metodo es mas corta:

   ..src > go
     time.AfterFunc(10 * time.Second, r.Launch)
   < src..

   En relacion con el valor del metodo es la @e(expresion del metodo). Al llamar
   a un metodo, a diferencia de una funcion ordinaria, debemos suministrar al
   receptor de una manera especial usando la sintaxis del selector. Una
   expresion de metodo, escrita @c(T.f) o @c[(*T).f] donde @c(T) es un tipo,
   produce un valor de funcion con un primer parametro tomando el lugar del
   receptor, por lo que puede ser llamado de la manera habitual.

   ..src > go
     p := Point{1, 2}
     q := Point{4, 6}

     distance := Point.Distance   // expresion del metodo
     fmt.Println(distance(p, q))  // "5"
     fmt.Printf("%T\n", distance) // "func(Point, Point) float64"

     scale := (*Point).ScaleBy
     scale(&p, 2)
     fmt.Println(p)            // "{2 4}"
     fmt.Printf("%T\n", scale) // "func(*Point, float64)"
   < src..

   Las expresiones de metodo pueden ser utiles cuando se necesita un valor para
   representar una eleccion entre varios metodos pertenecientes al mismo tipo
   para que pueda llamar al metodo elegido con muchos receptores diferentes. En
   el siguiente ejemplo, la variable @c(op) representa el metodo de suma o resta
   del tipo @c(Point), y @c(Path.TranslateBy) lo llama para cada punto en
   @c(Path):

   ..src > go
     type Point struct{ X, Y float64 }

     func (p Point) Add(q Point) Point { return Point{p.X + q.X, p.Y + q.Y} }
     func (p Point) Sub(q Point) Point { return Point{p.X - q.X, p.Y - q.Y} }

     type Path []Point

     func (path Path) TranslateBy(offset Point, add bool) {
       var op func(p, q Point) Point
       if add {
         op = Point.Add
       } else {
         op = Point.Sub
       }
       for i := range path {
         // en cada interaccion llama a path[i].Add(offset) o path[i].Sub(offset).
         path[i] = op(path[i], offset)
       }
     }
   < src..

** Seccion 6.5 <> Ejemplo: Tipo de Vector de Bits

   Los conjuntos en Go se implementan generalmente como un @c(map[T]bool), donde
   @c(T) es el tipo del elemento. Un conjunto representado por un mapa es muy
   flexible pero, para ciertos problemas, una representacion especializada puede
   superarla. Por ejemplo, en dominios como el analisis de flujo de datos donde
   los elementos del conjunto son pequeños numeros enteros no negativos, los
   conjuntos tienen muchos elementos, y las operaciones de conjunto como union e
   interseccion son comunes, un vector de bits es ideal.

   Un vector de bits utiliza un slice de valores o @"(palabras) de enteros sin
   signo, cada bit de los cuales representa un posible elemento del conjunto. El
   conjunto contiene @c(i) si se establece el enesimo bit. El siguiente programa
   muestra un tipo de vector de bits simple con tres metodos:

   ..figure > @l(gopl.io/ch6/intset/intset.go<>gopl.io/ch6/intset)

     ..src > go
       // un IntSet es us conjunto pequeño de enteros no negativos.
       // El valor cero representa un conjunto vacio.
       type IntSet struct {
         words []uint64
       }

       // Has Informa cuando el conjunto contiene valores x no negativos.
       func (s *IntSet) Has(x int) bool {
         word, bit := x/64, uint(x%64)
         return word < len(s.words) && s.words[word]&(1<<bit) != 0
       }

       // Add agrega el valor x no negativo al conjunto.
       func (s *IntSet) Add(x int) {
         word, bit := x/64, uint(x%64)
         for word >= len(s.words) {
           s.words = append(s.words, 0)
         }
         s.words[word] |= 1 << bit
       }

       // UnionWith establece s a la union de s y t.
       func (s *IntSet) UnionWith(t *IntSet) {
         for i, tword := range t.words {
           if i < len(s.words) {
             s.words[i] |= tword
           } else {
             s.words = append(s.words, tword)
           }
         }
       }
     < src..


   Ya que cada palabra tiene 64 bits, para localizar el bit @c(x), se utiliza el
   cociente @c(x/64) como el indice de la palabra y el resto @c(x%64) como el
   indice de bit dentro de esa palabra. La operacion @c(UnionWith) utiliza el
   operador binario OR @c(|) Para calcular la union de 64 elementos a la
   vez. (Vamos a revisar la eleccion de palabras de 64 bits en el Ejercicio
   6.5.)

   Esta aplicacion carece de muchas caracteristicas deseables, algunas de las
   cuales se plantean como ejercicios, pero es dificil vivir sin: una forma de
   imprimir un @c(IntSet) como una cadena. Vamos a darle un metodo @c(String)
   como lo hicimos con @c(Celsius) en la @l(#Seccion 2.5):

   ..src > go
     // String regresa el conjunto como una cadena de la forma "{1 2 3}".
     func (s *IntSet) String() string {
       var buf bytes.Buffer
       buf.WriteByte('{')
       for i, word := range s.words {
         if word == 0 {
           continue
         }
         for j := 0; j < 64; j++ {
           if word&(1<<uint(j)) != 0 {
             if buf.Len() > len("{") {
               buf.WriteByte(' ')
             }
             fmt.Fprintf(&buf, "%d", 64*i+j)
           }
         }
       }
       buf.WriteByte('}')
       return buf.String()
     }
   < src..

   Note la similitud del metodo anterior @c(String) con @c(intsToString) en la
   @l(#Seccion 3.5.4); @c(bytes.Buffer) se utiliza a menudo de esta manera en
   metodos @c(String). El paquete @c(fmt) maneja tipos con un metodo @c(String)
   especialmente para que los valores de los tipos complicados se puedan mostrar
   de una manera amigable para el usuario. En lugar de imprimir la
   representacion del valor en bruto (una estructura en este caso), @c(fmt)
   llama al metodo @c(String). El mecanismo se basa en interfaces y tipo de
   afirmaciones, que vamos a explicar en el @l(#Capitulo 7).

   Ahora podemos mostrar @c(IntSet) en accion:

   ..src > go
     var x, y IntSet
     x.Add(1)
     x.Add(144)
     x.Add(9)
     fmt.Println(x.String()) // "{1 9 144}"

     y.Add(9)
     y.Add(42)
     fmt.Println(y.String()) // "{9 42}"

     x.UnionWith(&y)
     fmt.Println(x.String()) // "{1 9 42 144}"

     fmt.Println(x.Has(9), x.Has(123)) // "true false"
   < src..

   Una palabra de precaucion: declaramos @c(String) y @c(Has) como metodos de
   tipo puntero @c(*IntSet) no por necesidad, sino por coherencia con los otros
   dos metodos, los cuales necesitan un receptor puntero porque asignan a
   @c(s.words). En consecuencia, un valor @c(IntSet) no tiene un metodo
   @c(String), en ocasiones, conduce a sorpresas como esta:

   ..src > go
     fmt.Println(&x)         // "{1 9 42 144}"
     fmt.Println(x.String()) // "{1 9 42 144}"
     fmt.Println(x)          // "{[4398046511618 0 65536]}"
   < src..

   En el primer caso, Imprimimos un puntero @c(*IntSet), que tiene un metodo
   @c(String). En el segundo caso, llamamos a @c[String()] en una variable
   @c(IntSet); el compilador inserta la operacion @c(&) implicita, que nos da un
   puntero, que tiene el metodo @c(String). Sin embargo, en el tercer caso,
   debido a que el valor @c(IntSet) no tiene un metodo @c(String),
   @c(fmt.Println) imprime la representacion de la estructura en su lugar. Es
   importante no olvidar el operador @c(&). Hacer @c(String) un metodo de
   @c(IntSet), no @c(*IntSet), podria ser una buena idea, pero esto requiere un
   juicio caso por caso.

   @b(Ejercicio 6.1): Implementar estos metodos adicionales:

   ..src > go
     func (*IntSet) Len() int      // regresa el numero de elementos
     func (*IntSet) Remove(x int)  // elimina x del conjunto
     func (*IntSet) Clear()        // elimina todos los elementos del conjunto
     func (*IntSet) Copy() *IntSet // regresa una copia del conjunto
   < src..

   @b(Ejercicio 6.2): Definir una metodo variadic @c[(*IntSet).AddAll(...int)]
   que permita añadir una lista de valores, como @c[s.AddAll(1, 2, 3)].

   @b(Ejercicio 6.3): @c[(*IntSet).UnionWith] calcula la union de dos conjuntos
   utilizando @c(|), el operador OR binario. Implementar metodos para
   @c(IntersectWith), @c(DifferenceWith), y @c(SymmetricDifference) para las
   operaciones de conjuntos correspondientes. (La diferencia simetrica de dos
   conjuntos contiene los elementos presentes en un conjunto o el otro, pero no
   ambos.)

   @b(Ejercicio 6.4): añadir un metodo @c(Elems) que devuelve un slice que
   contiene los elementos del conjunto, apto para iterar sobre el con una bucle
   @c(range).

   @b(Ejercicio 6.5): El tipo de cada palabra usada por @c(IntSet) es
   @c(uint64), pero la aritmetica de 64 bits puede ser ineficiente en una
   plataforma de 32 bits. Modificar el programa para usar el tipo @c(uint), que
   es el tipo entero sin signo mas eficiente para la plataforma. En lugar de
   dividir por 64, definir una constante que almacene el tamaño efectivo de
   @c(uint) en bits, 32 o 64. Se puede utilizar la expresion tal vez demasiado
   inteligente @c[32 << (^uint(0) >> 63)] para este proposito.

** Seccion 6.6 <> Encapsulacion

   Se dice que una variable o metodo de un objeto esta encapsulado si es
   inaccesible para los clientes del objeto. La encapsulacion, a veces llamado
   ocultacion de la informacion, es un aspecto clave de la programacion
   orientada a objetos.

   Go solo tiene un mecanismo para controlar la visibilidad de los nombres: los
   identificadores capitalizados se exportan desde el paquete en el que estan
   definidos y los nombres no capitalizados no. El mismo mecanismo que limita el
   acceso a los miembros de un paquete tambien limita el acceso a los campos de
   una estructura o los metodos de un tipo. Como consecuencia, para encapsular
   un objeto, debemos hacer que sea una estructura.

   Esa es la razon por la que el tipo @c(IntSet) de la seccion anterior fue
   declarado como un tipo de estructura a pesar de que solo tiene un unico
   campo:

   ..src > go
     type IntSet struct {
       words []uint64
     }
   < src..

   En cambio podriamos definir @c(IntSet) como un tipo de slice de la siguiente
   manera, aunque por supuesto tendriamos que sustituir cada ocurrencia de
   @c(s.words) por @c(*s) en sus metodos:

   ..src > go
     type IntSet []uint64
   < src..

   Aunque esta version de @c(IntSet) esencialmente seria equivalente, permitiria
   a clientes de otros paquetes leer y modificar el slice directamente. Dicho de
   otra manera, mientras que la expresion @c(*s) se podrian utilizar en
   cualquier paquete, @c(s.words) solo puede aparecer en el paquete que define
   @c(IntSet).

   Otra consecuencia de este mecanismo basado en el nombre es que la unidad de
   encapsulacion es el paquete, no el tipo como en muchos otros lenguajes. Los
   campos de un tipo de estructura son visibles para todo el codigo dentro del
   mismo paquete. Si el codigo aparece en una funcion o un metodo no hace
   ninguna diferencia.

   La encapsulacion proporciona tres beneficios. En primer lugar, debido a que
   los clientes no pueden modificar directamente las variables del objeto, es
   necesario inspeccionar menos enunciados para comprender los valores posibles
   de esas variables.

   En segundo lugar, ocultar los detalles de la implementacion impide que los
   clientes dependan de las cosas que podrian cambiar, lo que le da al diseñador
   mayor libertad para evolucionar la implementacion sin romper la
   compatibilidad de la API.

   Como ejemplo, considere el tipo @c(bytes.Buffer). Se utiliza con frecuencia
   para acumular cadenas muy cortas, por lo que es una optimizacion rentable
   para reservar un poco mas de espacio en el objeto para evitar la asignacion
   de memoria en este caso comun. Ya que @c(Buffer) es un tipo @c(struct), este
   espacio tiene la forma de un campo adicional de tipo @c([64]byte) con un
   nombre en minusculas. Ya que se añadio este campo, y no es exportado, los
   clientes de @c(Buffer) fuera del paquete @c(bytes) no son conscientes de
   ningun cambio, excepto un rendimiento mejorado. @c(Buffer) y su metodo
   @c(Grow) se muestran a continuacion, simplificado para mayor claridad:

   ..src > go
     type Buffer struct {
       buf     []byte
       initial [64]byte
       /* ... */
     }

     // Grow apmlia la capacidad del buffer, si es necesario,
     // para garantizar espacio por otros n bytes. [...]
     func (b *Buffer) Grow(n int) {
       if b.buf == nil {
         b.buf = b.initial[:0] // Utilizar inicialmente el espacio previamente asignado
       }
       if len(b.buf)+n > cap(b.buf) {
         buf := make([]byte, b.Len(), 2*cap(b.buf) + n)
         copy(buf, b.buf)
         b.buf = buf
       }
     }
   < src..

   El tercer beneficio de la encapsulacion, y en muchos casos el mas importante,
   es que impide que los clientes establezcan arbitrariamente las variables de
   un objeto. Debido a que las variables del objeto solo pueden ser definidas
   por funciones en el mismo paquete, el autor de ese paquete puede garantizar
   que todas esas funciones mantengan las invariantes internas del objeto. Por
   ejemplo, el tipo @c(Counter) a continuacion permite a los clientes incrementar
   el contador o reestablecerlo a cero, pero no ponerlo en un valor arbitrario:

   ..src > go
     type Counter struct { n int }

     func (c *Counter) N() int     { return c.n }
     func (c *Counter) Increment() { c.n++ }
     func (c *Counter) Reset()     { c.n = 0 }
   < src..

   Las Funciones que simplemente acceden o modifican los valores internos de un
   tipo, como los metodos del tipo @c(Logger) del paquete @c(log), a
   continuacion, se denominan @e(getters) (optenedores) y @e(setters)
   (definidores). Sin embargo, al nombrar a un metodo getter, por lo general
   omitimos el prefijo @c(Get). Esta preferencia por razones de brevedad se
   extiende a todos los metodos, no solo a los accesores de campo, y para otros
   prefijos redundantes, como @c(Fetch), @c(Find), y @c(Lookup).

   ..src > go
     package log

     type Logger struct {
       flags  int
       prefix string
       // ...
     }

     func (l *Logger) Flags() int
     func (l *Logger) SetFlags(flag int)
     func (l *Logger) Prefix() string
     func (l *Logger) SetPrefix(prefix string)
   < src..

   El estilo de Go no prohibe exportar los campos. Por supuesto, una vez
   exportado, un campo no puede ser exportado sin un cambio incompatible a la
   API, por lo que la eleccion inicial debe ser deliberada y debe considerar la
   complejidad de los invariantes que deben mantenerse, la probabilidad de
   cambios futuros y la cantidad del codigo cliente que se veria afectado por un
   cambio.

   La encapsulacion no siempre es deseable. Al revelar su representacion como un
   numero @c(int64) de nanosegundos, @c(time.Duration) nos permite usar todas
   las operaciones aritmeticas y de comparacion con duraciones habituales, e
   incluso definir constantes de este tipo:

   ..src > go
     const day = 24 * time.Hour
     fmt.Println(day.Seconds()) // "86400"
   < src..

   Como otro ejemplo, contraste @c(IntSet) con el tipo @c(geometry.Path) al
   principio de este capitulo. @c(Path) se definio como un tipo de slice,
   permitiendo a sus clientes construir instancias utilizando la sintaxis
   literal de slice, para iterar sobre sus puntos usando un bucle de rango, y
   asi sucesivamente, mientras que estas operaciones se le niegan a los clientes
   de @c(IntSet).

   Esta es la diferencia fundamental: @c(geometry.Path) es intrinsecamente una
   secuencia de puntos, ni mas ni menos, y no prevemos la adicion de nuevos
   campos a la misma, asi que tiene sentido para el paquete @c(geometry) revelar
   que @c(Path) es un slice. En contraste, un @c(IntSet) simplemente pasa a ser
   representado como un slice @c([]uint64). Podria haber sido representado
   mediante @c([]uint), o algo completamente diferente para los conjuntos que
   son escasos o muy pequeños, y que tal vez podrian beneficiarse de
   caracteristicas adicionales como un campo adicional para registrar el numero
   de elementos en el conjunto. Por estas razones, tiene sentido que @c(IntSet)
   sea opaco.

   En este capitulo, aprendimos como asociar metodos con tipos con nombre y como
   llamar a esos metodos. Aunque los metodos son cruciales para la programacion
   orientada a objetos, son solo la mitad de la imagen. Para completarla,
   necesitamos @e(interfaces), el tema del proximo capitulo.

* Capitulo 7 <> Interfaces

  Los tipos de interfaz expresan generalizaciones o abstracciones sobre los
  comportamientos de otros tipos. Al generalizar, las interfaces nos permiten
  escribir funciones que son mas flexibles y adaptables porque no estan
  vinculadas a los detalles de una implementacion en particular.

  Muchos lenguajes orientados a objetos tienen alguna nocion de interfaces, pero
  lo que hace que las interfaces de Go sean tan distintivas es que se @e(satisfacen
  de manera implicita). En otras palabras, no hay necesidad de declarar todas
  las interfaces que satisface un tipo determinado en concreto; basta con poseer
  los metodos necesarios. Este diseño le permite crear nuevas interfaces que
  sean satisfechas por tipos concretos existentes sin cambiar los tipos
  existentes, lo cual es particularmente util para tipos definidos en paquetes
  que no controla.

  En este capitulo, comenzaremos examinando la mecanica basica de los tipos de
  interfaz y sus valores. En el camino, estudiaremos varias interfaces
  importantes de la libreria estandar. Muchos programas Go hacen uso intensivo
  de interfaces estandar como lo hacen con las propias. Por ultimo, examinaremos
  los @e(tipos de aserciones) @%l(#Seccion 7.10<>§7.10) y @e(switches de tipo)
  @%l(#Seccion 7.13<>§7.13) y veremos como permiten un tipo diferente de
  generalidad.

** Seccion 7.1 <> Interfaces como Contratos

   Todos los tipos que hemos visto hasta ahora han sido @e(tipos concretos). Un
   tipo concreto especifica la representacion exacta de sus valores y expone las
   operaciones intrinsecas de esa representacion, como la aritmetica para
   numeros, o indexacion, @c(append), y @c(range) para slices. Un tipo concreto
   tambien puede proporcionar comportamientos adicionales a traves de sus
   metodos. Cuando se tiene un valor de un tipo concreto, usted sabe exactamente
   lo que es y lo que puede hacer con el.

   Hay otro tipo en Go llama un @e(tipo interfaz). Una interfaz es un tipo
   abstracto. No expone la representacion o estructura interna de sus valores,
   ni el conjunto de operaciones basicas que soporta; revela solo algunos de sus
   metodos. Cuando se tiene un valor de un tipo interfaz, que no saben nada de
   lo que es; solo se sabe lo que puede hacer, o mas exactamente, que
   comportamientos son proporcionados por sus metodos.

   A lo largo del libro, hemos estado utilizando dos funciones similares para el
   formateo de cadenas: @c(fmt.Printf), que escribe el resultado a la salida
   estandar (un archivo), y @c(fmt.Sprintf), que devuelve el resultado como un
   @c(string). Seria lamentable que la parte dificil, el formato del resultado,
   tuviera que ser duplicado debido a estas diferencias superficiales en la
   forma en que el resultado se utiliza. Gracias a las interfaces, no lo
   hace. Ambas funciones son, en efecto, envolturas alrededor de una tercer
   funcion, @c(fmt.Fprintf), que es agnostico acerca de lo que ocurre con el
   resultado que calcula:

   ..src > go
     package fmt

     func Fprintf(w io.Writer, format string, args ...interface{}) (int, error)

     func Printf(format string, args ...interface{}) (int, error) {
       return Fprintf(os.Stdout, format, args...)
     }

     func Sprintf(format string, args ...interface{}) string {
       var buf bytes.Buffer
       Fprintf(&buf, format, args...)
       return buf.String()
     }
   < src..

   El prefijo @c(F) de @c(Fprintf) significa @e(file) (archivo) e indica que la
   salida formateada se debe escribir en el fichero proporcionado como primer
   argumento. En el caso de @c(Printf), el argumento, @c(os.Stdout), es un
   @c(*os.File). En el caso @c(Sprintf), sin embargo, el argumento no es un
   archivo, aunque se asemeja superficialmente a uno: @c(&buf) es un puntero a
   un bufer de memoria a la que se pueden escribir bytes.

   El primer parametro de @c(Fprintf) no es un archivo cualquiera. Es un
   @c(io.Writer), que es un tipo de interfaz con la siguiente declaracion:

   ..src > go
     package io

     // Writer es la interfaz que envuelve el metodo de escritura basico.
     type Writer interface {
       // Write escribe len(p) bytes de p en el flujo de datos subyacente.
       // Devuelve el numero de bytes escritos de p (0 <= n <= len(p))
       // y cualquier error encontrado que cause un paro temprano en la escritura.
       // Write debe regresar un error no-nil si devulve n < len(p).
       // Write no debe modificar los datos del slice, ni siquiera temporalmente.
       //
       // Las imprementaciones no deben retener a p.
       Write(p []byte) (n int, err error)
     }
   < src..

   La interfaz @c(io.Writer) define el contrato entre @c(Fprintf) y sus
   interlocutores. Por un lado, el contrato requiere que el llamador proporcione
   un valor de un tipo concreto como @c(*os.File) o @c(*bytes.Buffer) que tiene
   un metodo denominado @c(Write) con la firma y el comportamiento apropiado.
   Por otra parte, el contrato garantiza que @c(Fprintf) hara su trabajo dando
   cualquier valor que satisfaga la interfaz @c(io.Writer). @c(Fprintf) no puede
   asumir que se esta escribiendo en un archivo o en la memoria, solo que se
   puede llamar a @c(Write).

   Ya que @c(fmt.Fprintf) no asume nada acerca de la representacion del valor y
   se basa unicamente en los comportamientos garantizados por el contrato
   @c(io.Writer), podemos pasar con seguridad un valor concreto de cualquier
   tipo que satisfaga @c(io.Writer) como primer argumento de @c(fmt.Fprintf).
   Esta libertad para sustituir un tipo por otro que satisface la misma interfaz
   se denomina @e(sustituibilidad), y es una caracteristica de la programacion
   orientada a objetos.

   Vamos a probar esto usando un nuevo tipo. A continuacion el metodo @c(Write)
   del tipo @c(*ByteCounter) simplemente cuenta los bytes escritos antes de
   descartarlos. (La conversion se requiere para hacer que los tipos de
   @c[len(p)] y @c(*c) coincidan en la sentencia de asignacion @c(+=).)

   ..figure > @l(gopl.io/ch7/bytecounter/main.go<>gopl.io/ch7/bytecounter)

     ..src > go
       type ByteCounter int

       func (c *ByteCounter) Write(p []byte) (int, error) {
         *c += ByteCounter(len(p)) // convert int to ByteCounter
         return len(p), nil
       }
     < src..


   Puesto que @c(*ByteCounter) satisface el contrato @c(io.Writer), podemos
   pasarlo a @c(Fprintf), que hace su formateo de cadenas ajeno a este cambio;
   @c(ByteCounter) acumula correctamente la longitud del resultado.

   ..src > go
     var c ByteCounter
     c.Write([]byte("hello"))
     fmt.Println(c) // "5", = len("hello")

     c = 0          // reinicia el contador
     var name = "Dolly"
     fmt.Fprintf(&c, "hello, %s", name)
     fmt.Println(c) // "12", = len("hello, Dolly")
   < src..

   Ademas de @c(io.Writer), hay otra interfaz de gran importancia para el
   paquete @c(fmt). @c(Fprintf) y @c(Fprintln) proporcionan una forma para que
   los tipos controlen como se imprimen sus valores. En la @l(#Seccion 2.5),
   definimos un metodo @c(String) para el tipo @c(Celsius) de modo que las
   temperaturas se impriman como @c("100°C"), y en la @l(#Seccion 6.5) hemos
   equipado a @c(*IntSet) con un metodo @c(String) de modo que los conjuntos
   fueran renderizados utilizando la notacion de conjuntos tradicional como
   @c("{1 2 3}"). La declaracion de un metodo @c(String) hace que un tipo
   satisfaga una de las interfaces mas utilizados de todas, @c(fmt.Stringer):

   ..src > go
     package fmt

     // El metodo String se utiliza para imprimr los valores recividos
     // como un operando de cualquier formato que acepte una cadena
     // o una impresion sin formato como Print.
     type Stringer interface {
       String() string
     }
   < src..

   Vamos a explicar como el paquete @c(fmt) descubre que valores satisfacen esta
   interfaz en la @l(#Seccion 7.10).

   @b(Ejercicio 7.1): Haciendo uso de las ideas de @c(ByteCounter), implementar
   contadores para lineas y palabras. Puedes encontrar util @c(bufio.ScanWords).

   @b(Ejercicio 7.2): Escribir una funcion @c(CountingWriter) con la firma
   siguiente, dando un @c(io.Writer), devuelve un nuevo @c(Writer) que envuelve
   el original, y un puntero a una variable @c(int64) que contenga en cualquier
   momento el numero de bytes escritos en el nuevo @c(Writer) .

   ..src > go
     func CountingWriter(w io.Writer) (io.Writer, *int64)
   < src..

   @b(Ejercicio 7.3): Escribir un metodo @c(String) para el tipo @c(*tree) de
   @c(gopl.io/ch4/treesort) @%l(#Seccion 4.4<>§4.4) que revele la secuencia de
   valores en el arbol.

** Seccion 7.2 <> Tipos de Interfaz

   Un tipo de interfaz especifica un conjunto de metodos que un tipo de concreto
   debe poseer para ser considerado una instancia de esa interfaz.

   El tipo @c(io.Writer) es una de las interfaces mas utilizados, ya que
   proporciona una abstraccion de todos los tipos a los que se pueden escribir
   bytes, que incluye archivos, buffers de memoria, conexiones de red, clientes
   HTTP, archivadores, hashers, etc. El paquete @c(io) define muchas otras
   interfaces utiles. Un @c(Reader) representa cualquier tipo del que se pueden
   leer bytes, y un @c(Closer) es cualquier valor que se puede cerrar, como un
   archivo o una conexion de red. (Por ahora probablemente has notado la
   convencion de nomenclatura para muchas de las interfaces de metodo unico de
   Go).

   ..src > go
     package io

     type Reader interface {
       Read(p []byte) (n int, err error)
     }

     type Closer interface {
       Close() error
     }
   < src..

   Mirando mas lejos, encontramos declaraciones de nuevos tipos de interfaz como
   combinaciones de los ya existentes. He aqui dos ejemplos:

   ..src > go
     type ReadWriter interface {
       Reader
       Writer
     }

     type ReadWriteCloser interface {
       Reader
       Writer
       Closer
     }
   < src..

   La sintaxis utilizada, se asemeja al enbebido de estructuras, nos permite
   nombrar otra interfaz como una abreviatura para escribir todos sus
   metodos. Esto se denomina @e(embeber) una interfaz. Podriamos haber escrito
   @c(io.ReadWriter) sin enbeberla, aunque de manera menos sucinta, como aqui:

   ..src > go
     type ReadWriter interface {
       Read(p []byte) (n int, err error)
       Write(p []byte) (n int, err error)
     }
   < src..

   o incluso utilizando una mezcla de los dos estilos:

   ..src > go
     type ReadWriter interface {
       Read(p []byte) (n int, err error)
       Writer
     }
   < src..

   Las tres declaraciones tienen el mismo efecto. El orden en que aparecen los
   metodos es irrelevante. Todo lo que importa es el conjunto de metodos.

   @b(Ejercicio 7.4): La funcion @c(strings.NewReader) devuelve un valor que
   satisface la interfaz @c(io.Reader) (y otras) mediante la lectura de su
   argumento, una cadena. Implementa tu mismo una version simple de
   @c(NewReader), y utilizala para hacer que el analizador de HTML @%l(#Seccion
   5.2<>§5.2) tome la entrada de una cadena.

   @b(Ejercicio 7.5): La funcion @c(LimitReader) en el paquete @c(io) acepta un
   @c(io.Reader) @c(r) y un numero de bytes @c(n), y devuelve otro @c(Reader)
   que lee desde @c(r) pero reporta una condicion de fin de archivo despues de
   @c(n) bytes. Implementalo.

   ..src > go
     func LimitReader(r io.Reader, n int64) io.Reader
   < src..

** Seccion 7.3 <> Satisfaccion de la Interfaz

   Un tipo satisface una interfaz si posee todos los metodos que la interfaz
   requiere. Por ejemplo, un @c(*os.File) satisface @c(io.Reader), @c(Writer),
   @c(Closer), y @c(ReadWriter). Un @c(*bytes.Buffer) satisface @c(Reader),
   @c(Writer), y @c(ReadWriter), pero no satisfacer @c(Closer), ya que no tiene
   un metodo @c(Close). Como una abreviatura, los programadores de Go a menudo
   dicen que un tipo concreto @"(es un) tipo de interfaz en particular, lo que
   significa que satisface la interfaz. Por ejemplo, un @c(*bytes.Buffer) es un
   @c(io.Writer); un @c(*os.File) es un @c(io.ReadWriter).

   La regla de asignabilidad @%l(#Seccion 2.4.2<>§2.4.2) para interfaces es muy
   simple: una expresion puede ser asignada a una interfaz solo si su tipo se
   ajusta a la interfaz. Asi que:

   ..src > go
     var w io.Writer
     w = os.Stdout           // OK: *os.File tiene metodo Write
     w = new(bytes.Buffer)   // OK: *bytes.Buffer tiene metodo Write
     w = time.Second         // error de compilacion: time.Duration carece de metodo Write

     var rwc io.ReadWriteCloser
     rwc = os.Stdout         // OK: *os.File tiene metodos Read, Write, Close
     rwc = new(bytes.Buffer) // error de compilacion: *bytes.Buffer carece de metodo Close
   < src..

   Esta regla se aplica incluso cuando el lado derecho es en si mismo una
   interfaz:

   ..src > go
     w = rwc                 // OK: io.ReadWriteCloser tiene metodo Write
     rwc = w                 // error de compilacion: io.Writer carece de metodo Close
   < src..

   Como @c(ReadWriter) y @c(ReadWriteCloser) incluyen todos los metodos de
   @c(Writer), cualquier tipo que satisface @c(ReadWriter) o @c(ReadWriteCloser)
   satisface @c(Writer) necesariamente.

   Antes de ir mas lejos, debemos explicar una sutileza en lo que significa para
   un tipo tener un metodo. Recuerde de la @l(#Seccion 6.2) que para cada tipo
   concreto llamado @c(T), algunos de sus metodos tienen un receptor de tipo
   @c(T), mientras que otros requieren un puntero @c(*T). Recordemos tambien que
   es legal llamar a un metodo @c(*T) en un argumento de tipo @c(T), siempre y
   cuando el argumento sea una variable; el compilador toma implicitamente su
   direccion. Pero esto es mero azucar sintactico: un valor de tipo @c(T) no
   posee todos los metodos que tiene un puntero @c(*T), y como resultado podria
   satisfacer menos interfaces.

   Un ejemplo lo hara claro. El metodo @c(String) del tipo @c(IntSet) de la
   @l(#Seccion 6.5) requiere un receptor puntero, asi que no podemos llamar a
   ese metodo en un valor @c(IntSet) no direccionable:

   ..src > go
     type IntSet struct { /* ... */ }
     func (*IntSet) String() string

     var _ = IntSet{}.String() // error de compilacion: String requiere un receptor *intSet
   < src..

   pero podemos decir que es una variables @c(IntSet):

   ..src > go
     var s IntSet
     var _ = s.String() // OK: s es una variable y &s tiene el metodo String
   < src..

   Sin embargo, puesto que solamente @c(*IntSet) tiene un metodo @c(String),
   solamente @c(*IntSet) satisface la interfaz @c(fmt.Stringer):

   ..src > go
     var _ fmt.Stringer = &s // OK
     var _ fmt.Stringer = s  // error de compilacion: IntSet carece de metodo String
   < src..

   La @l(#Seccion 12.8) incluye un programa que imprime los metodos de un valor
   arbitrario, y la herramienta @$(godoc -analysis=type) @%l(#Seccion
   10.7.4<>§10.7.4) muestra los metodos de cada tipo y la relacion entre las
   interfaces y tipos concretos.

   Como un sobre que envuelve y oculta la carta que contiene, una interfaz
   envuelve y oculta el tipo concreto y el valor que contiene. Solo los metodos
   revelados por el tipo de interfaz pueden ser llamados, incluso si el tipo
   concreto tiene otros:

   ..src > go
     os.Stdout.Write([]byte("hello")) // OK: *os.File tiene el metodo Write
     os.Stdout.Close()                // OK: *os.File tiene el metodo Close

     var w io.Writer
     w = os.Stdout
     w.Write([]byte("hello")) // OK: io.Writer tiene el metodo Write
     w.Close()                // compile error: io.Writer carece del metodo Close
   < src..

   Una interfaz con mas metodos, como @c(io.ReadWriter), nos dice mas acerca de
   los valores que contiene, y coloca mayores demandas sobre los tipos que la
   implementan, que una interfaz con un menos metodos como @c(io.Reader).
   Entonces, que hace el tipo @c(interface{}), que no tiene ningun metodo en
   absoluto, nos cuenta sobre los tipos concretos que lo satisfacen?

   Eso es correcto: nada. Esto puede parecer inutil, pero en realidad el tipo
   @c(interface{}), que se denomina el tipo de @e(interfaz vacia), es
   indispensable. Debido a que el tipo de interfaz vacia no impone exigencias a
   los tipos que lo satisfacen, podemos asignar @e(cualquier) valor a la
   interfaz vacia.

   ..src > go
     var any interface{}
     any = true
     any = 12.34
     any = "hello"
     any = map[string]int{"one": 1}
     any = new(bytes.Buffer)
   < src..

   A pesar de no ser obvio, hemos utilizando el tipo de interfaz vacia desde
   el primer ejemplo en este libro, porque es lo que permite que funciones como
   @c(fmt.Println), o @c(errorf) en la @l(#Seccion 5.7), acepten argumentos de
   cualquier tipo.

   Por supuesto, despues de crear un valor @c(interface{}) que contiene un valor
   booleano, float, string, mapa, puntero, o de cualquier otro tipo, no podemos
   hacer nada directamente con el valor que posee ya que la interfaz no tiene
   metodos. Necesitamos una forma de recuperar el valor nuevamente. Veremos como
   hacerlo utilizando un @e(tipo de asercion) en la @l(#Seccion 7.10).

   Dado que la satisfaccion de la interfaz depende solo de los metodos de los
   dos tipos implicados, no hay necesidad de declarar la relacion entre un tipo
   concreto y las interfaces que satisface. Dicho esto, ocasionalmente es util
   documentar y afirmar la relacion cuando se pretende, pero no se aplica de
   otro modo por el programa. La declaracion a continuacion afirma en tiempo de
   compilacion que un valor de tipo @c(*bytes.Buffer) satisface @c(io.Writer):

   ..src > go
     // *bytes.Buffer debe satirfacer io.Writer
     var w io.Writer = new(bytes.Buffer)
   < src..

   No tenemos que asignar una nueva variable, ya que cualquier valor de tipo
   @c(*bytes.Buffer) lo hara, incluso @c(nil), que escribimos como
   @c[(*bytes.Buffer)(nil)] mediante una conversion explicita. Y ya que nunca
   intentamos referirnos a @c(w), podemos sustituirlo por el identificador en
   blanco. Juntos, estos cambios nos dan esta variante mas frugal:

   ..src > go
     // *bytes.Buffer debe satisfacer io.Writer
     var _ io.Writer = (*bytes.Buffer)(nil)
   < src..

   Los tipos de interfaces no-vacios como @c(io.Writer) suelen ser satisfechos por
   un tipo de puntero, sobre todo cuando uno o mas de los metodos de interfaz
   implica algun tipo de mutacion en el receptor, como la hace el metodo @c(Write).
   Un puntero a una estructura es un tipo de metodo especialmente comun.

   Pero los tipos de puntero no son de ninguna manera los unicos tipos que
   satisfacen las interfaces, e incluso las interfaces con los metodos mutator
   pueden ser satisfechas por uno de los otros tipos de referencia de Go. Hemos
   visto ejemplos de tipos de slice con metodos (@c(geometry.Path), @l(#Seccion
   6.1<>§6.1)) y tipos de mapas con metodos (@c(url.Values), @l(#Seccion
   6.2.1<>§6.2.1)), y mas adelante veremos un tipo de funcion con metodos
   (@c(http.HandlerFunc), @l(#Seccion 7.7<>§7.7)). Incluso los tipos basicos
   pueden satisfacer interfaces; como vimos en la @l(#Seccion 7.4), @c(time.Duration)
   satisface @c(fmt.Stringer).

   Un tipo concreto puede satisfacer muchas interfaces no relacionadas.
   Considere un programa que organiza o vende artefactos culturales
   digitalizados como musica, peliculas y libros. Podria definir el siguiente
   conjunto de tipos concretos:

   ..pre >
     Album
     Book
     Movie
     Magazine
     Podcast
     TVEpisode
     Track

   Podemos expresar cada abstraccion de interes como una interfaz. Algunas
   propiedades son comunes a todos los artefactos, como un titulo, una fecha de
   creacion y una lista de creadores (autores o artistas).

   ..src > go
     type Artifact interface {
       Title() string
       Creators() []string
       Created() time.Time
     }
   < src..

   Otras propiedades estan restringidas a ciertos tipos de artefactos. Las
   propiedades de @c(printed_word) solo son relevantes para libros y revistas,
   mientras que solo las peliculas y episodios de television tienen una
   resolucion de pantalla.

   ..src > go
     type Text interface {
       Pages() int
       Words() int
       PageSize() int
     }

     type Audio interface {
       Stream() (io.ReadCloser, error)
       RunningTime() time.Duration
       Format() string // e.g., "MP3", "WAV"
     }

     type Video interface {
       Stream() (io.ReadCloser, error)
       RunningTime() time.Duration
       Format() string // e.g., "MP4", "WMV"
       Resolution() (x, y int)
     }
   < src..

   Estas interfaces no son sino una forma util de agrupar tipos concretos
   relacionados y expresar las facetas que comparten en comun. Podemos descubrir
   otras agrupaciones mas tarde. Por ejemplo, si descubrimos que necesitamos
   manejar elementos de @c(Audio) y @c(Video) de la misma manera, podemos
   definir una interfaz @c(Streamer) para representar sus aspectos comunes sin
   cambiar ninguna declaracion de tipos existentes.

   ..src > go
     type Streamer interface {
       Stream() (io.ReadCloser, error)
       RunningTime() time.Duration
       Format() string
     }
   < src..

   Cada agrupacion de tipos concretos basados en sus comportamientos compartidos
   puede expresarse como un tipo de interfaz. A diferencia de los lenguajes
   basados en clases, en los que el conjunto de interfaces satisfecho por una
   clase es explicito, en Go podemos definir nuevas abstracciones o agrupaciones
   de interes cuando las necesitamos, sin modificar la declaracion del tipo
   concreto. Esto es particularmente util cuando el tipo concreto proviene de un
   paquete escrito por un autor diferente. Por supuesto, es necesario que haya
   puntos comunes subyacentes en los tipos concretos.

** Seccion 7.4 <> Analizar Banderas con @c(flag.Value)

   En esta seccion, vamos a ver como otro interfaz estandar, @c(flag.Value), nos
   ayuda a definir nuevas notaciones de opciones de linea de comandos. Considere
   el programa a continuacion, que duerme durante un periodo de tiempo
   especificado.

   ..figure > @l(gopl.io/ch7/sleep/sleep.go<>gopl.io/ch7/sleep)

     ..src > go
       var period = flag.Duration("period", 1*time.Second, "sleep period")

       func main() {
         flag.Parse()
         fmt.Printf("Sleeping for %v...", *period)
         time.Sleep(*period)
         fmt.Println()
       }
     < src..


   Antes de que se vaya a dormir imprime el periodo de tiempo. El paquete
   @c(fmt) llama al metodo @c(String) de @c(time.Duration) para imprimir el
   periodo no como un numero de nanosegundos, sino en una notacion facil de
   usar:

   ..srci > sh
     > go build gopl.io/ch7/sleep
     > ./sleep
     Sleeping for 1s...
   < srci..

   Por defecto, el periodo de sueño es de un segundo, pero se puede controlar a
   traves de la bandera de linea de comandos @c(-period). La funcion
   @c(flag.Duration) crea una variable de tipo bandera @c(time.Duration) y
   permite al usuario especificar la duracion en una variedad de formatos
   faciles de usar, incluyendo la misma notacion que imprime el metodo
   @c(String). Esta simetria de diseño conduce a una interfaz de usuario
   agradable.

   ..srci > sh
     > ./sleep -period 50ms
     Sleeping for 50ms...
     > ./sleep -period 2m30s
     Sleeping for 2m30s...
     > ./sleep -period 1.5h
     Sleeping for 1h30m0s...
     > ./sleep -period "1 day"
     invalid value "1 day" for flag -period: time: invalid duration 1 day
   < srci..

   Debido a que las banderas de valor de duracion son tan utiles, esta
   caracteristica esta integrada en el paquete @c(flag), pero es facil definir
   nuevas notaciones bandera para nuestros propios tipos de datos. Solo
   necesitamos definir un tipo que satisfaga la interfaz @c(flag.Value), cuya
   declaracion es la siguiente:

   ..src > go
     package flag

     // Value es la interfaz con el valor almacenado en un indicador.
     type Value interface {
       String() string
       Set(string) error
     }
   < src..

   El metodo @c(String) formatea el valor de la bandera para su uso en los
   mensajes de ayuda de linea de comandos; asi, cada @c(flag.Value) es tambien
   un @c(fmt.Stringer). El metodo @c(Set) analiza su argumento de cadena y
   actualiza el valor del indicador. En efecto, el metodo @c(Set) es el inverso
   del metodo @c(String), y es una buena practica que puedan utilizar la misma
   notacion.

   Vamos a definir un tipo @c(celsiusFlag) que permite una temperatura que se
   especifica en @c(Celsius) o en @c(Fahrenheit) con una conversion
   apropiada. Observe que @c(celsiusFlag) incorpora un @c(Celsius) @%l(#Seccion
   2.5<>§2.5), consiguiendo asi un metodo @c(String) de forma gratuita. Para
   satisfacer @c(flag.Value), solo tenemos que declarar el metodo @c(Set):

   ..figure > @l(gopl.io/ch7/tempconv/tempconv.go<>gopl.io/ch7/tempconv)

     ..src > go
       // *celsiusFlag satisface la interfaz flag.Value.
       type celsiusFlag struct{ Celsius }

       func (f *celsiusFlag) Set(s string) error {
         var unit string
         var value float64
         fmt.Sscanf(s, "%f%s", &value, &unit) // no es necesario comprobar el error
         switch unit {
         case "C", "°C":
           f.Celsius = Celsius(value)
           return nil
         case "F", "°F":
           f.Celsius = FToC(Fahrenheit(value))
           return nil
         }
         return fmt.Errorf("invalid temperature %q", s)
       }
     < src..


   La llamada a @c(fmt.Sscanf) analiza un numero de coma flotante (@c[value]) y
   una cadena (@c[unit]) de la entrada @c(s). Aunque por lo general se debe
   comprobar el resultado error de @c(Sscanf), en este caso, no lo necesitamos
   porque si hay un problema, ningun caso coincidira con el @c(swich).

   La funcion @c(CelsiusFlag) siguiente lo envuelve todo. Al llamador, devuelve
   un puntero al campo @c(Celsius) enbebido dentro de la variable @c(f) de
   @c(celsiusFlag). El campo @c(Celsius) es la variable que sera actualizada por
   el metodo @c(Set) durante el procesamiento de banderas. La llamada a @c(Var)
   agrega la bandera al conjunto de banderas de linea de comando, la variable
   global @c(flag.CommandLine). Los programas con interfaces de linea de
   comandos inusualmente complejos pueden tener varias variables de este
   tipo. La llamada a @c(Var) asigna un argumento @c(*celsiusFlag) a un
   parametro @c(flag.Value), haciendo que el compilador compruebe que
   @c(*celsiusFlag) tiene los metodos necesarios.

   ..src > go
     // CelsiusFlag define una bandera Celsius con el nombre especificado,
     // valor predeterminado, y uso, y devuelve la direccion de la variable flag.
     // El argumento flag debe tener una cantidad y una unidad, por ejemplo, "100C".
     func CelsiusFlag(name string, value Celsius, usage string) *Celsius {
       f := celsiusFlag{value}
       flag.CommandLine.Var(&f, name, usage)
       return &f.Celsius
     }
   < src..

   Ahora podemos empezar a usar la nueva bandera en nuestros programas:

   ..figure > @l(gopl.io/ch7/tempflag/tempflag.go<>gopl.io/ch7/tempflag)

     ..src > go
       var temp = tempconv.CelsiusFlag("temp", 20.0, "the temperature")

       func main() {
         flag.Parse()
         fmt.Println(*temp)
       }
     < src..


   Aqui hay una sesion tipica:

   ..srci > sh
     > go build gopl.io/ch7/tempflag
     > ./tempflag
     20°C
     > ./tempflag -temp -18C
     -18°C
     > ./tempflag -temp 212°F
     100°C
     > ./tempflag -temp 273.15K
     invalid value "273.15K" for flag -temp: invalid temperature "273.15K"
     Usage of ./tempflag:
       -temp value
             the temperature (default 20°C)
     > ./tempflag -help
     Usage of ./tempflag:
       -temp value
             the temperature (default 20°C)
   < srci..


   @b(Ejercicio 7.6): Añadir soporte para temperaturas Kelvin a @c(tempflag).

   @b(Ejercicio 7.7): Explicar por que el mensaje de ayuda contiene @c(°C)
   cuando el valor por defecto de @c(20.0) no.

** Seccion 7.5 <> Valores de Interfaz

   Conceptualmente, un valor de un tipo de interfaz, o el valor de la interfaz,
   tiene dos componentes, un tipo concreto y un valor de ese tipo. Estos se
   denominan @e(tipo dinamico) y @e(valor dinamico) de la interfaz.

   Para un lenguaje de tipo estatico como Go, los tipos son un concepto de
   compilacion, por lo que un tipo no es un valor. En nuestro modelo conceptual,
   un conjunto de valores denominados @e(descriptores de tipo) proporcionan
   informacion sobre cada tipo, como su nombre y metodos. En un valor de
   interfaz, el componente de tipo esta representado por el descriptor de tipo
   apropiado.

   En las siguientes cuatro declaraciones, la variable @c(w) toma tres valores
   diferentes. (Los valores inicial y final son los mismos.)

   ..src > go
     var w io.Writer
     w = os.Stdout
     w = new(bytes.Buffer)
     w = nil
   < src..

   Echemos un vistazo mas de cerca el valor y el comportamiento dinamico de
   @c(w) despues de cada declaracion. La primera sentencia declara a @c(w):

   ..src > go
     var w io.Writer
   < src..

   En Go, las variables siempre se inicializan en un valor bien definido, y las
   interfaces no son la excepcion. El valor cero para una interfaz tiene ambos
   componentes de tipo y valor establecidos en @c(nil) (Figura 7.1).

   ..figure > Figura 7.1. Una interfaz de valor nil.

     ..art >
              w
              ┏━━━━━━━━━━━━┓
        tipo  ┃    nil     ┃
              ┣━━━━━━━━━━━━┫
       valor  ┃    nil     ┃
              ┗━━━━━━━━━━━━┛
     < art..

   Un valor de interfaz se describe como @c(nil) o no @c(nil) basado en su tipo
   dinamico, por lo que este es un valor de interfaz nil. Puede probar si un
   valor de interfaz es nil usando @c(w == nil) o @c(w != nil). Llamar a
   cualquier metodo de un valor de interfaz nil causa un panico:

   ..src > go
     w.Write([]byte("hello")) // panico: desreferencia de puntero nil
   < src..

   La segunda instruccion asigna un valor de tipo @c(*os.File) a @c(w):

   ..src > go
     w = os.Stdout
   < src..

   Esta asignacion implica una conversion implicita de un tipo concreto para un
   tipo de interfaz, y es equivalente a la conversion explicita
   @c[io.Writer(os.Stdout)]. Una conversion de este tipo, ya sea explicita o
   implicita, captura el tipo y el valor de su operando. El tipo dinamico del valor
   de la interfaz se establece en el descriptor de tipo para el tipo de puntero
   @c(*os.File), y su valor dinamico contiene una copia de @c(os.Stdout), que es
   un puntero a la variable @c(os.File) que representa la salida estandar del
   proceso (Figura 7.2).

   ..figure > Figura 7.2. Un valor de interfaz contiene un puntero @c(*os.File).

     ..img  > img/Figure-7.2.jpg


   Llamar al metodo @c(Write) en un valor de interfaz que contiene un puntero
   @c(*os.File) hace que se llame al metodo @c[(*os.File).Write]. La llamada
   imprime @c("hello").

   ..src > go
     w.Write([]byte("hello")) // "hello"
   < src..

   En general, no podemos saber en tiempo de compilacion cual sera el tipo
   dinamico de un valor interfaz, por lo que una llamada a traves de una
   interfaz debe utilizar el @e(envio dinamico). En lugar de una llamada
   directa, el compilador debe generar codigo para obtener la direccion del
   metodo con nombre @c(Write) desde el descriptor de tipos, y luego, realizar
   una llamada indirecta a esa direccion. El argumento del receptor de la
   llamada es una copia del valor dinamico de la interfaz, @c(os.Stdout). El
   efecto es como si hubieramos hecho esta llamada directamente:

   ..src > go
     os.Stdout.Write([]byte("hello")) // "hello"
   < src..

   La tercera instruccion asigna un valor de tipo @c(*bytes.Buffer) al valor de
   la interfaz:

   ..src > go
     w = new(bytes.Buffer)
   < src..

   El tipo dinamico es ahora @c(*bytes.Buffer) y el valor dinamico es un puntero
   al buffer recien asignado (Figura 7.3).

   ..figure > Figura 7.3. Un valor de interfaz que contiene un puntero @c(*bytes.Buffer)..

     ..img  > img/Figure-7.3.jpg


   Una llamada al metodo @c(Write) utiliza el mismo mecanismo que antes:

   ..src > go
     w.Write([]byte("hello")) // escribe "hello" en bytes.Buffer
   < src..

   Esta vez, el tipo de descriptor es @c(*bytes.Buffer), por lo que se llama al
   metodo @c[(*bytes.Buffer).Write] con la direccion del buffer como el valor
   del parametro de receptor. La llamada agrega @c("hello") al buffer.

   Por ultimo, la cuarta instruccion asigna @c(nil) al valor de la interfaz:

   ..src > go
     w = nil
   < src..

   Esto restablece sus dos componentes a @c(nil), restaurando @c(w) al mismo
   estado que cuando fue declarado, que se muestra en la Figura 7.1.

   Un valor de interfaz puede contener valores dinamicos arbitrariamente
   grandes. Por ejemplo, el tipo @c(time.Time), que representa un instante en el
   tiempo, es un tipo struct con varios campos no exportadas. Si creamos un
   valor de interfaz de el,

   ..src > go
     var x interface{} = time.Now()
   < src..

   El resultado podria ser similar al de la Figura 7.4. Conceptualmente, el
   valor dinamico siempre se ajusta dentro del valor de la interfaz, no importa
   cuan grande sea su tipo. (Esto es solo un modelo conceptual, una
   implementacion realista es muy diferente.)

   ..figure > Figura 7.4. Un valor de interfaz que contiene una estructura @c(time.Time).

     ..img  > img/Figure-7.4.jpg


   Los valores de interfaz se pueden comparar usando @c(==) y @c(!=). Dos
   valores de la interfaz son iguales si ambos son nil, o si sus tipos dinamicos
   son identicos y sus valores dinamicos son iguales de acuerdo con el
   comportamiento usual de @c(==) para ese tipo. Dado que los valores de
   interfaz son comparables, pueden utilizarse como las claves de un mapa o como
   el operando de una instruccion @c(switch).

   Sin embargo, si se comparan dos valores de interfaz y tienen el mismo tipo
   dinamico, pero ese tipo no es comparable (por ejemplo, un slice), entonces la
   comparacion falla con un panico:

   ..src > go
     var x interface{} = []int{1, 2, 3}
     fmt.Println(x == x) // panico: comparacion de tipo incompatible []int
   < src..

   En este sentido, los tipos de interfaz son inusuales. Otros tipos son
   comparables de forma segura (como tipos basicos y punteros) o no son
   comparables en absoluto (como slices, mapas y funciones), pero cuando se
   comparan valores de interfaz o tipos agregados que contienen valores de
   interfaz, debemos estar conscientes del potencial de una panico. Un riesgo
   similar existe cuando se utilizan interfaces como claves de mapa u operandos
   de switch. Solo compare valores de interfaz si esta seguro que contienen
   valores dinamicos de tipos comparables.

   Cuando se manejan errores o durante la depuracion, a menudo es util informar
   el tipo dinamico de un valor de interfaz. Para ello, utilizamos el verbo
   @c(%T) del paquete @c(fmt):

   ..src > go
     var w io.Writer
     fmt.Printf("%T\n", w) // "<nil>"

     w = os.Stdout
     fmt.Printf("%T\n", w) // "*os.File"

     w = new(bytes.Buffer)
     fmt.Printf("%T\n", w) // "*bytes.Buffer"
   < src..

   Internamente, @c(fmt) utiliza la reflexion para obtener el nombre del tipo
   dinamico de la interfaz. Veremos la reflexion en el @l(#Capitulo 12).

*** Seccion 7.5.1 <> Advertencia: Una interfaz que Contiene un Puntero Nil es No-Nil

    Un valor de interfaz nil, que no contiene ningun valor, no es el mismo que
    un valor de interfaz que contiene un puntero que pasa a ser nil. Esta sutil
    distincion crea una trampa en la que cada programador de Go se ha tropezado.

    Considere el programa a continuacion. Con @c(debug) establecido en @c(true), la
    funcion @c(main) recoge la salida de la funcion @c(f) en un @c(bytes.Buffer).

    ..src > go
      const debug = true

      func main() {
        var buf *bytes.Buffer
        if debug {
          buf = new(bytes.Buffer) // Habilitar la recopilacion de la salida
        }
        f(buf)                    // NOTA: sutilmente incorrecto!
        if debug {
          // ...use buf...
        }
      }

      // Si out no es nil, la salida se escribe en este.
      func f(out io.Writer) {
        // ...hacer algo...
        if out != nil {
          out.Write([]byte("done!\n"))
        }
      }
    < src..

    Podriamos esperar que el cambio de @c(debug) a @c(false) podria desactivar
    la recoleccion de la salida, pero en realidad hace que el programa entre en
    panico durante la llamada @c(out.Write):

    ..src > go
      if out != nil {
        out.Write([]byte("done!\n")) // panico: desreferencia de puntero nil
      }
    < src..

    Cuando @c(main) llamada a @c(f), asigna un puntero nil del tipo
    @c(*bytes.Buffer) al parametro @c(out), por lo que el valor dinamico de
    @c(out) es @c(nil). Sin embargo, su tipo dinamico es @c(*bytes.Buffer), lo
    que significa que @c(out) es una interfaz no-nil que contiene un valor de
    puntero nulo (Figura 7.5), por lo que la comprobacion defensiva @c(out !=
    nil) sigue siendo verdadero.

    ..figure > Figura 7.5. Una interfaz no-nil que contiene un puntero nil.

      ..art >
              w
              ┏━━━━━━━━━━━━━━━━━┓
         type ┃  *bytes.Buffer  ┃
              ┣━━━━━━━━━━━━━━━━━┫
        value ┃       nil       ┃
              ┗━━━━━━━━━━━━━━━━━┛
      < art..


    Como antes, el mecanismo de envio dinamico determina que
    @c[(*bytes.Buffer).Write] debe ser llamado pero esta vez con un valor
    receptor que es nil. Para algunos tipos, como @c(*os.File), nil es un
    receptor valido @%l(#Seccion 6.2.1<>§6.2.1), pero @c(*bytes.Buffer) no esta
    entre ellos. El metodo se llama, pero entra en panico al intentar acceder al
    bufer.

    El problema es que aunque un puntero @c(*bytes.Buffer) nulo tiene los
    metodos necesarios para satisfacer la interfaz, no satisface los requisitos
    de comportamiento de la interfaz. En particular, la llamada viola la
    condicion implicita de @c[(*bytes.Buffer).Write] de que receptor no sea nil,
    por lo que la asignacion de puntero nulo a la interfaz fue un error. La
    solucion es cambiar el tipo de @c(buf) en @c(main) a @c(io.Writer),
    evitando de ese modo la asignacion del valor disfuncional a la interfaz en
    el primer lugar:

    ..src > go
      var buf io.Writer
      if debug {
        buf = new(bytes.Buffer) // Habilitar la recopilacion de la salida
      }
      f(buf) // OK
    < src..

    Ahora que hemos cubierto la mecanica de los valores de interfaz, echemos un
    vistazo a algunas de las interfaces mas importantes de la libreria estandar.
    En las tres siguientes secciones, veremos como se utilizan las interfaces
    para ordenacion, para servir en la web y gestionar errores.

** Seccion 7.6 <> Ordenacion con @c(sort.Interface)

   Al igual que el formateo de cadenas, la ordenacion es una operacion
   frecuentemente utilizada en muchos programas. Aunque un Quicksort minimo se
   puede escribir en unas 15 lineas, una implementacion robusta es mucho mas
   larga, y no es el tipo de codigo que deberiamos escribir de nuevo o copiar
   cada vez que lo necesitamos.

   Afortunadamente, el paquete @c(sort) provee in situ la ordenacion de
   cualquier sequencia de acuerdo con cualquier funcion de ordenacion. Su diseño
   es bastante inusual. En muchos lenguajes, el algoritmo de ordenacion esta
   asociado con el tipo de datos de la secuencia, mientras que la funcion de
   ordenacion esta asociada con el tipo de los elementos. Por el contrario, la
   funcion @c(sort.Sort) de Go, no asume nada sobre de la representacion de la
   secuencia o de sus elementos. En su lugar, utiliza una interfaz,
   @c(sort.Interface), para especificar el contrato entre el algoritmo de
   ordenacion generica y cada tipo de secuencia que puede ser ordenada. Una
   implementacion de esta interfaz determina tanto la representacion concreta de
   la secuencia, que es a menudo un slice, y el orden deseado de sus elementos.

   Un algoritmo de ordenacion in situ necesita tres cosas–la longitud de la
   secuencia, una forma de comparar dos elementos, y una manera de intercambiar
   dos elementos–por lo que son los tres metodos de @c(sort.Interface):

   ..src > go
     package sort

     type Interface interface {
       Len() int
       Less(i, j int) bool // i, j son indices de la sequencia de elementos
       Swap(i, j int)
     }
   < src..

   Para ordenar cualquier secuencia, es necesario definir un tipo que implemente
   estos tres metodos, luego, aplicar @c(sort.Sort) a una instancia de ese
   tipo. Como quizas el ejemplo mas simple, considere clasificar un slice de
   strings. El nuevo tipo @c(StringSlice) y sus metodos @c(Len), @c(Less), y
   @c(Swap) se muestran a continuacion.

   ..src > go
     type StringSlice []string

     func (p StringSlice) Len() int           { return len(p) }
     func (p StringSlice) Less(i, j int) bool { return p[i] < p[j] }
     func (p StringSlice) Swap(i, j int)      { p[i], p[j] = p[j], p[i] }
   < src..

   Ahora podemos ordenar un slice de strings, @c(names), convirtiendo el slice
   a un @c(StringSlice) como aqui:

   ..src > go
     sort.Sort(StringSlice(names))
   < src..

   La conversion produce un valor de slice con la misma longitud, capacidad, y
   arreglo subyacente como @c(names), pero con un tipo que tiene los tres
   metodos necesarios para la clasificacion.

   Ordenar un slice de strings es tan comun que el paquete sort proporciona el
   tipo @c(StringSlice), asi como una funcion llamada @c(Strings) por lo que la
   llamada anterior se puede simplificar a @c[sort.Strings(names)].

   La tecnica aqui se adapta facilmente a otros ordenes de clasificacion, por
   ejemplo, para ignorar mayusculas o caracteres especiales. (El programa Go que
   ordena los terminos del indice y el numero de paginas de este libro hace
   esto, con una logica adicional para los numeros romanos.) Para una ordenacion
   mas complicada, usamos la misma idea, pero con estructuras de datos mas
   complicadas o implementaciones mas complicadas de los metodos
   @c(sort.Interface).

   Nuestro ejemplo de ejecucion para la clasificacion sera una lista de
   reproduccion de musica, mostrada como una tabla. Cada pista es una sola fila
   y cada columna es un atributo de esa pista, como artista, titulo y tiempo de
   ejecucion. Imagine que una interfaz grafica de usuario presenta la tabla y
   que al hacer clic en la cabecera de una columna, la lista de reproduccion se
   clasifica por ese atributo; haciendo clic en la misma columna, vuelve a
   invertir el orden. Echemos un vistazo a lo que podria suceder en respuesta a
   cada clic.

   La siguiente variable @c(tracks) contiene una lista de reproduccion. (Uno de
   los autores se disculpa por los gustos musicales del otro autor.) Cada
   elemento es indirecto, un puntero a un @c(Track). Aunque el codigo de abajo
   funcionaria si almacenamos los @c(Tracks) directamente, la funcion de
   clasificacion intercambiara muchos pares de elementos, por lo que se
   ejecutara mas rapido si cada elemento es un puntero, que es una sola palabra
   de la maquina, en lugar de un @c(Track) completo, lo que podrian ser ocho o
   mas palabras.

   ..figure > @l(gopl.io/ch7/sorting/main.go<>gopl.io/ch7/sorting)

     ..src > go
       type Track struct {
         Title  string
         Artist string
         Album  string
         Year   int
         Length time.Duration
       }

       var tracks = []*Track{
         {"Go", "Delilah", "From the Roots Up", 2012, length("3m38s")},
         {"Go", "Moby", "Moby", 1992, length("3m37s")},
         {"Go Ahead", "Alicia Keys", "As I Am", 2007, length("4m36s")},
         {"Ready 2 Go", "Martin Solveig", "Smash", 2011, length("4m24s")},
       }

       func length(s string) time.Duration {
         d, err := time.ParseDuration(s)
         if err != nil {
           panic(s)
         }
         return d
       }
     < src..


   La funcion @c(printTracks) imprime la lista de reproduccion como una
   tabla. Una pantalla grafica seria mejor, pero esta pequeña rutina utiliza el
   paquete @c(text/tabwriter) para producir una tabla cuyas columnas estan
   perfectamente alineadas y rellenas, como se muestra a continuacion. Observe
   que @c(*tabwriter.Writer) satisface @c(io.Writer). Recoge cada pieza de datos
   escrita en ella; su metodo @c(Flush) da formato a toda la tabla y lo escribe
   en @c(os.Stdout).

   ..src > go
     func printTracks(tracks []*Track) {
       const format = "%v\t%v\t%v\t%v\t%v\t\n"
       tw := new(tabwriter.Writer).Init(os.Stdout, 0, 8, 2, ' ', 0)
       fmt.Fprintf(tw, format, "Title", "Artist", "Album", "Year", "Length")
       fmt.Fprintf(tw, format, "-----", "------", "-----", "----", "------")
       for _, t := range tracks {
         fmt.Fprintf(tw, format, t.Title, t.Artist, t.Album, t.Year, t.Length)
       }
       tw.Flush() // calcula los anchos de columna e imprime la tabla
     }
   < src..

   Para ordenar la lista de reproduccion por el campo @c(Artist), definimos un
   nuevo tipo de slice con los metodos necesarios @c(Len), @c(Less), y @c(Swap),
   analogos a los que hicimos para @c(StringSlice).

   ..src > go
     type byArtist []*Track
     func (x byArtist) Len() int           { return len(x) }
     func (x byArtist) Less(i, j int) bool { return x[i].Artist < x[j].Artist }
     func (x byArtist) Swap(i, j int)      { x[i], x[j] = x[j], x[i] }
   < src..

   Para llamar a la rutina de ordenacion generica, primero debemos convertir
   @c(tracks) al nuevo tipo, @c(byArtist), que define el orden:

   ..src > go
     sort.Sort(byArtist(tracks))
   < src..

   Despues de ordenar el slice por artista, la salida de @c(printTracks) es

   ..pre >
     Title       Artist          Album              Year  Length
     -----       ------          -----              ----  ------
     Go Ahead    Alicia Keys     As I Am            2007  4m36s
     Go          Delilah         From the Roots Up  2012  3m38s
     Ready 2 Go  Martin Solveig  Smash              2011  4m24s
     Go          Moby            Moby               1992  3m37s
   < pre..


   Si el usuario solicita @"(ordenar por artista) una segunda vez, vamos a
   resolver los tracks en orden inverso. No tenemos que definir un nuevo tipo
   @c(byReverseArtist) con un metodo @c(Less) invertido, ya que el paquete
   @c(sort) proporciona una funcion @c(Reverse) que transforma cualquier orden a
   su inversa.

   ..src > go
     sort.Sort(sort.Reverse(byArtist(tracks)))
   < src..

   Despues de la ordenacin inversa del slice por artista, la salida de
   @c(printTracks) es

   ..pre >
     Title       Artist          Album              Year  Length
     -----       ------          -----              ----  ------
     Go          Moby            Moby               1992  3m37s
     Ready 2 Go  Martin Solveig  Smash              2011  4m24s
     Go          Delilah         From the Roots Up  2012  3m38s
     Go Ahead    Alicia Keys     As I Am            2007  4m36s
   < pre..


   La funcion @c(sort.Reverse) merece un vistazo mas de cerca, ya que utiliza la
   composicion @%l(#Seccion 6.3<>§6.3), que es una idea importante. El paquete
   @c(sort) define un tipo no exportado @c(reverse), que es una estructura que
   enbebe un @c(sort.Interface). El metodo @c(Less) de @c(reverse) llama al
   @c(Less) del valor enbebido @c(sort.Interface), pero con los indices
   invertidos, invirtiendo el orden de los resultados.

   ..src > go
     package sort

     type reverse struct{ Interface } // es decir, sort.Interface

     func (r reverse) Less(i, j int) bool { return r.Interface.Less(j, i) }

     func Reverse(data Interface) Interface { return reverse{data} }
   < src..

   @c(Len) y @c(Swap), los otros dos metodos de @c(reverse), son proporcionados
   implicitamente por el valor original @c(sort.Interface) porque es un campo
   enbebido. La funcion exportada @c(Reverse) devuelve una instancia del tipo
   @c(reverse) que contiene el valor original @c(sort.Interface).

   Para ordenar por una columna diferente, hay que definir un nuevo tipo, como
   @c(byYear):

   ..src > go
     type byYear []*Track

     func (x byYear) Len() int           { return len(x) }
     func (x byYear) Less(i, j int) bool { return x[i].Year < x[j].Year }
     func (x byYear) Swap(i, j int)      { x[i], x[j] = x[j], x[i] }
   < src..

   Despues de ordenamos los @c(tracks) por año usando @c[sort.Sort(byYear(tracks))],
   @c(printTracks) muestra una lista cronologica:

   ..pre >
     Title       Artist          Album              Year  Length
     -----       ------          -----              ----  ------
     Go          Moby            Moby               1992  3m37s
     Go Ahead    Alicia Keys     As I Am            2007  4m36s
     Ready 2 Go  Martin Solveig  Smash              2011  4m24s
     Go          Delilah         From the Roots Up  2012  3m38s
   < pre..

   Para cada tipo de slice y cada funcion de ordenacion necesitamos, declarar
   una nueva implementacion de @c(sort.Interface). Como se puede ver, los
   metodos @c(Len) y @c(Swap) tienen definiciones identicas para todos los tipos
   de slice. En el siguiente ejemplo, el tipo concreto @c(customSort) combina un
   slice con una funcion, permitiendo definir un nuevo orden de clasificacion
   escribiendo unicamente la funcion de comparacion. Por cierto, los tipos
   concretos que implementan @c(sort.Interface) no siempre son slices;
   @c(customSort) es un tipo struct.

   ..src > go
     type customSort struct {
       t    []*Track
       less func(x, y *Track) bool
     }

     func (x customSort) Len() int           { return len(x.t) }
     func (x customSort) Less(i, j int) bool { return x.less(x.t[i], x.t[j]) }
     func (x customSort) Swap(i, j int)      { x.t[i], x.t[j] = x.t[j], x.t[i] }
   < src..

   Vamos a definir una funcion de ordenamiento de multiples niveles cuya clave
   de ordenacion principal es @c(Title), cuya clave secundaria es @c(Year), y
   cuya clave terciaria es el tiempo de ejecucion, @c(Length). Aqui esta la
   llamada a @c(Sort) usando una funcion de ordenacion anonima:

   ..src > go
     sort.Sort(customSort{tracks, func(x, y *Track) bool {
       if x.Title != y.Title {
         return x.Title < y.Title
       }
       if x.Year != y.Year {
         return x.Year < y.Year
       }
       if x.Length != y.Length {
         return x.Length < y.Length
       }
       return false
     }})
   < src..

   Y aqui esta el resultado. Observe que el empate entre las dos pistas
   tituladas @"(Go) se rompe en favor de la mas antigua.

   ..pre >
     Title       Artist          Album              Year  Length
     -----       ------          -----              ----  ------
     Go          Moby            Moby               1992  3m37s
     Go          Delilah         From the Roots Up  2012  3m38s
     Go Ahead    Alicia Keys     As I Am            2007  4m36s
     Ready 2 Go  Martin Solveig  Smash              2011  4m24s
   < pre..

   Aunque la clasificacion de una secuencia de longitud @m(n) requiere @m[O(n
   log n)] operaciones de comparacion, probar si una secuencia ya esta ordenada
   requiere al menos @m(n-1) comparaciones. La funcion @c(IsSorted) del paquete
   @c(sort) comprueba esto por nosotros. Al igual que @c(sort.Sort), abstrae
   tanto la secuencia y su funcion de ordenacion utilizando @c(sort.Interface),
   pero nunca llama al metodo @c(Swap): Este codigo muestra las funciones
   @c(IntsAreSorted) e @c(Ints) y el tipo @c(IntSlice):

   ..src > go
     values := []int{3, 1, 4, 1}
     fmt.Println(sort.IntsAreSorted(values)) // "false"
     sort.Ints(values)
     fmt.Println(values)                     // "[1 1 3 4]"
     fmt.Println(sort.IntsAreSorted(values)) // "true"
     sort.Sort(sort.Reverse(sort.IntSlice(values)))
     fmt.Println(values)                     // "[4 3 1 1]"
     fmt.Println(sort.IntsAreSorted(values)) // "false"
   < src..


   Por conveniencia, el paquete @c(sort) proporciona versiones de sus funciones
   y tipos especializados para c([]int), @c([]string), y @c([]float64) usando
   sus ordenamientos naturales. Para otros tipos, como @c([]int64) o @c([]uint),
   estamos por nuestra cuenta, aunque el camino es corto.

   @b(Ejercicio 7.8): Muchas interfaces graficas de usuario proporcionan un
   widget de tabla con ordenacion de multiple nivel: la clave de ordenacion
   principal es la primer columna, la segunda clase de ordenacion es la segunda
   columna, y asi sucesivamente. Defina una implementacion de @c(sort.Interface)
   para utilizar con dicha tabla. Compare este enfoque con repetidos
   ordenamientos utilizando @c(sort.Stable).

   @b(Ejercicio 7.9): Utilice el paquete @c(html/template) @%l(#Seccion
   4.6<>§4.6) para reemplazar @c(printTracks) con una funcion que muestre los
   tracks como una tabla HTML. Utilice la solucion del ejercicio anterior para
   organizar que cada clic en un encabezado de columna haga una solicitud HTTP
   para ordenar la tabla.

   @b(Ejercicio 7.10): El tipo @c(sort.Interface) se puede adaptar a otros
   usos. Escriba una funcion @c[IsPalindrome(s sort.Interface) bool] que informe
   si la secuencia @c(s) es un palindromo, es decir, la inversion de la
   secuencia no lo cambiaria. Suponga que los elementos en los indices @c(i) y
   @c(j) son iguales si @c[!s.Less(i, j) && !s.Less(j, i)].

** Seccion 7.7 <> La Interfaz @c(http.Handler)

   En el @l(#Capitulo 1), vimos una idea de como utilizar el paquete
   @c(net/http) para implementar clientes web @%l(#Seccion 1.5<>§1.5) y
   servidores @%l(#Seccion 1.7<>§1.7). En esta seccion, vamos a ver mas de
   cerca la API del servidor, cuyo fundamento es la interfaz @c(http.Handler):

   ..figure > @c(net/http)

     ..src > go
       package http

       type Handler interface {
         ServeHTTP(w ResponseWriter, r *Request)
       }

       func ListenAndServe(address string, h Handler) error
     < src..

   La función @c(ListenAndServe) requiere una dirección de servidor, como
   @c("localhost:8000"), y una instancia de la interfaz @c(Handler) a la que
   todas las solicitudes deben enviarse. Se ejecuta para siempre, o hasta que el
   servidor falla (o se inicia) con un error, que siempre devuelve no-nil.

   Imagine un sitio de comercio electronico con una base de datos de los
   articulos a la venta con sus precios en dolares. El siguiente programa
   muestra la implementacion imaginable mas sencilla. Modela el inventario como
   un @c(database) de tipo mapa, a la que ha adjuntado un metodo @c(ServeHTTP)
   para que satisfaga la interfaz @c(http.Handler). El controlador se extiende
   sobre el mapa e imprime los elementos.

   ..figure > @l(gopl.io/ch7/http1/main.go<>gopl.io/ch7/http1)

     ..src > go
       func main() {
         db := database{"shoes": 50, "socks": 5}
         log.Fatal(http.ListenAndServe("localhost:8000", db))
       }

       type dollars float32

       func (d dollars) String() string { return fmt.Sprintf("$%.2f", d) }

       type database map[string]dollars

       func (db database) ServeHTTP(w http.ResponseWriter, req *http.Request) {
         for item, price := range db {
           fmt.Fprintf(w, "%s: %s\n", item, price)
         }
       }
     < src..


   Si iniciamos el servidor,

   ..srci > sh
     > go build gopl.io/ch7/http1
     > ./http1 &
   < srci..

   luego conectamos con el con el programa @$(fetch) de la @l(#Seccion 1.5) (o
   con un navegador web, si lo prefiere), obtenemos el siguiente resultado:

   ..srci > sh
     > go build gopl.io/ch1/fetch
     > ./fetch http://localhost:8000
     shoes: $50.00
     socks: $5.00
   < srci..

   Hasta ahora, el servidor solo puede enumerar su inventario completo y lo hara
   para cada solicitud, independientemente de la URL. Un servidor mas realista
   define varias URL diferentes, cada una desencadenando un comportamiento
   diferente. Vamos a llamar al comportamiento existente @c(/list) y añadamos
   otra que se llame @c(/price) que informa el precio de un solo articulo,
   especificado como un parametro de la peticion, por ejemplo @c(/price?item=socks).

   ..figure > @l(gopl.io/ch7/http2/main.go<>gopl.io/ch7/http2)

     ..src > go
       func (db database) ServeHTTP(w http.ResponseWriter, req *http.Request) {
         switch req.URL.Path {
         case "/list":
           for item, price := range db {
             fmt.Fprintf(w, "%s: %s\n", item, price)
           }
         case "/price":
           item := req.URL.Query().Get("item")
           price, ok := db[item]
           if !ok {
             w.WriteHeader(http.StatusNotFound) // 404
             fmt.Fprintf(w, "no such item: %q\n", item)
             return
           }
           fmt.Fprintf(w, "%s\n", price)
         default:
           w.WriteHeader(http.StatusNotFound)  // 404
           fmt.Fprintf(w, "no such page: %s\n", req.URL)
         }
       }
     < src..


   Ahora el controlador decide que logica hay que usar basado en el componente
   de la ruta de la URL, @c(req.URL.Path). Si el controlador no reconoce la
   ruta, se informa de un error HTTP al cliente llamando a
   @c[w.WriteHeader(http.StatusNotFound)]; esto debe hacerse antes de escribir
   cualquier texto a @c(w). (Por cierto, @c[http.ResponseWriter] es otra
   interfaz. @c[http.ResponseWriter] agrega metodos a @c(io.Writer) para enviar
   cabeceras de respuesta HTTP.) De manera equivalente, podriamos utilizar la
   funcion de utilidad @c(http.Error):

   ..src > go
     msg := fmt.Sprintf("no such page: %s\n", req.URL)
     http.Error(w, msg, http.StatusNotFound) // 404
   < src..

   El argumento @c(/price) llama al metodo @c(Query) de la URL para analizar los
   parametros de la peticion HTTP como un mapa, o mas precisamente, un mapa
   multiple de tipo @c(url.Values) @%l(#Seccion 6.2.1<>§6.2.1) del paquete
   @c(net/url). A continuacion, busca el primer parametro @c(item) y mira su
   precio. Si no se encontro el elemento, informa de un error.

   He aqui una sesion de ejemplo con el nuevo servidor:

   ..srci > sh
     > go build gopl.io/ch7/http2
     > go build gopl.io/ch1/fetch
     > ./http2 &
     > ./fetch http://localhost:8000/list
     shoes: $50.00
     socks: $5.00
     > ./fetch http://localhost:8000/price?item=socks
     $5.00
     > ./fetch http://localhost:8000/price?item=shoes
     $50.00
     > ./fetch http://localhost:8000/price?item=hat
     no such item: "hat"
     > ./fetch http://localhost:8000/help
     no such page: /help
   < srci..

   Obviamente podriamos seguir añadiendo casos a @c(ServeHTTP), pero en una
   aplicacion real, es conveniente definir la logica para cada caso en una
   funcion o un metodo independiente. Ademas, las URL relacionadas pueden
   necesitar una logica similar; varios archivos de imagen pueden tener URLs de
   tipo @c(/images/*.png), por ejemplo. Por estas razones, @c(net/http)
   proporciona @c(ServeMux), una @e(solicitud multiplexor), para simplificar la
   asociacion entre las direcciones URL y controladores. @c(ServeMux) agrega una
   coleccion de @c(http.Handlers) en un solo @c(http.Handler). Una vez mas,
   vemos que los diferentes tipos que satisfacen la misma interfaz son
   @e(sustituibles): el servidor web es capaz de consultar a cualquier
   @c(http.Handler), independientemente de que tipo concreto esta detras de el.

   Para una aplicacion mas compleja, pueden componerse varios @c(ServeMuxes)
   $para manejar requerimientos de secuenciacion mas intrincados. Go no tiene un
   framework web canonico analogo a Rails de Ruby o a Django de Python. Esto no
   quiere decir que tales frameworks no existan, pero los bloques de
   construccion en la libreria estandar de Go son lo suficientemente flexibles
   como para que los frameworks sean a menudo innecesarios. Ademas, aunque los
   frameworks son convenientes en las primeras fases de un proyecto, su
   complejidad adicional puede hacer que el mantenimiento a largo plazo sea mas
   dificil.

   En el siguiente programa, creamos un @c(ServeMux) y lo usamos para asociar
   las direcciones URL con los controladores correspondientes para las
   operaciones @c(/list) y @c(/price,) que se han dividido en metodos
   separados. A continuacion, utilizamos @c(ServeMux) como el controlador
   principal en la llamada a @c(ListenAndServe).

   ..figure > @l(gopl.io/ch7/http3/main.go<>gopl.io/ch7/http3)

     ..src > go
       func main() {
         db := database{"shoes": 50, "socks": 5}
         mux := http.NewServeMux()
         mux.Handle("/list", http.HandlerFunc(db.list))
         mux.Handle("/price", http.HandlerFunc(db.price))
         log.Fatal(http.ListenAndServe("localhost:8000", mux))
       }

       type database map[string]dollars

       func (db database) list(w http.ResponseWriter, req *http.Request) {
         for item, price := range db {
           fmt.Fprintf(w, "%s: %s\n", item, price)
         }
       }

       func (db database) price(w http.ResponseWriter, req *http.Request) {
         item := req.URL.Query().Get("item")
         price, ok := db[item]
         if !ok {
           w.WriteHeader(http.StatusNotFound) // 404
           fmt.Fprintf(w, "no such item: %q\n", item)
           return
         }
         fmt.Fprintf(w, "%s\n", price)
       }
     < src..


   Centremonos en las dos llamadas a @c(mux.Handle) que registran los
   manejadores. En la primera, @c(db.list) es un valor de metodo @%l(#Seccion
   6.4<>§6.4), es decir, un valor de tipo

   ..src > go
     func(w http.ResponseWriter, req *http.Request)
   < src..

   que, cuando se llama, invoca el metodo @c(database.list) con el valor
   receptor @c(db). Asi que @c(db.list) es una funcion que implementa el
   comportamiento como manejador, pero ya que no tiene metodos, no satisface la
   interfaz @c(http.Handler) y no se puede pasar directamente a @c(mux.Handle).

   La expresion @c[http.HandlerFunc(db.list)] es una conversion, no una llamada
   de funcion, ya que @c(http.HandlerFunc) es un tipo. Tiene la siguiente
   definicion:

   ..figure > @c(net/http)

     ..src > go
       package http

       type HandlerFunc func(w ResponseWriter, r *Request)

       func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
         f(w, r)
       }
     < src..


   @c(HandlerFunc) demuestra algunas caracteristicas inusuales del mecanismo de
   interfaz de Go. Es un tipo de funcion que tiene metodos y satisface una
   interfaz, @c(http.Handler). El comportamiento de su metodo @c(ServeHTTP) es
   llamar a la funcion subyacente. @c(HandlerFunc) es, por tanto, un adaptador
   que permite que un valor de funcion satisfaga una interfaz, donde la funcion
   y el unico metodo de la interfaz tienen la misma firma. En efecto, este truco
   permite que un solo tipo, como @c(database) cumpla con la interfaz
   @c(http.Handler) de varias maneras: una vez a traves de su metodo @c(list), y
   una vez mas a traves de su metodo @c(price), y asi sucesivamente.

   Debido a que el registro de un manejador de esta manera es tan comun,
   @c(ServeMux) tiene un metodo de conveniencia llamado @c(HandleFunc) que lo
   hace por nosotros, por lo que podemos simplificar el codigo de registro del
   manejador a esto:

   ..figure > @l(gopl.io/ch7/http3a/main.go<>gopl.io/ch7/http3a)

     ..src > go
       mux.HandleFunc("/list", db.list)
       mux.HandleFunc("/price", db.price)
     < src..


   Es facil ver desde el codigo anterior como uno podria construir un programa
   en el que hay dos servidores web diferentes, escuchando en diferentes
   puertos, definiendo diferentes URL y enviando a diferentes manejadores.
   Simplemente construiriamos otro @c(ServeMux) y hariamos otra llamada a
   @c(ListenAndServe), tal vez al mismo tiempo. Pero en la mayoria de los
   programas, un servidor web es suficiente. Ademas, es tipico definir
   manejadores HTTP a traves de muchos archivos de una aplicacion, y seria una
   molestia si todos tuvieran que ser registrados de manera explicita con la
   instancia de la aplicacion @c(ServeMux).

   Asi que, por conveniencia, @c(net/http) proporciona una instancia global
   @c(ServeMux) llamada @c(DefaultServeMux) y funciones a nivel de paquete
   llamadas @c(http.Handle) y @c(http.HandleFunc). Para utilizar
   @c(DefaultServeMux) como manejador principal del servidor, no es necesario
   pasarlo a @c(ListenAndServe); @c(nil) lo hara.

   La funcion principal del servidor se puede simplificar a

   ..figure > @l(gopl.io/ch7/http4/main.go<>gopl.io/ch7/http4)

     ..src > go
       func main() {
         db := database{"shoes": 50, "socks": 5}
         http.HandleFunc("/list", db.list)
         http.HandleFunc("/price", db.price)
         log.Fatal(http.ListenAndServe("localhost:8000", nil))
       }
     < src..


   Por ultimo, un recordatorio importante: como mencionamos en la @l(#Seccion
   1.7), el servidor web invoca cada manejador en una nueva goroutine, por lo
   que los manipuladores deben tomar precauciones como el @e(bloqueo) al acceder
   a variables de otras gorutinas, incluyendo otras solicitudes al mismo
   manejador. Hablaremos de concurrencia en los dos proximos capitulos.

   @b(Ejercicio 7.11) Agregar manejadores adicionales para que los clientes
   pueden crear, leer, actualizar y eliminar entradas de @c(database). Por
   ejemplo, una solicitud con formato @c(/update?item=socks&price=6) actualizara
   el precio de un articulo en el inventario e informar un error si el elemento
   no existe o si el precio no es valido. (Advertencia: este cambio introduce
   actualizacion de variables concurrentes.)

   @b(Ejercicio 7.12): Cambiar el manejador de @c(/list) para imprimir su salida
   como una tabla HTML, no como texto. Puede que el paquete @c(html/template)
   @%l(#Seccion 4.6<>§4.6) sea util.

** Seccion 7.8 <> La Interfaz @c(error)

   Desde el comienzo de este libro, hemos estado usando y creando valores del
   misterioso tipo predeclarado @c(error) sin explicar lo que realmente es. De
   hecho, es solo un tipo de interfaz con un unico metodo que devuelve un
   mensaje de error:

   ..src > go
     type error interface {
       Error() string
     }
   < src..

   La forma mas sencilla de crear un @c(error) es llamando a @c(errors.New,) que
   devuelve un nuevo @c(error) para un mensaje de error dado. Todo el paquete
   @c(errors) solo son cuatro lineas:

   ..src > go
     package errors

     func New(text string) error { return &errorString{text} }

     type errorString struct { text string }

     func (e *errorString) Error() string { return e.text }
   < src..

   El tipo subyacente de @c(errorString) es una estructura, no una cadena, para
   proteger su representacion de cambios involuntarios (o premeditados). Y la
   razon de que el tipo de puntero sea @c(*errorString), no es solo
   @c(errorString), para satisfacer la interfaz @c(error) es para que cada
   llamada a @c(New) asigne una instancia de error distinta que no es igual a
   ninguna otra. No queremos que un error distinguido como @c(io.EOF) sea igual
   a o uno que simplemente contien el mismo mensaje.

   ..src > go
     fmt.Println(errors.New("EOF") == errors.New("EOF")) // "false"
   < src..

   Las llamadas a @c(errors.New) son relativamente poco frecuentes porque hay
   una funcion de envoltura conveniente, @c(fmt.Errorf), que tambien hace
   formateo de cadenas. Lo usamos varias veces en el @l(#Capitulo 5).

   ..src > go
     package fmt

     import "errors"

     func Errorf(format string, args ...interface{}) error {
       return errors.New(Sprintf(format, args...))
     }
   < src..

   Aunque @c(*errorString) puede ser el tipo mas sencillo de @c(error), esta
   lejos de ser el unico. Por ejemplo, el paquete @c(syscall) proporciona la API
   de llamadas a bajo nivel de Go. En muchas plataformas, define un tipo
   numerico @c(Errno) que satisface @c(error), y en plataformas Unix, el metodo
   @c(Errno) de @c(Error) realiza una busqueda en una tabla de cadenas, como se
   muestra a continuacion:

   ..src > go
     package syscall

     type Errno uintptr // codigos de error del sistema operativo

     var errors = [...]string{
       1: "operation not permitted",   // EPERM
       2: "no such file or directory", // ENOENT
       3: "no such process",           // ESRCH
       // ...
     }

     func (e Errno) Error() string {
       if 0 <= int(e) && int(e) < len(errors) {
         return errors[e]
       }
       return fmt.Sprintf("errno %d", e)
     }
   < src..

   La siguiente sentencia crea un valor de interfaz que contiene el valor
   @c(Errno) 2, que significa la condicion POSIX @c(ENOENT):

   ..src > go
     var err error = syscall.Errno(2)
     fmt.Println(err.Error()) // "el fichero o directorio no existe"
     fmt.Println(err)         // "el fichero o directorio no existe"
   < src..

   El valor de @c(err) se muestra graficamente en la Figura 7.6.

   ..figure > Figura 7.6. Un valor de interfaz que contiene un entero @c(syscall.Errno).

     ..art >
             err
             ┏━━━━━━━━━━━━━━━━━┓
        tipo ┃  syscall.Errno  ┃
             ┣━━━━━━━━━━━━━━━━━┫
       valor ┃        2        ┃
             ┗━━━━━━━━━━━━━━━━━┛
     < art..


   @c(Errno) es una representacion eficiente de los errores de llamada del
   sistema extraidos de un conjunto finito, y satisface la interfaz estandar
   @c(error). Veremos otros tipos que satisfacen esta interfaz en la @l(#Seccion
   7.11).

** Seccion 7.9 <> Ejemplo: Evaluador de Expresiones

   En esta seccion, crearemos un evaluador para expresiones aritmeticas simples.
   Vamos a utilizar una interfaz, @c(Expr), para representar cualquier expresion
   en este lenguaje. Por ahora, esta interfaz no necesita metodos, pero
   agregaremos algunos mas tarde.

   ..src > go
     // Un Expr es una expresion aritmetica.
     type Expr interface{}
   < src..

   Nuestro lenguaje de expresiones consiste en literales de punto flotante; los
   operadores binarios @c(+), @c(-), @c(*) y @c(/); los operadores unarios
   @c(-x) y @c(+x); llamadas de funcion @c[pow(x,y)], @c[sin(x)], y @c[sqrt(x)];
   variables como @c(x) y @c(pi); y por supuesto los parentesis y la precedencia
   estandar de operadores. Todos los valores son del tipo @c(float64). Aqui hay
   algunas expresiones de ejemplo:

   ..src > go
     sqrt(A / pi)
     pow(x, 3) + pow(y, 3)
     (F - 32) * 5 / 9
   < src..

   Los cinco tipos concretos de abajo representan tipos particulares de
   expresiones. un @c(Var) representa una referencia a una variable. (Pronto
   veremos por que se exporta.) Un @c(literal) representa una constante de coma
   flotante. Los tipos @c(unary) y @c(binary) representan expresiones de
   operador con uno o dos operandos, que pueden ser cualquier tipo de @c(Expr).
   Un @c(call) es una llamada de funcion; restringiremos este campo @c(fn) a
   @c(pow), @c(sin), o @c(sqrt).

   ..figure > @l(gopl.io/ch7/eval/ast.go<>gopl.io/ch7/eval)

     ..src > go
       // Un Var identifica una variable, por ejemplo, x.
       type Var string

       // Un literal es un numero constante, por ejemplo, 3.141.
       type literal float64

       // Un unary representa una expresion de operador unario, por ejemplo, -x.
       type unary struct {
         op rune // one of '+', '-'
         x  Expr
       }

       // Un binary representa una expresion de operador binario, por ejemplo, x+y.
       type binary struct {
         op   rune // one of '+', '-', '*', '/'
         x, y Expr
       }

       // Un call representa una expresion de llamada a funcion, por ejemplo, sin(x).
       type call struct {
         fn   string // uno de "pow", "sin", "sqrt"
         args []Expr
       }
     < src..


   Para evaluar una expresion que contiene variables, necesitaremos un entorno
   que asigne nombres de variables a valores:

   ..src > go
     type Env map[Var]float64
   < src..

   Tambien necesitaremos cada tipo de expresion para definir un metodo @c(Eval)
   que devuelva el valor de la expresion en un entorno determinado. Puesto que
   cada expresion debe proporcionar este metodo, lo añadimos a la interfaz
   @c(Expr). El paquete exporta unicamente los tipos @c(Expr), @c(Env), y
   @c(Var); los clientes pueden utilizar el evaluador sin acceso a los otros
   tipos de expresion.

   ..src > go
     type Expr interface {
       // Eval devuelve el valor de este Expr en el entorno env.
       Eval(env Env) float64
     }
   < src..

   Los metodos concretos de @c(Eval) se muestran a continuacion. El metodo de
   @c(Var) realiza una busqueda de entorno, que devuelve cero si la variable no
   esta definida, y el metodo @c(literal) simplemente devuelve el valor literal.

   ..src > go
     func (v Var) Eval(env Env) float64 {
       return env[v]
     }

     func (l literal) Eval(_ Env) float64 {
       return float64(l)
     }
   < src..

   Los metodos @c(Eval) de @c(unary) y @c(binary) evaluan de forma recursiva sus
   operandos, luego aplican la operacion @c(op) a ellos. No consideramos
   divisiones por cero o infinito como errores, ya que producen un resultado, no
   finito. Finalmente, el metodo @c(call) evalua los argumentos de la funcion
   @c(pow), @c(sin), o @c(sqrt), y luego llama a la funcion correspondiente en
   el paquete @c(math).

   ..src > go
     func (u unary) Eval(env Env) float64 {
       switch u.op {
       case '+':
         return +u.x.Eval(env)
       case '-':
         return -u.x.Eval(env)
       }
       panic(fmt.Sprintf("unsupported unary operator: %q", u.op))
     }

     func (b binary) Eval(env Env) float64 {
       switch b.op {
       case '+':
         return b.x.Eval(env) + b.y.Eval(env)
       case '-':
         return b.x.Eval(env) - b.y.Eval(env)
       case '*':
         return b.x.Eval(env) * b.y.Eval(env)
       case '/':
         return b.x.Eval(env) / b.y.Eval(env)
       }
       panic(fmt.Sprintf("unsupported binary operator: %q", b.op))
     }

     func (c call) Eval(env Env) float64 {
       switch c.fn {
       case "pow":
         return math.Pow(c.args[0].Eval(env), c.args[1].Eval(env))
       case "sin":
         return math.Sin(c.args[0].Eval(env))
       case "sqrt":
         return math.Sqrt(c.args[0].Eval(env))
       }
       panic(fmt.Sprintf("unsupported function call: %s", c.fn))
     }
   < src..

   Varios de estos metodos pueden fallar. Por ejemplo, una expresion @c(call)
   podria tener una funcion desconocida o el numero incorrecto de argumentos.
   Tambien es posible construir una expresion @c(unary) o @c(binary) con un
   operador no valido como @c(!) o @c(<) (aunque la funcion @c(Parse) mencionada
   a continuacion nunca hara esto). Estos errores hacen que @c(Eval) entre en
   panico. Otros errores, la evaluacion de un @c(Var) no presente en el entorno,
   simplemente hacen que @c(Eval) devuelva el resultado incorrecto. Todos estos
   errores podrian ser detectados por la inspeccion de @c(Expr) antes de su
   evaluacion. Ese sera el trabajo del metodo @c(Check), que mostraremos pronto,
   pero primero vamos a probar @c(Eval).

   La funcion @c(TestEval) a continuacion, es una prueba del evaluador. Utiliza
   el paquete @c(testing), que explicaremos en el @l(#Capitulo 11), pero por
   ahora es suficiente saber que llamar a @c(t.Errorf) informa de un error. La
   funcion recorre una tabla de entradas que define tres expresiones y entornos
   diferentes para cada una. La primer expresion calcula el radio de un circulo
   dada su area @c(A), la segunda calcula la suma de los cubos de dos variables
   @c(x) e @c(y), y la tercera convierte una temperatura de Fahrenheit @c(F)
   a Celsius.

   ..src > go
     func TestEval(t *testing.T) {
       tests := []struct {
         expr string
         env  Env
         want string
       }{
         {"sqrt(A / pi)", Env{"A": 87616, "pi": math.Pi}, "167"},
         {"pow(x, 3) + pow(y, 3)", Env{"x": 12, "y": 1}, "1729"},
         {"pow(x, 3) + pow(y, 3)", Env{"x": 9, "y": 10}, "1729"},
         {"5 / 9 * (F - 32)", Env{"F": -40}, "-40"},
         {"5 / 9 * (F - 32)", Env{"F": 32}, "0"},
         {"5 / 9 * (F - 32)", Env{"F": 212}, "100"},
       }
       var prevExpr string
       for _, test := range tests {
         // Imprime expr solo cuando hay cambios.
         if test.expr != prevExpr {
           fmt.Printf("\n%s\n", test.expr)
           prevExpr = test.expr
         }
         expr, err := Parse(test.expr)
         if err != nil {
           t.Error(err) // analiza error
           continue
         }
         got := fmt.Sprintf("%.6g", expr.Eval(test.env))
         fmt.Printf("\t%v => %s\n", test.env, got)
         if got != test.want {
           t.Errorf("%s.Eval() in %v = %q, want %q\n",
             test.expr, test.env, got, test.want)
         }
       }
     }
   < src..

   Para cada entrada en la tabla, la prueba analiza la expresion, la evalua en
   el entorno e imprime el resultado. No tenemos espacio para mostrar la funcion
   @c(Parse) aqui, pero lo encontrara si se descarga el paquete usando @$(go
   get).

   El comando @$(go test) @%l(#Seccion 11.1<>§11.1) ejecuta las pruebas de un
   paquete:

   ..srci > sh
     > go test -v gopl.io/ch7/eval
   < srci..

   La bandera @c(-v) nos permite ver la salida impresa de la prueba, que
   normalmente se suprime para una prueba exitosa como esta. Aqui esta la salida
   de la prueba de las sentencias @c(fmt.Printf):

   ..srci > sh
     sqrt(A / pi)
         map[A:87616 pi:3.141592653589793] => 167

     pow(x, 3) + pow(y, 3)
         map[x:12 y:1] => 1729
         map[x:9 y:10] => 1729

     5 / 9 * (F - 32)
         map[F:-40] => -40
         map[F:32] => 0
         map[F:212] => 100
   < srci..

   Afortunadamente hasta ahora los datos de entrada han sido bien formados, pero
   es poco probable que dure nuestra suerte. Incluso en los lenguajes
   interpretados, es comun comprobar la sintaxis de errores @e(estaticos), es
   decir, errores que pueden ser detectados sin ejecutar el programa. Al separar
   los controles estaticos de los dinamicos, podemos detectar errores antes y
   realizar muchas verificaciones de una sola vez en lugar de cada vez que se
   evalua una expresion.

   Vamos a añadir otro metodo a la interfaz @c(Expr). El metodo @c(Check)
   comprueba si hay errores estaticos en un arbol de sintaxis de
   expresiones. Vamos a explicar su parametro @c(vars) en un momento.

   ..src > go
     type Expr interface {
       Eval(env Env) float64
       // Check informa errores en este Expr y agrega sus Vars al conjunto.
       Check(vars map[Var]bool) error
     }
   < src..

   El metodo concreto @c(Check) se muestran a continuacion. La evaluacion de
   @c(literal) y @c(Var) no puede fallar, por lo que los metodos @c(Check) para
   estos tipos devuelven @c(nil). Los metodos para @c(unary) y @c(binary)
   primero verifican que el operador es valido, luego comprueban recursivamente
   los operandos. Del mismo modo, el metodo de @c(call) primero comprueba que la
   funcion se conoce y tiene el numero correcto de argumentos, entonces, de
   forma recursiva comprueba cada argumento.

   ..src > go
     func (v Var) Check(vars map[Var]bool) error {
       vars[v] = true
       return nil
     }

     func (literal) Check(vars map[Var]bool) error {
       return nil
     }

     func (u unary) Check(vars map[Var]bool) error {
       if !strings.ContainsRune("+-", u.op) {
         return fmt.Errorf("unexpected unary op %q", u.op)
       }
       return u.x.Check(vars)
     }

     func (b binary) Check(vars map[Var]bool) error {
       if !strings.ContainsRune("+-*/", b.op) {
         return fmt.Errorf("unexpected binary op %q", b.op)
       }
       if err := b.x.Check(vars); err != nil {
         return err
       }
       return b.y.Check(vars)
     }

     func (c call) Check(vars map[Var]bool) error {
       arity, ok := numParams[c.fn]
       if !ok {
         return fmt.Errorf("unknown function %q", c.fn)
       }
       if len(c.args) != arity {
         return fmt.Errorf("call to %s has %d args, want %d",
           c.fn, len(c.args), arity)
       }
       for _, arg := range c.args {
         if err := arg.Check(vars); err != nil {
           return err
         }
       }
       return nil
     }

     var numParams = map[string]int{"pow": 2, "sin": 1, "sqrt": 1}
   < src..

   Hemos listado una seleccion de entradas defectuosas y los errores que
   provocan, en dos grupos. La funcion @c(Parse) (no se muestra) informa de
   errores de sintaxis y la funcion @c(Check) de informes de errores semanticos.

   ..pre >
     x % 2             unexpected '%'
     math.Pi           unexpected '.'
     !true             unexpected '!'
     "hello"           unexpected '"'

     log(10)           unknown function "log"
     sqrt(1, 2)        call to sqrt has 2 args, want 1
   < pre..

   El argumento de @c(Check), un conjunto de @c(Vars), acumula el conjunto de
   nombres de variables que se encuentran dentro de la expresion. Cada una de
   estas variables debe estar presente en el entorno para que la evaluacion
   tenga exito. Este conjunto es, logicamente, el @e(resultado) de la llamar a
   @c(Check), pero debido a que el metodo es recursivo, es mas conveniente para
   @c(Check) llenar el conjunto pasandolo como parametro. El cliente debe
   proporcionar un conjunto vacio en la llamada inicial.

   En la @l(#Seccion 3.2), se represento una funcion @c[f(x,y)] que se establece
   en tiempo de compilacion. Ahora que podemos analizar, comprobar y evaluar
   expresiones en cadenas, podemos construir una aplicacion web que recibe una
   expresion en tiempo de ejecucion del cliente y traza la superficie de esa
   funcion. Podemos utilizar los @c(vars) establecidos para comprobar que la
   expresion es una funcion de dos variables, @c(x) e @c(y)–tres, en realidad,
   ya que proporcionamos @c(r), el radio, como una conveniencia. Y usaremos el
   metodo @c(Check) para rechazar expresiones mal formadas antes de que comience
   la evaluacion, de modo que no repitamos esas verificaciones durante las
   40.000 evaluaciones (100×100 celulas, cada una con cuatro esquinas) de la
   funcion siguiente.

   La funcion @c(parseAndCheck) combina estos pasos de analisis y comprobacion:

   ..figure > @l(gopl.io/ch7/surface/surface.go<>gopl.io/ch7/surface)

     ..src > go
       import "gopl.io/ch7/eval"

       func parseAndCheck(s string) (eval.Expr, error) {
         if s == "" {
           return nil, fmt.Errorf("empty expression")
         }
         expr, err := eval.Parse(s)
         if err != nil {
           return nil, err
         }
         vars := make(map[eval.Var]bool)
         if err := expr.Check(vars); err != nil {
           return nil, err
         }
         for v := range vars {
           if v != "x" && v != "y" && v != "r" {
             return nil, fmt.Errorf("undefined variable: %s", v)
           }
         }
         return expr, nil
       }
     < src..


   Para hacer de esto una aplicacion web, todo lo que necesitamos es la siguiente
   funcion @c(plot), que tiene la firma familiar de un @c(http.HandlerFunc):

   ..src > go
     func plot(w http.ResponseWriter, r *http.Request) {
       r.ParseForm()
       expr, err := parseAndCheck(r.Form.Get("expr"))
       if err != nil {
         http.Error(w, "bad expr: "+err.Error(), http.StatusBadRequest)
         return
       }
       w.Header().Set("Content-Type", "image/svg+xml")
       surface(w, func(x, y float64) float64 {
         r := math.Hypot(x, y) // distance from (0,0)
         return expr.Eval(eval.Env{"x": x, "y": y, "r": r})
       })
     }
   < src..

   La funcion @c(plot) analiza y comprueba la expresion especificada en la
   peticion HTTP y la utiliza para crear una funcion anonima de dos
   variables. La funcion anonima tiene la misma firma que la funcion fija @c(f)
   del programa de trazado de la superficie original, pero evalua la expresion
   proporcionada por el usuario. El entorno define @c(x), @c(y), y el radio
   @c(r). Finalmente, @c(plot) llama a @c(surface), que es solo la funcion
   @c(main) de @c(gopl.io/ch3/surface), modificado para tomar la funcion de
   trazar y la salida de @c(io.Writer) como parametros, en lugar de utilizar la
   funcion fija @c(f) y @c(os.Stdout). La Figura 7.7 muestra tres superficies
   producidas por el programa.

   ..figure > Figura 7.7. Las superficies de tres funciones: (a)
     @c[sin(-x)*pow(1.5,-r)]; (b) @c[pow(2,sin(y))*pow(2,sin(x))/12]; (c)
     @c[sin(x*y/10)/10].

     ..img  > img/Figure-7.7.a.jpg

     ..img  > img/Figure-7.7.b.jpg

     ..img  > img/Figure-7.7.c.jpg


   @b(Ejercicio 7.13): Agregue una metodo @c(String) a @c(Expr) para imprimir el
   arbol de sintaxis. Compruebe que los resultados, cuando se analiza de nuevo,
   producen un arbol equivalente.

   @b(Ejercicio 7.14): Definir un nuevo tipo concreto que satisfaga la interfaz
   @c(Expr) y ofrece una nueva operacion como calcular el valor minimo de sus
   operandos. Ya que la funcion @c(Parse) no crea instancias de este nuevo tipo,
   para usarlo necesitara construir un arbol de sintaxis directamente (o
   extender el analizador).

   @b(Ejercicio 7.15): Escriba un programa que lee una sola expresion de la
   entrada estandar, solicita al usuario que proporcione valores para las
   variables, y luego  evalue la expresion en el medio ambiente
   resultante. Maneje todos los errores con gracia.

   @b(Ejercicio 7.16): Escribia un programa de calculadora basado en la web.

** Seccion 7.10 <> Aserciones de Tipo

   Una @e(asercion de tipo) es una operacion aplicada a un valor de interfaz.
   Sintacticamente, se ve como @c[x.(T)], donde @c(x) es una expresion de un
   tipo de interfaz y @c[T] es un tipo, denominado el tipo @"(afirmado). Una
   asercion de tipo comprueba que el tipo dinamico de su operando coincide con
   el tipo declarado.

   Hay dos posibilidades. En primer lugar, si el tipo afirmado @c(T) es un tipo
   concreto, entonces la asercion de tipo comprueba si el tipo dinamico @c(x) es
   @e(identico a) @c(T). Si esta comprobacion tiene exito, el resultado de la
   asercion de tipo es el valor dinamico @c(x), cuyo tipo es, por supuesto,
   @c(T). En otras palabras, una asercion de tipo a un tipo concreto extrae el
   valor concreto de su operando. Si la comprobacion falla, entonces la
   operacion entra en panico. Por ejemplo:

   ..src > go
     var w io.Writer
     w = os.Stdout
     f := w.(*os.File)      // exito: f == os.Stdout
     c := w.(*bytes.Buffer) // panico: interfaz contiene *os.File, no *bytes.Buffer
   < src..

   En segundo lugar, si en lugar del tipo afirmado @c(T) es un tipo de interfaz,
   entonces, la asercion de tipo comprueba si el tipo dinamico @c(x)
   @e(satisface) a @c(T). Si esta comprobacion tiene exito, el valor dinamico no
   se extrae; el resultado sigue siendo una interfaz con el mismo tipo y valor
   de componentes, pero el resultado tiene el tipo de interfaz @c(T). En otras
   palabras, una asercion de tipo a un tipo de interfaz cambia el tipo de la
   expresion, haciendo accesible un conjunto de metodos diferente (y
   generalmente mas grande), pero conserva los componentes dinamicos de tipo y
   valor dentro del valor de la interfaz.

   Despues de la asercion del primer tipo a continuacion, tanto @c(w) y @c(rw)
   contienen @c(os.Stdout) por lo que cada uno tiene un tipo dinamico de
   @c(*os.File), pero @c(w), un @c(io.Writer), expone solo el metodo @c(Write)
   del archivo, mientras que @c(rw) expone tambien su metodo @c(Read).

   ..src > go
     var w io.Writer
     w = os.Stdout
     rw := w.(io.ReadWriter) // exito: *os.File tiene tanto Read como Write

     w = new(ByteCounter)
     rw = w.(io.ReadWriter)  // panico: *ByteCounter no tiene metodo Read
   < src..

   No importa el tipo bajo la asercion, si el operando es un valor de interfaz
   nil, la asercion de tipo falla. Rara vez se necesita una asercion de tipo a
   un tipo de interfaz menos restrictivo (uno con menos metodos), ya que se
   comporta como una asignacion, excepto en el caso nulo.

   ..src > go
     w = rw             // io.ReadWriter es asignable a io.Writer
     w = rw.(io.Writer) // falla solo si rw == nil
   < src..

   A menudo no estamos seguros del tipo dinamico de un valor de interfaz, y nos
   gustaria probar si es algun tipo particular. Si la asercion de tipo aparece
   en una asignacion en la que se esperan dos resultados, como las siguientes
   declaraciones, la operacion no entra en panico cuando se produce un error,
   sino que devuelve un segundo resultado adicional, un booleano que indica
   exito:

   ..src > go
     var w io.Writer = os.Stdout
     f, ok := w.(*os.File)      // exito: ok, f == os.Stdout
     b, ok := w.(*bytes.Buffer) // fallo: !ok, b == nil
   < src..

   El segundo resultado es asignado convencionalmente a una variable llamada
   @c(ok). Si la operacion ha fallado, @c(ok) es falso, y el primer resultado es
   igual al valor cero del tipo afirmado, que en este ejemplo es nil
   @c(*bytes.Buffer).

   El resultado @c(ok) a menudo se utiliza de inmediato para decidir que hacer a
   continuacion. La forma extendida de la sentencia @c(if) hace esto muy compacto:

   ..src > go
     if f, ok := w.(*os.File); ok {
       // ...use f...
     }
   < src..

   Cuando el operando de una asercion de tipo es una variable, en lugar de
   inventar otro nombre para la nueva variable local, a veces vera el nombre
   original reutilizado, ocultando el original, asi:

   ..src > go
     if w, ok := w.(*os.File); ok {
       // ...utilizar w...
     }
   < src..

** Seccion 7.11 <> Discriminacion de Errores con Aserciones de Tipo

   Consideremos el conjunto de errores devueltos por las operaciones de archivos
   en el paquete @c(os). La E/S pueden fallar por varias razones, pero tres
   tipos de fallos a menudo deben manejarse de manera diferente: el archivo ya
   existe (para las operaciones de creacion), el archivo no se encuentra (para
   operaciones de lectura) y el permiso esta denegado. El paquete @c(os)
   proporciona estas tres funciones de ayuda para clasificar el fallo indicado
   por un determinado valor de @c(error):

   ..src > go
     package os

     func IsExist(err error) bool
     func IsNotExist(err error) bool
     func IsPermission(err error) bool
   < src..

   Una implementacion naïve de uno de estos predicados podria comprobar que el
   mensaje de error contenga una cierta subcadena,

   ..src > go
     func IsNotExist(err error) bool {
       // NOTA: no es robusto!
       return strings.Contains(err.Error(), "file does not exist")
     }
   < src..

   Pero debido a que la logica para manejar los errores de E/S puede variar de
   una plataforma a otra, este enfoque no es robusto y el mismo fallo puede ser
   reportado con una variedad de diferentes mensajes de error. La comprobacion
   de subcadenas de mensajes de error puede ser util durante la prueba para
   asegurarse de que las funciones fallan de la manera esperada, pero es
   inadecuado para el codigo en produccion.

   Un enfoque mas confiable es representar valores de error estructurados
   utilizando un tipo especifico. El paquete OS define un tipo llamado
   @c(PathError) para describir las fallas que implican una operacion en una
   ruta de archivo, como @c(Open) o @c(Delete), y una variante llamada
   @c(LinkError) para describir los fallos de las operaciones que implican dos
   rutas de archivos, como @c(Symlink) y @c(Rename). Aqui esta @c(os.PathError):

   ..src > go
     package os

     // PathError registra un error y la operacion y ruta de archivo que lo causo.
     type PathError struct {
       Op   string
       Path string
       Err  error
     }

     func (e *PathError) Error() string {
       return e.Op + " " + e.Path + ": " + e.Err.Error()
     }
   < src..

   La mayoria de los clientes no son conscientes de @c(PathError) y el manejo
   con todos los errores de una manera uniforme llamando a sus metodos de
   @c(Error). Aunque el metodo @c(Error) de @c(PathError) forma un mensaje
   simplemente concatenando los campos, la estructura de @c(PathError) conserva
   los componentes subyacentes del error. Los clientes que necesitan distinguir
   un tipo de fallo de otro pueden usar una asercion de tipo para detectar el
   tipo especifico del error; el tipo especifico proporciona mas detalle que una
   simple cadena.

   ..src > go
     _, err := os.Open("/no/such/file")
     fmt.Println(err) // "open /no/such/file: No such file or directory"
     fmt.Printf("%#v\n", err)
     // Salida:
     // &os.PathError{Op:"open", Path:"/no/such/file", Err:0x2}
   < src..

   Asi funcionan las tres funciones auxiliares. Por ejemplo, @c(IsNotExist), que
   se muestra a continuacion, informa si un error es igual a @c(syscall.ENOENT)
   @%l(#Seccion 7.8<>§7.8) o al error distinguido @c(os.ErrNotExist) (vea
   @c(io.EOF) en la @l(#Seccion 5.4.2<>§5.4.2)), o es un @c(*PathError) cuyo
   error subyacente es uno de esos dos.

   ..src > go
     import (
       "errors"
       "syscall"
     )

     var ErrNotExist = errors.New("file does not exist")

     // IsNotExist regresa un booleano que indica si se conoce el error
     // informa que no existe un archivo o directorio. Se satisface por
     // ErrNotExist asi como algunos errores syscall.
     func IsNotExist(err error) bool {
       if pe, ok := err.(*PathError); ok {
         err = pe.Err
       }
       return err == syscall.ENOENT || err == ErrNotExist
     }
   < src..

   Y aqui esta en accion:

   ..src > go
     _, err := os.Open("/no/such/file")
     fmt.Println(os.IsNotExist(err)) // "true"
   < src..

   Por supuesto, la estructura @c(PathError) se pierde si el mensaje de error se
   combina en una cadena mas grande, por ejemplo, mediante una llamada a
   @c(fmt.Errorf). La discriminacion de errores se debe hacer generalmente
   inmediatamente despues de la operacion fallida, antes de que un error se
   propague al llamador.

** Seccion 7.12 <> Consultar Comportamientos con Aserciones de Tipo de Interfaz

   La siguiente logica es similar a la parte del servidor web @c(net/http)
   responsable de escribir campos de cabecera HTTP como @c("Content-type:
   text/html"). El @c(io.Writer) @c(w) representa la respuesta HTTP; los bytes
   escritos en el, se envian en ultima instancia a algun navegador web.

   ..src > go
     func writeHeader(w io.Writer, contentType string) error {
       if _, err := w.Write([]byte("Content-Type: ")); err != nil {
         return err
       }
       if _, err := w.Write([]byte(contentType)); err != nil {
         return err
       }
       // ...
     }
   < src..

   Debido a que el metodo @c(Write) requiere un slice de bytes, y el valor que
   desea escribir es una cadena, se requiere una conversion @c{[]byte(...)}.
   Esta conversion asigna memoria y hace una copia, pero la copia se tira casi
   inmediatamente despues. Vamos a pretender que esta es una parte fundamental
   del servidor web y que nuestro perfil ha revelado que esta asignacion de
   memoria lo esta ralentizando. ¿Podemos evitar asignar memoria aqui?

   La interfaz @c(io.Writer) nos informa solo un hecho sobre el tipo concreto
   que @c(w) almacena: que los bytes se pueden escribir en el. Si miramos detras
   de cortinas del paquete @c(net/http), vemos que el tipo dinamico que @c(w)
   tiene en este programa tambien tiene un metodo @c(WriteString) que permite
   que las cadenas sean escritas eficientemente, evitando la necesidad de
   asignar una copia temporal. (Esto puede parecer un disparo en la oscuridad,
   pero una serie de tipos importantes que satisfacen @c(io.Writer) tambien
   tienen un metodo @c(WriteString), incluyendo @c(*bytes.Buffer), @c(*os.File)
   y @c(*bufio.Writer)).

   No podemos asumir que un @c(w) @c(io.Writer) arbitrario tambien tiene el
   metodo @c(WriteString). Pero podemos definir una nueva interfaz que tiene
   solo este metodo y utilizar una asercion de tipo para probar si el tipo
   dinamico de @c(w) satisface esta nueva interfaz.

   ..src > go
     // writeString escribe s a w.
     // Si w tiene un metodo WriteString, se invoca en lugar de w.Write.
     func writeString(w io.Writer, s string) (n int, err error) {
       type stringWriter interface {
         WriteString(string) (n int, err error)
       }
       if sw, ok := w.(stringWriter); ok {
         return sw.WriteString(s) // evitar copia
       }
       return w.Write([]byte(s)) // almacena una copia temporal
     }

     func writeHeader(w io.Writer, contentType string) error {
       if _, err := writeString(w, "Content-Type: "); err != nil {
         return err
       }
       if _, err := writeString(w, contentType); err != nil {
         return err
       }
       // ...
     }
   < src..

   Para evitar repetirnos a nosotros mismos, hemos movido la comprobacion a la
   funcion de utilidad @c(writeString), pero es tan util que la libreria
   estandar la proporciona como @c(io.WriteString). Es la forma recomendada de
   escribir una cadena a un @c(io.Writer).

   Lo curioso en este ejemplo es que no existe una interfaz estandar que defina
   el metodo @c(WriteString) y especifique su comportamiento requerido. Ademas,
   si un tipo concreto satisface o no la interfaz @c(stringWriter) se determina
   solo por sus metodos, y no por ninguna relacion declarada entre el y el tipo
   de interfaz. Lo que esto significa es que la tecnica anterior se basa en la
   suposicion de que @e(si) un tipo satisface la interfaz de abajo, @e(entonces)
   @c[WriteString(s)] debe tener el mismo efecto que @c{Write([]byte(s))}.

   ..src > go
     interface {
       io.Writer
       WriteString(s string) (n int, err error)
     }
   < src..

   Aunque @c(io.WriteString) documenta su suposicion, pocas funciones que la
   llaman probablemente documenten que estas tambien hacen el mismo
   supuesto. Definir un metodo de un tipo particular se toma como un
   asentimiento implicito para un determinado contrato de comportamiento. Los
   recien llegados a Go, especialmente aquellos con antecedentes en lenguajes
   fuertemente tipados, pueden encontrar esta falta de intencion explicita
   inquietante, pero rara vez es un problema en la practica. Con la excepcion de
   la interfaz vacia @c(interface{}), los tipos de interfaz rara vez son
   satisfechas por coincidencia involuntaria.

   La anterior funcion @c(writeString) utiliza una asercion de tipo para ver
   si un valor de un tipo de interfaz general tambien satisface un tipo de
   interfaz mas especifico, y de ser asi, se utiliza el comportamiento de la
   interfaz especifica. Esta tecnica se puede poner en uso, sea o no la interfaz
   a consultar estandar como @c(io.ReadWriter) o definida por el usuario como
   @c(stringWriter).

   Tambien es como @c(fmt.Fprintf) distingue valores que satisfacen @c(error) o
   @c(fmt.Stringer) de todos los demas valores. Dentro de @c(fmt.Fprintf), hay
   un paso que convierte un unico operando en una cadena, algo asi:

   ..src > go
     package fmt

     func formatOneValue(x interface{}) string {
       if err, ok := x.(error); ok {
         return err.Error()
       }
       if str, ok := x.(Stringer); ok {
         return str.String()
       }
       // ...todos los demas tipos...
     }
   < src..

   Si @c(x) satisface cualquiera de las dos interfaces, eso determina el formato
   del valor. Si no, el caso por defecto maneja todos los demas tipos mas o
   menos uniformemente usando la reflexion; vamos a averiguar como en el
   @l(#Capitulo 12).

   De nuevo, esto hace la suposicion de que cualquier tipo con un metodo
   @c(String) satisface el contrato de comportamiento de @c(fmt.Stringer), que
   es devolver una cadena adecuada para la impresion.

** Seccion 7.13 <> Switches de Tipo

   Las interfaces se utilizan en dos estilos distintos. En el primer estilo,
   ejemplificado por @c(io.Reader), @c(io.Writer), @c(fmt.Stringer),
   @c(sort.Interface), @c(http.Handler) y @c(error), los metodos de una interfaz
   expresan las similitudes de los tipos concretos que satisfacen la interfaz,
   pero ocultan los detalles de representacion y operaciones intrinsecas de esos
   tipos concretos. El enfasis esta en los metodos, no en los tipos concretos.

   El segundo estilo explota la capacidad de un valor interfaz para contener
   valores de una variedad de tipos concretos y considera que la interfaz es la
   @e(union) de esos tipos. Las aserciones de tipo se utilizan para
   discriminar entre estos tipos dinamicamente y tratar cada caso de manera
   diferente. En este estilo, el enfasis esta en los tipos concretos que
   satisfacen la interfaz, no en los metodos de la interfaz (si de hecho tiene
   alguno), y no se oculta la informacion. Vamos a describir interfaces
   utilizadas de esta manera como @e(uniones discriminadas).

   Si esta familiarizado con la programacion orientada a objetos, es posible
   reconocer estos dos estilos como @e(polimorfismo de subtipos) y el
   @e(polimorfismo ad hoc), pero no necesita recordar esos terminos. Para el
   resto de este capitulo, presentaremos ejemplos del segundo estilo.

   La API de Go para consultar una base de datos SQL, como las de otros
   lenguajes, nos permite separar de forma clara la parte fija de una consulta
   de las partes variables. Un ejemplo de cliente podria tener este aspecto:

   ..src > go
     import "database/sql"

     func listTracks(db sql.DB, artist string, minYear, maxYear int) {
       result, err := db.Exec(
         "SELECT * FROM tracks WHERE artist = ? AND ? <= year AND year <= ?",
         artist, minYear, maxYear)
       // ...
     }
   < src..

   El metodo @c(Exec) reemplaza cada @c('?') en la cadena de consulta con un
   literal SQL que denota el valor del argumento correspondiente, que puede ser
   un valor booleano, un numero, una cadena, o @c(nil). La construccion de
   consultas de esta manera ayuda a evitar ataques de inyeccion SQL, en el que
   un adversario toma el control de la consulta mediante la explotacion de una
   cita incorrecta de datos de entrada. Dentro de @c(Exec), podriamos encontrar
   una funcion como la siguiente, que convierte cada valor de argumento para su
   notacion SQL.

   ..src > go
     func sqlQuote(x interface{}) string {
       if x == nil {
         return "NULL"
       } else if _, ok := x.(int); ok {
         return fmt.Sprintf("%d", x)
       } else if _, ok := x.(uint); ok {
         return fmt.Sprintf("%d", x)
       } else if b, ok := x.(bool); ok {
         if b {
           return "TRUE"
         }
         return "FALSE"
       } else if s, ok := x.(string); ok {
         return sqlQuoteString(s) // (no se muestra)
       } else {
         panic(fmt.Sprintf("unexpected type %T: %v", x, x))
       }
     }
   < src..

   Una sentencia @c(switch) simplifica una cadena @c(if)-@c(else) que realiza
   una serie de pruebas de igualdad de valor. De forma analoga una sentencia
   @c(switch de tipos) simplifica una cadena @c(if)-@c(else) de aserciones de
   tipo.

   En su forma mas simple, un switch de tipos se parece a una sentencia switch
   ordinaria en la que el operando es @c[x.(type)]–esto es, literalmente, la
   palabra clave @c(type)–y cada caso tiene uno o mas tipos. Un switch de tipo
   habilita una ramificacion multidireccional basada en el tipo dinamico del
   valor de la interfaz. El caso @c(nil) coincide si @c(x == nil), y el caso
   @c(default) coincide si no lo hace ningun otro caso. Un switch de tipos para
   @c(sqlQuote) tendria estos casos:

   ..src > go
     switch x.(type) {
     case nil:       // ...
     case int, uint: // ...
     case bool:      // ...
     case string:    // ...
     default:        // ...
     }
   < src..

   Al igual que con una sentencia @c(switch) ordinaria @%l(#Seccion 1.8<>§1.8),
   los casos se consideran en orden y, cuando se encuentra una coincidencia, se
   ejecuta el cuerpo del caso. El orden de los casos se vuelve significativo
   cuando uno o mas tipos de casos son interfaces, ya que entonces existe la
   posibilidad de que dos casos coincidan. La posicion del caso @c(default) en
   relacion con los demas es irrelevante. @c(fallthrough) no esta permitido.

   Observe que en la funcion original, la logica de los casos @c(bool) y
   @c(string) necesita acceso al valor extraido por la asercion de tipo. Dado que
   esto es tipico, la instruccion switch de tipo tiene una forma extendida que
   enlaza el valor extraido con una nueva variable dentro de cada caso:

   ..src > go
     switch x := x.(type) { /* ... */ }
   < src..

   Aqui hemos llamado las nuevas variables @c(x) tambien; como con las
   aserciones de tipo, la reutilizacion de nombres de variables es comun. Al
   igual que una instruccion @c(switch), un switch de tipo crea implicitamente
   un bloque lexico, por lo que la declaracion de la nueva variable llamada
   @c(x) no entra en conflicto con una variable @c(x) en un bloque externo. Cada
   @c(case) tambien crea implicitamente un bloque lexico independiente.

   Reescribiendo @c(sqlQuote) para utilizar la forma extendida de un switch de
   tipo lo hace significativamente mas claro:

   ..src > go
     func sqlQuote(x interface{}) string {
       switch x := x.(type) {
       case nil:
         return "NULL"
       case int, uint:
         return fmt.Sprintf("%d", x) // aqui x tiene tipo interface{}.
       case bool:
         if x {
           return "TRUE"
         }
         return "FALSE"
       case string:
         return sqlQuoteString(x) // (no se muestra)
       default:
         panic(fmt.Sprintf("unexpected type %T: %v", x, x))
       }
     }
   < src..

   En esta version, dentro del bloque de cada caso de tipo unico, la variable
   @c(x) tiene el mismo tipo que el caso. Por ejemplo, @c(x) tiene tipo @c(bool)
   dentro del caso @c(bool) y @c(string) dentro del caso @c(string). En todos
   los demas casos, @c(x) tiene el tipo (interfaz) del @c(switch) operante, que
   es @c(interface{}) en este ejemplo. Cuando se requiere la misma accion para
   varios casos, como @c(int) y @c(uint), el switch de tipo hace que sea facil
   combinarlos.

   Aunque @c(sqlQuote) acepta un argumento de cualquier tipo, la funcion solo se
   ejecuta si el tipo del argumento coincide con uno de los casos en el switch
   de tipo; de lo contrario, entra en panico con un mensaje de @"(tipo
   inesperado). Aunque el tipo de @c(x) es @c(interface{}), lo consideramos una
   union discriminada de @c(int), @c(uint), @c(bool), @c(string), y @c(nil).

** Seccion 7.14 <> Ejemplo: Decodificacion XML Basada en Tokens

   La @l(#Seccion 4.5) mostro como decodificar documentos JSON en estructuras de
   datos Go con las funciones @c(Marshal) y @c(Unmarshal) del paquete
   @c(encoding/json). El paquete @c(encoding/xml) proporciona una API similar.
   Este enfoque es conveniente cuando queremos construir una representacion del
   arbol de documentos, pero eso es innecesario para muchos programas. El
   paquete @c(encoding/xml) tambien proporciona una API de bajo nivel @e(basada
   en tokens) para decodificar XML. En el estilo basado en tokens, el analizador
   consume la entrada y produce un flujo de tokens, principalmente de cuatro
   tipos–@c(StartElement), @c(EndElement), @c(CharData), y @c(Comment)–cada uno
   de los cuales es un tipo concreto en el paquete @c(encoding/xml). Cada
   llamada a @c[(*xml.Decoder).Token] devuelve un token.

   Las partes relevantes de la API se muestran aqui:

   ..figure > @c(encoding/xml)

     ..src > go
       package xml

       type Name struct {
         Local string     // por ejemplo, "Title" o "id"
       }

       type Attr struct { // por ejemplo, name="value"
         Name Name
         Value string
       }

       // Un Token incluye StartElement, EndElement, CharData,
       // y Comment, mas algunos tipos esotericos (no mostrados).
       type Token interface{}
       type StartElement struct { // por ejemplo, <name>
         Name Name
         Attr []Attr
       }
       type EndElement struct { Name Name } // por ejemplo, </name>
       type CharData []byte                 // por ejemplo, <p>CharData</p>
       type Comment []byte                  // por ejemplo, <!-- Comment -->

       type Decoder struct{ /* ... */ }

       func NewDecoder(io.Reader) *Decoder
       func (*Decoder) Token() (Token, error) // regresa el sigiente token en la sequencia
     < src..

   La interfaz @c(Token), que no tiene metodos, es tambien un ejemplo de una
   union discriminada. El proposito de una interfaz tradicional como
   @c(io.Reader) es ocultar los detalles de los tipos concretos que lo
   satisfagan para que se puedan crear las nuevas implementaciones; cada tipo
   concreto es tratado uniformemente. Por el contrario, el conjunto de tipos
   concretos que satisfacen una union discriminada es fijada por el diseño y
   expuesto, no ocultado. Los tipos de union discriminados tienen pocos metodos;
   las funciones que actuan sobre ellas se expresan como un conjunto de casos
   utilizando un switch de tipo, con logica diferente en cada caso.

   El programa @$(xmlselect) a continuacion, extrae e imprime el texto encontrado
   bajo ciertos elementos en un arbol de documentos XML. Usando la API
   anterior, puede hacer su trabajo en un solo paso sobre la entrada sin
   materializar el arbol.

   ..figure > @l(gopl.io/ch7/xmlselect/main.go<>gopl.io/ch7/xmlselect)

     ..src > go
       // Xmlselect imprime el texto de los elemenos seleccionados de un documento XML.
       package main

       import (
         "encoding/xml"
         "fmt"
         "io"
         "os"
         "strings"
       )

       func main() {
         dec := xml.NewDecoder(os.Stdin)
         var stack []string // stack de nombres de elementos
         for {
           tok, err := dec.Token()
           if err == io.EOF {
             break
           } else if err != nil {
             fmt.Fprintf(os.Stderr, "xmlselect: %v\n", err)
             os.Exit(1)
           }
           switch tok := tok.(type) {
           case xml.StartElement:
             stack = append(stack, tok.Name.Local) // push
           case xml.EndElement:
             stack = stack[:len(stack)-1]          // pop
           case xml.CharData:
             if containsAll(stack, os.Args[1:]) {
               fmt.Printf("%s: %s\n", strings.Join(stack, " "), tok)
             }
           }
         }
       }

       // containsAll informa si x contiene los elementos de y, en orden.
       func containsAll(x, y []string) bool {
         for len(y) <= len(x) {
           if len(y) == 0 {
             return true
           }
           if x[0] == y[0] {
             y = y[1:]
           }
           x = x[1:]
         }
         return false
       }
     < src..


   Cada vez que el bucle en @c(main) encuentra un @c(StartElement), empuja el
   nombre del elemento en una pila, y para cada @c(EndElement) saca el nombre de
   la pila. La API garantiza que la secuencia de tokens de @c(StartElement) y
   @c(EndElement) se correspondan correctamente, incluso en documentos con
   formato incorrecto. Los @c(Comments) se ignoran. Cuando @c(xmlselect)
   encuentra un @c(CharData), imprime el texto solo si la pila contiene todos
   los elementos nombrados por los argumentos de linea de comandos, en orden.

   El siguiente comando imprime el texto de cualquier elemento @c(h2) que
   aparezca debajo de dos niveles de elementos @c(div). Su entrada es la
   especificacion XML, en un documento XML.

   ..srci > sh
     > go build gopl.io/ch1/fetch
     > ./fetch http://www.w3.org/TR/2006/REC-xml11-20060816 |
     ^ ./xmlselect div div h2
     html body div div h2: 1 Introduction
     html body div div h2: 2 Documents
     html body div div h2: 3 Logical Structures
     html body div div h2: 4 Physical Structures
     html body div div h2: 5 Conformance
     html body div div h2: 6 Notation
     html body div div h2: A References
     html body div div h2: B Definitions for Character Normalization
     ...
   < srci..

   @b(Ejercicio 7.17): Extiende @$(xmlselect) para que los elementos puedan ser
   seleccionados no solo por su nombre, sino tambien por sus atributos, a la
   manera de CSS, de modo que, por ejemplo, un elemento como @c(<div id="page"
   class="wide">) podria ser seleccionado encontrando su @c(id) o @c(class),
   asi como su nombre.

   @b(Ejercicio 7.18): Utilizando el API decodificador basado en tokens, escribir
   un programa que lea un documento XML arbitrario y construya un arbol de nodos
   genericos que lo represente. Los nodos son de dos tipos: los nodos
   @c(CharData) representan cadenas de texto, y los nodos @c(Element)
   representan elementos con nombre y atributos. Cada nodo de elemento tiene un
   slice de nodos secundarios.

   Puede que las siguientes declaraciones sean utiles.

   ..src > go
     import "encoding/xml"

     type Node interface{} // CharData or *Element

     type CharData string

     type Element struct {
       Type     xml.Name
       Attr     []xml.Attr
       Children []Node
     }
   < src..

** Seccion 7.15 <> Algunos Consejos

   Al diseñar un nuevo paquete, los programadores novatos en Go a menudo
   comienzan creando un conjunto de interfaces y solo mas tarde definen los
   tipos concretos que los satisfacen. Este enfoque resulta en muchas
   interfaces, cada una de las cuales tiene una sola implementacion. No lo
   hagas. Tales interfaces son abstracciones innecesarias; tambien tienen un
   costo de tiempo de ejecucion. Puede restringir que metodos de un tipo o
   campos de una estructura son visibles fuera de un paquete utilizando el
   mecanismo de exportacion @%l(#Seccion 6.6<>§6.6). Las interfaces solo son
   necesarias cuando hay dos o mas tipos concretos que deben tratarse de manera
   uniforme.

   Hacemos una excepcion a esta regla cuando una interfaz es satisfecha por un
   solo tipo concreto pero ese tipo no puede vivir en el mismo paquete que la
   interfaz debido a sus dependencias. En ese caso, una interfaz es una buena
   manera de desacoplar dos paquetes.

   Debido a que las interfaces se usan en Go solo cuando estan satisfechas por
   dos o mas tipos, necesariamente se abstraen de los detalles de cualquier
   implementacion en particular. El resultado es interfaces mas pequeñas con
   pocos metodos mas simples, a menudo, solo con uno como @c(io.Writer) o
   @c(fmt.Stringer). Las interfaces pequeñas son mas faciles de satisfacer
   cuando aparecen nuevos tipos. Una buena regla de oro para el diseño de
   interfaces es @e(pedir solo lo que necesitas).

   Esto concluye nuestro recorrido de metodos e interfaces. Go tiene un gran
   soporte para el estilo de programacion orientado a objetos, pero esto no
   significa que necesite usarlo exclusivamente. No todo debe ser un objeto; las
   funciones independientes tienen su lugar, al igual que los tipos de datos no
   encapsulados. Observe que, en conjunto, los ejemplos en los primeros cinco
   capitulos de este libro llaman no mas de dos docenas de metodos, como
   @c(input.Scan), a diferencia de las llamadas de funcion ordinaria como
   @c(fmt.Printf).

* Capitulo 8 <> Gorutinas y Canales

  La programación concurrente, la expresión de un programa como una composición
  de varias actividades autónomas, nunca ha sido tan importante como lo es hoy
  en día. Los servidores Web gestionan solicitudes para miles de clientes a la
  vez. Las aplicaciones de tabletas y teléfonos generan animaciones en la
  interfaz de usuario al tiempo que realizan simultáneamente solicitudes de
  cálculo y de red en segundo plano. Incluso los problemas tradicionales de
  lotes–leer algunos datos, calcular, escribir algo–utilizan concurrencia para
  ocultar la latencia de operaciones E/S y para explotar los procesadores de una
  computadora moderna, que cada año crecen en número pero no en velocidad.

  Go permite dos estilos de programación concurrente. Este capítulo presenta las
  gorutinas y canales que soportan @e(procesos secuenciales comunicantes) o
  @A(CSP), un modelo de concurrencia en el cual los valores se pasan entre
  actividades independientes (goroutines) pero las variables están en su mayor
  parte confinadas a una sola actividad. El @l(#Capítulo 9) cubre algunos
  aspectos del modelo más tradicional de memoria compartida multihilo, que será
  familiar si ha utilizado hilos en otros lenguajes populares. El
  @l(#Capítulo 9) también señala algunos peligros y trampas importantes de la
  programación concurrente que no profundizaremos en este capítulo.

  A pesar de que el soporte de Go para la concurrencia es una de sus grandes
  fortalezas, el razonamiento sobre los programas concurrentes es
  intrínsecamente más difícil que los secuenciales, y las intuiciones adquiridas
  a partir de la programación secuencial a veces pueden desviarnos. Si este es
  tu primer encuentro con la concurrencia, recomendamos dedicar un poco más de
  tiempo para pensar en los ejemplos de estos dos capítulos.

** Seccion 8.1 <> Gorutinas

   En Go, cada actividad que se ejecuta simultáneamente se denomina
   @e(gorutina). Considere un programa que tiene dos funciones, una que hace
   algún cálculo y otra que escribe alguna salida, y asume que ninguna de las
   dos funciones llama a la otra. Un programa secuencial puede llamar a una
   función y luego llamar a la otra, pero en un programa @e(concurrente) con dos
   o más gorutinas, las llamadas a @e(ambas) funciones pueden estar activas al
   mismo tiempo. Veremos un programa asi en un momento.

   Si ha utilizado subprocesos o subprocesos del sistema operativo en otros
   lenguajes, puede suponer que una gorutina es similar a un subproceso y que
   podrá escribir programas correctos. Las diferencias entre hilos y gorutinas
   son esencialmente cuantitativas, no cualitativas, y serán descritas en la
   @l(#Sección 9.8).

   Cuando un programa inicia, su única gorutina es la que llama a la función
   @c(main), así que la llamamos la @e(gorutina principal). Las nuevos gorutinas
   son creadas por la declaración @c(go). Sintácticamente, una sentencia @c(go)
   es una función ordinaria o una llamada a un método prefijado por la palabra
   clave @c(go). Una sentencia @c(go) hace que la función sea llamada en una
   gorutina recién creada. La sentencia @c(go) en si misma se completa
   inmediatamente:

   ..src > go
     f()    // llamar a f(); espera el retorno
     go f() // crea una nueva gorutina que llama a f(); no espera
   < src..

   En el ejemplo a continuación, la gorutina principal calcula el 45 número de
   Fibonacci. Dado que utiliza un algoritmo recursivo terriblemente ineficiente,
   se ejecuta durante un tiempo apreciable, durante el cual nos gustaría
   proporcionar al usuario una indicación visual de que el programa sigue en
   ejecución, mediante la visualización de un texto @"(spinner) animado.

   ..figure > @l(gopl.io/ch8/spinner/main.go<>gopl.io/ch8/spinner)

     ..src > go
       func main() {
         go spinner(100 * time.Millisecond)
         const n = 45
         fibN := fib(n) // lento
         fmt.Printf("\rFibonacci(%d) = %d\n", n, fibN)
       }

       func spinner(delay time.Duration) {
         for {
           for _, r := range `-\|/` {
             fmt.Printf("\r%c", r)
             time.Sleep(delay)
           }
         }
       }

       func fib(x int) int {
         if x < 2 {
           return x
         }
         return fib(x-1) + fib(x-2)
       }
     < src..


   Después de varios segundos de animación, la llamada @c[fib(45)] regresa y la
   función @c(main) imprime su resultado:

   ..pre >
     Fibonacci(45) = 1134903170


   Luego regresa la función @c(main) principal. Cuando esto sucede, todas las
   gorutinas terminan abruptamente y el programa sale. Aparte de regresar de
   @c(main) o salir del programa, no hay ninguna forma programática para que una
   goroutine detenga a otra, pero como veremos más adelante, hay maneras de
   comunicarse con una gorutina para pedirle que se detenga.

   Observe cómo el programa se expresa como la composición de dos actividades
   autónomas, la animacion y el cálculo de Fibonacci. Cada uno se escribe como
   una función separada pero ambos avanzan simultáneamente.

** Seccion 8.2 <> Ejemplo: Servidor de Reloj Concurrente

   El trabajo en red es un dominio natural en el que se utiliza la concurrecia,
   ya que los servidores suelen manejar muchas conexiones de sus clientes a la
   vez, cada cliente es esencialmente independiente de los demás. En esta
   sección, presentaremos el paquete @c(net), que proporciona los componentes
   para construir programas de cliente y servidor en red que se comunican a
   través de TCP, UDP o sockets de dominio Unix. El paquete @c(net/http) que
   hemos estado utilizando desde el @l(#Capitulo 1) se construye en la parte
   superior de las funciones del paquete @c(net).

   Nuestro primer ejemplo es un servidor de reloj secuencial que escribe el
   tiempo actual al cliente una vez por segundo:

   ..figure > @l(gopl.io/ch8/clock1/clock.go<>gopl.io/ch8/clock1)

     ..src > go
       // Clock1 es un servidor TCP que escribe periodicamente la hora.
       package main

       import (
         "io"
         "log"
         "net"
         "time"
       )

       func main() {
         listener, err := net.Listen("tcp", "localhost:8000")
         if err != nil {
           log.Fatal(err)
         }
         for {
           conn, err := listener.Accept()
           if err != nil {
             log.Print(err) // e.g., coneccion abortada
             continue
           }
           handleConn(conn) // maneja una coneccion a la vez
         }
       }

       func handleConn(c net.Conn) {
         defer c.Close()
         for {
           _, err := io.WriteString(c, time.Now().Format("15:04:05\n"))
           if err != nil {
             return // e.g., cliente desconectado
           }
           time.Sleep(1 * time.Second)
         }
       }
     < src..


   La función @c(Listen) crea un @c(net.Listener), un objeto que escucha las
   conexiones entrantes en un puerto de red, en este caso el puerto TCP
   @c(localhost:8000). El método @c(Accept) del oyente se bloquea hasta que se
   realiza una petición de conexión entrante, y luego devuelve un objeto
   @c(net.Conn) que representa la conexión.

   La función @c(handleConn) maneja una conexión completa del cliente. En un
   bucle, escribe el tiempo actual, @c[time.Now()], al cliente. Ya que
   @c(net.Conn) satisface la interfaz @c(io.Writer), podemos escribir en el
   directamente. El bucle termina cuando falla la escritura, lo más probable es
   porque el cliente se haya desconectado, momento en el que @c(handleConn)
   cierra su lado de la conexión usando una llamada diferida a @c(Close) y
   vuelve a esperar otra solicitud de conexión.

   El método @c(time.Time.Format) proporciona una forma de dar formato a la
   información de fecha y hora por ejemplo. Su argumento es una plantilla que
   indica la forma de dar formato a un tiempo de referencia, específicamente
   @c(Mon Jan 2 03:04:05PM 2006 UTC-0700). El tiempo de referencia tiene ocho
   componentes (día de la semana, mes, día del mes, etc.). Cualquier colección
   de ellos puede aparecer en la cadena @c(Format) en cualquier orden y en
   varios formatos; los componentes seleccionados de la fecha y la hora se
   mostrarán en los formatos seleccionados. Aquí estamos usando la hora, minuto
   y segundo del tiempo. El paquete @c(time) define plantillas para muchos
   formatos de hora estándar, como @c(time.RFC1123). El mismo mecanismo se
   utiliza a la inversa al analizar un tiempo usando @c(time.Parse).

   Para conectarse al servidor, necesitaremos un programa cliente como @$(nc)
   @%"(netcat), un programa de utilidad estándar para manipular conexiones de
   red:

   ..srci > sh
     > go build gopl.io/ch8/clock1
     > ./clock1 &
     > nc localhost 8000
     13:58:54
     13:58:55
     13:58:56
     13:58:57
     ^C
   < srci..

   El cliente muestra el tiempo enviado por el servidor cada segundo hasta que
   interrumpimos el cliente con Control-C, que en los sistemas Unix produce el
   eco @c(^C) por el shell. Si @$(nc) o netcat no está instalado en su sistema,
   puede usar @$(telnet) o esta versión simple de @$(netcat) que utiliza
   @c(net.Dial) para conectarse a un servidor TCP:

   ..figure > @l(gopl.io/ch8/netcat1/netcat.go<>gopl.io/ch8/netcat1)

     ..src > go
       // Netcat1 es un cliente TCP de solo lectura.
       package main

       import (
         "io"
         "log"
         "net"
         "os"
       )

       func main() {
         conn, err := net.Dial("tcp", "localhost:8000")
         if err != nil {
           log.Fatal(err)
         }
         defer conn.Close()
         mustCopy(os.Stdout, conn)
       }

       func mustCopy(dst io.Writer, src io.Reader) {
         if _, err := io.Copy(dst, src); err != nil {
           log.Fatal(err)
         }
       }
     < src..


   Este programa lee datos de la conexión y los escribe en la salida estándar
   hasta que se produce una condición de fin de archivo o un error. La función
   @c(mustCopy) es una utilidad usada en varios ejemplos en esta sección. Vamos
   a correr dos clientes al mismo tiempo en diferentes terminales, una mostrada
   a la izquierda y otra a la derecha:

   ..cols >

     ..srci > sh
       > go build gopl.io/ch8/netcat1
       > ./netcat1
       13:58:54
       13:58:55
       13:58:56
       ^C
     < srci..

     ..srci > sh
       > killall clock1
     < srci..

   <>

     ..srci > sh
       > ./netcat1

       13:58:57
       13:58:58
       13:58:59
       ^C
     < srci..


   El comando @$(killall) es una utilidad Unix que elimina todos los procesos
   con el nombre dado.

   El segundo cliente debe esperar hasta que finalice el primer cliente porque
   el servidor es secuencial; sólo se maneja un cliente a la vez. Sólo se
   necesita un pequeño cambio para hacer que el servidor sea concurrente:
   agregar la palabra clave @c(go) a la llamada a @c(handleConn) hace que cada llamada
   se ejecute en su propia gorutina.

   ..figure > @l(gopl.io/ch8/clock2/clock.go<>gopl.io/ch8/clock2)

     ..src > go
       for {
         conn, err := listener.Accept()
         if err != nil {
           log.Print(err)    // por ejemplo, coneccion anulada
           continue
         }
         go handleConn(conn) // maneja conecciones concurrentemente
       }
     < src..


   Ahora, varios clientes pueden recivir el tiempo a la vez:

   ..cols >

     ..srci > sh
       > go build gopl.io/ch8/clock2
       > ./clock2 &
       > go build gopl.io/ch8/netcat1
       > ./netcat1
       14:02:54
       14:02:55
       14:02:56
       14:02:57
       14:02:58
       14:02:59
       14:03:00
       14:03:01
       ^C
     < srci..

     ..srci > sh
       > killall clock1
     < srci..

   <>

     ..srci > sh
       > ./netcat1
       14:02:55
       14:02:56
       ^C
     < srci..

     ..srci > sh
       > ./netcat1
       14:03:00
       14:03:01
       14:03:02
       ^C
     < srci..


   @b(Ejercicio 8.1): Modificar @$(clock2) para aceptar un número de puerto y
   escribir un programa, @$(clockwall), que actúe como cliente de varios
   servidores de reloj a la vez, leyendo los tiempos de cada uno y mostrando los
   resultados en una tabla, similar a la pared de los relojes que se ven en
   algunas oficinas de negocios. Si tiene acceso a equipos distribuidos
   geográficamente, ejecute instancias de forma remota; de lo contrario, ejecute
   instancias locales en diferentes puertos con zonas horarias falsas.

   ..srci > sh
     > TZ=US/Eastern    ./clock2 -port 8010 &
     > TZ=Europe/London ./clock2 -port 8020 &
     > TZ=Asia/Tokyo    ./clock2 -port 8030 &
     > clockwall NewYork=localhost:8010 London=localhost:8020 Tokyo=localhost:8030
   < srci..


   @b(Ejercicio 8.2): Implementar un servidor de transferencia de archivos
   simultáneo (FTP). El servidor debe interpretar los comandos de cada cliente
   como @$(cd) para cambiar el directorio, @$(ls) para listar un directorio,
   @$(get) para enviar el contenido de un archivo y @$(close) para cerrar la
   conexión. Puede utilizar el comando @$(ftp) estándar como cliente o escribir
   el suyo.

** Seccion 8.3 <> Ejemplo: Servidor Echo Concurrente

   El servidor de reloj utiliza una gorutina por conexión. En esta sección,
   crearemos un servidor de eco que utiliza múltiples gorutinas por conexión.
   La mayoría de los servidores de eco simplemente escriben lo que lean, lo que
   se puede hacer con esta trivial versión de @c(handleConn):

   ..src > go
     func handleConn(c net.Conn) {
       io.Copy(c, c) // NOTA: Ignorando errores
       c.Close()
     }
   < src..

   Un servidor de eco más interesante podría simular las reverberaciones de un
   eco real, con la respuesta fuerte al principio (@c("HELLO!")), Luego moderado
   (@c("¡Hello!")) después de un retraso, luego callado (@c("¡hello!") como en
   esta versión de @c(handleConn):

   ..figure > @l(gopl.io/ch8/reverb1/reverb.go<>gopl.io/ch8/reverb1)

     ..src > go
       func echo(c net.Conn, shout string, delay time.Duration) {
         fmt.Fprintln(c, "\t", strings.ToUpper(shout))
         time.Sleep(delay)
         fmt.Fprintln(c, "\t", shout)
         time.Sleep(delay)
         fmt.Fprintln(c, "\t", strings.ToLower(shout))
       }

       func handleConn(c net.Conn) {
         input := bufio.NewScanner(c)
         for input.Scan() {
           echo(c, input.Text(), 1*time.Second)
         }
         // NOTA: ignorando posibles errores de input.Err()
         c.Close()
       }
     < src..


   Necesitaremos actualizar nuestro programa cliente para que envíe la entrada
   del terminal al servidor mientras copia la respuesta del servidor a la
   salida, lo que presenta otra oportunidad de utilizar la concurrencia:

   ..figure > @l(gopl.io/ch8/netcat2/netcat.go<>gopl.io/ch8/netcat2)

     ..src > go
       func main() {
         conn, err := net.Dial("tcp", "localhost:8000")
         if err != nil {
           log.Fatal(err)
         }
         defer conn.Close()
         go mustCopy(os.Stdout, conn)
         mustCopy(conn, os.Stdin)
       }
     < src..


   Mientras la gorutina principal lee la entrada estándar y la envía al
   servidor, una segunda gorutina lee e imprime la respuesta del servidor.
   Cuando la gorutina principal encuentra el final de la entrada, por ejemplo,
   después de que el usuario teclee Control-D (@c(^D)) en el terminal (o el
   equivalente Control-Z en Microsoft Windows), el programa se detiene, incluso
   si la otra gorutina aun tiene trabajo que hacer. (Veremos cómo hacer que el
   programa espere a que ambos lados terminen una vez que hayamos introducido
   los canales en @l(#Sección 8.4.1).)

   En la siguiente sesion, la entrada del cliente está alineada a la izquierda y
   las respuestas del servidor tienen indentacion. El cliente grita en el
   servidor de eco tres veces:

   ..srci > sh
     > go build gopl.io/ch8/reverb1
     > ./reverb1 &
     > go build gopl.io/ch8/netcat2
     > ./netcat2
     Hello?
         HELLO?
         Hello?
         hello?
     Is there anybody there?
         IS THERE ANYBODY THERE?
     Yooo-hooo!
         Is there anybody there?
         is there anybody there?
         YOOO-HOOO!
         Yooo-hooo!
         yooo-hooo!
     ^D
     > killall reverb1
   < srci..

   Tenga en cuenta que el tercer grito del cliente no se maneja hasta que el
   segundo grito se ha agotado, lo que no es muy realista. Un eco real
   consistiría en la @e(composición) de los tres gritos independientes. Para
   simularlo, necesitaremos más goroutines. Una vez más, todo lo que tenemos que
   hacer es añadir la palabra clave @c(go), esta vez a la llamada a @c(eco)

   ..figure > @l(gopl.io/ch8/reverb2/reverb.go<>gopl.io/ch8/reverb2)

     ..src > go
       func handleConn(c net.Conn) {
         input := bufio.NewScanner(c)
         for input.Scan() {
           go echo(c, input.Text(), 1*time.Second)
         }
         // NOTA: Ignorando errores potenciales de input.Err()
         c.Close()
       }
     < src..


   Los argumentos a la función iniciada por @c(go) se evalúan cuando se ejecuta
   la instrucción @c(go); así @c[input.Text()] se evalúa en la gorutina
   principal. Ahora los ecos son simultáneos y se superponen en el tiempo:

   ..srci > sh
     > go build gopl.io/ch8/reverb2
     > ./reverb2 &
     > ./netcat2
     Is there anybody there?
         IS THERE ANYBODY THERE?

     Yooo-hooo!
         Is there anybody there?
         YOOO-HOOO!
         is there anybody there?
         Yooo-hooo!
         yooo-hooo!
     ^D
     > killall reverb2
   < srci..

   Todo lo que se requería para hacer que el servidor utilizara la concurrencia,
   no sólo para manejar las conexiones de varios clientes, sino incluso dentro
   de una sola conexión, era la inserción de dos palabras clave @c(go).

   Sin embargo, al agregar estas palabras clave, tuvimos que considerar
   cuidadosamente que métodos de @c(net.Conn) es seguro llamar simultáneamente,
   lo cual no es cierto para la mayoría de los tipos. Discutiremos el concepto
   crucial de la seguridad de la concurrencia en el próximo capítulo.

** Seccion 8.4 <> Canales

   Si las gorutinas son las actividades concurrentes de un programa Go, los
   @e(canales) son las conexiones entre ellas. Un canal es un mecanismo de
   comunicacion que permite a una gorutina enviar valores a otra gorutina. Cada
   canal es un conducto para los valores de un tipo particular, llamado el
   @e(tipo de elemento) del canal. El tipo de un canal cuyos elementos tienen
   tipo @c(int) se escribe @c(chan int).

   Para crear un canal, se utiliza la funcion nativa @c(make):

   ..src > go
     ch := make(chan int) // ch tiene tipo 'chan int'
   < src..

   Al igual que con los mapas, un canal es una referencia a la estructura de
   datos creada por @c(make). Cuando copiamos un canal o pasamos uno como
   argumento a una funcion, estamos copiando una referencia, de modo que el
   llamador y el receptor llaman a la misma estructura de datos. Como con otros
   tipos de referencia, el valor cero de un canal es @c(nil).

   Dos canales del mismo tipo pueden compararse usando @c(==). La comparacion es
   verdadera si ambas son referencias a la misma estructura de datos de canal.
   Un canal puede tambien ser comparado con @c(nil).

   Un canal tiene dos operaciones principales, @e(enviar) y @e(recibir),
   conocidas colectivamente como @e(comunicaciones). Una sentencia de envio
   transmite un valor de una gorutina, a traves del canal, a otra gorutina
   ejecutando una expresion de recepcion correspondiente. Ambas operaciones se
   escriben utilizando el operador @c(<-). En una declaracion de envio, el
   @c(<-) separa los operandos de canal y de valor. En una expresion de
   recepcion, @c(<-) precede al operando del canal. Una expresion de recepcion
   cuyo resultado no se utiliza es una sentencia valida.

   ..src > go
     ch <- x  // una sentencia de envio

     x = <-ch // una sentencia de recepcion en una instruccion de asignacion
     <-ch     // una sentencia de recepcion; el resultado se descarta
   < src..

   Los canales soportan una tercera operacion, @e(cierre), que establece una
   bandera que indica que no se eviaran mas valores en este canal; los intentos
   subsiguientes de envio probocaran un panico. Las operaciones de recepcion en
   un canal cerrado generan los valores que se han enviado hasta que no quedan
   mas valores; cualquier operacion de recepcion se completa inmediatamente y
   produce el valor cero del tipo de elemento del canal.

   Para cerrar un canal, llamamos a la funcion nativa @c(close):

   ..src > go
     close(ch)
   < src..

   Un canal creado con una simple llamada a @c(make) se denomina un canal @e(sin
   bufer), pero @c(make) acepta un segundo argumento opcional, un entero denominado
   la @e(capacidad) del canal. Si la capacidad es distinta de cero, @c(make)
   crea un canal @e(con bufer).

   ..src > go
     ch = make(chan int)    // canal sin bufer
     ch = make(chan int, 0) // canal sin bufer
     ch = make(chan int, 3) // canal cor bufer con capacidad 3
   < src..

   Veremos primero los canales sin bufer y en la @l(#Seccion 8.4.4) los canales
   con buffer.

*** Seccion 8.4.1 <> Canales sin Buffer

    Una operacion de envio en un canal sin bufer, bloquea la gorutina de envio
    hasta que otra gorutina ejecute la recepcion correspondiente en el mismo
    canal, momento en el que se transmite el valor y ambas gorutinas pueden
    continuar. Por el contrario, si la operacion de recepcion se intenta
    primero, la gorutina de recepcion se bloquea hasta que otra gorutina realice
    un envio en el mismo canal.

    La comunicacion a traves de un canal sin bufer hace que las gorutinas de
    envio y recepcion se sincronicen. Debido a esto, los canales sin bufer a
    veces se llaman canales @e(sincronos). Cuando se envia un valor en un canal
    sin bufer, la recepcion del valor @e(ocurre antes) del re-despertar de la
    gorutina enviada.

    En discusiones de concurrencia, cuando decimos @e(x sucede antes de y), no
    queremos decir simplemente que @e(x) ocurre antes en el tiempo que @e(y);
    queremos decir que se garantiza que lo haga y que todos sus efectos
    anteriores, como actualizaciones a las variables, estan completos y que
    usted puede confiar en ellos.

    Cuando @e(x) no ocurre antes de @e(y) ni despues @e(y), decimos que @e(x es
    concurrente con y). Esto no significa que @e(x) e @e(y) son necesariamente
    simultaneas, simplemente que no podemos asumir nada acerca de su ordenacion.
    Como veremos en el siguiente capitulo, es necesario ordenar ciertos eventos
    durante la ejecucion del programa para evitar los problemas que surgen
    cuando dos gorutinas acceden simultaneamente a la misma variable.

    El programa cliente en la @l(#Seccion 8.3) copia la entrada al servidor en
    su gorutina principal, por lo que el programa cliente termina tan pronto
    como la corriente de entrada se cierra, incluso si la gorutina de fondo
    continua trabajando. Para hacer que el programa espere a que la gorutina de
    fondo se complete antes de salir, usamos un canal para sincronizar las dos
    gorutinas:

    ..figure > @l(gopl.io/ch8/netcat3/netcat.go<>gopl.io/ch8/netcat3)

      ..src > go
        func main() {
          conn, err := net.Dial("tcp", "localhost:8000")
          if err != nil {
            log.Fatal(err)
          }
          done := make(chan struct{})
          go func() {
            io.Copy(os.Stdout, conn) // NOTA: ignorando errores
            log.Println("done")
            done <- struct{}{}       // señala la gorutina principal
          }()
          mustCopy(conn, os.Stdin)
          conn.Close()
          <-done // espera a que la gorutina de fondo termine
        }
      < src..


    Cuando el usuario cierra el flujo de entrada estandar, @c(mustCopy) regresa
    y la gorutina principal llama a @c[conn.Close()], cerrando las dos mitades
    de la conexion de red. Cerrar la mitad de escritura de la conexion hace que
    el servidor vea una condicion de fin de archivo. Cerrar la mitad de leectura
    hace que la gorutina de fondo llame a @c(io.Copy) para devolver @"(error de
    lectura por conexion cerrada), por lo que hemos eliminado el registro de
    errores; el Ejercicio 8.3 sugiere una mejor solucion. (Observe que la
    sentencia @c(go) llama a una funcion literal, una construccion comun.)

    Antes de que regrese, la gorutina de fondo registra un mensaje, luego envia
    un valor en el canal @c(done). La gorutina principal espera hasta que haya
    recibido este valor antes de volver. Como resultado, el programa siempre
    registra el mensaje @"(done) antes de salir.

    Los mensajes enviados a traves de canales tienen dos aspectos importantes.
    Cada mensaje tiene un valor, pero a veces el hecho de la comunicacion y el
    momento en que ocurre son igualmente importantes. Llamamos a los mensajes
    @e(eventos) cuando se quiere hacer hincapie en este aspecto. Cuando el
    evento no contiene informacion adicional, es decir, su unico proposito es la
    sincronizacion, vamos a enfatizar esto mediante el uso de un canal cuyo tipo
    de elemento es @c(struct{}), aunque es comun el uso de un canal de @c(bool)
    o @c(int) para el mismo proposito, ya que @c(done <- 1) es mas corto que @c(done
    <- struct{}{}).

    @b(Ejercicio 8.3): En @$(netcat3), el valor de interfaz @c(conn) tiene el
    tipo concreto @c(*net.TCPConn), lo que representa una conexion TCP. Una
    conexion TCP se compone de dos mitades que pueden ser cerradas de forma
    independiente utilizando sus metedos @c(CloseRead) y
    @c(CloseWrite). Modifica la gorutina principal de @$(netcat3) para cerrar
    solo la mitad de escritura de la conexion para que el programa continue
    imprimiendo los ultimos ecos del servidor @$(reverb1) incluso despues de que
    la entrada estandar ha sido cerrada. (Hacer esto en el servidor @$(reverb2)
    es mas dificil; consulte el Ejercicio 8.4.)

*** Seccion 8.4.2 <> Tuberias

    Los canales se pueden utilizar para conectar gorutinas a la vez, de modo que
    la salida de una sea la entrada a otra. Esto se llama una tuberia. El
    siguiente programa consta de tres gorutinas conectadas por dos canales, como
    se muestra esquematicamente en la Figura 8.1.

    ..figure > Figura 8.1. Una tuberia de tres etapas.

      ..img  > img/Figure-8.1.jpg


    La primer gorutina, @e(counter), genera los numeros enteros 0, 1, 2, ..., y
    los envia sobre un canal a la segunda gorutina, @e(squarer), que recibe
    cada valor, optiene su cuadrado, y envia el resultado a traves de otro canal a
    la tercer gorutina, @e(printer), que recibe los valores al cuadrado y los
    imprime. Para mayor claridad de este ejemplo, hemos elegido intencionalmente
    funciones muy simples, aunque por supuesto son demasiado computacionalmente
    triviales para justificar sus propias gorutinas en un programa realista.

    ..figure > @l(gopl.io/ch8/pipeline1/main.go<>gopl.io/ch8/pipeline1)

      ..src > go
        func main() {
          naturals := make(chan int)
          squares := make(chan int)

          // Counter
          go func() {
            for x := 0; ; x++ {
              naturals <- x
            }
          }()

          // Squarer
          go func() {
            for {
              x := <-naturals
              squares <- x * x
            }
          }()

          // Printer (in main goroutine)
          for {
            fmt.Println(<-squares)
          }
        }
      < src..


    Como es de esperar, el programa imprime la serie infinita de cuadrados 0, 1,
    4, 9 y asi sucesivamente. Tuberias como esta se pueden encontrar en los
    programas de servidor de larga duracion donde los canales se utilizan para
    la comunicacion a lo largo de la vida entre gorutinas que contienen bucles
    infinitos. Pero ¿y si queremos enviar solo un numero finito de valores a
    traves de la tuberia?

    Si el remitente sabe que nunca se enviaran valores adicionales en un canal,
    es util comunicar este hecho a las gorutinas receptor para que puedan dejar
    de esperar. Esto se logra @e(cerrando) el canal utilizando la funcion nativa
    @c(close):

    ..src > go
      close(naturals)
    < src..

    Despues de que se haya cerrado un canal, cualquier otra operacion de envio
    producira un panico. Despues de que el canal cerrado ha sido @e(drenado), es
    decir, despues de que el ultimo elemento enviado ha sido recibido, todas las
    operaciones subsiguientes de recepcion se llevaran a cabo sin bloqueo, pero
    daran un valor cero. Cerrar el canal @c(naturals) haria que el bucle de
    cuadrados girara mientras recive un flujo interminable de valores cero, y
    enviaria estos ceros a la impresora.

    No hay manera de probar directamente si un canal ha sido cerrado, pero hay
    una variante de la operacion de recepcion que produce dos resultados: el
    elemento de canal recibido, ademas de un valor booleano, convencionalmente
    llamado @c(ok), que es @c(true) para una recepcion exitosa y @c(false) para
    una recepcion en un canal cerrado y drenado. Usando esta caracteristica,
    podemos modificar el bucle de @c(squares) para parar cuando el canal
    @c(naturals) se drene y a su vez cerrar el canal @c(squares).

    ..src > go
      // Squarer
      go func() {
        for {
          x, ok := <-naturals
          if !ok {
            break // el canal estaba cerrado y drenado
          }
          squares <- x * x
        }
        close(squares)
      }()
    < src..

    Debido a que la sintaxis anterior es torpe y este patron es comun, el
    lenguaje nos permite utilizar un bucle @c(range) para iterar a traves de
    canales. Esta es una sintaxis mas conveniente para recibir todos los valores
    enviados en un canal y finalizar el bucle despues del ultimo.

    En la tuberia de abajo, cuando la gorutina @c(counter) termina su bucle
    despues de 100 elementos, se cierra el canal @c(naturals), haciendo que
    @c(squarer) termine su bucle y cerrar el canal @c(squares). (En un programa
    mas complejo, podria tener sentido para el contador y las funciones
    @c(squarer) diferir las llamadas a @c(close) desde el principio.) Por
    ultimo, la gorutina principal termina su bucle y el programa se cierra.

    ..figure > @l(gopl.io/ch8/pipeline2/main.go<>gopl.io/ch8/pipeline2)

      ..src > go
        func main() {
          naturals := make(chan int)
          squares := make(chan int)

          // Counter
          go func() {
            for x := 0; x < 100; x++ {
              naturals <- x
            }
            close(naturals)
          }()

          // Squarer
          go func() {
            for x := range naturals {
              squares <- x * x
            }
            close(squares)
          }()

          // Printer (in main goroutine)
          for x := range squares {
            fmt.Println(x)
          }
        }
      < src..


    No es necesario cerrar cada canal cuando haya terminado con el. Solo es
    necesario cerrar un canal cuando es importante decir a los receptores que
    todos los datos han sido enviados. Un canal que el recolector de basura
    determine que no puede ser alcanzado tendra sus recursos recuperados,
    independientemente de si esta o no cerrado. (No hay que confundir esto con
    la operacion de cierre de los archivos abiertos. Es importante llamar al
    metodo @c(Close) en todos los archivos cuando haya terminado con ellos.)

    Intentar cerrar un canal ya cerrado provoca un panico, al igual que el
    cierre de un canal nil. El cierre de los canales tiene otro uso como un
    mecanismo de difusion, que cubriremos en la @l(#Seccion 8.9).

*** Seccion 8.4.3 <> Tipos de Canal Unidireccional

    A medida que los programas crecen, es natural dividir grandes funciones en
    piezas mas pequeñas. Nuestro ejemplo anterior utiliza tres gorutinas,
    comunicandoce a traves de dos canales, que eran variables locales de
    @c(main). El programa se divide naturalmente en tres funciones:

    ..src > go
      func counter(out chan int)
      func squarer(out, in chan int)
      func printer(in chan int)
    < src..

    La funcion @c(squarer), situada en el centro de la tuberia, toma dos
    parametros, el canal de entrada y el canal de salida. Ambos tienen el mismo
    tipo, pero sus usos previstos son opuestas: @c(in) es solo para recivir de,
    y @c(out) es solo para enviar a. Los nombres @c(in) y @c(out) transmiten
    esta intencion, pero aun asi, nada impide a @c(squarer) enviar a @c(in) o
    recibir desde @c(out).

    Esta disposicion es tipica. Cuando un canal se suministra como un parametro
    de funcion, es casi siempre con la intencion de que se utilice
    exclusivamente para enviar o exclusivamente para recibir.

    Para documentar esta intencion y evitar el mal uso, el sistema de tipos Go
    proporciona tipos de canal @e(unidireccionales) que exponen solo una u otra
    de las operaciones de envio y recepcion. El tipo @c(chan<- int), un canal
    @e(solo de envio) de @c(int), permite envio pero no recepcion. Por el
    contrario, el tipo @c(<-chan int), @c(<-chan int) un canal solo de recepcion
    de @c(int), permite recivir pero no enviar. (La posicion de la flecha @c(<-)
    en relacion con la palabra clave @c(chan) es un mnemonico. Las infracciones
    de esta disciplina se detectan en tiempo de compilacion.

    Dado que la operacion @c(close) asegura que no se produciran mas envios en
    un canal, solo la gorutina de envio esta en una posicion llamarla, y por
    esta razon es un error en tiempo de compilacion intentar cerrar un canal
    de solo recepcion.

    Esta es la tuberia de @c(squaring) una vez mas, esta vez con canales
    unidireccionales:

    ..figure > @l(gopl.io/ch8/pipeline3/main.go<>gopl.io/ch8/pipeline3)

      ..src > go
        func counter(out chan<- int) {
          for x := 0; x < 100; x++ {
            out <- x
          }
          close(out)
        }

        func squarer(out chan<- int, in <-chan int) {
          for v := range in {
            out <- v * v
          }
          close(out)
        }

        func printer(in <-chan int) {
          for v := range in {
            fmt.Println(v)
          }
        }

        func main() {
          naturals := make(chan int)
          squares := make(chan int)

          go counter(naturals)
          go squarer(squares, naturals)
          printer(squares)
        }
      < src..


    La llamada @c[counter(naturals)] convierte implicitamente @c(naturals), en
    un valor de tipo @c(chan int), con el tipo del parametro, @c(chan<- int). La
    llamada @c[printer(squares)] hace una conversion implicita a @c(<-chan int).
    Las conversiones de tipos de canal bidireccionales a unidireccionales se
    permiten en cualquier asignacion. Sin embargo, no hay vuelta atras: una vez
    que tenga un valor de un tipo unidireccional como @c(chan<- int), no hay
    forma de obtener de el un valor de tipo @c(chan int) que se refiera a la
    misma estructura de datos del canal..

*** Seccion 8.4.4 <> Canales con Buffer

    un canal almacenado en buffer tiene una cola de elementos. El tamaño maximo
    de la cola se determina cuando se crea, por el argumento de capacidad de
    @c(make). La declaracion siguiente crea un canal con buffer capaz de mantener
    tres valores @c(string). La Figura 8.2 es una representacion grafica de
    @c(ch) y el canal al que se refiere.

    ..src > go
      ch = make(chan string, 3)
    < src..

    ..figure > Figura 8.2. Un canal con buffer vacio.

      ..img  > img/Figure-8.2.jpg


    Una operacion de envio en un canal con buffer inserta un elemento en la parte
    posterior de la cola, y una operacion de recepcion elimina un elemento del
    frente. Si el canal esta lleno, la operacion de envio bloquea su gorutina
    hasta que el espacio sea puesto a disposicion por la recepcion de otra
    gorutina. Por el contrario, si el canal esta vacio, una operacion de
    recepcion se bloquea hasta que un valor es enviado por otra gorutina.

    Podemos enviar hasta tres valores en este canal sin bloquear la gorutina:

    ..src > go
      ch <- "A"
      ch <- "B"
      ch <- "C"
    < src..

    En este punto, el canal esta lleno (Figura 8.3), y una cuarta sentencia de
    envio lo bloquearia.

    ..figure > Figura 8.3. Un canal con bufer lleno.

      ..img  > img/Figure-8.3.jpg

    Si recibimos un valor,

    ..src > go
      fmt.Println(<-ch) // "A"
    < src..

    El canal no esta lleno ni vacio (Figura 8.4), de modo que una operacion de
    envio o de recepcion podria continuar sin bloqueo. De esta manera, el bufer
    del canal desacopla las gorutinas de envio y recepcion.

    ..figure > Figura 8.4. Un canal con buffer parcialmente lleno.

      ..img  > img/Figure-8.3.jpg

    En el caso improbable de que un programa necesite conocer la capacidad de
    conal con buffer, se puede obtener llamando a la funcion nativa @c(cap):

    ..src > go
      fmt.Println(cap(ch)) // "3"
    < src..

    Cuando se aplica a un canal, la funcion nativa @c(len) devuelve el numero de
    elementos actualmente almacenados en el buffer. Ya que en un programa
    concurrente esta informacion es probable que sea obsoleta tan pronto como se
    recupera, su valor es limitado, pero podria ser util durante el diagnostico
    de fallos u optimizacion de rendimiento.

    ..src > go
      fmt.Println(len(ch)) // "2"
    < src..

    Despues de dos operaciones de recepcion mas, el canal esta vacio de nuevo, y
    un cuarto podria bloquearlo:

    ..src > go
      fmt.Println(<-ch) // "B"
      fmt.Println(<-ch) // "C"
    < src..

    En este ejemplo, las operaciones de envio y recepcion fueron todas
    realizadas por la misma gorutina, pero en programas reales generalmente son
    ejecutadas por gorutinas diferentes. Los principiantes a veces se sienten
    tentados a usar canales con buffer dentro de una unica gorutina como una
    cola, atraidos por su sintaxis agradablemente sencilla, pero esto es un
    error. Los canales estan profundamente conectados con la programacion de las
    gorutinas, y sin  otra gorutina que reciba del canal, un remitente –y tal
    vez todo el programa–corre el riesgo de quedar bloqueado para siempre. Si
    todo lo que necesita es una simple cola, haga una utilizando un slice.

    El siguiente ejemplo muestra una aplicacion de un canal con bufer. Realiza
    solicitudes paralelas a tres @c(mirrors), es decir, servidores equivalentes
    pero geograficamente distribuidos. Envia sus respuestas a traves de un canal
    con bufer, luego recibe y devuelve solo la primer respuesta, que es la mas
    rapida en llegar. Por lo tanto @c(mirroredQuery) devuelve un resultado
    incluso antes de que los dos servidores mas lentos hayan respondido. (Por
    cierto, es normal que varias gorutinas envien valores al mismo canal de
    forma concurrente, como en este ejemplo, o para recibir del mismo canal).

    ..src > go
      func mirroredQuery() string {
        responses := make(chan string, 3)
        go func() { responses <- request("asia.gopl.io") }()
        go func() { responses <- request("europe.gopl.io") }()
        go func() { responses <- request("americas.gopl.io") }()
        return <-responses // devuelve la respuesta mas rapida
      }

      func request(hostname string) (response string) { /* ... */ }
    < src..

    Si hubieramos utilizado un canal sin bufer, las dos gorutinas mas lentas se
    habrian atascado tratando de enviar sus respuestas a un canal del cual
    ninguna gorutina jamas recibira. Esta situacion, denominada una @e(fuga de
    gorutina), seria un error. A diferencia de las variables basura, las
    gorutinas filtradas no se recogen automaticamente, por lo que es importante
    asegurarse de que las gorutinas terminan cuando ya no se necesitan.

    La eleccion entre canales con o sin bufer, y la eleccion de la capacidad de
    un canal con bufer, pueden afectar a la correccion de un programa. Los
    canales sin bufer proporcionan mayores garantias de sincronizacion porque
    cada operacion de envio se sincroniza con su recepcion correspondiente; con
    canales con buffer, estas operaciones se desacoplan. Ademas, cuando
    conocemos un limite superior en el numero de valores que se enviaran en un
    canal, no es inusual crear un canal con buffer de ese tamaño y realizar
    todos los envios antes de que se reciba el primer valor. Si no se asigna
    suficiente capacidad al buffer, el programa se bloqueara.

    Los canales con buffer tambien puede afectar el rendimiento del programa.
    Imaginese tres cocineros en una pasteleria, un horno, y un frigorifico y
    otro decorando cada pastel antes de pasarlo al siguiente cocinero en la
    linea de montaje. En una cocina con poco espacio, cada cocinero que ha
    terminado un pastel debe esperar a que el cocinero siguiente este listo para
    aceptarlo; esta cita es analoga a la comunicacion a traves de un canal sin
    bufer.

    Si hay espacio para un pastel entre cada cocinero, un cocinero puede colocar
    un pastel terminado alli e inmediatamente comenzar a trabajar en el
    siguiente; esto es analogo a un canal con buffer con capacidad 1. Mientras
    los cocineros trabajen aproximadamente a la misma velocidad en promedio, la
    mayoria de estos traspasos proceden rapidamente, suavizando las diferencias
    transitorias en sus respectivas velocidades. Mas espacio entre los
    cocineros–buffers mas grandes–puede suavizar las variaciones transitorias
    mas grandes en sus tarifas sin parar la linea de ensamblaje, tal como sucede
    cuando un cocinero toma una pequeño descanso, luego se apresura para
    alcanzar a los demas.

    Por otro lado, si una etapa anterior de la linea de montaje es
    consistentemente mas rapida que la siguiente etapa, el buffer entre ellos
    pasara la mayor parte de su tiempo lleno. Por el contrario, si la etapa
    posterior es mas rapida, el bufer estara normalmente vacio. Un buffer no
    proporciona ningun beneficio en este caso.

    La metafora de la linea de montaje es util para los canales y gorutinas. Por
    ejemplo, si la segunda etapa es mas elaborada, un solo cocinero puede no ser
    capaz de mantenerse al dia con el suministro del primer cocinero o
    satisfacer la demanda del tercero. Para resolver el problema, podriamos
    contratar a otro cocinero para ayudar al segundo, realizando la misma tarea
    pero trabajando independientemente. Esto es analogo a crear otra gorutina
    que se comunica sobre los mismos canales.

    No tenemos espacio para mostralo aqui, pero el paquete @c(gopl.io/ch8/cake)
    simula esta pasteleria, con varios parametros que se pueden variar. Incluye
    comparativas @%l(#Seccion 11.4<>§11.4) para algunos de los escenarios
    descritos anteriormente.

** Seccion 8.5 <> Bucle en Paralelo

   En esta seccion, exploraremos algunos patrones de concurrencia comunes para
   ejecutar todas las iteraciones de un bucle en paralelo. Consideraremos el
   problema de producir imagenes en miniatura de un conjunto de imagenes de
   tamaño completo. El paquete @c(gopl.io/ch8/thumbnail) proporciona un funcion
   @c(ImageFile) que puede escalar una sola imagen. No vamos a mostrar su
   implementacion, pero se puede descargar desde @l(http://www.gopl.io/<>gopl.io).

   ..figure > @l(gopl.io/ch8/thumbnail/thumbnail_test.go<>gopl.io/ch8/thumbnail)

     ..src > go
       // ImageFile lee una imagen de infile y escribe
       // una version en miniatura de la misma en el mismo directorio.
       // Devuelve el nombre del archivo generado, por ejemplo. "foo.thumb.jpeg".
       func ImageFile(infile string) (string, error)
     < src..


   El siguiente programa realiza un bucle sobre una lista de nombres de archivo
   de imagen y produce una miniatura para cada uno:

   ..figure > @l(gopl.io/ch8/thumbnail/thumbnail_test.go<>gopl.io/ch8/thumbnail)

     ..src > go
       // makeThumbnails crea miniaturas de los archivos especificados.
       func makeThumbnails(filenames []string) {
         for _, f := range filenames {
           if _, err := thumbnail.ImageFile(f); err != nil {
             log.Println(err)
           }
         }
       }
     < src..


   Obviamente, el orden en que procesamos los archivos no importa, ya que cada
   operacion de escalado es independiente de todas los demas. Problemas como
   este que consisten enteramente en subproblemas que son completamente
   independientes entre si, se describen como @e(vergonzosamente paralelos).  Los
   problemas vergonzosamente paralelos son el tipo mas facil para implementar
   concurrencia y disfrutar de un rendimiento que linealmente escala con la
   cantidad de paralelismo.

   Vamos a ejecutar todas estas operaciones en paralelo, ocultando asi la
   latencia de la E/S de archivos y el uso de varias CPU para los calculos de
   escalado de imagen. Nuestro primer intento de una version concurrente solo
   añade una palabras clave @c(go). Ignoraremos los errores por ahora y los
   abordaremos mas adelante.

   ..src > go
     // NOTA: incorrecto!
     func makeThumbnails2(filenames []string) {
       for _, f := range filenames {
         go thumbnail.ImageFile(f) // NOTA: ignorando errores
       }
     }
   < src..

   Esta version se ejecuta realmente rapido–demasiado rapido, de hecho, tarda
   menos tiempo que el original, incluso cuando la porcion de nombres de archivo
   contiene solo un elemento. Si no hay paralelismo, ¿como puede la version
   concurrente posiblemente correr mas rapido? La respuesta es que
   @c(makeThumbnails) regresa antes de que haya terminado de hacer lo que tenia
   que hacer. Comienza todas las gorutinas, una por cada nombre de archivo, pero
   no espera a que terminen.

   No hay una forma directa de esperar hasta que una gorutina haya terminado,
   pero podemos cambiar la gorutina interior para reportar su terminacion a la
   gorutina exterior enviando un evento en un canal compartido. Dado que sabemos
   que hay exactamente @c[len(filenames)] gorutinas interiores, la gorutina
   exterior solo necesita contar estos eventos antes de regresar:

   ..src > go
     // makeThumbnails3 crea miniaturas de los archivos especificados en paralelo.
     func makeThumbnails3(filenames []string) {
       ch := make(chan struct{})
       for _, f := range filenames {
         go func(f string) {
           thumbnail.ImageFile(f) // NOTA: ignorando errores
           ch <- struct{}{}
         }(f)
       }

       // Esperar a que los gourutines terminen
       for range filenames {
         <-ch
       }
     }
   < src..

   Notese que pasamos el valor de f como argumento explicito a la funcion
   literal en lugar de utilizar la declaracion de @c(f) envolviendo el bucle
   @c(for):

   ..src > go
     for _, f := range filenames {
       go func() {
         thumbnail.ImageFile(f) // NOTA: incorrecto!
         // ...
       }()
     }
   < src..

   Recordemos que el problema de capturar la variable del bucle dentro de una
   funcion anonima, se describe en la @l(#Seccion 5.6.1). Arriba, la unica
   variable @c(f) es compartida por todos los valores de la funcion anonima y
   actualizado por sucesivas iteraciones del bucle. Por el momento las nuevas
   gorutinas comenzar a ejecutar la funcion literal, el bucle @c(for) puede
   tener actualizada @c(f) e iniciar otra iteracion o (mas probablemente)
   terminarlo en su totalidad, por lo que cuando estas gorutinas leen el valor
   de @c(f), todas ellas observan el valor del elemento final del slice.
   Mediante la adicion de un parametro explicito, nos aseguramos de que se
   utiliza el valor de @c(f) actual cuando se ejecuta la sentencia @c(go).

   ¿Que pasa si queremos devolver los valores de cada gorutina de trabajo a la
   principal?  Si la llamada a @c(thumbnail.ImageFile) no puede crear un
   archivo, devuelve un error. La proxima version de @c(makeThumbnails) devuelve
   el primer error que recibe de cualquiera de las operaciones de escalado:

   ..src > go
     // makeThumbnails4 crea miniaturas de los archivos especificados en paralelo.
     // Devuelve un error si ocurrio alguno.
     func makeThumbnails4(filenames []string) error {
       errors := make(chan error)
       for _, f := range filenames {
         go func(f string) {
           _, err := thumbnail.ImageFile(f)
           errors <- err
         }(f)
       }

       for range filenames {
         if err := <-errors; err != nil {
           return err // NOTA: incorrecto: fuga de gorutina!
         }
       }

       return nil
     }
   < src..

   Esta funcion tiene un error sutil. Cuando encuentra el primer error no nil,
   se devuelve el error al llamador, sin dejar drenada la gorutina de canal
   @c(errors). Cada gorutina trabajador restante se bloqueara para siempre
   cuando intente enviar un valor en ese canal, y nunca terminara. Esta
   situacion, una fuga de gorutina @%l(#Seccion 8.4.4<>§8.4.4), puede hacer que
   todo el programa se atasque o se quede sin memoria.

   La solucion mas sencilla es utilizar un canal con capacidad suficiente para
   que ningun trabajador se bloque cuando envie un mensaje. (Una solucion
   alternativa es crear otra gorutina para drenar el canal, mientras la gorutina
   principal devuelve el primer error sin demora).

   La siguiente version de @c(makeThumbnails) utiliza un canal con buffer para
   devolver los nombres de los archivos de imagen generados junto con cualquier
   error.

   ..src > go
     // makeThumbnails5 crea miniaturas de los archivos especificados en paralelo.
     // Devuelve los errores de archivo generados en un orden arbitrario,
     // o un error si algun paso falla.
     func makeThumbnails5(filenames []string) (thumbfiles []string, err error) {
       type item struct {
         thumbfile string
         err       error
       }

       ch := make(chan item, len(filenames))
       for _, f := range filenames {
         go func(f string) {
           var it item
           it.thumbfile, it.err = thumbnail.ImageFile(f)
           ch <- it
         }(f)
       }

       for range filenames {
         it := <-ch
         if it.err != nil {
           return nil, it.err
         }
         thumbfiles = append(thumbfiles, it.thumbfile)
       }

       return thumbfiles, nil
     }
   < src..

   Nuestra version final de @c(makeThumbnails), a continuacion, devuelve el
   numero total de bytes ocupados por los nuevos archivos. A diferencia de las
   versiones anteriores, recibe los nombres de archivo no como un slice sino a
   traves de un canal de cadenas, por lo que no podemos predecir el numero de
   iteraciones del bucle.

   Para saber cuando ha terminado la ultima gorutina (que puede no ser la ultima
   en comenzar), necesitamos incrementar un contador antes de que cada gorutina
   comience y decrementarlo cuando cada gorutina termine. Esto exige un tipo
   especial de contador, que se puede manipular con seguridad desde multiples
   gorutinas y que proporciona una manera de esperar hasta que se convierte en
   cero. Este tipo de contador se conoce como @c(sync.WaitGroup), y el siguiente
   codigo muestra como usarlo:

   ..src > go
     // makeThumbnails6 crea miniaturas de los archivos especificados en paralelo.
     // Devuelve el numero de bytes ocupados por los archivos que crea.
     func makeThumbnails6(filenames <-chan string) int64 {
       sizes := make(chan int64)
       var wg sync.WaitGroup // numero de gorutinas de trabajo
       for f := range filenames {
         wg.Add(1)
         // trabajador
         go func(f string) {
           defer wg.Done()
           thumb, err := thumbnail.ImageFile(f)
           if err != nil {
             log.Println(err)
             return
           }
           info, _ := os.Stat(thumb) // OK para ignorar el error
           sizes <- info.Size()
         }(f)
       }

       // closer
       go func() {
         wg.Wait()
         close(sizes)
       }()

       var total int64
       for size := range sizes {
         total += size
       }

       return total
     }
   < src..

   Observe la asimetria en los metodos @c(Add) y @c(Done). @c(Add), que
   incrementa el contador, debe ser llamado antes de que el trabajador empiece
   la gorutina, no dentro de ella; de lo contrario no estariamos seguros de que
   @c(Add) @e(ocurre antes) de que la gorutina de @"(cierre) llame a @c(Wait).
   Ademas, @c(Add) toma un parametro, pero @c(Done) no; que es equivalente a
   @c[Add(-1)]. Utilizamos @c(defer) para asegurar que el contador se decrementa
   incluso en el caso de error. La estructura del codigo anterior es un patron
   comun e idiomatico para realizar un bucle en paralelo cuando no conocemos el
   numero de iteraciones.

   El canal @c(sizes) transporta el tamaño de cada archivo de nuevo a la
   gorutina principal, que los recibe usando un bucle @c(range) y calcula la
   suma. Observe como creamos un gorutina para esperar que los trabajadores
   terminen antes de cerrar el canal @c(sizes). Estas dos operaciones, espera y
   cierre, deben ser concurrentes con el bucle sobre @c(sizes).  Consideremos
   las alternativas: si la operacion de espera se coloca en la goruta principal
   antes del bucle, nunca terminaria, y si se colocaba despues del bucle, seria
   inalcanzable ya que sin nada cerrando el canal, el bucle nunca terminaria.

   La Figura 8.5 ilustra la secuencia de eventos en la funcion
   @c(makeThumbnails6). Las lineas verticales representan gorutinas. Los
   segmentos delgados indican la espera, los segmentos gruesos actividad. Las
   flechas diagonales indican eventos que sincronizan una gorutina con otra. El
   tiempo fluye hacia abajo. Note como la gorutina principal pasa la mayor parte
   de su tiempo en el bucle @c(range), esperando a que un trabajador envie un
   valor o al cierre del canal.

   ..figure > Figura 8.5. La secuencia de eventos en @c(makeThumbnails6).

     ..img  > img/Figure-8.5.jpg


   @b(Ejercicio 8.4): Modificar el servidor @$(reverb2) para utilizar un
   @c(sync.WaitGroup) por conexion para contar el numero de gorutinas @c(echo)
   activas. Cuando cae a cero, cierre la mitad de escritura de la conexion TCP
   como se describe en el Ejercicio 8.3. Compruebe que su cliente @$(netcat3)
   modificado de ese ejercicio espera los ecos finales de varios gritos
   simultaneos, incluso despues de haber cerrado la entrada estandar.

   @b(Ejercicio 8.5): Tome un programa secuencial CPU dependiente existente,
   como el programa de Mandelbrot de la @l(#Seccion 3.3) o el calculo de
   superficie 3-D de la @l(#Seccion 3.2), y ejecutar su bucle principal
   utilizando canales paralelos para la comunicacion. ¿Cuanto mas rapido se
   ejecuta en una maquina multiprocesador? ¿Cual es el numero optimo de
   gorutinas a usar?

** Seccion 8.6 <> Ejemplo: Rastreador Web Concurrente

   En la @l(#Seccion 5.6), hicimos un simple rastreador web que exploro el grafo
   de un enlace web con primer onden de amplitud. En esta seccion, lo haremos
   concurrente para que las llamadas independientes a @c(crawl) puedan explotar
   el paralelismo de E/S disponible en la web. la funcion @c(crawl) sigue siendo
   exactamente que en @c(gopl.io/ch5/findlinks3):

   ..figure > @l(gopl.io/ch8/crawl1/findlinks.go<>gopl.io/ch8/crawl1)

     ..src > go
       func crawl(url string) []string {
         fmt.Println(url)
         list, err := links.Extract(url)
         if err != nil {
           log.Print(err)
         }
         return list
       }
     < src..


   La funcion principal se asemeja a @c(breadthFirst) @%l(#Seccion 5.6<>§5.6).
   Como antes, una lista de trabajo registra la cola de elementos que necesitan
   procesamiento, cada elemento es una lista de URLs a rastrear, pero esta vez,
   en lugar de representar la cola utilizando un slice, usamos un canal. Cada
   llamada al @c(crawl) se produce en su propia gorutina y envia los enlaces que
   descubre de nuevo a la lista de trabajo.

   ..src > go
     func main() {
       worklist := make(chan []string)

       // Comienza con los argumentos de la linea de comandos.
       go func() { worklist <- os.Args[1:] }()

       // Rastrea la red concurrentemente.
       seen := make(map[string]bool)
       for list := range worklist {
         for _, link := range list {
           if !seen[link] {
             seen[link] = true
             go func(link string) {
               worklist <- crawl(link)
             }(link)
           }
         }
       }
     }
   < src..

   Observe que la gorutina de rastreo toma a @c(link) como un parametro explicito
   para evitar el problema de captura de variables de bucle que vimos por
   primera vez en la @l(#Seccion 5.6.1). Observe tambien que el envio inicial de
   los argumentos de linea de comandos a la lista de trabajo debe ejecutarse en
   su propia gorutina para evitar un @e(punto muerto), una situacion en la cual
   tanto la gorutina principal y como la gorutina de rastreo intentan enviarse
   el uno al otro mientran que ninguno esta recibiendo. Una solucion alternativa
   seria utilizar un canal con buffer.

   El rastreador ahora es altamente concurrente e imprime una tormenta de
   direcciones URL, pero tiene dos problemas. El primer problema se manifiesta
   como mensajes de error en el registro despues de unos segundos de operacion:

   ..srci > sh
     > go build gopl.io/ch8/crawl1
     > ./crawl1 http://gopl.io/
     http://gopl.io/
     https://golang.org/help/

     https://golang.org/doc/
     https://golang.org/blog/
     ...
     2015/07/15 18:22:12 Get ...: dial tcp: lookup blog.golang.org: no such host
     2015/07/15 18:22:12 Get ...: dial tcp 23.21.222.120:443: socket: too many open files
     ...
   < srci..

   El mensaje inicial de error es un informe sorprendente de un fallo de
   busqueda de DNS para un dominio confiable. El mensaje de error siguiente
   revela la causa: el programa a creado tantas conexiones de red a la vez que
   se supero el limite por proceso en el numero de archivos abiertos, haciendo
   que operaciones como las busquedas de DNS y la llama a @c(net.Dial) empiecen
   a fallar.

   El programa es demasiado paralelo. El paralelismo ilimitado rara vez es una
   buena idea ya que siempre hay un factor limitante en el sistema, como el
   numero de nucleos de CPU para cargas de trabajo de calculo, el numero de
   usos y cabeceras para operaciones de E/S de disco local, el ancho de banda
   de la red para descargas de streaming, o la capacidad de servicio de un
   servicio web. La solucion es limitar el numero de usos paralelos del recurso
   para que coincida con el nivel de paralelismo que esta disponible. Una manera
   sencilla de hacerlo en nuestro ejemplo es asegurarse de que no hay mas de
   @e(n) llamadas a @c(links.Extract) activas a la vez, donde @e(n) es
   holgadamente inferior al limite del descriptor de ficheros–20 por
   ejemplo. Esto es analogo a la manera en que un portero en un club nocturno
   atestado admite a un huesped solamente cuando algun otro huesped sale.

   Podemos limitar el paralelismo utilizando un canal con buffer de capacidad
   @e(n) para modelar una concurrencia primitiva denominada @e(semaforo contador).
   Conceptualmente, cada una de las @e(n) ranuras vacantes en el buffer del
   canal representa una señal que autoriza al titular a proceder. Enviar un
   valor al canal adquiere un token, y recibe un valor del canal libera un
   token, creando una nueva ranura vacante. Esto asegura que a la mayoria de los
   @e(n) envios puedan producirse sin una recepcion intermedia. (Aunque podria
   ser mas intuitivo tratar las ranuras @e(ocupadas) en canal con bufer como
   tokens, utilizando ranuras vacias evita la necesidad de llenar el buffer.)
   Dado que el tipo de elemento de canal no es importante, vamos a utilizar
   @c(struct{}), Que tiene tamaño cero.

   Vamos a reescribir la funcion @c(crawl) para que la llamada a
   @c(links.Extract) se encuentre entre corchetes para las operaciones de
   adquirir y liberar un token, asegurando asi que a lo sumo hay 20 llamadas
   activas al mismo tiempo. Es una buena practica mantener las operaciones de
   semaforo lo mas cerca posible de la operacion de E/S que regulan.

   ..figure > @l(gopl.io/ch8/crawl2/findlinks.go<>gopl.io/ch8/crawl2)

     ..src > go
       // tokens es un semaforo de conteo usado para
       // imponer un limite de 20 petiones concurrentes.
       var tokens = make(chan struct{}, 20)

       func crawl(url string) []string {
         fmt.Println(url)
         tokens <- struct{}{} // aquirir un token
         list, err := links.Extract(url)
         <-tokens             // liberar el token

         if err != nil {
           log.Print(err)
         }
         return list
       }
     < src..


   El segundo problema es que el programa nunca termina, incluso cuando ha
   descubierto todos los enlaces accesibles desde las URLs iniciales. (Por
   supuesto, es poco probable que note este problema a menos que elija las URLs
   inicialmente o implemente la caracteristica de limitacion de profundidad del
   Ejercicio 8.6). Para que el programa termine, necesitamos romper el bucle
   principal cuando la lista de trabajo este vacia @e(y) no existan gorutinas de
   rastreo activas.

   ..src > go
     func main() {
       worklist := make(chan []string)
       var n int // numero de envios pendientes a la lista de trabajo

       // Comienza con los argumentos de la linea de comandos.
       n++
       go func() { worklist <- os.Args[1:] }()

       // Rastradeor web concurrente.
       seen := make(map[string]bool)
       for ; n > 0; n-- {
         list := <-worklist
         for _, link := range list {
           if !seen[link] {
             seen[link] = true
             n++
             go func(link string) {
               worklist <- crawl(link)
             }(link)
           }
         }
       }
     }
   < src..

   En esta version, el contador @c(n) mantiene un registro del numero de envios
   a la lista de trabajo que aun esta por ocurrir. Cada vez que sabemos que un
   elemento necesita ser enviado a la lista de trabajo, incrementamos @c(n), una
   vez antes de enviar los argumentos iniciales de linea de comandos, y de nuevo
   cada vez que se inicie una gorutina rastreador. El bucle principal termina
   cuando @c(n) cae a cero, ya que no hay mas trabajo por hacer.

   Ahora el rastreador concurrente se ejecuta aproximadamente 20 veces mas
   rapido que el rastreador con primer orden de amplitud de la @l(#Seccion 5.6),
   sin errores, y termina correctamente si se debe completar su tarea.

   El siguiente programa muestra una solucion alternativa al problema de la
   concurrencia excesiva. Esta version utiliza la funcion de rastreo original
   que no tiene semaforo de conteo, sino que la llama desde una de las 20
   rutinas de rastreo de larga duracion, garantizando asi que al menos 20
   solicitudes HTTP esten activas simultaneamente.

   ..figure > @l(gopl.io/ch8/crawl3/findlinks.go<>gopl.io/ch8/crawl3)

     ..src > go
       func main() {
         worklist := make(chan []string)  // lista de URLs, puede tener duplicados
         unseenLinks := make(chan string) // URLs desduplicadas

         // Agrega argumentos de linea de comandos a la lista de trabajo.
         go func() { worklist <- os.Args[1:] }()

         // Crea 20 gorutinas de rastreo para buscar cada enlace no visto.
         for i := 0; i < 20; i++ {
           go func() {
             for link := range unseenLinks {
               foundLinks := crawl(link)
               go func() { worklist <- foundLinks }()
             }
           }()
         }

         // La gorutina principal desduplica los elementos de la lista de trabajo
         // y envia los no vistos a los rastreadores.
         seen := make(map[string]bool)
         for list := range worklist {
           for _, link := range list {
             if !seen[link] {
               seen[link] = true
               unseenLinks <- link
             }
           }
         }
       }
     < src..


   Las gorutinas de rastreo son todas alimentadas por el mismo canal,
   @c(unseenLinks). La gorutina principal es responsable de deduplicar los
   elementos que recibe de la lista de trabajo, y luego enviar cada enlace no
   visto sobre el canal @c(unseenLinks) a una gorutina de rastreo.

   El mapa @c(seen) esta @e(confinado) dentro de la gorutina principal; es
   decir, solo puede ser accedido por esa gorutina. Al igual que otras formas de
   ocultar la informacion, el confinamiento nos ayuda a razonar sobre la
   correccion de un programa. Por ejemplo, las variables locales no pueden
   mencionarse por su nombre fuera de la funcion en la que se declaran;
   variables que no escapan @%l(#Seccion 2.3.4<>§2.3.4) de una funcion no se
   puede acceder desde fuera de esa funcion; y los campos encapsulados de un
   objeto no se puede acceder excepto por los metodos de ese objeto. En todos
   los casos, la ocultacion de la informacion ayuda a limitar las interacciones
   no deseadas entre partes del programa.

   Los enlaces encontrados por @c(crawl) se envian a la lista de trabajo desde
   una gorutina dedicada para evitar un punto muerto.

   Para ahorrar espacio, no hemos abordado el problema de la terminacion en este
   ejemplo.

   @b(Ejercicio 8.6): Añadir limite de profundidad al rastreador concurrente.
   Es decir, si el usuario establece @c(-depth=3), entonces solo se obtendran
   las URL accesibles como un maximo de tres enlaces.

   @b(Ejercicio 8.7): Escribir un programa concurrente que cree un espejo local
   de un sitio web, obteniendo cada pagina accesible y escribiendola en un
   directorio en el disco local. Solo se deben buscar las paginas dentro del
   dominio original (por ejemplo, @l(https://golang.org<>golang.org)). Las URL
   de las paginas reflejadas deben modificarse segun sea necesario para que se
   refieran a la pagina espejo, no al original.

** Seccion 8.7 <> Multiplexacion con @c(select)

   El programa a continuacion realiza la cuenta atras para un lanzamiento de
   cohetes. la funcion @c(time.Tick) devuelve un canal en el que se envia
   eventos periodicamente, actuando como un metronomo. El valor de cada evento
   es una marca de tiempo, pero rara vez es tan interesante como el hecho de su
   entrega.

   ..figure > @l(gopl.io/ch8/countdown1/countdown.go<>gopl.io/ch8/countdown1)

     ..src > go
       func main() {
         fmt.Println("Commencing countdown.")
         tick := time.Tick(1 * time.Second)
         for countdown := 10; countdown > 0; countdown-- {
           fmt.Println(countdown)
           <-tick
         }
         launch()
       }
     < src..


   Ahora vamos a añadir la capacidad de abortar la secuencia de lanzamiento
   presionando la tecla de retorno durante la cuenta atras. En primer lugar,
   empezamos un gorutina que intenta leer un solo byte de la entrada estandar y,
   si tiene exito, envia un valor en un canal llamado @c(abort).

   ..figure > @l(gopl.io/ch8/countdown2/countdown.go<>gopl.io/ch8/countdown2)

     ..src > go
       abort := make(chan struct{})
       go func() {
         os.Stdin.Read(make([]byte, 1)) // lee un solo byte
         abort <- struct{}{}
       }()
     < src..


   Ahora cada iteracion del bucle de cuenta atras tiene que esperar a que un
   evento llegue a uno de los dos canales: el canal tinker si todo esta bien
   (@"(nominal) en la jerga de la NASA) o un evento de aborto si hubo una
   anomalia. No podemos recibir de cada canal porque cualquiera de las
   operaciones que intentamos primero bloqueara hasta su finalizacion.
   Necesitamos multiplexar estas operaciones, y para ello, necesitamos una
   @e(sentencia select).

   ..src > go
     select {
     case <-ch1:
       // ...
     case x := <-ch2:
       // ...use x...
     case ch3 <- y:
       // ...
     default:
       // ...
     }
   < src..

   La forma general de una sentencia @c(select) se muestra arriba. Al igual que
   una sentencia @c(switch), tiene un numero de casos y una opcion
   @c(default). Cada caso especifica una comunicacion (un envio o recepcion en
   el algun canal) y un bloque de los estados asociados. Puede aparecen una
   expresion de recepcion en si misma, como en el primer caso, o dentro de una
   declaracion de variable compacta, como en el segundo caso; la segunda forma
   le permite referirse al valor recibido.

   Un @c(select) espera hasta que una comunicacion por algun caso esta lista
   para proceder. A continuacion, realiza esa comunicacion y ejecuta las
   declaraciones asociadas del caso; las otras comunicaciones no suceden. Un
   @c(select) sin casos, @c(select{}), espera por siempre.

   Volvamos a nuestro programa de lanzamiento de cohetes. La funcion
   @c(time.After) devuelve inmediatamente un canal, e inicia una nueva gorutina
   que envia un unico valor en ese canal despues del tiempo especificado. La
   instruccion de seleccion a continuacion espera hasta que llegue el primero de
   dos eventos, ya sea un evento de anulacion o el evento que indica que han
   transcurrido 10 segundos. Si pasan 10 segundos sin abortar, el lanzamiento
   continua.

   ..src > go
     func main() {
       // ...crear canal abort...

       fmt.Println("Commencing countdown. Press return to abort.")
       select {
       case <-time.After(10 * time.Second):
         // no hacer nada.
       case <-abort:
         fmt.Println("Launch aborted!")
         return
       }
       launch()
     }
   < src..

   El siguiente ejemplo es mas sutil. El canal @c(ch), cuyo bufer es de tamaño
   1, esta alternativamente vacio y luego lleno, por lo que solo uno de los
   casos puede proceder, ya sea enviando cuando @e(i) es par, o bien recibiendo
   cuando @c(i) es impar. Siempre imprime @c(0 2 4 6 8).

   ..src > go
     ch := make(chan int, 1)
     for i := 0; i < 10; i++ {
       select {
       case x := <-ch:
         fmt.Println(x) // "0" "2" "4" "6" "8"
       case ch <- i:
       }
     }
   < src..

   Si varios casos estan listos, @c(select) toma uno al azar, lo que asegura que
   cada canal tiene la misma probabilidad de ser seleccionado. Aumentar el
   tamaño del bufer del ejemplo anterior hace que su salida no sea determinista,
   porque cuando el bufer no esta lleno ni vacio, la sentencia @c(select) en
   sentido figurado arroja una moneda.

   Hagamos que nuestro programa de lanzamiento imprima la cuenta regresiva. La
   siguiente instruccion @c(select) hace que cada iteracion del bucle espere
   hasta 1 segundo para un aborto, pero no mas.

   ..figure > @l(gopl.io/ch8/countdown3/countdown.go<>gopl.io/ch8/countdown3)

     ..src > go
       func main() {
         // ...crear canal abort...

         fmt.Println("Commencing countdown.  Press return to abort.")
         tick := time.Tick(1 * time.Second)
         for countdown := 10; countdown > 0; countdown-- {
           fmt.Println(countdown)
           select {
           case <-tick:
             // no hacer nada.
           case <-abort:
             fmt.Println("Launch aborted!")
             return
           }
         }
         launch()
       }
     < src..


   la funcion @c(time.Tick) se comporta como si se crea un gorutina que llama a
   @c(time.Sleep) en un bucle, enviando un evento cada vez que se despierta.
   Cuando la funcion de cuenta atras regresa, se detiene la recepcion de eventos
   de @c(tick), pero la gorutina de conteo sigue alli, tratando en vano de
   enviar en un canal donde no hay una gorutina recibiendo–una fuga de gorutina
   @%l(#Seccion 8.4.4<>§8.4.4).

   la funcion @c(Tick) es conveniente, pero solo es apropiada cuando se
   necesitan ticks durante todo el tiempo de vida de la aplicacion. De lo
   contrario, deberiamos usar este patron:

   ..src > go
     ticker := time.NewTicker(1 * time.Second)

     <-ticker.C    // recibir desde el canal tiker

     ticker.Stop() // hace que la gorutina tiker termine
   < src..

   A veces queremos intentar enviar o recibir en un canal, pero evitando el
   bloqueo si el canal no esta listo–una comunicacion @e(no bloqueante). Una
   sentencia @c(select) puede hacer eso tambien. Un @c(select) pueden tener un
   caso @c(default) que especifica que hacer cuando ninguna de las otras
   comunicaciones puede proceder de inmediato.

   La instruccion @c(select) a continuacion recibe un valor del canal @c(abort)
   si hay uno para recibir; de lo contrario no hace nada. Se trata de una
   operacion de recepcion no bloqueante; hacerlo repetidamente se denomina un
   canal de @e(sondeo).

   ..src > go
     select {
     case <-abort:
       fmt.Printf("Launch aborted!\n")
       return
     default:
       // no hacer nada
     }
   < src..

   El valor cero para un canal es @c(nil). Tal vez sorprendentemente, los
   canales nil a veces son utiles. Debido a que las operaciones de envio y
   recepcion en un canal nil se bloquean para siempre, nunca se selecciona un
   caso en una sentencia @c(select) cuyo canal es @c(nil). Esto nos permite
   utilizar @c(nil) para activar o desactivar los casos que corresponden a
   caracteristicas como el manejo de tiempos de espera o cancelacion, en
   respuesta a otros eventos de entrada o de salida que emite. Veremos un
   ejemplo en la siguiente seccion.

   @b(Ejercicio 8.8): Utilizando una instruccion @c(select), agregue un tiempo
   de espera al servidor de eco de la @l(#Seccion 8.3) para que se desconecte
   cualquier cliente que no grite nada en 10 segundos.

** Seccion 8.8 <> Ejemplo: Trayecto de Directorio Concurrente

   En esta seccion, vamos a construir un programa que informa del uso de disco
   de uno o mas directorios especificados por linea de comandos, como el comando
   Unix @$(du). La mayor parte de su trabajo es realizado por la funcion
   @c(walkDir) a continuacion, que enumera las entradas del directorio @c(dir)
   utilizando la funcion auxiliar @c(dirents).

   ..figure > @l(gopl.io/ch8/du1/main.go<>gopl.io/ch8/du1)

     ..src > go
       // walkDir camina recursivamente el arbol de archivos raiz en dir
       // y envia el tamaño de cada archivo encontrado en fileSize.
       func walkDir(dir string, fileSizes chan<- int64) {
         for _, entry := range dirents(dir) {
           if entry.IsDir() {
             subdir := filepath.Join(dir, entry.Name())
             walkDir(subdir, fileSizes)
           } else {
             fileSizes <- entry.Size()
           }
         }
       }

       // dirents devuelve las entradas del directorio dir.
       func dirents(dir string) []os.FileInfo {
         entries, err := ioutil.ReadDir(dir)
         if err != nil {
           fmt.Fprintf(os.Stderr, "du1: %v\n", err)
           return nil
         }
         return entries
       }
     < src..


   la funcion @c(ioutil.ReadDir) devuelve un slice de @c(os.FileInfo)–la misma
   informacion que una llamada a @c(os.Stat) regresa para un solo archivo. Para
   cada subdirectorio, @c(walkDir) se llama a si misma recursivamente, y para
   cada archivo, @c(walkDir) envia un mensaje en el canal @c(fileSizes). El
   mensaje es el tamaño del archivo en bytes.

   La funcion principal, que se muestra a continuacion, utiliza dos gorutinas.
   La gorutina de fondo se llama @c(walkDir) por cada directorio especificado en
   la linea de comandos y finalmente cierra el canal @c(fileSizes). La gorutina
   principal calcula la suma de los tamaños del archivo que recibe del canal y
   finalmente imprime el total.

   ..src > go
     // El comando du1 calcula el uso de disco de los archivos en el directorio.
     package main

     import (
       "flag"
       "fmt"
       "io/ioutil"
       "os"
       "path/filepath"
     )

     func main() {
       // Determina los directorios iniciales.
       flag.Parse()
       roots := flag.Args()
       if len(roots) == 0 {
         roots = []string{"."}
       }

       // Recorre el arbol de archivos.
       fileSizes := make(chan int64)
       go func() {
         for _, root := range roots {
           walkDir(root, fileSizes)
         }
         close(fileSizes)
       }()

       // Imprime los reslutados.
       var nfiles, nbytes int64
       for size := range fileSizes {
         nfiles++
         nbytes += size
       }
       printDiskUsage(nfiles, nbytes)
     }

     func printDiskUsage(nfiles, nbytes int64) {
       fmt.Printf("%d files %.1f GB\n", nfiles, float64(nbytes)/1e9)
     }
   < src..

   Este programa hace una pausa durante mucho tiempo antes de imprimir su
   resultado:

   ..srci > sh
     > go build gopl.io/ch8/du1
     > ./du1 $HOME /usr /bin /etc
     213201 files 62.7 GB
   < srci..

   El programa seria mas agradable si nos mantiene informados de su
   progreso. Sin embargo, simplemente moviendo la llamada a @c(printDiskUsage)
   en el bucle, lo haria imprimir miles de lineas de salida.

   La variante de @$(du) a continuacion, imprime los totales de forma periodica,
   pero solo si se especifica la bandera @c(-v) ya que no todos los usuarios
   querra ver mensajes de progreso. la gorutina de fondo que se repite sobre
   @c(roots) se mantiene sin cambios. la gorutina principal ahora utiliza un
   @c(ticker) para generar acontecimientos cada 500ms, y una declaracion
   @c(select) para esperar un mensaje del tamaño del archivo, en cuyo caso
   actualiza el total, o un evento tick, en cuyo caso imprime el total
   actual. Si no se especifica la bandera @c(-v), el canal @c(tick) sigue siendo
   nil, y en efecto se desactiva en su caso en el @c(select).

   ..figure > @l(gopl.io/ch8/du2/main.go<>gopl.io/ch8/du2)

     ..src > go
       var verbose = flag.Bool("v", false, "show verbose progress messages")

       func main() {
         // ...inicia gorutina de fondo...

         // Imprime el resultado periodicamente.
         var tick <-chan time.Time
         if *verbose {
           tick = time.Tick(500 * time.Millisecond)
         }
         var nfiles, nbytes int64
       loop:
         for {
           select {
           case size, ok := <-fileSizes:
             if !ok {
               break loop // fileSizes es cerrado
             }
             nfiles++
             nbytes += size
           case <-tick:
             printDiskUsage(nfiles, nbytes)
           }
         }
         printDiskUsage(nfiles, nbytes) // total final
       }
     < src..


   Dado que el programa ya no utiliza una bucle @c(range), el primer caso
   @c(select) debe probar explicitamente si el canal @c(fileSizes) se ha
   cerrado, utilizando la forma de dos resultados para recibir la operacion. Si
   el canal se ha cerrado, el programa rompe fuera del bucle. Las sentencia
   @c(break) rompe la etiqueta tanto en @c(selec) y el bucle @c(for); una
   marcada @c(break) no etiquetada saldria solo fuera de @c(select), haciendo que
   el bucle comience la siguiente iteracion.

   El programa ahora nos da un flujo de actualizaciones:

   ..srci > sh
     > go build gopl.io/ch8/du2
     > ./du2 -v $HOME /usr /bin /etc
     28608 files 8.3 GB
     54147 files 10.3 GB
     93591 files 15.1 GB
     127169 files 52.9 GB
     175931 files 62.2 GB
     213201 files 62.7 GB
   < srci..

   Sin embargo, todavia toma demasiado tiempo para terminar. No hay ninguna
   razon por la cual todas las llamadas a @c(walkDir) no se pueden hacer al
   mismo tiempo, explotando de esta manera el paralelismo en el disco del
   sistema. La tercera version de @$(du), a continuacion, crea una nueva
   gorutina para cada llamada a @c(walkDir). Se utiliza un @c(sync.WaitGroup)
   @%l(#Seccion 8.5<>§8.5) para contar el numero de llamadas a @c(walkDir) que
   aun estan activas, y una gorutina mas para cerrar el canal @c(fileSizes)
   cuando el contador llega a cero.

   ..figure > @l(gopl.io/ch8/du3/main.go<>gopl.io/ch8/du3)

     ..src > go
       func main() {
         // ...determina roots...

         // Recorre cada raiz del arbol de archivos en paralelo.
         fileSizes := make(chan int64)
         var n sync.WaitGroup
         for _, root := range roots {
           n.Add(1)
           go walkDir(root, &n, fileSizes)
         }
         go func() {
           n.Wait()
           close(fileSizes)
         }()
         // ...bucle select...
       }

       func walkDir(dir string, n *sync.WaitGroup, fileSizes chan<- int64) {
         defer n.Done()
         for _, entry := range dirents(dir) {
           if entry.IsDir() {
             n.Add(1)
             subdir := filepath.Join(dir, entry.Name())
             go walkDir(subdir, n, fileSizes)
           } else {
             fileSizes <- entry.Size()
           }
         }
       }
     < src..


   Ya que este programa crea miles de gorutinas en su apogeo, tenemos que
   cambiar @c(dirents) para utilizar un semaforo contador para evitar que se
   abran demasiados archivos a la vez, tal como lo hicimos para el rastreador web
   en la @l(#Seccion 8.6):

   ..src > go
     // sema es un semaforo de conteo para limitar la concurrencia en dirents
     var sema = make(chan struct{}, 20)

     // dirents devuelve las entradas de directorio dir
     func dirents(dir string) []os.FileInfo {
       sema <- struct{}{}        // adquirir token
       defer func() { <-sema }() // liberar token
       // ...
   < src..

   Esta version se ejecuta varias veces mas rapido que la anterior, aunque hay
   mucha variabilidad de sistema a sistema.

   @b(Ejercicio 8.9): Escribir una version de @$(du) que calcule y muestre
   periodicamente totales separados por cada uno de los directorios @c(root).

** Seccion 8.9 <> Cancelacion

   A veces necesitamos instruir a una gorutina para que detenga lo que esta
   haciendo, por ejemplo, en un servidor web que realiza un calculo en nombre de
   un cliente que se ha desconectado.

   No hay manera de que una gorutina termine directamente a otra, ya que dejaria
   todas sus variables compartidas en estados indefinidos. En el programa de
   lanzamiento de cohetes @%l(#Seccion 8.7<>§8.7) enviamos un solo valor en un
   canal llamado @c(abort), que la gorutina de cuenta regresiva interpreto como
   una peticion para detenerse. Pero ¿y si necesitamos cancelar dos gorutinas, o
   un numero arbitrario?

   Una posibilidad podria ser la de enviar tantos eventos en el canal @c(abort)
   como gorutinas haya que cancelar. Sin embargo, si algunas de las gorutinas ya
   se han terminado, nuestra cuenta sera demasiado grande, y nuestros envios
   quedaran atascados. Por otra parte, si esas gorutinas han generado otras
   gorutinas, nuestra cuenta sera demasiado pequeña, y algunas gorutinas
   permaneceran inconscientes de la cancelacion. En general, es dificil saber
   cuantos gorutinas estan trabajando en nuestro nombre en un momento
   dado. Ademas, cuando un gorutina recibe un valor del canal @c(abort), consume
   ese valor para que otros gorutinas no lo vean. Para la cancelacion, lo que
   necesitamos es un mecanismo fiable para @e(transmitir) un evento sobre un
   canal de modo que muchas gorutinas puedan verlo @e(tal) como ocurre y ver mas
   tarde que @e(ha) ocurrido.

   Recuerde que despues de que un canal ha sido cerrado y drenado de todos los
   valores enviados, las operaciones de recepcion posteriores proceden
   inmediatamente, dando valores cero. Podemos explotar esto para crear un
   mecanismo de difusion: no enviar un valor en el canal, cerrarlo.

   Podemos agregar la cancelacion al programa @$(du) de la seccion anterior con
   algunos cambios simples. En primer lugar, creamos un canal de cancelacion en
   el que no se envian valores, pero cuyo cierre indica que es hora de que el
   programa detenga lo que esta haciendo. Tambien definimos una funcion de
   utilidad, @c(cancelled), que verifica o sondea el estado de cancelacion en el
   instante en que se llama.

   ..figure > @l(gopl.io/ch8/du4/main.go<>gopl.io/ch8/du4)

     ..src > go
       var done = make(chan struct{})

       func cancelled() bool {
         select {
         case <-done:
           return true
         default:
           return false
         }
       }
     < src..


   A continuacion, creamos una gorutina que leera desde la entrada estandar, que
   normalmente esta conectada al terminal. Tan pronto como se lee cualquier
   entrada (por ejemplo, el usuario pulsa la tecla de retorno), esta gorutina
   difunde la cancelacion cerrando el canal @c(done).

   ..src > go
     // cancelar el recorrido cuando se detecta una entrada
     go func() {
       os.Stdin.Read(make([]byte, 1)) // lee un solo byte
       close(done)
     }()
   < src..

   Ahora necesitamos hacer que nuestras gorutinas respondan a la cancelacion. En
   la gorutina principal, se añade un tercer caso a la instruccion @c(select)
   que trata de recibir desde el canal @c(done). La funcion regresa si se
   selecciona este caso, pero antes de regresar debe drenar el canal
   @c(fileSizes), descartando todos los valores hasta que el canal esta
   cerrado. Esto se hace para asegurar que todas las llamadas activas a
   @c(walkDir) puedan correr hasta el final sin quedar atascado enviando a
   @c(fileSizes).

   ..src > go
     for {
       select {
       case <-done:
         // Drena fileSizes para permitir que las gorutinas existentes terminen.
         for range fileSizes {
           // no hacer nada.
         }
         return
       case size, ok := <-fileSizes:
         // ...
       }
     }
   < src..

   La gorutina @c(walkDir) escruta el estado de cancelacion cuando empieza y
   regresa sin hacer nada si se establece el estado. Esto convierte todas
   las gorutinas creadas despues de la cancelacion en no-ops:

   ..src > go
     func walkDir(dir string, n *sync.WaitGroup, fileSizes chan<- int64) {
       defer n.Done()
       if cancelled() {
         return
       }
       for _, entry := range dirents(dir) {
         // ...
       }
     }
   < src..

   Puede ser rentable sondear el estado de cancelacion de nuevo dentro del bucle
   @c(walkDir), para evitar la creacion gorutinas despues del evento de
   cancelacion. La cancelacion implica una compensacion; una respuesta mas rapida a
   menudo requiere cambios mas intrusivos a la logica del programa. Asegurarse
   de que ninguna operacion costosa ocurre despues del evento de cancelacion
   puede requerir la actualizacion de muchos lugares en su codigo, pero a menudo
   la mayoria del beneficio se puede obtener comprobando la cancelacion en
   algunos lugares importantes.

   Un poco de perfilado de este programa revelo que el cuello de botella es la
   adquisicion de un token de semaforos en @c(dirents). El @c(select) a
   continuacion hace que esta operacion sea cancelable y reduce la latencia
   tipica del programa de cientos a decenas de milisegundos:

   ..src > go
     func dirents(dir string) []os.FileInfo {
       select {
       case sema <- struct{}{}:  // aquirir token
       case <-done:
         return nil // cancelled
       }
       defer func() { <-sema }() // liberar token

       // ...leer directorio...
     }
   < src..

   Ahora, cuando se produce la cancelacion, todas las gorutinas de fondo se
   detienen rapidamente y la funcion @c(main) regresa. Por supuesto, cuando
   @c(main) regresa, un programa sale, por lo que puede ser dificil distinguir
   una funcion principal que limpia despues de si misma de una que no lo
   hace. Hay un truco muy util que podemos utilizar durante las pruebas: si en
   lugar de regresar de @c(main) en caso de cancelacion, llevamos a cabo una
   llamada a @c(panic), entonces en tiempo de ejecucion se volcara la pila de
   cada gorutina en el programa. Si la gorutina principal es la unica que queda,
   sera limpiada despues a si misma. Pero si otras gorutinas permanecen, pueden
   no haber sido canceladas correctamente, o quizas se han cancelado pero la
   cancelacion toma tiempo; una pequeña investigacion puede valer la pena. El
   volcado de un panico a menudo contiene informacion suficiente para distinguir
   estos casos.

   @b(Ejercicio 8.10): Las peticiones HTTP pueden cancelarce cerrando el canal
   opcional @c(Cancel) en la estructura @c(http.Request). Modificar el
   rastreador web de la @l(#Seccion 8.6) para admitir la cancelacion.

   Sugerencia: la conveniente funcion @c(http.Get) no le brinda la oportunidad
   de personalizar una @c(Request). En su lugar, cree la solicitud utilizando
   @c(http.NewRequest), establezca su campo @c(Cancel) y, a continuacion, realice la
   solicitud llamando a @c[http.DefaultClient.Do(req)].

   @b(Ejercicio 8.11): Siguiendo el enfoque de @c(mirroredQuery) en la
   @l(#Seccion 8.4.4), impremente una variante de @$(fetch) que solicite varias
   direcciones URL al mismo tiempo. Tan pronto como llegue la primera respuesta,
   cancele las otras solicitudes.

** Seccion 8.10 <> Ejemplo: Server de Chat

   Terminaremos este capitulo con un servidor de chat que permite a varios
   usuarios difundir mensajes de texto entre si. Hay cuatro tipos de gorutina en
   este programa. Hay una instancia por cada gorutina @c(main) y
   @c(broadcaster), y para cada conexion de cliente hay una gorutina
   @c(handleConn) y @c(clientWriter). El emisor un buen ejemplo de como se
   utiliza @c(select), ya que tiene que responder a tres diferentes tipos de
   mensajes.

   El trabajo de la gorutina principal, demostrado abajo, es escuchar y aceptar
   conexiones entrantes de la red de clientes. Para cada uno, crea una nueva
   gorutina @c(handleConn), al igual que en el servidor eco concurrente que
   vimos al principio de este capitulo.

   ..figure > @l(gopl.io/ch8/chat/chat.go<>gopl.io/ch8/chat)

     ..src > go
       func main() {
         listener, err := net.Listen("tcp", "localhost:8000")
         if err != nil {
           log.Fatal(err)
         }

         go broadcaster()
         for {
           conn, err := listener.Accept()
           if err != nil {
             log.Print(err)
             continue
           }
           go handleConn(conn)
         }
       }
     < src..


   A continuacion esta el emisor. Su variable local @c(clients) registra el
   conjunto actual de los clientes conectados. La unica informacion registrada
   sobre cada cliente es la identidad de su canal de mensajes salientes, sobre
   este mas tarde.

   ..src > go
     type client chan<- string          // un canal de mensajes salientes

     var (
       entering = make(chan client)
       leaving  = make(chan client)
       messages = make(chan string)     // todos los mensajes de los clientes entrantes
     )

     func broadcaster() {
       clients := make(map[client]bool) // todos los clientes conectados
       for {
         select {
         case msg := <-messages:
           // Difusion de mensajes entrantes a todos
           // Canales de mensajes salientes de los clientes.
           for cli := range clients {
             cli <- msg
           }
         case cli := <-entering:
           clients[cli] = true
         case cli := <-leaving:
           delete(clients, cli)
           close(cli)
         }
       }
     }
   < src..

   El emisor escucha los canales globales @c(entering) y @c(leaving) para
   anunciar la llegada y salida de @c(clients). Cuando recibe uno de estos
   eventos, actualiza el conjunto de clientes, y si el evento fue una salida,
   cierra el canal de mensajes de salida del cliente. El emisor tambien escucha
   los eventos globales en el canal @c(messages), al que cada cliente envia
   todos sus mensajes entrantes. Cuando el emisor recibe uno de estos eventos,
   transmite el mensaje a cada cliente conectado.

   Ahora echemos un vistazo a las gorutinas por cliente. La funcion
   @c(handleConn) crea un nuevo canal de mensaje de salida para su cliente y
   anuncia la llegada de este cliente a la emisora atravez del canal
   @c(entering). A continuacion, lee cada linea de texto del cliente, enviando
   cada linea al emisor a traves del canal de mensajes entrantes global,
   prefijando cada mensaje con la identidad de su remitente. Una vez que no hay
   nada mas que leer desde el cliente, @c(handleConn) anuncia la salida del
   cliente a traves del canal @c(leaving) y cierra la conexion.

   ..src > go
     func handleConn(conn net.Conn) {
       ch := make(chan string) // mensajes salientes del cliente
       go clientWriter(conn, ch)

       who := conn.RemoteAddr().String()
       ch <- "You are " + who
       messages <- who + " has arrived"
       entering <- ch

       input := bufio.NewScanner(conn)
       for input.Scan() {
         messages <- who + ": " + input.Text()
       }
       // NOTA: ignorando errores potenciales de input.Err()

       leaving <- ch
       messages <- who + " has left"
       conn.Close()
     }

     func clientWriter(conn net.Conn, ch <-chan string) {
       for msg := range ch {
         fmt.Fprintln(conn, msg) // NOTA: ignorando errores de red
       }
     }
   < src..

   Ademas, @c(handleConn) crea una gorutina @c(clientWriter) para cada cliente
   que recibe los mensajes difundidos al canal de mensaje de salida del cliente
   y los escribe en la conexion de red del cliente. El bucle de escritura del
   criente termina cuando el difusor cierra el canal despues de recibir una
   notificacion de salida @c(leaving).

   La pantalla muestra el servidor en accion con dos clientes en ventanas
   separadas en el mismo equipo, utilizando @c(netcat) para charlar:

   ..srci > sh
     > go build gopl.io/ch8/chat
     > go build gopl.io/ch8/netcat3
   < srci..

   ..cols >

     ..srci > sh
       > ./chat &
       > ./netcat3
       You are 127.0.0.1:64208
       127.0.0.1:64211 has arrived
       Hi!
       127.0.0.1:64208: Hi!

       127.0.0.1:64211: Hi yourself.
       ^C
     < srci..

     ..srci > sh
       > ./netcat3
       You are 127.0.0.1:64216

       127.0.0.1:64211: Welcome.

       127.0.0.1:64211 has left
     < srci..

   <>

     ..srci > sh
       > ./netcat3
       You are 127.0.0.1:64211
       127.0.0.1:64208: Hi!
       Hi yourself.
       127.0.0.1:64211: Hi yourself.

       127.0.0.1:64208 has left

       127.0.0.1:64216 has arrived
       Welcome.
       127.0.0.1:64211: Welcome.
       ^C
     < srci..


   Al hospedar una sesion de chat para @m(n) clientes, este programa ejecuta
   @m(2n+2) gorutinas al mismo tiempo que se comunican, sin embargo, no necesita
   operaciones de bloqueo explicitas @%l(#Seccion 9.2<>§9.2). El mapa
   @c(clients) se limita a solo una gorutina, el emisor, por lo que no se puede
   acceder al mismo tiempo. Las unicas variables que son compartidas por
   gorutinas multiples son canales e instancias de @c(net.Conn), ambos
   concurrentemente seguros. Hablaremos mas sobre el confinamiento, la seguridad
   de la concurrencia y las implicaciones de compartir las variables a traves de
   gorutinas en el proximo capitulo.

   @b(Ejercicio 8.12): Hacer que el emisor anuncia el conjunto actual de
   clientes para cada nueva llegada. Esto requiere que los clientes establecidos
   @c(clients) y los canales de entrada @c(entering) y salida registren
   tambien el nombre del cliente.

   @b(Ejercicio 8.13): Hacer que el servidor de chat desconecte clientes
   inactivos, como los que no han enviado ningun mensaje en los ultimos cinco
   minutos. Sugerencia: llamar a @c[conn.Close()] en otra gorutina desbloquea
   las llamadas activas @c(Read) como la realizada por @c[input.Scan()].

   @b(Ejercicio 8.14): Cambiar el protocolo de red del servidor de chat para que
   cada cliente proporcione su nombre al entrar. Utilice ese nombre en lugar de
   la direccion de red cuando prefija cada mensaje con la identidad de su
   remitente.

   @b(Ejercicio 8.15): El fallo de cualquier programa cliente para leer datos de
   manera oportuna en ultima instancia, hace que todos los clientes queden
   atascados. Modifique el emisor para omitir un mensaje en lugar de esperar si
   un escritor de cliente no esta listo para aceptarlo. Como alternativa,
   agregue un bufer en el canal de mensajes saliente de cada cliente para que la
   mayoria de los mensajes no se descarten; el emisor debe utilizar un envio sin
   bloqueo a este canal.

* Capitulo 9 <> Concurrencia con Variables Compartidas

  En el capitulo anterior presentamos varios programas que utilizan gorutinas y
  canales para expresar la concurrencia de forma directa y natural. Sin embargo,
  al hacerlo, comentamos una serie de cuestiones importantes y sutiles que los
  programadores deben tener en cuenta al escribir codigo concurrente.

  En este capitulo, examinaremos mas de cerca la mecanica de la concurrencia. En
  particular, señalaremos algunos de los problemas asociados con el intercambio
  de variables entre multiples gorutinas, las tecnicas analiticas para reconocer
  esos problemas y los patrones para resolverlos. Finalmente, explicaremos
  algunas de las diferencias tecnicas entre gorutinas e hilos del sistema
  operativo.

** Seccion 9.1 <> Condiciones de Carrera

   En un programa secuencial, es decir, un programa con solo una gorutina, los
   pasos del programa ocurren en el orden de ejecucion familiar determinado por
   la logica del programa. Por ejemplo, en una secuencia de declaraciones, la
   primera sucede antes de la segunda, y asi sucesivamente. En un programa con
   dos o mas gorutinas, los pasos dentro de cada gorutina suceden en el orden
   familiar, pero, en general, no sabemos si un evento @e(x) en una gorutina
   sucede antes de un evento @e(y) en otra gorutina, o pasa despues de esta, o
   simultaneamente. Cuando no podemos decir con confianza que un evento
   @e(ocurre antes) que el otro, entonces los eventos de @e(x) y @e(y) son
   @e(concurrentes).

   Considere una funcion que funcione correctamente en un programa secuencial.
   Esa funcion es @e(concurrentemente segura) si continua trabajando
   correctamente incluso cuando se llama concurrentemente, es decir, a partir de
   dos o mas gorutinas sin sincronizacion adicional. Podemos generalizar esta
   nocion a un conjunto de funciones en colaboracion, como los metodos y
   operaciones de un tipo particular. Un tipo es seguro para la concurrencia si
   todos sus metodos y operaciones accesibles son concurrentemente seguros.

   Podemos hacer un programa seguro para la concurrencia sin hacer que cada tipo
   concreto en el programa sea concurrentemente seguro. De hecho, los tipos
   concurrentemente seguros son la excepcion en lugar de la regla, por lo que
   debe acceder a una variable simultaneamente solo si la documentacion de su
   tipo indica que esto es seguro. Evitamos el acceso concurrente a la mayoria
   de las variables, ya sea mediante su @e(confinamiento) a una sola gorutina o
   manteniendo una invariante de mas alto nivel de @e(exclusion mutua).
   Explicaremos estos terminos en este capitulo.

   En contarste, se espera que las funciones a nivel de paquete @e(sean)
   compatibles con la concurrencia. Ya que las variables de nivel de paquete no
   pueden limitarse a una sola gorutina, las funciones que las modifican deben
   imponer la exclusion mutua.

   Existen muchas razones por las que una funcion puede no funcionar cuando se
   llama concurrentemente, incluyendo el punto muerto, el bloqueo vivo y la
   inanicion de recursos. No tenemos espacio para discutir todos ellos, por lo
   que nos centraremos en la mas importante, la @e(condicion de carrera).

   Una condicion de carrera es una situacion en la que el programa no da el
   resultado correcto para algunas intercalaciones de las operaciones de
   multiples gorutinas. Las condiciones de carrera son perniciosas porque pueden
   permanecer latentes en un programa y aparecen con poca frecuencia, quizas
   solo bajo carga pesada o cuando se utilizan ciertos compiladores, plataformas
   o arquitecturas. Esto los hace dificiles de reproducir y diagnosticar.

   Es tradicion explicar la gravedad de las condiciones de la carrera a traves
   de la metafora de la perdida financiera, por lo que vamos a considerar un
   programa de cuenta bancaria simple.

   ..src > go
     // El paquete bank implementa un banco con solo una cuenta.
     package bank

     var balance int

     func Deposit(amount int) { balance = balance + amount }

     func Balance() int { return balance }
   < src..

   (Podriamos haber escrito el cuerpo de la funcion @c(Deposit) como @c(balance
   += amount), lo que es equivalente, pero la forma mas larga simplificara la
   explicacion.)

   Para este programa trivial, podemos ver a simple vista que cualquier
   secuencia de llamadas a @c(Deposit) y @c(Balance) dara la respuesta correcta,
   es decir, @c(Balance) reportara la suma de todas las cantidades depositadas
   previamente. Sin embargo, si llamamos a estas funciones no en una secuencia,
   sino al mismo tiempo, no se garantiza que @c(Balance) de la respuesta
   correcta. Considere las dos siguientes gorutinas, que representan dos
   transacciones en una cuenta bancaria conjunta:

   ..src > go
     // Alice:
     go func() {
       bank.Deposit(200)                // A1
       fmt.Println("=", bank.Balance()) // A2
     }()

     // Bob:
     go bank.Deposit(100)               // B
   < src..

   Alice deposita $200, luego comprueba su balance, mientras que Bob deposita
   $100. Dado que los pasos @c(A1) y @c(A2) se producen simultaneamente con
   @c(B), no podemos predecir el orden en que se producen. Intuitivamente,
   podria parecer que solo hay tres posibles ordenaciones, que llamaremos a
   @"(Alicia primero), a @"(Bob primero), y @"(Alice/Bob/Alice). La siguiente
   tabla muestra el valor de la variable @c(balance) despues de cada paso. Las
   cadenas entre comillas representan los resbalones impresos.

   ..pre >
     Alice primero           Bob primero          Alice/Bob/Alice
                 0                     0                        0
         A1    200             B     100                A1    200
         A2 "= 200"            A1    300                B     300
         B     300             A2 "= 300"               A2 "= 300"


   En todos los casos el balance es de $300. La unica variacion es si el balance
   de Alice incluye la transaccion de Bob o no, pero los clientes estan
   satisfechos de cualquier manera.

   Pero esta intuicion es incorrecta. Hay una cuarto resultado posible, en el
   que el deposito de Bob se produce en medio de deposito de Alice, despues de
   que el equilibrio se ha leido (@c(balance + amount)), pero antes de que haya
   sido actualizada (@c(balance = ...)), haciendo que la transaccion de Bob
   desaparezca. Esto se debe a que la operacion de deposito de Alice @c(A1) es
   realmente una secuencia de dos operaciones, una lectura y una escritura; las
   llamaremos @c(A1r) y @c(A1w). Aqui esta la intercalacion problematica:

   ..pre >
     Carrera de Datos
              0
     A1r      0          ... = balance + amount
     B      100
     A1w    200          balance = ...
     A2  "= 200"


   Despues de @c(A1r), la expresion @c(balance + amount) se evalua a 200, por lo
   que este es el valor escrito durante @c(A1w), a pesar del deposito
   intermedio. El saldo final es de solo $200. El banco es $100 mas rico a
   expensas de Bob.

   Este programa contiene un determinado tipo de condicion de carrera llamado
   @c(carrera de datos). Una carrera de datos ocurre cuando dos gorutinas
   acceden simultaneamente a la misma variable y al menos uno de los accesos es
   una escritura.

   Las cosas se ponen aun mas desordenadas si la carrera de datos implica una
   variable de un tipo que es mas grande que una sola palabra de maquina, como
   una interfaz, una cadena o un slice. Este codigo actualiza @c(x)
   concurrentemente como dos slices de diferentes longitudes:

   ..src > go
     var x []int
     go func() { x = make([]int, 10) }()
     go func() { x = make([]int, 1000000) }()
     x[999999] = 1 // NOTA: comportamiento no definido; posible corrupcion de memoria!
   < src..

   El valor de @c(x) en la declaracion final no esta definido; podria ser nil, o
   un slice de longitud 10, o un slice de longitud 1,000,000. Pero recuerda que
   hay tres partes en un slice: el puntero, la longitud y la capacidad. Si el
   puntero viene de la primera llamada a realizar y la longitud viene de la
   segunda, @c(x) sera una quimera, un slice cuya longitud nominal es de
   1,000,000, pero cuya matriz subyacente tiene solo 10 elementos. En esta
   eventualidad, el almacenamiento en el elemento 999.999 bloquearia una
   ubicacion de memoria aleatoria arbitraria, con consecuencias imposibles de
   predecir y dificiles de depurar y localizar. Este campo de minas semantico se
   llama un @e(comportamiento indefinido) y es bien conocido por los
   programadores de C; afortunadamente rara vez es tan problematico en Go como
   en C.

   Incluso la nocion de que un programa concurrente es una intercalacion de
   varios programas secuenciales es una falsa intuicion. Como veremos en la
   @l(#Seccion 9.4), las carreras de datos pueden tener resultados aun mas
   extraños. Muchos programadores–incluso algunos muy inteligentes–en ocasiones
   ofrecen justificaciones para carreras de datos conocidos en sus programas:
   @"(el costo de la exclusion mutua es demasiado alto), @"(esta logica es solo
   para el registro), @"(no me importa si dejo caer algunos mensajes), y asi
   sucesivamente. La ausencia de problemas en un compilador y una plataforma
   dados puede darles una falsa confianza. Una buena regla general es que no hay
   tal cosa como una carrera de datos benigna. Entonces, ¿como evitamos las
   carreras de datos en nuestros programas?

   Vamos a repetir la definicion, ya que es tan importante: Una carrera de datos se
   produce cuando dos gorutinas acceder a la misma variable al mismo tiempo y al
   menos uno de los accesos es una escritura. De esta definicion se deduce que
   hay tres maneras de evitar una carrera de datos.

   La primera manera es no escribir la variable. Considere el siguiente mapa,
   que es poblado perezosamente, ya que cada clave se solicita por primera
   vez. Si @c(Icon) se llama secuencialmente, el programa funciona bien, pero si
   @c(Icon) se llama al mismo tiempo, hay una carrera de datos accediendo al
   mapa.

   ..src > go
     var icons = make(map[string]image.Image)

     func loadIcon(name string) image.Image

     // NOTA: no es seguro para la concurrencia!
     func Icon(name string) image.Image {
       icon, ok := icons[name]
       if !ok {
         icon = loadIcon(name)
         icons[name] = icon
       }
       return icon
     }
   < src..

   Si en lugar de eso inicializamos el mapa con todas las entradas necesarias
   antes de crear gorutinas adicionales y nunca lo modificamos de nuevo,
   entonces cualquier numero de gorutinas puede llamar concurrentemente a
   @c(Icon) de forma segura puesto que cada uno solo lee el mapa.

   ..src > go
     var icons = map[string]image.Image{
       "spades.png":   loadIcon("spades.png"),
       "hearts.png":   loadIcon("hearts.png"),
       "diamonds.png": loadIcon("diamonds.png"),
       "clubs.png":    loadIcon("clubs.png"),
     }

     // Seguro para la concurrencia.
     func Icon(name string) image.Image { return icons[name] }
   < src..

   En el ejemplo anterior, la variable @c(icons) se asigna durante la
   inicializacion del paquete, lo que ocurre antes de que comience la funcion
   principal del programa. Una vez inicializado, @c(icons) no se modifica. Las
   estructuras de datos que nunca se modifican o son inmutables son
   intrinsecamente seguras y no necesitan sincronizacion. Pero, obviamente, no
   podemos utilizar este enfoque si las actualizaciones son esenciales, como con
   una cuenta bancaria.

   La segunda forma de evitar una carrera de datos es evitar el acceso a la
   variable desde multiples gorutinas. Este es el enfoque adoptado por muchos de
   los programas del capitulo anterior. Por ejemplo, la gorutina principal en el
   rastreador web concurrente @%l(#Seccion 8.6<>§8.6) es la unica gorutina que
   tiene acceso al mapa @c(seen) y la gorutina @c(broadcaster) en el servidor
   de chat @%l(#Seccion 8.10<>§8.10) es la unica gorutina que accede al mapa
   @c(clients). Estas variables se limitan a una sola gorutina.

   Ya que otras gorutinas no pueden acceder a la variable directamente, deben
   usar un canal para enviar a la gorutina de confinamiento una solicitud de
   consulta o actualizacion de la variable. Esto es lo que se quiere decir con
   el mantra Go @"(No se comunique compartiendo memoria; en su lugar, comparta
   la memoria mediante la comunicacion). Una gorutina por la que los corredores
   acceden a una variable confinada usando solicitudes de canal se denomina
   @e(gorutina monitor) para esa variable. Por ejemplo, la gorutina
   @c(broadcaster) monitorea el acceso al mapa de clientes.

   Aqui esta el ejemplo del banco reescrito con la variable @c(balance)
   confinada a una gorutina monitor llamada @c(teller):

   ..figure > @l(gopl.io/ch9/bank1/bank.go<>gopl.io/ch9/bank1)

     ..src > go
       // El paquete bank es concurrentemente seguro con una cuenta.
       package bank

       var deposits = make(chan int) // envia la cantidad a depositar
       var balances = make(chan int) // recive el balance

       func Deposit(amount int) { deposits <- amount }
       func Balance() int       { return <-balances }

       func teller() {
         var balance int // balance esta confinado a la gorutina teller
         for {
           select {
           case amount := <-deposits:
             balance += amount
           case balances <- balance:
           }
         }
       }

       func init() {
         go teller() // inicia la gorutina monitor
       }
     < src..


   Incluso cuando una variable no puede ser confinada a una sola gorutina
   durante toda su vida, el confinamiento todavia puede ser una solucion al
   problema del acceso concurrente. Por ejemplo, es comun compartir una variable
   entre gorutinas en una tuberia, pasando su direccion de una etapa a la
   siguiente a traves de un canal. Si cada etapa de la tuberia se abstiene de
   acceder a la variable despues de enviarla a la siguiente etapa, entonces
   todos los accesos a la variable son secuenciales. En efecto, la variable esta
   confinada a una etapa de la tuberia, luego confinada a la siguiente, y asi
   sucesivamente. Esta disciplina es a veces llamado el @e(confinamiento en serie).

   En el siguiente ejemplo, @c(Cakes) se confina en serie, primero a la gorutina
   @c(baker), despues, a la gorutina @c(icer):

   ..src > go
     type Cake struct{ state string }

     func baker(cooked chan<- *Cake) {
       for {
         cake := new(Cake)
         cake.state = "cooked"
         cooked <- cake // baker nunca toca este pastel de nuevo
       }
     }

     func icer(iced chan<- *Cake, cooked <-chan *Cake) {
       for cake := range cooked {
         cake.state = "iced"
         iced <- cake   // icer nunca toca este pastel de nuevo
       }
     }
   < src..

   La tercera manera de evitar una carrera de datos es permitir que muchas
   gorutinas accedan a la variable, pero solo una a la vez. Este enfoque se
   conoce como @e(exclusion mutua) y es el objeto de la siguiente seccion.

   @b(Ejercicio 9.1): Añadir una funcion @c[Withdraw(amount int) bool] al
   programa @c(gopl.io/ch9/bank1). El resultado debe indicar si la transaccion
   tuvo exito o fracaso debido a fondos insuficientes. El mensaje enviado a la
   gorutina monitor debe contener tanto la cantidad a retirar y un nuevo canal
   por el cual la gorutina monitor puede enviar el resultado booleano de nuevo a
   @c(Withdraw).

** Seccion 9.2 <> Exclusion mutua: @c(sync.Mutex)

   En la @l(#Seccion 8.6), se utilizo un canal con buffer como un @e(semaforo
   contador) para asegurar que no mas de 20 gorutinas hacen peticiones HTTP
   simultaneas. Con la misma idea, podemos usar un canal de capacidad 1 para
   asegurar que a lo sumo una gorutina acceda a una variable compartida a la
   vez. Un semaforo que cuenta solamente a 1 se denomina @e(semaforo binario).

   ..figure > @l(gopl.io/ch9/bank2/bank.go<>gopl.io/ch9/bank2)

     ..src > go
       var (
         sema    = make(chan struct{}, 1) //  un semaforo binario custodia balance
         balance int
       )

       func Deposit(amount int) {
         sema <- struct{}{} // aquirir token
         balance = balance + amount
         <-sema             // liberar token
       }

       func Balance() int {
         sema <- struct{}{} // aquirir token
         b := balance
         <-sema             // liberar token
         return b
       }
     < src..


   Este patron de @e(exclusion mutua) es tan util que esta soportado
   directamente por el tipo de objeto @c(mutex) del paquete @c(sync). Su metodo
   @c(Lock) adquiere el token (llamado @e(bloqueo)) y su metodo @c(Unlock) lo
   libera:

   ..figure > @l(gopl.io/ch9/bank3/bank.go<>gopl.io/ch9/bank3)

     ..src > go
       import "sync"

       var (
         mu      sync.Mutex // custodia balance
         balance int
       )

       func Deposit(amount int) {
         mu.Lock()
         balance = balance + amount
         mu.Unlock()
       }

       func Balance() int {
         mu.Lock()
         b := balance
         mu.Unlock()
         return b
       }
     < src..


   Cada vez que una gorutina accede a las variables del banco (aqui solo
   @c(balance)), debe llamar al metodo @c(Lock) de mutex para adquirir un
   bloqueo exclusivo. Si alguna otra gorutina ha adquirido el bloqueo, esta
   operacion se bloqueara hasta que la otra gorutina llame a @c(Unlock) y el
   bloqueo vuelva a estar disponible. La exclusion mutua @e(custodia) las
   variables compartidas. Por convencion, las variables custodiadas por un mutex
   se declaran inmediatamente despues de la declaracion del propio mutex. Si se
   desvia de esto, asegurese de documentarlo.

   La region de codigo entre @c(Lock) y @c(Unlock) en la que un gorutina es
   libre de leer y modificar las variables compartidas se denomina @e(seccion
   critica). Llama a @c(Unlock) de parte del poseeodor del bloqueo @e(ocurrira
   antes) de que cualquier otra gorutina pueda adquirir el bloqueo para si. Es
   esencial que la gorutina libere el bloqueo una vez que haya terminado, en
   toda las rutas a traves de la funcion, incluyendo rutas de error.

   El programa bancario anterior ejemplifica un patron de concurrencia comun. Un
   conjunto de funciones exportadas encapsula una o mas variables de manera que
   la unica forma de acceder a las variables es a traves de estas funciones (o
   metodos, para las variables de un objeto). Cada funcion adquiere un bloqueo
   mutex al principio y lo libera al final, asegurando asi que las variables
   compartidas no se acceden simultaneamente. Esta disposicion de funciones,
   bloqueo mutex y variables se denomina @e(monitor). (Este uso previo de la
   palabra @"(monitor) inspiro el termino @"(gorutina monitor). Ambos usos
   comparten el significado de un agente que asegura el acceso sequencial a las
   variables.)

   Dado que las secciones criticas en las funciones @c(Deposit) y @c(Balance)
   son tan cortas–una sola linea, ninguna ramificacion–llamar a @c(Unlock) al
   final es sencillo. En las secciones criticas mas complejas, especialmente
   aquellas en los que los errores deben resolverse regregando antes, puede ser
   dificil saber que las llamadas a @c(Lock) y @c(Unlock) estan estrictamente
   emparejadas en todas las rutas. La declaracion @c(defer) de Go viene al
   rescate: al diferir una llamada a @c(Unlock), la seccion critica se extiende
   implicitamente al final de la funcion actual, liberandonos de tener que
   insertar una llamada @c(Unlock) en uno o mas lugares lejos de la llamada a
   @c(Lock).

   ..src > go
     func Balance() int {
       mu.Lock()
       defer mu.Unlock()
       return balance
     }
   < src..

   En el ejemplo anterior, @c(Unlock) se ejecuta @e(despues) de que la
   instruccion de retorno ha leido el valor de @c(balance), por lo que la
   funcion @c(Balance) es segura para la concurrencia. Como beneficio adicional,
   ya no necesitamos la variable local @c(b).

   Por otra parte, un @c(Unlock) diferido funcionara incluso si la seccion
   critica entra en panico, lo que puede ser importante en los programas que
   hacen uso de @c(recover) @%l(#Seccion 5.10<>§5.10). Un @c(defer) es
   ligeramente mas caro que una llamada explicita a @c(Unlock), pero no lo
   suficiente para justificar codigo menos claro. En programas concurrentes,
   siempre favoresca la claridad y resista la optimizacion prematura. Siempre
   que sea posible, utilice @c(defer) y deje que las secciones criticas se
   extienden hasta el final de una funcion.

   Considere la funcion @c(Withdraw) a continuacion. En caso de exito, reduce el
   balance en la cantidad especificada y devuelve @c(true). Pero si la cuenta
   tiene fondos suficientes para la transaccion, @c(Withdraw) restaura el
   balance y devuelve @c(false).

   ..src > go
     // NOTA: no atomico!
     func Withdraw(amount int) bool {
       Deposit(-amount)
       if Balance() < 0 {
         Deposit(amount)
         return false // fondos insuficientes
       }
       return true
     }
   < src..

   Esta funcion finalmente da el resultado correcto, pero tiene un efecto
   secundario desagradable. Cuando se intenta un retiro excesivo, el balance
   transitoriamente se sumerge por debajo de cero. Esto puede causar una
   retirada simultanea de una suma modesta que se rechazara espuriosamente. Asi
   que si Bob trata de comprar un coche deportivo, Alice no puede pagar por su
   cafe de la mañana. El problema es que @c(Withdraw) no es @e(atomico):
   consiste en una secuencia de tres operaciones separadas, cada una de las
   cuales adquiere y luego libera el bloqueo de exclusion mutua, pero nada
   bloquea toda la secuencia.

   Idealmente, @c(Withdraw) debe adquirir el bloqueo mutex una vez alrededor de
   toda la operacion. Sin embargo, este intento no funcionara:

   ..src > go
     // NOTA: incorrecto!
     func Withdraw(amount int) bool {
       mu.Lock()
       defer mu.Unlock()
       Deposit(-amount)
       if Balance() < 0 {
         Deposit(amount)
         return false // fondos insuficientes
       }
       return true
     }
   < src..

   @c(Deposit) intenta adquirir el bloqueo mutex una segunda vez llamando a
   @c[mu.Lock()], pero debido a que los bloqueos de exclusion mutua no son
   @e(reentrantes)–No es posible bloquear un mutex que ya esta bloqueado–esto
   lleva a un punto muerto en el que nada puede proceder, y @c(Withdraw) se
   bloqua para siempre.

   Hay una buena razon para que los mutex de Go no sean reentrantes. El
   proposito de un mutex es asegurar que ciertos invariantes de las variables
   compartidas se mantengan en puntos criticos durante la ejecucion del
   programa. Una de las invariantes es que la @"(gorutina no esta accediendo a
   las variables compartidas), pero puede haber invariantes adicionales
   especificas a las estructuras de datos que custodia el mutex. Cuando una
   gorutina adquiere un bloqueo mutex, puede suponer que los invariantes se
   mantienen. Mientras mantiene el bloqueo, puede actualizar las variables
   compartidas para que los invariantes se violen temporalmente. Sin embargo,
   cuando se libera el bloqueo, debe garantizar que el orden ha sido restaurado
   y mantiene los invariantes una vez mas. Aunque un mutex reentrante aseguraria
   que ninguna otra parte acceda a las variables compartidas, no puede proteger
   las invariantes adicionales de esas variables.

   Una solucion comun es dividir una funcion como @c(Deposit) en dos: una
   funcion no exportada, @c(deposit), que asume que el bloqueo ya se retiene y
   hace el trabajo real, y una funcion exportada @c(Deposit) que adquiere el
   bloqueo antes de llamar a @c(deposit). Podemos expresar @c(Withdraw) en
   terminos de @c(deposit) de la siguiente manera:

   ..src > go
     func Withdraw(amount int) bool {
       mu.Lock()
       defer mu.Unlock()
       deposit(-amount)
       if balance < 0 {
         deposit(amount)
         return false // fondos insuficientes
       }
       return true
     }

     func Deposit(amount int) {
       mu.Lock()
       defer mu.Unlock()
       deposit(amount)
     }

     func Balance() int {
       mu.Lock()
       defer mu.Unlock()
       return balance
     }

     // Esta funcion requiere que se mantenga el bloqueo.
     func deposit(amount int) { balance += amount }
   < src..

   Por supuesto, la funcion @c(deposit) mostrada aqui es tan trivial que una
   funcion @c(Withdraw) realista no se molestaria en llamarla, no obstante,
   ilustra el principio.

   La encapsulacion @%l(#Seccion 6.6<>§6.6), mediante la reduccion de las
   interacciones inesperadas en un programa, nos ayuda a mantener la estructura
   de datos invariantes. Por la misma razon, la encapsulacion tambien nos ayuda
   a mantener invariantes concurrentes. Cuando utilice un mutex, asegurese de
   que tanto el como las variables que protege no se exportan, ya sean variables
   a nivel de paquete o campos de una estructura.

** Seccion 9.3 <> Mutex de Lectura/Escritura: @c(sync.RWMutex)

   En un ataque de ansiedad despues de ver su deposito de $100 desaparecer sin
   dejar rastro, Bob escribe un programa para comprobar su saldo bancario
   cientos de veces por segundo. El lo ejecuta en casa, en el trabajo, y en su
   telefono. El banco se da cuenta de que el aumento del trafico esta retrasando
   los depositos y retiros, porque todas las peticiones de @c(Balance) se
   ejecutan secuencialmente, manteniendo el bloqueo exclusivo, inpidiendo
   temporalmente que otras gorutinas se ejecute.

   Dado que la funcion @c(Balance) solo tiene que leer el estado de la variable,
   de hecho, seria seguro que multiples llamadas @c(Balance) se ejecuten
   concurrentemente, siempre y cuando no se ejecute ninguna llamada a
   @c(Deposit) o @c(Withdraw). En este escenario necesitamos un tipo especial de
   bloqueo que permita que las operaciones de solo lectura se realicen en
   paralelo entre si, pero que las operaciones de escritura tengan acceso
   totalmente exclusivo. Este bloqueo se denomina @e(lectores multiples,
   escritor unico), y en Go es proporcionado por @c(sync.RWMutex):

   ..src > go
     var mu sync.RWMutex
     var balance int

     func Balance() int {
       mu.RLock() // bloqueo de lectores
       defer mu.RUnlock()
       return balance
     }
   < src..

   La funcion @c(Balance) ahora llama a los metodos @c(RLock) y @c(RUnlock) para
   adquirir y liberar @e(lectores) o bloqueo @e(compartido). la funcion
   @c(Deposit), queda sin cambios, llama a los metodos @c(mu.Lock) y
   @c(mu.Unlock) para adquirir y liberar un @e(escritor o bloqueo) exclusivo.

   Despues de este cambio, la mayor parte de peticiones de @c(Balance) de Bob se
   ejecutan en paralelo entre si y terminar mas rapidamente. El bloqueo esta
   disponible la mayoria del tiempo, y las solicitudes @c(Deposit) puede
   proceder de manera oportuna.

   RLock solo se puede utilizar si no hay escritura en variables compartidas en
   la seccion critica. En general, no debemos suponer que la funciones de solo
   lectura @e(logicamente) no actualizan algunas variables. Por ejemplo, un
   metodo que parece ser un simple accesorio tambien puede incrementar un
   contador de uso interno o actualizar un cache para que las llamadas repetidas
   sean mas rapidas. En caso de duda, utilice un @c(Lock) exclusivo.

   Solo es rentable utilizar @c(RWMutex) cuando la mayoria de las gorutinas que
   adquieren el bloqueo son lectores, y el bloqueo esta bajo @e(contencion), es
   decir, las gorutinas rutinariamente tienen que esperar para adquirirla. Un
   @c(RWMutex) requiere contabilidad interna mas compleja, por lo que es mas
   lento que un mutex regular para bloqueos sin contencion.

** Seccion 9.4 <> Sincronizacion de Memoria

   Usted puede preguntarse por que el metodo @c(Balance) necesita exclusion
   mutua, ya sea basada en canales o basada en mutex. Despues de todo, a
   diferencia de @c(Deposit), que consiste solo en una sola operacion, por lo
   que no hay peligro de ejecutar otra gorutina @"(en medio) de la misma. Hay
   dos razones por las que necesitamos un mutex. La primera es que es igualmente
   importante que @c(Balance) no se ejecute en medio de alguna otra operacion
   como @c(Withdraw). La segunda (y mas sutil) razon es que la sincronizacion es
   mas que solo el orden de ejecucion de multiples gorutinas; la sincronizacion
   tambien afecta a la memoria.

   En una computadora moderna puede haber decenas de procesadores, cada uno con
   su propia cache local de memoria principal. Por razones de eficiencia, las
   escrituras en memoria se almacenan en el buffer de cada procesador y se
   descargan en la memoria principal solo cuando es necesario. Incluso pueden
   estar comprometidos con la memoria principal en un orden diferente de lo que
   fueron escritos por la gorutina de escritura. Las primitivas de
   sincronizacion como las comunicaciones de canal y las operaciones de mutex
   hacen que el procesador descargue y comprometa todas sus escrituras
   acumuladas de modo que los efectos de la ejecucion de gorutina hasta ese
   punto esten garantizados para ser visibles para gorutinas que se ejecutan en
   otros procesadores.

   Considere las posibles salidas del siguiente fragmento de codigo:

   ..src > go
     var x, y int
     go func() {
       x = 1                   // A1
       fmt.Print("y:", y, " ") // A2
     }()
     go func() {
       y = 1                   // B1
       fmt.Print("x:", x, " ") // B2
     }()
   < src..

   Dado que estas dos gorutinas son concurrentes y acceden a variables
   compartidas sin exclusion mutua, existe una carrera de datos, por lo que no debe
   sorprendernos que el programa no sea determinista. Podemos esperar que
   imprima cualquiera de estos cuatro resultados, que corresponden a
   intercalaciones intuitivas de las declaraciones etiquetadas del programa:

   ..pre >
     y:0 x:1
     x:0 y:1
     x:1 y:1
     y:1 x:1

   La cuarta linea podria explicarse por la secuencia @c(A1), @c(B1), @c(A2),
   @c(B2) o por @c(B1), @c(A1), @c(A2), @c(B2), por ejemplo. Sin embargo, estos dos
   resultados podrian ser una sorpresa:

   ..pre >
     x:0 y:0
     y:0 x:0

   Pero dependiendo del compilador, la CPU, y muchos otros factores, pueden
   suceder tambien. ¿Que posible intercalacion de los cuatro enunciados podria
   explicarlos?

   Dentro de una sola gorutina, los efectos de cada declaracion se garantizan
   para ocurrir en el orden de la ejecucion; las gorutinas son
   @e(secuencialmente consistentes). Pero en ausencia de sincronizacion
   explicita utilizando un canal o mutex, no hay garantia de que los eventos
   sean vistos en el mismo orden por todas las gorutinas. Aunque la gorutina @c(A)
   debe observar el efecto de la escritura @c(x = 1) antes de que se lea el
   valor de @c(y), no necesariamente observar la escritura a @c(y) realizada por
   la gorutina @c(B), por lo que @c(A) puede imprimir un valor obsoleto de @c(y).

   Es tentador tratar de entender la concurrencia como si se correspondiera a
   @e(alguna) intercalacion de los estados de cada gorutina, pero como muestra
   el ejemplo anterior, no es asi como un compilador o una CPU moderna trabajan.
   Debido a que la asignacion y @c(Print) se refieren a diferentes variables, un
   compilador puede concluir que el orden de las dos declaraciones no puede
   afectar el resultado, e intercambiarlos. Si las dos gorutinas se ejecutan en
   diferentes CPUs, cada uno con su propia memoria cache, las escrituras de una
   gorutina no son visibles para el @c(Print) de la otra gorutina hasta que las
   caches se sincronizan con la memoria principal.

   Todos estos problemas de concurrencia pueden ser evitados por el uso
   consistente de patrones simples y establecidos. Siempre que sea posible,
   limite las variables a una unica gorutina; para todas las demas variables,
   utilice la exclusion mutua.

** Seccion 9.5 <> Inicializacion Perezosa: @c(sync.Once)

   Es una buena practica diferir un costoso paso de inicializacion hasta el
   momento en que se necesita. Inicializar una variable de antemano aumenta la
   latencia de inicio de un programa y es innecesario si la ejecucion no siempre
   alcanza la parte del programa que utiliza esa variable. Volvamos a la
   variable @c(icons) que vimos en el capitulo anterior:

   ..src > go
     var icons map[string]image.Image
   < src..

   Esta version de @c(Icon) utiliza @e(inicializacion perezosa):

   ..src > go
     func loadIcons() {
       icons = map[string]image.Image{
         "spades.png":   loadIcon("spades.png"),
         "hearts.png":   loadIcon("hearts.png"),
         "diamonds.png": loadIcon("diamonds.png"),
         "clubs.png":    loadIcon("clubs.png"),
       }
     }

     // NOTA: no es concurrentemente seguro!
     func Icon(name string) image.Image {
       if icons == nil {
         loadIcons() // inicializacion unica
       }
       return icons[name]
     }
   < src..

   Para una variable accedida por solo una gorutina, podemos usar el patron
   anterior, pero este patron no es seguro si @c(Icon) se llama concurrentemente.
   Al igual la funcion original @c(Deposit) del banco, @c(Icon) consta de varios
   pasos: Comprueba si @c(icons) es nil, entonces carga los iconos, luego, carga
   @c(icons) a un valor no nil. La intuicion podria sugerir que el peor
   resultado posible de la condicion de carrera anterior es que la funcion
   @c(loadIcons) se llame varias veces. Mientras que la primera gorutina esta
   ocupada cargando los iconos, otra gorutina que entre a @c(Icon) encontraria
   que la variable sigue siendo igual a @c(nil), y podria tambien llamar a
   @c(loadIcons).

   Pero esta intuicion tambien es incorrecta. (Esperamos que a estas alturas
   esta desarrollando una nueva intuicion sobre la concurrencia, que no deba
   confiar en las intuiciones sobre la concurrencia!) Recordemos la discusion de
   la memoria de la @l(#Seccion 9.4). En ausencia de sincronizacion explicita,
   el compilador y la CPU son libres de reordenar los accesos a la memoria en
   cualquier numero de maneras, siempre y cuando el comportamiento de cada
   gorutina sea consistente secuencialmente. Una posible reordenacion de las
   declaraciones de @c(loadIcons) se muestra a continuacion. Se almacena el mapa
   vacio en la variable @c(icons) antes de poblarlo:

   ..src > go
     func loadIcons() {
       icons = make(map[string]image.Image)
       icons["spades.png"] = loadIcon("spades.png")
       icons["hearts.png"] = loadIcon("hearts.png")
       icons["diamonds.png"] = loadIcon("diamonds.png")
       icons["clubs.png"] = loadIcon("clubs.png")
     }
   < src..

   En consecuencia, un gorutina que encuentre a @c(icons) siendo no-nil no puede
   asumir que la inicializacion de la variable esta completa.

   La forma mas sencilla de garantizar que todas las gorutinas observan los
   efectos de @c(loadIcons) es sincronizarlos utilizando un mutex:

   ..src > go
     var mu sync.Mutex // custodia a icons
     var icons map[string]image.Image

     // concurrentemente seguro.
     func Icon(name string) image.Image {
       mu.Lock()
       defer mu.Unlock()
       if icons == nil {
         loadIcons()
       }
       return icons[name]
     }
   < src..

   Sin embargo, el costo de aplicar el acceso mutuamente excluyente a @c(icons)
   es que dos gorutinas no pueden acceder a la variable al mismo tiempo, incluso
   una vez que la variable se ha inicializado de forma segura y nunca sera
   modificada de nuevo. Esto sugiere un bloqueo de lectores multiples:

   ..src > go
     var mu sync.RWMutex // custodia a icons
     var icons map[string]image.Image

     // concurrentemente seguro.
     func Icon(name string) image.Image {
       mu.RLock()
       if icons != nil {
         icon := icons[name]
         mu.RUnlock()
         return icon
       }
       mu.RUnlock()

       // adquiere un bloqueo exclusivo
       mu.Lock()
       if icons == nil { // NOTA: debe volver a comprobar por nil
         loadIcons()
       }
       icon := icons[name]
       mu.Unlock()
       return icon
     }
   < src..

   Ahora hay dos secciones criticas. la primer gorutina adquiere un bloqueo de
   lectura, consulta el mapa, despues libera el bloqueo. Si se encontro una
   entrada (el caso comun), se devuelve. Si no se encontro ninguna entrada, la
   gorutina adquiere un bloqueo de escritura. No hay manera de actualizar un
   bloqueo compartido a un exclusiva sin liberar primero el bloqueo compartido,
   por lo que debemos volver a comprobar la variable @c(icons) en caso de que
   otra gorutina ya la haya inicializado en el interin.

   El patron anterior nos da mayor concurrencia, pero es complejo y, por tanto,
   propenso a errores. Afortunadamente, el paquete @c(sync) proporciona una
   solucion especializada para el problema de la inicializacion unica:
   @c(sync.Once). Conceptualmente, un @c(Once) se compone de un mutex y una
   variable booleana que registra si la inicializacion ha tenido lugar; el mutex
   protege tanto las estructuras de datos booleanas como las del cliente. El
   unico metodo, @c(Do), acepta la funcion de inicializacion como su argumento.
   Vamos a utilizar @c(Once) para simplificar la funcion @c(Icon):

   ..src > go
     var loadIconsOnce sync.Once
     var icons map[string]image.Image

     // concurrentemente seguro.
     func Icon(name string) image.Image {
       loadIconsOnce.Do(loadIcons)
       return icons[name]
     }
   < src..

   Cada llamada a @c[Do(loadIcons)] bloquea el mutex y comprueba la variable
   booleana. En la primer llamada, en la que la variable es falsa, @c(Do) llama
   a @c(loadIcons) y la variable se establece a verdadero. Las llamadas
   posteriores no hacen nada, pero la sincronizacion de exclusion mutua asegura
   que los efectos de @c(loadIcons) sobre la memoria (en concreto, @c(icons)) se
   hacen visibles a todas las gorutinas. Usando @c(sync.Once) de esta manera,
   podemos evitar compartir las variables con otras gorutinas hasta que se han
   construido correctamente.

   @b(Ejercicio 9.2): Vuelva a escribir el ejemplo @c(PopCount) de la
   @l(#Seccion 2.6.2) de manera que inicialice la tabla de consulta utilizando
   @c(sync.Once) la primera vez que sea necesario. (Siendo realistas, el costo
   de la sincronizacion seria prohibitivo para una pequeña y altamente
   optimizada funcion como @c(PopCount).)

** Seccion 9.6 <> El Detector de Carreras

   Incluso con el mayor cuidado, es demasiado facil crear errores de
   concurrencia. Afortunadamente, el runtime y herramientas de Go esta equipado
   con una herramienta sofisticada y facil de usar de analisis dinamico, el
   @e(detector de carrera).

   Simplemente agregue la bandera @c(-race) al comando @$(go build), @$(go run)
   o @$(go test). Esto hace que el compilador construya una version modificada
   de su aplicacion o pruebe con instrumentacion adicional que registre
   efectivamente todos los accesos a variables compartidas que ocurrieron
   durante la ejecucion, junto con la identidad de la gorutina que leyo o
   escribio la variable. Ademas, el programa modificado registra todos los
   eventos de sincronizacion, por ejemplo, declaraciones @c(go), operaciones de
   canal, y llamadas a @c[(*sync.Mutex).Lock], @c[(*sync.WaitGroup).Wait], etc.
   (El conjunto completo de eventos de sincronizacion se especifica en el
   documento @e(The Go Memory Model) que acompaña a la especificacion del
   lenguaje.)

   El detector de carreras estudia esta corriente de eventos, buscando casos en
   los que una gorutina lee o escribe una variable compartida que fue escrita
   recientemente por una gorutina diferente sin una operacion de sincronizacion
   intermedia. Esto indica un acceso simultaneo a la variable compartida y, por
   tanto, una carrera de datos. La herramienta imprime un informe que incluye la
   identidad de la variable y las pila de funciones activas llamadas en la
   gorutina de lectura y la gorutina de escritura. Esto suele ser suficiente
   para identificar el problema. La @l(#Seccion 9.7) contiene un ejemplo del
   detector de carrera en accion.

   El detector de carrera informa todas las carreras de datos que se ejecutaron
   realmente. Sin embargo, solo puede detectar las condiciones de carrera que se
   producen durante una carrera; no puede demostrar que nunca ocurrira ninguna.
   Para obtener los mejores resultados, asegurese de que sus pruebas utilizan
   sus paquetes concurrentemente.

   Debido a la contabilidad adicional, un programa construido con la deteccion
   de carrera necesita mas tiempo y memoria para funcionar, pero la sobrecarga
   es tolerable incluso para muchos trabajos en produccion. Para condiciones de
   carrera poco frecuentes, dejar que el detector de carrera haga su trabajo
   puede ahorrar horas o dias de depuracion.

** Seccion 9.7 <> Ejemplo: Cache Concurrente Sin Bloqueo

   En esta seccion, vamos a construir una @e(memoria cache concurrente sin
   bloqueo), una abstraccion que resuelve un problema que se presenta con
   frecuencia en programas concurrentes del mundo real, pero no esta bien
   dirigido por las bibliotecas existentes. Este es el problema de @e(momorizar)
   una funcion, es decir, poner en cache el resultado de una funcion de modo que
   tiene que ser calculada solamente una vez. Nuestra solucion sera segura para
   la concurrencia y evitara la contencion asociada con diseños basados en un
   bloqueo unico para toda la memoria cache.

   Usaremos la funcion @c(httpGetBody) a continuacion como ejemplo del tipo de
   funcion que podriamos desear memorizar. Hace una peticion HTTP GET y lee el
   cuerpo de la respuesta. Las llamadas a esta funcion son relativamente caras,
   por lo que nos gustaria evitar repetirlas innecesariamente.

   ..src > go
     func httpGetBody(url string) (interface{}, error) {
       resp, err := http.Get(url)
       if err != nil {
         return nil, err
       }
       defer resp.Body.Close()
       return ioutil.ReadAll(resp.Body)
     }
   < src..

   La linea final esconde una sutileza menor. @c(ReadAll) devuelve dos
   resultados, @c([]byte) y un @c(error), pero ya que estos son asignables a
   los tipos de resultados declarados de @c(httpGetBody)–@c(interface{}) y
   @c(error), respectivamente–podemos devolver el resultado de la llamada sin
   mas preambulos. Hemos Elegimos este tipo retorno para @c(httpGetBody) para
   que se ajuste al tipo de funciones que nuestra memoria cache esta diseñada
   para memorizar.

   Aqui esta el primer bosquejo de la cache:

   ..figure > @l(gopl.io/ch9/memo1/memo.go<>gopl.io/ch9/memo1)

     ..src > go
       // El paquete memo proporciona concurrencia segura.
       // momorizacion de una funcion de tipo Func.
       package memo

       // Un Memo almacena en cache los resultados de lamar a Func
       type Memo struct {
         f     Func
         cache map[string]result
       }

       // Func es el tipo de la funcion a memorizar.
       type Func func(key string) (interface{}, error)

       type result struct {
         value interface{}
         err   error
       }

       func New(f Func) *Memo {
         return &Memo{f: f, cache: make(map[string]result)}
       }

       // NOTA: no es seguro concurrentemente!
       func (memo *Memo) Get(key string) (interface{}, error) {
         res, ok := memo.cache[key]
         if !ok {
           res.value, res.err = memo.f(key)
           memo.cache[key] = res
         }
         return res.value, res.err
       }
     < src..


   Una instancia de @c(Memo) almacena la funcion @c(f) a memorizar, de tipo
   @c(Func), y la memoria cache, que es una correspondencia de strings a
   @c(results). Cada @c(result) es simplemente el par de resultados devueltos
   por una llamada a @c(f)–un valor y un error. Vamos a mostrar algunas
   variaciones de @c(Memo) a medida que avanza el diseño, pero todos compartiran
   estos aspectos basicos.

   A continuacion se muestra un ejemplo de como utilizar @c(Memo). Para cada
   elemento en una corriente de URLs entrantes, llamamos a @c(Get), registrando
   la latencia de la llamada y la cantidad de datos que devuelve:

   ..src > go
     m := memo.New(httpGetBody)
     for url := range incomingURLs() {
       start := time.Now()
       value, err := m.Get(url)
       if err != nil {
         log.Print(err)
       }
       fmt.Printf("%s, %s, %d bytes\n",
         url, time.Since(start), len(value.([]byte)))
     }
   < src..

   Podemos utilizar el paquete @c(testing) (el tema del @l(#Capitulo 11)) para
   investigar sistematicamente el efecto de memorizacion. A partir de la salida
   de la prueba a continuacion, vemos que la corriente URL contiene duplicados,
   y que aunque la primer llamada a @c[(*Memo).Get] para cada URL toma cientos
   de milisegundos, la segunda peticion devuelve la misma cantidad de datos en
   menos de un milisegundo.

   ..srci > sh
     > go test -v gopl.io/ch9/memo1
     === RUN   Test
     https://golang.org, 175.026418ms, 7537 bytes
     https://godoc.org, 172.686825ms, 6878 bytes
     https://play.golang.org, 115.762377ms, 5767 bytes
     http://gopl.io, 749.887242ms, 2856 bytes
     https://golang.org, 721ns, 7537 bytes
     https://godoc.org, 152ns, 6878 bytes
     https://play.golang.org, 205ns, 5767 bytes
     http://gopl.io, 326ns, 2856 bytes
     --- PASS: Test (1.21s)
     PASS
     ok gopl.io/ch9/memo1   1.257s
   < srci..

   Esta prueba ejecuta todas las llamadas a @c(Get) secuencialmente.

   Dado que las solicitudes HTTP son una gran oportunidad para el paralelismo,
   cambiemos la prueba para que realice todas las solicitudes concurrentemente.
   La prueba utiliza un @c(sync.WaitGroup) que espera hasta que la ultima solicitud
   se ha completada antes de regresar.

   ..src > go
     m := memo.New(httpGetBody)
     var n sync.WaitGroup
     for url := range incomingURLs() {
       n.Add(1)
       go func(url string) {
         start := time.Now()
         value, err := m.Get(url)
         if err != nil {
           log.Print(err)
         }
         fmt.Printf("%s, %s, %d bytes\n",
           url, time.Since(start), len(value.([]byte)))
         n.Done()
       }(url)
     }
     n.Wait()
   < src..

   La prueba se ejecuta mucho mas rapido, pero por desgracia es poco probable
   que funcione correctamente todo el tiempo. Podemos notar fallos inesperados
   de cache, o resultados de cache que devuelven valores incorrectos, o incluso
   un crasheo.

   Peor aun, es probable que funcione correctamente @e(algunas) de las veces,
   por lo que ni siquiera se puede notar que tiene un problema. Pero si lo
   ejecutamos con la bandera @c(-race), el detector de carrera @%l(#Seccion
   9.6<>§9.6) a menudo imprime un informe como este:

   ..srci > sh
     > go test -run=TestConcurrent -race -v gopl.io/ch9/memo1
     === RUN   TestConcurrent
     ...
     WARNING: DATA RACE
     Write by goroutine 36:
       runtime.mapassign1()
           ~/go/src/runtime/hashmap.go:411 +0x0
       gopl.io/ch9/memo1.(*Memo).Get()
           ~/gobook2/src/gopl.io/ch9/memo1/memo.go:32 +0x205
     Previous write by goroutine 35:
       runtime.mapassign1()
           ~/go/src/runtime/hashmap.go:411 +0x0
       gopl.io/ch9/memo1.(*Memo).Get()
           ~/gobook2/src/gopl.io/ch9/memo1/memo.go:32 +0x205
     ...
     Found 1 data race(s)
     FAIL    gopl.io/ch9/memo1   2.393s
   < srci..

   La referencia a @c(memo.go:32) nos dice que dos goroutines han actualizado el
   mapa @c(cache) sin ninguna sincronizacion intermedia. @c(Get) no es
   concurrentemente seguro: tiene una carrera de datos.

   ..src n(28) > go
     func (memo *Memo) Get(key string) (interface{}, error) {
       res, ok := memo.cache[key]
       if !ok {
         res.value, res.err = memo.f(key)
         memo.cache[key] = res
       }
       return res.value, res.err
     }
   < src..

   La manera mas sencilla de hacer que la cache sea concurrentemente segura es
   utilizar sincronizacion basada en monitor. Todo lo que tenemos que hacer es
   añadir un mutex a @c(Memo), adquirir el bloqueo de exclusion mutua en el
   inicio de @c(Get) y liberarlo despues de su regreso, de modo que las dos
   operaciones @c(cache) ocurran dentro de la seccion critica:

   ..figure > @l(gopl.io/ch9/memo2/memo.go<>gopl.io/ch9/memo2)

     ..src > go
       type Memo struct {
         f     Func
         mu    sync.Mutex // custodia a cache
         cache map[string]result
       }

       // Get es concurrentemente segura.
       func (memo *Memo) Get(key string) (value interface{}, err error) {
         memo.mu.Lock()
         res, ok := memo.cache[key]
         if !ok {
           res.value, res.err = memo.f(key)
           memo.cache[key] = res
         }
         memo.mu.Unlock()
         return res.value, res.err
       }
     < src..


   Ahora el detector de carrera guarda silencio, incluso cuando se ejecutan las
   pruebas concurrentemente. Desafortunadamente este cambio a @c(Memo) invierte
   nuestras mejoras de rendimiento anteriores. Al mantener el bloqueo durante la
   duracion de cada llamada a @c(f), @c(Get) serializa todas las operaciones de
   E/S que pretendiamos poner en paralelo. Lo que necesitamos es una cache
   @e(sin bloqueo), una que no serialice las llamadas a la funcion que memoriza.

   En la siguiente implementacion de @c(Get), la gorutina llamada adquiere el
   bloqueo dos veces: una vez para la busqueda, y luego una segunda vez para la
   actualizacion si la busqueda devuelve nada. En el medio, otras gorutinas son
   libres de usar la memoria cache.

   ..figure > @l(gopl.io/ch9/memo3/memo.go<>gopl.io/ch9/memo3)

     ..src > go
       func (memo *Memo) Get(key string) (value interface{}, err error) {
         memo.mu.Lock()
         res, ok := memo.cache[key]
         memo.mu.Unlock()
         if !ok {
           res.value, res.err = memo.f(key)

           // Entre las dos secciones criticas, varias gorutinas
           // pueden correr para calcular f(key) y actualizar el mapa.
           memo.mu.Lock()
           memo.cache[key] = res
           memo.mu.Unlock()
         }
         return res.value, res.err
       }
     < src..


   El rendimiento mejora de nuevo, pero ahora observamos que algunas URL se
   estan recuperando dos veces. Esto ocurre cuando dos o mas gorutinas llaman a
   @c(Get) para la misma URL o casi al mismo tiempo. Ambas consultan la memoria
   cache, no encuentran ningun valor, y luego llaman a la funcion lenta @c(f).
   Luego ambas actualizan el mapa con el resultado que obtuvieron. Uno de los
   resultados es sobrescrito por el otro.

   Idealmente, nos gustaria evitar este trabajo redundante. Esta caracteristica
   a veces se denomina @e(supresion de duplicados). En la version de @c(Memo) a
   continuacion, cada elemento del mapa es un puntero a una estructura
   @c(entry). Cada @c(entry) contiene el resultado memorizado de una llamada a
   la funcion @c(f), como antes, pero, ademas, contiene un canal llamado
   @c(ready). Justo despues de establecer @c(result) con @c(entry), este canal
   se cierra, para a @e(emitir) @%l(#Seccion 8.9<>§8.9) a cualquier otra gorutina
   que ahora es seguro para ellas leer el resultado desde @c(entry).

   ..figure > @l(gopl.io/ch9/memo4/memo.go<>gopl.io/ch9/memo4)

     ..src > go
       type entry struct {
         res   result
         ready chan struct{} // cerrado cuando res esta listo
       }

       func New(f Func) *Memo {
         return &Memo{f: f, cache: make(map[string]*entry)}
       }

       type Memo struct {
         f     Func
         mu    sync.Mutex // guards cache
         cache map[string]*entry
       }

       func (memo *Memo) Get(key string) (value interface{}, err error) {
         memo.mu.Lock()
         e := memo.cache[key]
         if e == nil {
           // Esta es la primer solicitud de esta clave.
           // Esta gorutina se hace rosponsable de calcular
           // el valor  y transmitir la condicion de ready.
           e = &entry{ready: make(chan struct{})}
           memo.cache[key] = e
           memo.mu.Unlock()

           e.res.value, e.res.err = memo.f(key)

           close(e.ready) // condicion de transmicion lista
         } else {
           // Esta es una solicitud repetida para esta clave.
           memo.mu.Unlock()

           <-e.ready      // esperar condicion de ready
         }
         return e.res.value, e.res.err
       }
     < src..


   Una llamada a @c(Get) ahora implica la adquisicion del bloqueo mutex que
   custodia el mapa @c(cache), buscando en el mapa un puntero a una @c(entry)
   existente, asignando e insertando una nueva @c(entry) si no se encontro
   ninguna, y luego liberando el bloqueo. Si habia una @c(entry) existente, su
   valor no esta necesariamente listo aun–otra gorutina podria estar llamando a
   la funcion lenta @c(f)–por lo que la gorutina que llama debe esperar la
   condicion @"(ready) de @c(entry) antes de leer el @c(entry) de
   @c(result). Esto se hace leyendo un valor del canal @c(ready), ya que esto
   bloquea la operacion hasta que el canal esta cerrado.

   Si no hay una @c(entry) existente, a continuacion, insenta una nueva
   @c(entry) @"(no listo) en el mapa, la gorutina actual se hace responsable de
   la invocacion de la funcion lenta, actualizando @c(entry), y trasmitiendo la
   disponibilidad de la nueva @c(entry) a cualquier otra gorutina que podria
   (para entonces) estar esperando.

   Observe que las variables @c(e.res.value) y @c(e.res.err) en @c(entry) se
   comparten entre varias gorutinas. la gorutina que crea @c(entry) establece
   sus valores, y otras gorutinas leen sus valores una vez que la condicion
   @"(ready) ha sido transmitida. A pesar de ser accedido por multiples
   gorutinas, no es necesario el bloqueo mutex. El cierre del canal @c(ready)
   @e(sucede antes) de cualquier otra gorutina reciba el evento de transmision,
   por lo que la escritura a esas variables en la primer gorutina @e(sucede
   antes) de que sean leidos por gorutinas posteriores. No hay carrera de datos.

   Nuestra cache concurrente, que suprime duplicados y no bloquea, esta
   completa.

   La implementacion de @c(Memo) anterior utiliza un mutex para custodiar una
   variable de un mapa que es compartida por cada gorutina que llame a
   @c(Get). Es interesante contrastar este diseño con uno alternativo en la que
   la variable de mapa se confina a una @e(gorutina monitor) a la que los
   llamantes de @c(Get) deben enviar un mensaje.

   Las declaraciones de @c(Func), @c(result), y @c(entry) se mantienen como
   antes:

   ..src > go
     // Func es el tipo de la funcion a memorizar.
     type Func func(key string) (interface{}, error)

     // Un result es el resultado de llamar a un Func
     type result struct {
       value interface{}
       err   error
     }

     type entry struct {
       res   result
       ready chan struct{} // cerrado cuando res esta listo
     }
   < src..

   Sin embargo, el tipo @c(Memo) ahora consiste en un canal, @c(requests), a
   traves del cual el llamador de @c(Get) se comunica con la gorutina
   monitor. El tipo de elemento del canal es un @c(request). Con este esquema el
   llamador de @c(Get) envia a la gorutina monitor la clave, es decir, el
   argumento de la funcion a memorizar, y otro canal, @c(response), sobre el
   cual el resultado debe ser enviado de vuelta cuando este disponible. Este
   canal llevara un solo valor.

   ..figure > @l(gopl.io/ch9/memo5/memo.go<>gopl.io/ch9/memo5)

     ..src > go
       // Un request es un mensaje solicitado para que Func aplique la clave
       type request struct {
         key      string
         response chan<- result // el cliente quiere un solo resultado
       }

       type Memo struct{ requests chan request }

       // New regresa una memorizacion de f. Los clientes deben llamar posteriormente a Close.
       func New(f Func) *Memo {
         memo := &Memo{requests: make(chan request)}
         go memo.server(f)
         return memo
       }

       func (memo *Memo) Get(key string) (interface{}, error) {
         response := make(chan result)
         memo.requests <- request{key, response}
         res := <-response
         return res.value, res.err
       }

       func (memo *Memo) Close() { close(memo.requests) }
     < src..


   El metodo @c(Get), arriba, crea un canal de respuesta, lo pone en la
   solicitud, lo envia a la gorutina monitor, despues recibe inmediatamente de
   esta.

   La @c(cache) variable se confina a la gorutina monitor @c[(*Memo).server],
   que se muestra a continuacion. El monitor lee las peticiones en un bucle
   hasta que el canal de solicitud es cierra mediente el metodo @c(Close). Para
   cada solicitud, consulta la cache, creando e insertando una nueva @c(entry)
   si no se encontro ninguna.

   ..src > go
     func (memo *Memo) server(f Func) {
       cache := make(map[string]*entry)
       for req := range memo.requests {
         e := cache[req.key]
         if e == nil {
           // Esta es la primer solicitud para esta clave
           e = &entry{ready: make(chan struct{})}
           cache[req.key] = e
           go e.call(f, req.key) // llama a f(key)
         }
         go e.deliver(req.response)
       }
     }

     func (e *entry) call(f Func, key string) {
       // Evalua la funcion.
       e.res.value, e.res.err = f(key)
       // Transmite la condicion ready.
       close(e.ready)
     }

     func (e *entry) deliver(response chan<- result) {
       // Espera por la condicion ready.
       <-e.ready
       // Envia el resultado al cliente.
       response <- e.res
     }
   < src..

   De manera similar a la version basada en mutex, la primer solicitud de una
   clave dada se convierte en responsable de llamar a la funcion @c(f) de esa
   clave, almacenar el resultado en @c(entry), y difundir la disponibilidad de
   @c(entry) al cerrar el canal @c(ready). Esto se hace mediante
   @c[(*entry).call].

   Una solicitud posterior para la misma clave se encuentra el @c(entry)
   existente en el mapa, espera a que el resultado este listo, y envia el
   resultado a traves del canal de respuesta a la gorutina cliente que llama a
   @c(Get). Esto se hace mediante @c[(*entry).deliver]. Los metodos @c(call) y
   @c(deliver) deben ser llamados en sus propias gorutinas para asegurar que el
   monitor de gorutina no detiene el procesamiento de nuevas solicitudes.

   Este ejemplo muestra que es posible construir muchas estructuras simultaneas
   utilizando cualquiera de los dos enfoques–variables compartidas y bloqueos,
   o comunicacion de procesos secuenciales–sin excesiva complejidad.

   No siempre es obvio que enfoque es preferible en una situacion dada, pero
   vale la pena saber como se corresponden. A veces, cambiar de un enfoque a
   otro puede hacer que su codigo sea mas sencillo.

   @b(Ejercicio 9.3): Extender el tipo @c(Func) y el metodo @c[(*Memo).Get] para
   que los llamantes puedan proporcionar un canal @c(done) opcional a traves del
   cual se puede cancelar la operacion @%l(#Seccion 8.9<>§8.9). Los resultados
   de una @c(Func) cancelada no deben almacenarse en cache.

** Seccion 9.8 <> Gorutinas e Hilos

   En el capitulo anterior dijimos que la diferencia entre gorutinas e hilos del
   sistema operativo (OS) podrian ignorarse hasta mas tarde. Aunque las
   diferencias entre ellas son esencialmente cuantitativas, una diferencia
   cuantitativa lo suficientemente grande se convierte en una cualitativa, y lo
   mismo sucede con las gorutinas e hilos. Ha llegado el momento de distinguirlos.

*** Seccion 9.8.1 <> Pilas Expandibles

    Cada hilo del Sistema Operativo tiene un bloque de tamaño fijo de memoria (a
    menudo tan grande como 2 MB) para su @e(pila), el area de trabajo donde se
    guardan las variables locales de las llamadas a funciones que estan en curso
    o suspendidos temporalmente mientras que otra funcion se llama. Esta pila de
    tamaño fijo es simultaneamente demasiado y muy poco. Una pila de 2MB seria
    un enorme desperdicio de memoria para una pequeña gorutina, como una que
    simplemente espera un @c(WaitGroup) y luego cierra un canal. No es raro que
    un programa Go cree cientos de miles de gorutinas al mismo tiempo, lo que
    seria imposible con pilas tan grandes. Sin embargo, a pesar de su tamaño,
    las pilas de tamaño fijo no siempre son lo suficientemente grandes para las
    funciones mas complejas y profundamente recursivas. Cambiar el tamaño fijo
    puede mejorar la eficiencia del espacio y permitir que se creen mas
    subprocesos, o puede permitir funciones mas profundamente recursivas, pero
    no puede hacer ambas cosas.

    En contraste, un gorutina comienza su vida con una pequeña pila, tipicamente
    2KB. La pila de una gorutina, como la pila de un subproceso del sistema
    operativo, contiene las variables locales de las llamadas de funcion activas
    y suspendidas, pero a diferencia de un subproceso del sistema operativo, la
    pila de una gorutina no es fija; crece y se encoge segun sea necesario. El
    limite de tamaño para una pila de gorutina puede ser tanto como 1 GB, varios
    ordenes de magnitud mas grande que la pila de un hilo de tamaño fijo, aunque
    por supuesto pocas gorutinas utilizan tanto.

    @b(Ejercicio 9.4): Construir una tuberia que conecta un numero arbitrario de
    gorutinas con canales. ¿Cual es el numero maximo de etapas de canalizacion
    que puede crear sin quedarse sin memoria? ¿Cuanto tarda un valor en
    transitar por toda la tuberia?

*** Seccion 9.8.2 <> Planificacion de Gorutina

    Los subprocesos del sistema operativo estan programados por el kernel del
    sistema operativo. Cada pocos milisegundos, un temporizador de hardware
    interrumpe el procesador, lo que hace que se invoque una funcion del nucleo
    llamada el @e(planificador). Esta funcion suspende el subproceso actualmente
    en ejecucion y guarda sus registros en la memoria, revisa la lista de
    subprocesos y decide cual deberia ejecutar a continuacion, restaura los
    registros de ese subproceso de la memoria y reanuda la ejecucion de ese
    subproceso. Debido a que los hilos del SO estan programadas por el nucleo,
    pasar el control de un hilo a otro requiere un @e(cambio de contexto)
    completo, es decir, guardar el estado del hilo de un usuario en memoria,
    restaurando el estado de otro, y actualizar las estructuras de datos del
    planificador. Esta operacion es lenta, debido a su pobre localidad y el
    numero de accesos de memoria requeridos, e historicamente solo ha empeorado
    a medida que aumenta el numero de ciclos de CPU requeridos para acceder a la
    memoria.

    El runtime de Go contiene su propio planificador que utiliza una tecnica
    conocida como @e(planificacion m:n), ya que multiplexa (o planifica) @e(m)
    gorutinas en @m(n) hilos del SO. El trabajo del planificador Go es analogo
    al del planificador del nucleo, pero solo se refiere a las gorutinas de un
    solo programa Go.

    A diferencia del planificador de hilos del sistema operativo, el
    planificador de Go no se invoca periodicamente por un temporizador de
    hardware, sino implicitamente por ciertas construcciones en lenguaje Go. Por
    ejemplo, cuando una gorutina llama a @c(time.Sleep) o bloquea en una
    operacion de canal o mutex, el planificador la pone a dormir y se ejecuta
    otra gorutina hasta que es hora de despertar el primero. Debido a que no
    necesita un cambio al contexto del kernel, la reprogramacion de una gorutina
    es mucho mas barata que la reprogramacion de un hilo.

    @b(Ejercicio 9.5): Escribir un programa con dos gorutinas que envien
    mensajes de ida y vuelta sobre dos canales sin bufer en modo
    ping-pong. ¿Cuantas comunicaciones por segundo puede mantener el programa?

*** Seccion 9.8.3 <> @c(GOMAXPROCS)

    El planificador Go utiliza un parametro llamado @c(GOMAXPROCS) para
    determinar cuantos hilos del OS puede estar ejecutando activamente en
    ejecucion el codigo Go al mismo tiempo. Su valor predeterminado es el numero
    de CPUs en la maquina, por lo que en una maquina con 8 CPUs, el planificador
    programara el codigo Go en hasta 8 hilos del SO a la vez. (@c(GOMAXPROCS) es
    la @e(n) en la planificacion @e(m:n)). Las Gorutinas que estan durmiendo o
    bloqueadas en una comunicacion no necesitan un hilo en absoluto. Las
    Gorutinas que estan bloqueadas con llamadas al sistema de E/S u otro tipo de
    llamadas a funciones no Go, no necesita un hilo del SO, por lo que
    @c(GOMAXPROCS) no tienen por que dar cuenta de ellas.

    Puede controlar de forma explicita este parametro mediante la variable de
    entorno @c(GOMAXPROCS) o la funcion @c(runtime.GOMAXPROCS). Podemos ver el
    efecto de @c(GOMAXPROCS) en este pequeño programa, que imprime un flijo sin
    fin de unos y ceros:

    ..src > go
      for {
        go fmt.Print(0)
        fmt.Print(1)
      }
    < src..

    ..srci > sh
      > GOMAXPROCS=1 go run hacker-cliche.go
      111111111111111111110000000000000000000011111...
      > GOMAXPROCS=2 go run hacker-cliche.go
      010101010101010101011001100101011010010100110...
    < srci..

    En la primera ejecucion, al menos una gorutina fue ejecutada a la
    vez. Inicialmente, era la gorutina principal, que imprime unos. Despues de
    un periodo de tiempo, el planificador de Go lo puso a dormir y desperto la
    gorutina que imprime ceros, dandole un giro para correr en el hilo del
    sistema operativo. En la segunda ejecucion, habia dos subprocesos de sistema
    operativo disponibles, por lo que ambas gorutinas se ejecutaron
    simultaneamente, imprimiendo digitos en la misma tasa. Debemos destacar que
    muchos factores estan involucrados en la programacion de gorutinas, y el
    tiempo de ejecucion esta en constante evolucion, por lo que sus resultados
    pueden diferir de los anteriores.

    @b(Ejercicio 9.6): Medir como varia el desempeño de un programa paralelo
    ligado a calculo (vea el Ejercicio 8.5) con @c(GOMAXPROCS). ¿Cual es el
    valor optimo en su computadora? ¿Cuantas CPU tiene su computadora?

*** Seccion 9.8.4 <> Las Gorutinas No Tienen Identidad

    En la mayoria de los sistemas operativos y lenguajes de programacion que
    admiten multihilo, el subproceso actual tiene una identidad distinta que se
    puede obtener facilmente como un valor ordinario, normalmente un entero o
    puntero. Esto hace que sea facil de construir una abstraccion denominada
    @e(almacenamiento local de hilos), que es esencialmente un mapa global con
    clave de identidad de hilos, de modo que cada hilo puede almacenar y
    recuperar valores independientes de los otros hilos.

    Las gorutinas no tienen ninguna nocion de la identidad que es accesible al
    programador. Esto es por diseño, ya que el almacenamiento local de hilos
    tiende a ser abusado. Por ejemplo, en un servidor web implementado en un
    lenguaje con almacenamiento local de hilos, es comun que muchas funciones
    busquen informacion sobre la solicitud HTTP en cuyo nombre estan trabajando
    actualmente buscando en ese almacenamiento. Sin embargo, al igual que con
    los programas que dependen excesivamente de las variables globales, esto
    puede conducir a una @"(accion a distancia) malsana en la que el
    comportamiento de una funcion no esta determinado unicamente por sus
    argumentos, sino por la identidad del hilo en el que se ejecuta. Por lo
    tanto, si la identidad del hilo debe cambiar–algunos hilos de trabajo se
    alistan para ayudar, y–la funcion se comporta de forma misteriosa.

    Go fomenta un estilo de programacion mas simple haciendo explicitos los
    parametros que afectan el comportamiento de una funcion. Esto no solo hace
    que los programas sean mas faciles de leer, sino que nos permite asignar
    libremente subtareas de una funcion dada a muchas gorutinas diferentes sin
    preocuparnos por su identidad.

    Ahora ha aprendido sobre todas las caracteristicas del lenguje que necesita
    para escribir programas Go. En los proximos dos capitulos, retrocederemos
    para ver algunas de las practicas y herramientas que soportan la
    programacion en general: como estructurar un proyecto como un conjunto de
    paquetes, y como obtener, construir, probar, evaluar el rendimiento,
    documentar, y compartir esos paquetes.

* Capitulo 10 <> Paquetes y la Herramienta Go

  A dia de hoy un programa de tamaño modesto podria contener 10.000 funciones.
  Sin embargo, su autor tiene que pensar en solo unas pocas de ellas y el
  diseñar aun menos, porque la gran mayoria fueron escritas por otros y puestas
  a disposicion para su reutilizacion a traves de paquetes.

  Go incluye mas de 100 paquetes estandar que proporcionan las bases para la
  mayoria de las aplicaciones. La comunidad Go, con un prospero ecosistema para
  diseñar, compartir, reutilizar y mejorar paquetes ha publicado muchos mas, y
  usted puede encontrar un indice de busqueda en @l(http://godoc.org). En este
  capitulo, mostraremos como utilizar los paquetes existentes y crear otros
  nuevos.

  Go tambien viene con la herramienta @$(go), un comando sofisticado pero facil
  de usar para gestionar los espacios de trabajo de los paquetes de Go. Desde el
  comienzo del libro, hemos estado mostrando como utilizar la herramienta @$(go)
  para descargar, compilar y ejecutar programas de ejemplo. En este capitulo,
  vamos a ver los conceptos subyacentes de la herramienta y daremos un paseo por
  sus capacidades, que incluyen la impresion de documentacion y la consulta de
  metadatos sobre los paquetes en el espacio de trabajo. En el siguiente
  capitulo vamos a explorar sus caracteristicas para realizar pruebas.

** Seccion 10.1 <> Introduccion

   El proposito de cualquier sistema de paquetes es hacer que el diseño y
   mantenimiento de programas grandes sea practico, agrupando las
   caracteristicas relacionadas en unidades que puedan ser facilmente
   comprendidas y modificadas, independientemente de los otros paquetes del
   programa. Esta @e(modularidad) permite que los paquetes sean compartidos y
   reutilizados por diferentes proyectos, distribuidos dentro de una
   organizacion, o puestos a disposicion del resto del mundo.

   Cada paquete define un espacio de nombre distinto que incluye sus
   identificadores. Cada nombre esta asociado con un paquete en particular, lo
   que nos permite elegir nombres cortos y claros para los tipos, funciones,
   etc., que usamos con mas frecuencia, sin crear conflictos con otras partes
   del programa.

   Los paquetes tambien proporcionan @e(encapsulacion) controlando que nombres
   son visibles o exportados fuera del paquete. La restriccion de la visibilidad
   de los miembros del paquete oculta las funciones y tipos auxiliares de la
   API del paquete, lo que permite al responsable del paquete cambiar la
   implementacion con la confianza de que ningun codigo fuera del paquete se
   vera afectado. Restringir la visibilidad tambien oculta las variables para
   que los clientes puedan acceder y actualizarlas solo mediante funciones
   exportadas que preserven las invariantes internas o impongan la exclusion
   mutua en un programa concurrente.

   Cuando cambiamos un archivo, debemos recompilar el paquete del archivo y
   potencialmente todos los paquetes que dependen de el. La compilacion de Go es
   notablemente mas rapida que la mayoria de los otros lenguajes compilados,
   incluso cuando se construye desde cero. Hay tres razones principales para la
   velocidad del compilador. En primer lugar, todas las importaciones deben
   estar listadas explicitamente al principio de cada archivo de origen, por lo
   que el compilador no tiene que leer y procesar un archivo completo para
   determinar sus dependencias. En segundo lugar, las dependencias de un paquete
   forman un grafo aciclico dirigido, y debido a que no hay ciclos, los paquetes
   pueden ser compilados por separado y tal vez en paralelo. Finalmente, el
   archivo de objeto de un paquete compilado Go registra informacion de
   exportacion no solo para el propio paquete, sino tambien para sus
   dependencias. Al compilar un paquete, el compilador debe leer un archivo
   objeto para cada importacion pero no necesita mirar mas alla de estos
   archivos.

** Seccion 10.2 <> Rutas de Importacion

   Cada paquete esta identificado por una cadena unica denominada su @e(ruta de
   importacion). Las rutas de importacion son las cadenas que aparecen en las
   declaraciones @c(import).

   ..src > go
     import (
       "fmt"
       "math/rand"
       "encoding/json"

       "golang.org/x/net/html"

       "github.com/go-sql-driver/mysql"
     )
   < src..

   Como mencionamos en la @l(#Seccion 2.6.1), la especificacion del lenguaje Go
   no define el significado de estas cadenas o como determinar la ruta de
   importacion de un paquete, sino que deja estas cuestiones a las herramientas.
   En este capitulo, analizaremos con detalle como las interpreta la herramienta
   @$(go), ya que eso es lo que la mayoria de los programadores de Go utilizan
   para construir, probar, etc. Sin embargo, existen otras herramientas. Por
   ejemplo, los programadores de Go que utilizan el sistema de compilacion
   multilenguaje interno de Google siguen reglas diferentes para nombrar y
   localizar paquetes, especificar pruebas y demas, que se ajusten mas a las
   convenciones de ese sistema.

   Para los paquetes que desea compartir o publicar, las vias de acceso de
   importacion deben ser unicas a nivel global. Para evitar conflictos, las
   rutas de importacion de todos los paquetes distintos de los de la biblioteca
   estandar deben comenzar con el nombre de dominio de Internet de la
   organizacion que posee o aloja el paquete; esto tambien hace posible
   encontrar paquetes. Por ejemplo, la declaracion anterior importa un
   analizador HTML mantenido por el equipo Go y un popular controlador de base
   de datos MySQL de terceros.

** Seccion 10.3 <> La Declaracion @c(package)

   En Go se requiere una declaracion @c(package) al inicio de cada archivo
   fuente. Su proposito principal es determinar el identificador por defecto
   para ese paquete (denominado el @e(nombre del paquete)) cuando se importa por
   otro paquete.

   Por ejemplo, todos los archivos del paquete @c(math/rand) comienzan con
   @c(package rand), por lo que al importar este paquete, puede acceder a sus
   miembros como @c(rand.Int), @c(rand.Float64), etc.

   ..src > go
     package main

     import (
       "fmt"
       "math/rand"
     )

     func main() {
       fmt.Println(rand.Int())
     }
   < src..

   Convencionalmente, el nombre del paquete es el ultimo segmento de la ruta de
   importacion y, como resultado, dos paquetes pueden tener el mismo nombre
   aunque sus rutas de importacion difieran necesariamente. Por ejemplo, los
   paquetes cuyas rutas de importacion son @c(math/rand) y @c(crypto/rand)
   tienen el nombre @c(rand). Veremos como usar ambos en el mismo programa en un
   momento.

   Hay tres excepciones principales a la convencion del @"(ultimo segmento). La
   primera es que un paquete que define un comando (un programa ejecutable Go)
   siempre tiene el nombre @c(main), independientemente de la ruta de
   importacion del paquete. Esta es una señal para @$(go build) @%l(#Seccion
   10.7.3<>§10.7.3) que debe invocar el enlazador para crear un archivo
   ejecutable.

   La segunda excepcion es que algunos archivos en el directorio pueden tener el
   sufijo @c(_test) en su nombre de paquete si el nombre del archivo termina con
   @c(_test.go). Un directorio de este tipo puede definir @e(dos) paquetes: el
   habitual, ademas de otro denominado @e(paquete externo de prueba). El sufijo
   @c(_test) indica a @$(go test) que debe construir ambos paquetes, e indica
   que archivos pertenecen a cada paquete. Los paquetes de prueba externos se
   utilizan para evitar ciclos en el grafico de importacion que surgen de las
   dependencias de la prueba; se cubren con mas detalle en la @l(#Seccion
   11.2.4).

   La tercera excepcion es que algunas herramientas para la gestion de
   dependencias añaden sufijos del numero de version a rutas de importacion,
   como @c("gopkg.in/yaml.v2"). El nombre del paquete excluye el sufijo, por lo
   que en este caso seria simplemente @c(yaml).

** Seccion 10.4 <> Declaraciones @c(import)

   Un archivo de codigo Go puede contener cero o mas declaraciones @c(import)
   inmediatamente despues de la declaracion @c(package) y antes de la primera
   declaracion de no importacion. Cada declaracion de importacion puede
   especificar la ruta de importacion de un unico paquete o varios paquetes en
   una lista entre parentesis. Las dos formas a continuacion son equivalentes
   pero la segunda forma es mas comun.

   ..src > go
     import "fmt"
     import "os"
   < src..

   ..src > go
     import (
       "fmt"
       "os"
     )
   < src..

   Los paquetes importados pueden agruparse introduciendo lineas en blanco;
   tales grupos suelen indicar diferentes dominios. El orden no es
   significativo, pero por convencion las lineas de cada grupo se ordenan
   alfabeticamente. (Tanto @$(gofmt) como @$(goimports) las agruparan y
   ordenaran por usted.)

   ..src > go
     import (
       "fmt"
       "html/template"
       "os"

       "golang.org/x/net/html"
       "golang.org/x/net/ipv4"
     )
   < src..

   Si tenemos que importar dos paquetes cuyos nombres son los mismos, como
   @c(math/rand) y @c(crypto/rand), en un tercer paquete, la declaracion de
   importacion debe especificar un nombre alternativo para al menos uno de ellos
   para evitar el conflicto. Esto se denomina @e(renombrar la importacion).

   ..src > go
     import (
       "crypto/rand"
       mrand "math/rand" // el nombre alternativo mrand evita conflictos
     )
   < src..

   El nombre alternativo solo afecta al archivo de importacion. Otros archivos,
   incluso los del mismo paquete, pueden importar el paquete usando su nombre
   predeterminado o un nombre diferente.

   Renombrar una importacion es util incluso cuando no hay conflicto. Si el
   nombre del paquete importado es dificil de manejar, como ocurre a veces con
   el codigo generado automaticamente, es posible que el nombre abreviado sea
   mas conveniente. El mismo nombre abreviado debe ser usado consistentemente
   para evitar confusiones. La eleccion de un nombre alternativo puede ayudar a
   evitar conflictos con nombres de variables locales comunes. Por ejemplo, en
   un archivo con muchas variables locales llamado @c(path), podriamos importar
   el paquete estandar @c("path") como @c(pathpkg).

   Cada declaracion de importacion establece una dependencia del paquete actual
   al paquete importado. La herramienta @$(go build) informara un error si estas
   dependencias forman un ciclo.

** Seccion 10.5 <> Importaciones En Blanco

   Es un error importar un paquete en un archivo pero no hacer referencia al
   nombre que define, dentro de ese archivo. Sin embargo, en ocasiones hay que
   importar un paquete solo por los efectos secundarios de hacerlo: evaluacion
   de las expresiones de inicializador de sus variables y ejecucion de sus
   funciones @c(init) a nivel de paquete @%l(#Seccion 2.6.2<>§2.6.2). Para
   suprimir el error de @"(importacion no utilizada) que encontrariamos de otra
   manera, debemos utilizar una importacion de cambio de nombre en la que el
   nombre alternativo sea @c(_), el identificador en blanco. Como de costumbre,
   el identificador en blanco nunca puede ser referenciado.

   ..src > go
     import _ "image/png" // registra decodificador PNG
   < src..

   Esto se conoce como una @e(importacion en blanco). Se utiliza con mayor
   frecuencia para implementar un mecanismo de tiempo de compilacion mediante el
   cual el programa principal puede habilitar caracteristicas opcionales
   mediante la importacion en blanco de paquetes adicionales. Primero veremos
   como usarlo, luego veremos como funciona.

   El paquete @c(image) de la biblioteca estandar exporta una funcion @c(Decode)
   que lee bytes desde un @c(io.Reader), averigua que formato de imagen se
   utiliza para codificar los datos, invocar el decodificador apropiado, y
   devolver el @c(image.Image) resultante. Usando @c(image.Decode), es facil
   construir un convertidor de imagenes simple que lee una imagen en un formato
   y lo escribe en otro:

   ..figure > @l(gopl.io/ch10/jpeg/main.go<>gopl.io/ch10/jpeg)

     ..src > go
       // El comando jpeg lee una imagen PNG de la entrada estandar
       // y lo escribe como una imagen JPEG en la salida estandar.
       package main

       import (
         "fmt"
         "image"
         "image/jpeg"
         _ "image/png" // registra decodificador PNG
         "io"
         "os"
       )

       func main() {
         if err := toJPEG(os.Stdin, os.Stdout); err != nil {
           fmt.Fprintf(os.Stderr, "jpeg: %v\n", err)
           os.Exit(1)
         }
       }

       func toJPEG(in io.Reader, out io.Writer) error {
         img, kind, err := image.Decode(in)
         if err != nil {
           return err
         }
         fmt.Fprintln(os.Stderr, "Input format =", kind)
         return jpeg.Encode(out, img, &jpeg.Options{Quality: 95})
       }
     < src..


   Si lo alimentamos con la salida de @c(gopl.io/ch3/mandelbrot) @%l(#Seccion
   3.3<>§3.3) al programa convertidor, detecta el formato de entrada PNG y
   escribe una version JPEG de la Figura 3.3.

   ..srci > sh
     > go build gopl.io/ch3/mandelbrot
     > go build gopl.io/ch10/jpeg
     > ./mandelbrot | ./jpeg >mandelbrot.jpg
     Input format = png
   < srci..

   Observe la importacion en blanco de @c(image/png). Sin esa linea, el programa
   compila y vincula como de costumbre, pero ya no puede reconocer o decodificar
   la entrada en formato PNG:

   ..srci > sh
     > go build gopl.io/ch10/jpeg
     > ./mandelbrot | ./jpeg >mandelbrot.jpg
     jpeg: image: unknown format
   < srci..

   Asi es como funciona. La biblioteca estandar ofrece descodificadores para
   GIF, PNG y JPEG, y los usuarios pueden proporcionar otros, pero para mantener
   ejecutables pequeños, los decodificadores no se incluyen en una aplicacion a
   menos que se solicite explicitamente. la funcion @c(image.Decode) consulta
   una tabla de formatos soportados. Cada entrada en la tabla especifica cuatro
   cosas: el nombre del formato; una cadena que es un prefijo de todas las
   imagenes codificadas de esta manera, utilizadas para detectar la
   codificacion; una funcion @c(Decode) que decodifica una imagen codificada; y
   otra funcion @c(DecodeConfig) que decodifica solo los metadatos de la imagen,
   como su tamaño y espacio de color. Se añade una entrada a la tabla llamando a
   @c(image.RegisterFormat), normalmente desde dentro del paquete inicializador
   del paquete de soporte para cada formato, como este en @c(image/png):

   ..src > go
     package png // image/png

     func Decode(r io.Reader) (image.Image, error)
     func DecodeConfig(r io.Reader) (image.Config, error)

     func init() {
       const pngHeader = "\x89PNG\r\n\x1a\n"
       image.RegisterFormat("png", pngHeader, Decode, DecodeConfig)
     }
   < src..

   El efecto es que una aplicacion solo necesita importar el paquete en blanco
   para el formato que necesita, para hacer a la funcion @c(image.Decode) capaz
   de decodificarlo.

   El paquete @c(database/sql) utiliza un mecanismo similar para permitir a los
   usuarios instalar solo los controladores de base de datos que necesita. Por
   ejemplo:

   ..src > go
     import (
       "database/sql"
       _ "github.com/lib/pq"                // habilitira el soporte para Postgres
       _ "github.com/go-sql-driver/mysql"   // habilitira el soporte para MySQL
     )

     db, err = sql.Open("postgres", dbname) // OK
     db, err = sql.Open("mysql", dbname)    // OK
     db, err = sql.Open("sqlite3", dbname)  // devuelve error: controlador desconocido "sqlite3"
   < src..

   @b(Ejercicio 10.1): Extender el programa @$(jpeg) para que convierta
   cualquier formato de entrada compatible con cualquier formato de salida,
   utilizando @c(image.Decode) para detectar el formato de entrada y una bandera
   para seleccionar el formato de salida.

   @b(Ejercicio 10.2): Definir una funcion generica de lectura de archivos capaz
   de leer archivos ZIP (@c(archive/zip)) y archivos tar POSIX (@c(archive/tar)).
   Utilice un mecanismo de registro similar al descrito anteriormente para que
   el soporte de cada formato de archivo se pueda conectar usando importaciones
   en blanco.

** Seccion 10.6 <> Paquetes y Nombres

   En esta seccion, ofreceremos algunos consejos sobre como seguir las
   distintivas convenciones de Go para nombrar paquetes y sus miembros.

   Al crear un paquete, mantenga su nombre corto, pero no tan corto como para
   ser criptico. Los paquetes mas utilizados en la biblioteca estandar se
   nombran @c(bufio), @c(bytes), @c(flag), @c(fmt), @c(http), @c(io), @c(json),
   @c(os), @c(sort), @c(sync) y @c(time).

   Sea descriptivo y sin ambigüedades donde sea posible. Por ejemplo, no nombre
   un paquete de utilidades @c(util) cuando un nombre como @c(imageutil) o
   @c(ioutil) es especifico y aun asi conciso. No se debe elegir nombres de los
   paquetes que se utilizan comunmente para las variables locales relacionados,
   o puede obligar a los clientes del paquete a renombrar las importaciones, al
   igual que con el paquete @c(path).

   Los nombres de los paquetes usualmente toman la forma singular. Los paquetes
   estandar @c(bytes), @c(errors) y @c(strings) utilizan el plural para evitar
   ocultar los tipos predeclarados correspondientes y, en el caso de
   @c(go/types), para evitar conflictos con una palabra clave.

   Evite nombres de paquetes que ya tengan otras connotaciones. Por ejemplo, se
   utilizamos originalmente el nombre @c(temp) para el paquete de conversion de
   temperatura en la @l(#Seccion 2.5), pero eso no duro mucho tiempo. Era una
   idea terrible, porque @"(temp) es un sinonimo casi universal de @"(temporal).
   Pasamos un breve periodo con el nombre @c(temperature), pero era demasiado
   largo y no decia lo que hace el paquete. Al final, se convirtio en
   @c(tempconv), que es mas corto y similar a @c(strconv) .

   Ahora pasemos a la nomenclatura de los miembros del paquete. Puesto que cada
   referencia a un miembro de otro paquete utiliza un identificador calificado
   como @c(fmt.Println), la carga de describir el elemento del paquete es
   soportado igualmente por el nombre del paquete y el nombre del miembro. No
   tenemos que mencionar el concepto de formateo en @c(Println) debido a que el
   nombre del paquete @c(fmt) ya hace eso. Al diseñar un paquete, considere como
   funcionan las dos partes de un identificador cualificado, no solo el nombre
   del miembro. Estos son algunos ejemplos caracteristicos:

   ..pre >
     bytes.Equal     flag.Int     http.Get     json.Marshal

   Podemos identificar algunos patrones de denominacion comunes. El paquete
   @c(strings) proporciona una serie de funciones para manipular cadenas
   independientes:

   ..src > go
     package strings

     func Index(needle, haystack string) int

     type Replacer struct{ /* ... */ }
     func NewReplacer(oldnew ...string) *Replacer

     type Reader struct{ /* ... */ }
     func NewReader(s string) *Reader
   < src..

   La palabra @c(string) no aparece en ninguno de sus nombres. Los clientes se
   refieren a ellos como @c(strings.Index), @c(strings.Replacer), etc.

   Otros paquetes que podriamos describir como paquetes de un solo tipo, como
   @c(html/template) y @c(math/rand), exponen un tipo de datos principal mas sus
   metodos, y con frecuencia una nueva funcion para crear instancias.

   ..src > go
     package rand // "math/rand"

     type Rand struct{ /* ... */ }
     func New(source Source) *Rand
   < src..

   Esto puede conducir a la repeticion, como en @c(template.Template) o
   @c(rand.Rand), por lo que los nombres de estos tipos de paquetes suelen ser
   especialmente cortos.

   En el otro extremo, hay paquetes como @c(net/http) que tienen una gran
   cantidad de nombres sin mucha estructura, ya que desempeñan una tarea
   complicada. A pesar de tener mas de veinte tipos y muchas mas funciones, los
   miembros mas importantes del paquete tienen los nombres mas simples: @c(Get),
   @c(Post), @c(Handle), @c(Error), @c(Client), @c(Server).

** Seccion 10.7 <> La Herramienta Go

   El resto de este capitulo se refiere a la herramienta @$(go), que se utiliza
   para descargar, consultar, formatear, crear, probar e instalar paquetes de
   codigo Go.

   La herramienta @$(go) combina las caracteristicas de un conjunto diverso de
   herramientas en un conjunto de comandos. Es un gestor de paquetes (analogo a
   @$(apt) o @$(rpm)) que responde a consultas sobre su inventario de paquetes,
   calcula sus dependencias y las descarga desde sistemas de control de
   versiones remotos. Es un sistema de construccion que calcula las dependencias
   de archivos e invoca compiladores, ensambladores, enlazadores, aunque es
   intencionalmente menos completo que el @$(make) estandar de Unix. Y es un
   operador de pruebas, como veremos en el @l(#Capitulo 11).

   Su interfaz de linea de comandos utiliza el estilo @"(navaja suiza), con mas
   de una docena de subcomandos, algunos de los cuales ya hemos visto, como
   @c(get), @c(run), @c(build) y @c(fmt). Puede ejecutar @$(go help) para ver el
   indice de la documentacion incorporada, pero como referencia, hemos realizado
   una lista de los comandos mas utilizados a continuacion:

   ..srci > sh
     > go
     ...
         build       compile packages and dependencies
         clean       remove object files
         doc         show documentation for package or symbol
         env         print Go environment information
         fix         run go tool fix on packages
         fmt         run gofmt on package sources
         generate    generate Go files by processing source
         get         download and install packages and dependencies
         install     compile and install packages and dependencies
         list        list packages
         run         compile and run Go program
         test        test packages
         tool        run specified go tool
         version     print Go version
         vet         run go tool vet on packages

     Use "go help [command]" for more information about a command.
     ...
   < srci..

   Para mantener la necesidad de configuracion al minimo, la herramienta @$(go)
   se basa en gran medida en las convenciones. Por ejemplo, dado el nombre de un
   archivo fuente Go, la herramienta puede encontrar su paquete que lo contiene,
   ya que cada directorio contiene un unico paquete y la ruta de importacion de
   un paquete corresponde a la jerarquia de directorios en el espacio de
   trabajo. Dada la ruta de importacion de un paquete, la herramienta puede
   encontrar el directorio correspondiente en el que almacena los archivos
   objeto. Tambien puede encontrar la direccion URL del servidor que aloja el
   repositorio de codigo fuente.

*** Seccion 10.7.1 <> Organizacion del Espacio de Trabajo

    La unica configuracion de la mayoria de los usuarios necesitan es la
    variable de entorno @c(GOPATH), que especifica la raiz del espacio de
    trabajo. Cuando se cambia a otro espacio de trabajo, los usuarios actualizan
    el valor de @c(GOPATH). Por ejemplo, mientras trabajamos en este libro
    establecemos @c(GOPATH) a @c($HOME/gobook):

    ..srci > sh
      > export GOPATH=$HOME/gobook
      > go get gopl.io/...
    < src..

    Despues de descargar todos los programas de este libro utilizando el comando
    anterior, su espacio de trabajo contendra una jerarquia como esta:

    ..pre >
      GOPATH/
            src/
                gopl.io/
                        .git/
                        ch1/
                            helloworld/
                                       main.go
                            dup/
                                main.go
                            ...
                golang.org/x/net/
                                .git/
                                html/
                                    parse.go
                                    node.go
                                    ...
            bin/
                helloworld
                dup
            pkg/
                darwin_amd64/
                ...
    < pre..

    @c(GOPATH) tiene tres subdirectorios. El subdirectorio @f(src) contiene el
    codigo fuente. Cada paquete reside en un directorio cuyo nombre en relacion
    con @c($GOPATH/src) es la ruta de importacion del paquete, como
    @c(gopl.io/ch1/helloworld). Observe que un solo espacio de trabajo
    @c(GOPATH) contiene multiples repositorios con control de versiones debajo
    de @f(src), como @c(gopl.io) o @c(golang.org). El subdirectorio @f(pkg) es
    donde las herramientas de construccion almacenan paquetes compilados, y el
    subdirectorio @f(bin) contiene los programas ejecutables como
    @$(helloworld).

    Una segunda variable de entorno, @$(GOROOT), especifica el directorio raiz
    de la distribucion Go, que ofrece todos los paquetes de la biblioteca
    estandar. La estructura de directorios debajo de @c(GOROOT) es analoga a
    @c(GOPATH), por lo que, por ejemplo, los archivos de origen del paquete
    @c(fmt) residen en el directorio @c($GOROOT/src/fmt). Los usuarios no
    necesitan configurar @c(GOROOT) ya que, por defecto, la herramienta @$(go)
    utilizara la ubicacion donde se instalo.

    El comando @$(go env) imprime los valores efectivos de las variables de
    entorno correspondientes a la cadena de herramientas, incluidos los valores
    por defecto para los que faltan. @c(GOOS) especifica el sistema operativo de
    destino (por ejemplo, @c(android), @c(linux), @c(darwin), o @c(windows)) y
    @c(GOARCH) especifica la arquitectura de procesador objetivo, como
    @c(amd64), @c(386), o @c(arm). Aunque @c(GOPATH) es la unica variable que
    debe establecer, los demas de vez en cuando aparecen en nuestras
    explicaciones.

    ..srci > sh
      > go env
      GOPATH="/home/gopher/gobook"
      GOROOT="/usr/local/go"
      GOARCH="amd64"
      GOOS="darwin"
    < srci..

*** Seccion 10.7.2 <> Descargando paquetes

    Cuando se utiliza la herramienta @$(go), la ruta de importacion de un paquete
    indica no solo donde encontrarlo en el espacio de trabajo local, sino donde
    encontrarlo en Internet para que @$(go get) pueda recuperarlo y actualizarlo.

    El comando @$(go get) puede descargar un solo paquete o todo un subarbol o
    repositorio usando la notacion @c(...), como en la seccion anterior. La
    herramienta tambien calcula y descarga todas las dependencias de los
    paquetes iniciales, como el paquete @c(golang.org/x/net/html) que aparecio
    en el espacio de trabajo en el ejemplo anterior.

    Una vez que @$(go get) ha descargado los paquetes, los construye y luego
    instala las librerias y comandos. Veremos los detalles en la siguiente
    seccion, pero un ejemplo mostrara lo sencillo que es el proceso. El primer
    comando a continuacion optiene la herramienta @$(golint), que comprueba si
    hay problemas de estilo comunes en codigo fuente Go. El segundo comando
    ejecuta @$(golint) en @c(gopl.io/ch2/popcount) de la @l(#Seccion 2.6.2). Es
    util que nos informe que hemos olvidado escribir un comentario de
    documentacion para el paquete:

    ..srci > sh
      > go get github.com/golang/lint/golint
      > $GOPATH/bin/golint gopl.io/ch2/popcount
      src/gopl.io/ch2/popcount/main.go:1:1:
        package comment should be of the form "Package popcount ..."
    < srci..

    El comando @$(go get) tiene soporte para los sitios de alojamiento de codigo
    populares como GitHub, Bitbucket y Launchpad y puede hacer las solicitudes
    apropiadas en sus sistemas de control de versiones. Para sitios menos
    conocidos, es posible que deba indicar que protocolo de control de versiones
    debe utilizar en la ruta de importacion, como Git o Mercurial. Ejecuta @$(go
    help importpath) para los detalles.

    Los directorios que @$(go get) crea son verdaderos clientes del repositorio
    remoto, no solo copias de los archivos, por lo que puede utilizar los
    comandos de control de versiones para ver una comparacion de las ediciones
    locales que ha realizado o para actualizar a una revision diferente. Por
    ejemplo, el directorio @f(golang.org/x/net) es un cliente Git:

    ..srci > sh
      > cd $GOPATH/src/golang.org/x/net
      > git remote -v
      origin  https://go.googlesource.com/net (fetch)
      origin  https://go.googlesource.com/net (push)
    < srci..

    Observe que el nombre de dominio en la ruta de importacion del paquete,
    @c(golang.org), difiere del nombre de dominio real del servidor Git,
    @c(go.googlesource.com). Esta es una caracteristica de la herramienta Go que
    permite que los paquetes usen un nombre de dominio personalizado en su ruta
    de importacion al ser alojados por un servicio generico como
    @l(https://googlesource.com) o @l(https://github.com). Las paginas HTML
    debajo de @l(https://golang.org/x/net/html) incluyen los metadatos que se
    muestran a continuacion, que redirecciona la herramienta @$(go) al
    repositorio Git en el lugar del alojamiento actual:

    ..srci > sh
      > go build gopl.io/ch1/fetch
      > ./fetch https://golang.org/x/net/html | grep go-import
      <meta name="go-import" content="golang.org/x/net git https://go.googlesource.com/net">
    < srci..

    Si especifica la bandera @c(-u), @$(go get) se asegurara de que todos los
    paquetes que visita, incluidas las dependencias, se actualizan a su ultima
    version antes de ser construido e instalado. Sin ese indicador, los paquetes
    que ya existen localmente no se actualizaran.

    El comando @$(go get -u) recupera generalmente la ultima version de cada
    paquete, lo cual es conveniente cuando se inicia, pero puede ser inadecuado
    para proyectos desplegados, donde el control preciso de dependencias es
    critico para la higiene de los lanzamientos. La solucion habitual a este
    problema es el @e(proveedor) del codigo, es decir, hacer una copia local
    persistente de todas las dependencias necesarias, para actualizar esta copia
    cuidadosa y deliberadamente. Antes de Go 1.5, esto requiere cambiar las
    rutas de importacion de esos paquetes, por lo que nuestra copia de
    @c(golang.org/x/net/html) se convertiria en
    @c(gopl.io/vendor/golang.org/x/net/html). Las versiones mas recientes de la
    herramienta soportan directorios de proveedores directamente, aunque no
    tenemos espacio para mostrar los detalles aqui. Vea @e(Directorios de
    Proveedores) en la salida del comando @$(go help gopath).

    @b(Ejercicio 10.3): Utilizando @$(fetch http://gopl.io/ch1/helloworld?go-get=1),
    averigüe que servicio alberga los ejemplos de codigo para este libro.  (Las
    peticiones HTTP de @$(go get) incluyen el parametro @c(go-get) para que los
    servidores pueden distinguirlos de las solicitudes del navegador comun.)

*** Seccion 10.7.3 <> Construccion de Paquetes

    El comando @$(go build) compila cada argumento de paquete. Si el paquete es
    una libreria, el resultado se descarta; esto simplemente comprueba que el
    paquete esta libre de errores de compilacion. Si el paquete se llama
    @c(main), @$(go build) invoca el enlazador para crear un archivo ejecutable
    en el directorio actual; el nombre del ejecutable se toma del ultimo
    segmento de la ruta de importacion del paquete.

    Dado que cada directorio contiene un solo paquete, cada programa ejecutable,
    o @e(comando) en la terminologia Unix, requiere su propio directorio. Estos
    directorios son a veces los hijos de un directorio denominado @c(cmd), como
    el comando @c(golang.org/x/tools/cmd/godoc) que sirve la documentacion del
    paquete Go a traves de una interfaz web @%l(#Seccion 10.7.4<>§10.7.4).

    Los paquetes pueden especificarse por sus rutas de importacion, como hemos
    visto anteriormente, o por un nombre de directorio relativo, que debe
    comenzar con un @c(.) o @c(..) incluso si esto no se requere normalmente. Si
    no se proporciona ningun argumento, se supone el directorio actual. Por lo
    tanto los siguientes comandos construyen el mismo paquete, aunque cada uno
    escribe el ejecutable en el directorio en el que @$(go build) se ejecuta:

    ..srci > sh
      > cd $GOPATH/src/gopl.io/ch1/helloworld
      > go build
    < srci..

    y:

    ..srci > sh
      > cd cualquier-sitio
      > go build gopl.io/ch1/helloworld
    < srci..

    y:

    ..srci > sh
      > cd $GOPATH
      > go build ./src/gopl.io/ch1/helloworld
    < srci..

    pero no:

    ..srci > sh
      > cd $GOPATH
      > go build src/gopl.io/ch1/helloworld
      Error: cannot find package "src/gopl.io/ch1/helloworld".
    < srci..

    Los paquetes tambien se pueden especificar como una lista de nombres de
    archivo, aunque esto tiende a utilizarse solo para programas pequeños y
    experimentos puntuales. Si el nombre del paquete es @c(main), el nombre del
    ejecutable viene del nombre base del primer archivo @f(.go).

    ..srci > sh
      > cat quoteargs.go
      package main

      import (
        "fmt"
        "os"
      )

      func main() {
        fmt.Printf("%q\n", os.Args[1:])
      }
      > go build quoteargs.go
      > ./quoteargs one "two three" four\ five
      ["one" "two three" "four five"]
    < srci..

    Especialmente para programas descartables como este, queremos ejecutar el
    archivo ejecutable tan pronto como lo hayamos construido. El comando @$(go
    run) combina estos dos pasos:

    ..srci > sh
      > go run quoteargs.go one "two three" four\ five
      ["one" "two three" "four five"]
    < srci..

    El primer argumento que no termina en @f(.go) se asume como el principio de
    la lista de argumentos para el ejecutable de Go.

    Por defecto, el comando @$(go build) construye el paquete solicitado y todas
    sus dependencias, y luego tira a la basura todo el codigo compilado, excepto
    el ejecutable final, si lo hubiera. Tanto el analisis de dependencias como
    la compilacion son sorprendentemente rapidos, pero a medida que los
    proyectos crecen hasta decenas de paquetes y cientos de miles de lineas de
    codigo, el tiempo para recompilar las dependencias puede llegar a ser
    notable, potencialmente varios segundos, incluso cuando no todas las
    dependencias han cambiado.

    El comando @$(go install) es muy similar a @$(go build), excepto que guarda
    el codigo compilado para cada paquete y comando en lugar de tirarlo a la
    basura. Los paquetes compilados se guardan bajo el directorio
    @f($GOPATH/pkg) correspondiente al directorio @f(src) en el que reside el
    codigo fuente y los ejecutables de comando se guardan en el directorio
    @f($GOPATH/bin). (Muchos usuarios agregan @f($GOPATH/bin) en su ruta de
    busqueda ejecutable.) A partir de entonces, @$(go build) y @$(go install) no
    ejecutan el compilador para esos paquetes y comandos si no han cambiado,
    haciendo las compilaciones posteriores mucho mas rapido. Por conveniencia,
    @$(go build -i) instala los paquetes que son dependencias del objetivo a
    compilar.

    Dado que los paquetes compilados varian segun la plataforma y la
    arquitectura, @$(go install) los guarda debajo de un subdirectorio cuyo
    nombre incorpora los valores de las variables de entorno @c(GOOS) y
    @c(GOARCH). Por ejemplo, en un Mac el paquete @c(golang.org/x/net/html) se
    compila e instala en el archivo @f(golang.org/x/net/html.a) bajo
    @f($GOPATH/pkg/darwin_amd64).

    Es facil aplicar @e(compilacion cruzada) a un programa Go, es decir,
    construir un ejecutable destinado a un sistema operativo o CPU diferente.
    Solo hay que establecer las variables @c(GOOS) o @c(GOARCH) durante la
    construccion. El programa @$(cross) imprime el sistema operativo y la
    arquitectura para la que fue construido:

    ..figure > @l(gopl.io/ch10/cross/main.go<>gopl.io/ch10/cross)

      ..src > go
        func main() {
          fmt.Println(runtime.GOOS, runtime.GOARCH)
        }
      < src..


    Los comandos siguientes producen ejecutables de 64 y 32 bits,
    respectivamente:

    ..srci > sh
      > go build gopl.io/ch10/cross
      > ./cross
      darwin amd64
      > GOARCH=386 go build gopl.io/ch10/cross
      > ./cross
      darwin 386
    < srci..

    Algunos paquetes pueden necesitar compilar versiones diferentes del codigo
    para ciertas plataformas o procesadores, para tratar problemas de
    portabilidad de bajo nivel o para proporcionar versiones optimizadas de
    rutinas importantes, por ejemplo. Si un nombre de archivo incluye un sistema
    operativo o arquitectura de procesador, como @f(net_linux.go) o
    @f(asm_amd64.s), la herramienta @$(go) compilara el archivo solo cuando se
    construye para ese objetivo. Comentarios especiales llamados @e(etiquetas de
    compilacion) ofrecen un control mas detallado. Por ejemplo, si un archivo
    contiene este comentario:

    ..src > go
      // +build linux darwin
    < src..

    antes de la declaracion del paquete (y su comentario de documentacion),
    @$(go build) compilara solo cuando se compile para Linux o Mac OS X, y este
    comentario indica nunca compilar el archivo:

    ..src > go
      // +build ignore
    < src..

    Para mas detalles, consulte la seccion @e(Build Constraints) de la
    documentacion del paquete @c(go/build):

    ..srci > sh
      > go doc go/build
    < srci..

*** Seccion 10.7.4 <> Documentacion de Paquetes

    El estilo Go anima fuertemente la buena documentacion de las API del
    paquete. Cada declaracion de un miembro del paquete exportado y la propia
    declaracion del paquete deben ir precedidas inmediatamente de un comentario
    que explique su proposito y uso.

    Los @e(comentarios de documentacion) de Go siempre son oraciones completas,
    y la primera frase es por lo general un resumen que se inicia con el nombre
    que se declaro. Los parametros de funcion y otros identificadores se
    mencionan sin citacion o marcado. Por ejemplo, aqui esta el comentario de
    documentacion para @c(fmt.Fprintf):

    ..src > go
      // Fprintf formateo de acuerdo con un especificador de formato y escrib en w.
      // Devuelve el numero de bytes escritos y cualquier error de escritura encontrado.
      func Fprintf(w io.Writer, format string, a ...interface{}) (int, error)
    < src..

    Los detalles del formateo de @c(Fprintf) se explican en un comentario de
    documentacion asociado al paquete @c(fmt) en si. Un comentario que precede
    inmediatamente a una declaracion @c(package) se considera el comentario de
    documentacion para el paquete en su conjunto. Solo debe haber uno, aunque
    puede aparecer en cualquier archivo. Los comentarios de paquetes mas largos
    pueden justificar un archivo propio; @c(fmt) tiene mas de 300 lineas. Este
    archivo normalmente se llama @f(doc.go) .

    Una buena documentacion no necesita ser extensa, y la documentacion no es un
    sustituto de la sencillez. De hecho, las convenciones de Go favorecen la
    brevedad y simplicidad en la documentacion como en todas las cosas, ya que
    la documentacion, como el codigo, tambien requiere mantenimiento. Muchas
    declaraciones se pueden explicar en una oracion bien redactada, y si el
    comportamiento es realmente obvio, no necesita comentarse. A lo largo del
    libro, a medida que el espacio lo permite, hemos precedido a muchas
    declaraciones por comentarios de documentacion, pero encontraremos mejores
    ejemplos buscando en la biblioteca estandar. Dos herramientas pueden
    ayudarte a hacer eso.

    La herramienta @$(go doc) imprime la declaracion y el comentario de
    documentacion de la entidad especificada en la linea de comandos, que puede
    ser un paquete:

    ..srci > sh
      > go doc time
      package time // import "time"

      Package time provides functionality for measuring and displaying time.

      const Nanosecond Duration = 1 ...
      func After(d Duration) <-chan Time
      func Sleep(d Duration)
      func Since(t Time) Duration
      func Now() Time
      type Duration int64
      type Time struct { ... }
      ...mucho mas...
    < srci..

    O un miembro del paquete:

    ..srci > sh
      > go doc time.Since
      func Since(t Time) Duration

          Since returns the time elapsed since t.
          It is shorthand for time.Now().Sub(t).
    < srci..

    O un metodo:

    ..srci > sh
      > go doc time.Duration.Seconds
      func (d Duration) Seconds() float64

          Seconds returns the duration as a floating-point number of seconds.
    < srci..

    La herramienta no necesita rutas de importacion completas o letras
    mayusculas y minusculas del identificador exactas. Este comando imprime la
    documentacion de @c[(*json.Decoder).Decode] del paquete @c(encoding/json):

    ..srci > sh
      > go doc json.decode
      func (dec *Decoder) Decode(v interface{}) error

          Decode reads the next JSON-encoded value from its input and stores
          it in the value pointed to by v.
    < srci..

    La segunda herramienta, confusamente nombrada @$(godoc), sirve paginas HTML
    entre-enlazadas que proporcionan la misma informacion que @$(go doc) y mucho
    mas. El servidor @$(godoc) en @l(https://golang.org/pkg) cubre la biblioteca
    estandar. La Figura 10.1 muestra la documentacion del paquete @c(time), y en
    la @l(#Seccion 11.6) veremos la pantalla interactiva de @$(godoc) de
    programas de ejemplo. El servidor @$(godoc) en @l(https://godoc.org) tiene
    un indice de busqueda de miles de paquetes de codigo abierto.

    Tambien puede ejecutar una instancia de @$(godoc) en su espacio de trabajo
    si desea navegar por sus propios paquetes. Visite @l(http://localhost:8000/pkg)
    en su navegador mientras se ejecuta este comando:

    ..srci > sh
      > godoc -http=:8000
    < srci..

    Sus banderas @c(-analysis=type) y @c(-analysis=pointer) aumentan la
    documentacion y el codigo fuente con resultados del analisis estatico
    avanzado.

*** Seccion 10.7.5 <> Paquetes Internos

    El paquete es el mecanismo mas importante para la encapsulacion en programas
    Go. Los identificadores sin exportacion son visibles solo dentro del mismo
    paquete, y los identificadores exportados son visibles para el mundo.

    A veces, sin embargo, el camino medio seria util, una forma de definir
    identificadores que son visibles para un pequeño conjunto de paquetes de
    confianza, pero no para todos. Por ejemplo, cuando estamos dividiendo un
    paquete grande en partes mas manejables, es posible que no deseemos revelar
    las interfaces entre esas partes a otros paquetes. O quizas queramos
    compartir funciones de utilidad entre varios paquetes de un proyecto sin
    exponerlos mas ampliamente. O tal vez solo queremos experimentar con un
    nuevo paquete sin comprometerse prematuramente con su API, poniendolo @"(a
    prueba) con un conjunto limitado de clientes.

    ..figure > Figura 10.1. El paquete @c(time) en @$(godoc).

      ..img  > img/Figure-10.1.jpg

    Para hacer frente a estas necesidades, la herramienta @$(go build) maneja
    un paquete de forma especial si su ruta de importacion contiene un segmento
    de ruta denominado @c(interno). Dichos paquetes se denominan @e(paquetes
    internos). Un paquete interno puede ser importado por otro paquete que esta
    dentro del arbol raiz en el paquete del directorio @c(internal). Por
    ejemplo, los paquetes a continuacion, @c(net/http/internal/chunked) pueden
    ser importados de @c(net/http/httputil) o @c(net/http), pero no de
    @c(net/url). Sin embargo, @c(net/url) puede importar @c(net/http/httputil).

    ..pre >
      net/http
      net/http/internal/chunked
      net/http/httputil
      net/url

*** Seccion 10.7.6 <> Consultando Paquetes

    La herramienta @$(go list) reporta informacion sobre los paquetes
    disponibles. En su forma mas simple, @$(go list) comprueba si un paquete
    esta presente en el espacio de trabajo e imprime su ruta de importacion si
    es asi:

    ..srci > sh
      > go list github.com/go-sql-driver/mysql
      github.com/go-sql-driver/mysql
    < srci..

    Un argumento para @$(go list) puede contener el comodin @"c(...), que
    coincide con cualquier subcadena de ruta de importacion de un paquete.
    Podemos usarlo para enumerar todos los paquetes dentro de un espacio de
    trabajo Go:

    ..srci > sh
      > go list ...
      archive/tar
      archive/zip
      bufio
      bytes
      cmd/addr2line
      cmd/api
      ...mucho mas...
    < srci..

    O dentro de un subarbol especifico:

    ..srci > sh
      > go list gopl.io/ch3/...
      gopl.io/ch3/basename1
      gopl.io/ch3/basename2
      gopl.io/ch3/comma
      gopl.io/ch3/mandelbrot
      gopl.io/ch3/netflag
      gopl.io/ch3/printints
      gopl.io/ch3/surface
    < srci..

    O relacionados con un tema particular:

    ..srci > sh
      > go list ...xml...
      encoding/xml
      gopl.io/ch7/xmlselect
    < srci..

    El comando @$(go list) obtiene los metadatos completos de cada paquete, no
    solo la ruta de importacion, y pone esta informacion a disposicion de los
    usuarios u otras herramientas en una variedad de formatos. La bandera
    @c(-json) proboca que @$(go list) imprima el registro completo de cada
    paquete en formato JSON:

    ..srci > sh
      > go list -json hash
      {
          "Dir": "/home/gopher/go/src/hash",
          "ImportPath": "hash",
          "Name": "hash",
          "Doc": "Package hash provides interfaces for hash functions.",
          "Target": "/home/gopher/go/pkg/darwin_amd64/hash.a",
          "Goroot": true,
          "Standard": true,
          "Root": "/home/gopher/go",
          "GoFiles": [
                 "hash.go"
          ],
          "Imports": [
              "io"
          ],
          "Deps": [
              "errors",
              "io",
              "runtime",
              "sync",
              "sync/atomic",
              "unsafe"
          ]
      }
    < srci..

    La bandera @c(-f) permite a los usuarios personalizar el formato de salida
    utilizando el lenguaje de la plantilla del paquete @c(text/template)
    @%l(#Seccion 4.6<>§4.6). Este comando imprime las dependencias transitivas
    del paquete @c(strconv), separados por espacios:

    ..srci > sh
      > go list -f '{{join .Deps " "}}' strconv
      errors math runtime unicode/utf8 unsafe
    < srci..

    y el comando muestra las importaciones directas de cada paquete en el
    subarbol @c(compress) de la biblioteca estandar:

    ..srci > sh
      > go list -f '{{.ImportPath}} -> {{join .Imports " "}}' compress/...
      compress/bzip2 -> bufio io sort
      compress/flate -> bufio fmt io math sort strconv
      compress/gzip -> bufio compress/flate errors fmt hash hash/crc32 io time
      compress/lzw -> bufio errors fmt io
      compress/zlib -> bufio compress/flate errors fmt hash hash/adler32 io
    < srci..

    El comando @$(go list) es util tanto para consultas interactivas puntuales y
    para scripts de construccion y automatizacion de pruebas. Lo volveremos a
    utilizar en la @l(#Seccion 11.2.4). Para obtener mas informacion, incluyendo
    el conjunto de campos disponibles y su significado, ver la salida de
    @$(go help list).

    En este capitulo, hemos explicado todos los subcomandos importantes de la
    herramientas @$(go) excepto uno. En el siguiente capitulo, veremos como se
    utiliza el comando @$(go test) para probar programas Go.

    @b(Ejercicio 10.4): Construir una herramienta que reporte el conjunto de
    todos los paquetes en el espacio de trabajo que dependen de forma transitiva
    de los paquetes especificados por los argumentos. Sugerencia: tendra que ejecutar
    @$(go list) dos veces, una para los paquetes iniciales y una vez para todos los
    paquetes. Es posible que desee analizar su salida JSON utilizando el paquete
    @c(encoding/json) @%l(#Seccion 4.5<>§4.5).

* Capitulo 11 <> Pruebas

  Maurice Wilkes, el desarrollador de EDSAC, el primer computador con programa
  almacenado, tevo una vision sorprendente mientras subia las escaleras de su
  laboratorio en 1949. En @e(Memoirs of a Computer Pioneer), recordo, @"(La
  realizacion se me vino con toda la fuerza que una buena Parte del resto de mi
  vida iba a ser gastada en encontrar errores en mis propios programas.)
  Seguramente cada programador de una computadora con programas almacenados
  desde entonces puede simpatizar con Wilkes, aunque tal vez no sin algo de
  desconcierto en su ingenuidad sobre las dificultades de la construccion de
  software.

  Los programas de hoy son mucho mas grandes y complejos que en el tiempo de
  Wilkes, por supuesto, y se ha dedicado mucho esfuerzo a tecnicas para hacer
  que esta complejidad sea manejable. Dos tecnicas en particular destacan por su
  eficacia. La primera es la revision por pares de los programas antes de que se
  desplieguen. El segundo, el tema de este capitulo, son las pruebas.

  Las pruebas, que implican implicitamente pruebas @e(automatizadas), es la
  practica de escribir pequeños programas que comprueban que el codigo bajo
  prueba (el codigo de @e(produccion)) se comporta como se esperaba para ciertas
  entradas, que suelen ser cuidadosamente elegidas para ejercer ciertas
  funciones o al azar para asegurar amplia cobertura.

  El campo de las pruebas de software es enorme. La tarea del testeo ocupa a
  todos los programadores en parte del tiempo y algunos programadores todo el
  tiempo. La literatura sobre las pruebas incluye miles de libros impresos y
  millones de palabras publicadas en blogs. En todos los lenguajes de
  programacion, hay docenas de paquetes de software destinados a la construccion
  de pruebas, algunos con una gran cantidad de teoria, y el campo parece atraer
  a mas de unos pocos profetas con seguidores que lo hacen parecer un culto. Es
  casi suficiente para convencer a los programadores de que para escribir
  pruebas efectivas deben adquirir un nuevo conjunto de habilidades.

  La aproximacion de Go a las pruebas puede parecer de baja tecnologia en
  comparacion. Se basa en un solo comando, @$(go test), y un conjunto de
  convenciones para escribir funciones de prueba que @$(go test) puede
  ejecutar. El mecanismo relativamente ligero es efectivo para pruebas puras, y
  se extiende naturalmente a puntos de referencia y ejemplos sistematicos para
  la documentacion.

  En la practica, escribir codigo de prueba no es muy diferente de escribir el
  programa original en si. Escribimos funciones cortas que se centran en una
  parte de la tarea. Debemos tener cuidado con las condiciones limites, pensar
  en las estructuras de datos y razonar sobre los resultados que un calculo debe
  producir a partir de entradas adecuadas. Pero este es el mismo proceso que
  escribir codigo Go ordinario; no requiere nuevas anotaciones, convenciones o
  herramientas.

** Seccion 11.1 <> La Herramienta @$(go test)

   El subcomando @$(go test) es un controlador de pruebas para paquetes Go que
   se organizan de acuerdo con ciertas convenciones. En un directorio de
   paquetes, los archivos cuyos nombres terminan con @f(_test.go) no son parte
   del paquete normalmente construido por @$(go build) sino que son una parte de
   el cuando se construyen mediante @$(go test).

   Dentro de archivos @f(*_test.go), tres tipos de funciones se tratan de forma
   especial: pruebas, benchmarks, y ejemplos. Una @e(funcion de prueba), es una
   funcion cuyo nombre comienza con @c(Test), ejerce cierta logica del programa
   para el comportamiento correcto; @$(go test) llama a la funcion de prueba e
   informa del resultado, que es @c(PASS) o @c(FAIL). Una funcion de benchmark
   tiene un nombre que comienza con @c(Benchmark) y mide el rendimiento de una
   operacion; @$(go test) informes el tiempo de ejecucion medio de la
   operacion. Y una funcion de ejemplo, cuyo nombre empieza por @c(Example),
   proporciona documentacion revisada por la maquina. Vamos a cubrir las pruebas
   en detalle en la @l(#Seccion 11.2), los benchmarks en la @l(#Seccion 11.4), y
   los ejemplos en la @l(#Seccion 11.6).

   La heramienta @$(go test) examina los archivos @f(*_test.go) para estas
   funciones especiales, genera un paquete @c(main) temporal que hace todas las
   llamadas de manera apropiada, compila y ejecuta, informa de los resultados, y
   luego se limpia.

** Seccion 11.2 <> Funciones @c(Test)

   Cada archivo de prueba debe importar el paquete @c(testing). Las funciones de
   prueba tienen la siguiente firma:

   ..src > go
     func TestNormbre(t *testing.T) {
       // ...
     }
   < src..

   Los nombres de las funciones de prueba deben comenzar con @c(Test); el sufijo
   opcional @e(Nombre) debe comenzar con una letra mayuscula:

   ..src > go
     func TestSin(t *testing.T) { /* ... */ }
     func TestCos(t *testing.T) { /* ... */ }
     func TestLog(t *testing.T) { /* ... */ }
   < src..

   El parametro @c(t) proporciona metodos para informar fallos de las pruebas y
   registrar informacion adicional. Vamos a definir un paquete de ejemplo
   @c(gopl.io/ch11/word1), que contiene una sola funcion @c(IsPalindrome) que
   informa si una cadena se lee igual hacia adelante y hacia atras. (Esta
   implementacion prueba cada byte dos veces si la cadena es un palindromo,
   volveremos a esto en breve).

   ..figure > @l(gopl.io/ch11/word1/word.go<>gopl.io/ch11/word1)

     ..src > go
       // El paquete word proporciona utilidades para juegos de palabras.
       package word

       // IsPalindrome informa si s se lee igual hacia adelante y hacia atras.
       // (Nuestro primer intento.)
       func IsPalindrome(s string) bool {
         for i := range s {
           if s[i] != s[len(s)-1-i] {
             return false
           }
         }
         return true
       }
     < src..


   En el mismo directorio, el archivo @f(word_test.go) contiene dos funciones de
   prueba con nombre @c(TestPalindrome) y @c(TestNonPalindrome). Cada uno
   comprueba que @c(IsPalindrome) da la respuesta correcta para una entrada
   unica e informa fallos utilizando @c(t.Error):

   ..src > go
     package word

     import "testing"

     func TestPalindrome(t *testing.T) {
       if !IsPalindrome("detartrated") {
         t.Error(`IsPalindrome("detartrated") = false`)
       }
       if !IsPalindrome("kayak") {
         t.Error(`IsPalindrome("kayak") = false`)
       }
     }

     func TestNonPalindrome(t *testing.T) {
       if IsPalindrome("palindrome") {
         t.Error(`IsPalindrome("palindrome") = true`)
       }
     }
   < src..

   Una comando @$(go test) (o @$(go build)) sin argumentos de paquete opera
   sobre el paquete en el directorio actual. Podemos construir y ejecutar las
   pruebas con el siguiente comando.

   ..srci > sh
     > cd $GOPATH/src/gopl.io/ch11/word1
     > go test
     ok   gopl.io/ch11/word1 0.008s
   < srci..

   Satisfecho, enviamos el programa, pero no antes de que los invitados de la
   fiesta envien los informes de error iniciales. Un usuario frances llamado
   Noelle Eva Elleon se queja de que IsPalindrome no reconoce @"(été). Otro, de
   Centroamerica, se siente decepcionado al denegar @"(A man, a plan, a canal:
   Panama). Estos informes de errores especificos y pequeños naturalmente se
   prestan a nuevos casos de prueba.

   ..src > go
     func TestFrenchPalindrome(t *testing.T) {
       if !IsPalindrome("été") {
         t.Error(`IsPalindrome("été") = false`)
       }
     }
     func TestCanalPalindrome(t *testing.T) {
       input := "A man, a plan, a canal: Panama"
       if !IsPalindrome(input) {
         t.Errorf(`IsPalindrome(%q) = false`, input)
       }
     }
   < src..

   Para evitar la larga cadena de entrada dos veces, utilizamos @c(Errorf), que
   proporciona formateo, como @c(Printf).

   Cuando se han añadido las dos nuevas pruebas, el comando @$(go test) falla
   con mensajes informativos de error.

   ..srci > sh
     > go test
     --- FAIL: TestFrenchPalindrome (0.00s)
         word_test.go:28: IsPalindrome("été") = false
     --- FAIL: TestCanalPalindrome (0.00s)
         word_test.go:35: IsPalindrome("A man, a plan, a canal: Panama") = false
     FAIL
     FAIL    gopl.io/ch11/word1 0.014s
   < srci..

   Es recomendable escribir la prueba primero y observar que desencadena el
   mismo fallo descrito por el informe de error del usuario. Solo entonces
   podremos estar seguros de que cualquier solucion que hagamos concierne al
   problema correcto.

   Como beneficio adicional, ejecutar @$(go test) generalmente es mas rapido que
   ejecutar manualmente los pasos descritos en el informe de errores, lo que nos
   permite iterar mas rapidamente. Si la suite de pruebas contiene muchas
   pruebas lentas, podemos hacer un progreso aun mas rapido si somos selectivos
   sobre cuales corremos.

   La bandera @c(-v) imprime el nombre y el tiempo de ejecucion de cada prueba
   en el paquete:

   ..srci > sh
     > go test -v
     === RUN TestPalindrome
     --- PASS: TestPalindrome (0.00s)
     === RUN TestNonPalindrome
     --- PASS: TestNonPalindrome (0.00s)
     === RUN TestFrenchPalindrome
     --- FAIL: TestFrenchPalindrome (0.00s)
     word_test.go:28: IsPalindrome("été") = false
     === RUN TestCanalPalindrome
     --- FAIL: TestCanalPalindrome (0.00s)
     word_test.go:35: IsPalindrome("A man, a plan, a canal: Panama") = false
     FAIL
     exit status 1
     FAIL    gopl.io/ch11/word1 0.017s
   < srci..

   y la bandera @c(-run), cuyo argumento es una expresion regular, hace que
   @$(go test) ejecute solo aquellas pruebas cuyo nombre de funcion coincide con
   el patron:

   ..srci > sh
     > go test -v -run="French|Canal"
     === RUN TestFrenchPalindrome
     --- FAIL: TestFrenchPalindrome (0.00s)
     word_test.go:28: IsPalindrome("été") = false
     === RUN TestCanalPalindrome
     --- FAIL: TestCanalPalindrome (0.00s)
     word_test.go:35: IsPalindrome("A man, a plan, a canal: Panama") = false
     FAIL
     exit status 1
     FAIL    gopl.io/ch11/word1 0.014s
   < srci..

   Por supuesto, una vez que hemos conseguido que las pruebas seleccionadas
   pasen, debemos invocar a @$(go test) sin banderas para ejecutar el conjunto
   de pruebas entero una ultima vez antes de que confirme el cambio.

   Ahora nuestra tarea es arreglar los errores. Una rapida investigacion revela
   la causa del primer fallo en @c(IsPalindrome) esta en utilizar secuencias de
   bytes, no secuencias de runas, por lo que los caracteres no ASCII, como la
   @c(é) en @c("été") lo confunden. El segundo error surge de no ignorar entre
   mayusculas y minusculas, espacios y signos de puntuacion.

   reescribimos la funcion con mas cuidado:

   ..figure > @l(gopl.io/ch11/word2/word.go<>gopl.io/ch11/word2)

     ..src > go
       // El paquete word proporciona utilidades para juegos de palabras.
       package word

       import "unicode"

       // IsPalindrome informa si s se lee igual hacia adelante y hacia atras.
       // Se ignora entre mayusculas y minusculas, al igual que las no-letras.
       func IsPalindrome(s string) bool {
         var letters []rune
         for _, r := range s {
           if unicode.IsLetter(r) {
             letters = append(letters, unicode.ToLower(r))
           }
         }
         for i := range letters {
           if letters[i] != letters[len(letters)-1-i] {
             return false
           }
         }
         return true
       }
     < src..


   Tambien escribimos un conjunto mas completo de casos de prueba que combina
   todas las anteriores y una nueva serie en una tabla.

   ..src > go
     func TestIsPalindrome(t *testing.T) {
       var tests = []struct {
         input string
         want  bool
       }{
         {"", true},
         {"a", true},
         {"aa", true},
         {"ab", false},
         {"kayak", true},
         {"detartrated", true},
         {"A man, a plan, a canal: Panama", true},
         {"Evil I did dwell; lewd did I live.", true},
         {"Able was I ere I saw Elba", true},
         {"été", true},
         {"Et se resservir, ivresse reste.", true},
         {"palindrome", false}, // no-palindromo
         {"desserts", false},   // semi-palindromo
       }
       for _, test := range tests {
         if got := IsPalindrome(test.input); got != test.want {
           t.Errorf("IsPalindrome(%q) = %v", test.input, got)
         }
       }
     }
   < src..

   Nuestras nuevas pruebas pasan:

   ..srci > sh
     > go test gopl.io/ch11/word2
     ok      gopl.io/ch11/word2        0.015s
   < srci..

   Este estilo de prueba @e(basado en tablas) es muy comun en Go. Es facil
   agregar nuevas entradas de tabla segun sea necesario, y como la logica de
   asercion no se duplica, podemos invertir mas esfuerzo en producir un buen
   mensaje de error.

   La salida de una prueba erronea @e(no) incluye la traza de la pila entera en
   el momento de la llamada a @c(t.Errorf). @c(t.Errorf) tampoco provoca un
   panico o detiene la ejecucion de la prueba, a diferencia de muchos errores de
   asercion en frameworks de prueba para otros lenguajes. Las pruebas son
   independientes entre si. Si una entrada temprana en la tabla hace que la
   prueba falle, las entradas de tabla posteriores se aun se comprobaran, y asi
   podemos aprender sobre multiples fallas durante una sola ejecucion.

   Cuando realmente debemos detener una funcion de prueba, tal vez porque algun
   codigo de inicializacion fallo o para prevenir un fallo ya reportado que
   proboque una cascada confusa de otros fallos, utilizamos @c(t.Fatal) o
   @c(t.Fatalf). Estos deben ser llamados desde la misma gorutina como la
   funcion @c(Test), no de la otra creada durante la prueba.

   Los mensajes de fallo generalmente tienen la forma @c["f(x) = y, quiero z"], donde
   @c[f(x)] explica la operacion a intentar y su entrada, @c(y) es el
   resultado real, y @c(z) el resultado esperado. Cuando es conveniente, como en
   nuestro ejemplo palindromo, se utiliza la sintaxis actual para la parte
   @c[f(x)]. La visualizacion de @c(x) es particularmente importante en una
   prueba basada en tablas, ya que una asercion dada se ejecuta muchas veces
   con diferentes valores. Evite la informacion repetitiva y redundante. Cuando
   se prueba una funcion booleana como @c(IsPalindrome), omita la parte @c(z)
   puesto que no agrega ninguna informacion. Si @c(x), @c(y) o @c(z) es largo,
   en su lugar imprima un resumen relevante de las partes. El autor de una
   prueba debe esforzarse por ayudar al programador que debe diagnosticar un
   fallo de la prueba.

   @b(Ejercicio 11.1): escribir pruebas para el programa @$(charcount) en la
   @l(#Seccion 4.3).

   @b(Ejercicio 11.2): Escribir una serie de pruebas para @c(IntSet)
   @%l(#Seccion 6.5<>§6.5) que comprueba que su comportamiento despues de cada
   operacion es equivalente a un conjunto basado en los mapas nativos. Guarde su
   implementacion para el benchmar del Ejercicio 11.7.

*** Seccion 11.2.1 <> Pruebas Aleatorias

    Las pruebas basadas en tablas son convenientes para comprobar que una
    funcion funciona en entradas cuidadosamente seleccionadas para ejercer casos
    interesantes en la logica. Otro enfoque, @e(pruebas aleatorias), explora una
    gama mas amplia de entradas mediante la construccion de entradas al azar.

    ¿Como sabemos que resultado esperar de nuestra funcion, dada una entrada
    aleatoria? Hay dos estrategias. La primera es escribir una implementacion
    alternativa de la funcion que utiliza un algoritmo menos eficiente pero mas
    sencillo y claro, y comprobar que ambas implementaciones dan el mismo
    resultado. La segunda es crear valores de entrada de acuerdo con un patron
    para que sepamos que salida esperamos.

    El ejemplo siguiente utiliza el segundo enfoque: la funcion
    @c(randomPalindrome) genera palabras que se sabe que son palindromos por
    construccion.

    ..src > go
      import "math/rand"

      // randomPalindrome devuelve un palindromo cuya longitud y contenido
      // se derivan del generador de numeros pseudo aleatorios rng.
      func randomPalindrome(rng *rand.Rand) string {
        n := rng.Intn(25)             // longitud aleatoria hasta 24
        runes := make([]rune, n)
        for i := 0; i < (n+1)/2; i++ {
          r := rune(rng.Intn(0x1000)) // runa aleatoria hasta '\u0999'
          runes[i] = r
          runes[n-1-i] = r
        }
        return string(runes)
      }

      func TestRandomPalindromes(t *testing.T) {
        // Inicializa un generador de números pseudoaleatorios.
        seed := time.Now().UTC().UnixNano()
        t.Logf("Random seed: %d", seed)
        rng := rand.New(rand.NewSource(seed))

        for i := 0; i < 1000; i++ {
          p := randomPalindrome(rng)
          if !IsPalindrome(p) {
            t.Errorf("IsPalindrome(%q) = false", p)
          }
        }
      }
    < src..

    Dado que las pruebas aleatorizadas son no deterministas, es fundamental que
    el registro de la prueba de fallo registre informacion suficiente para
    reproducir el fallo. En nuestro ejemplo, la entrada @c(p) para
    @c(IsPalindrome) nos dice todo lo que necesitamos saber, pero para las
    funciones que aceptan entradas mas complejas, puede ser mas sencillo
    registrar la semilla del generador de numeros pseudo-aleatorios (como lo
    hacemos arriba) que volcar toda la estructura de datos de entrada. Armado
    con ese valor de semilla, podemos modificar facilmente la prueba para
    reproducir el fracaso de forma determinista.

    Utilizando la hora actual como una fuente de aleatoriedad, la prueba
    explorara nuevas entradas cada vez que se ejecute, durante todo el curso de
    su vida util. Esto es especialmente valioso si su proyecto utiliza un
    sistema automatizado para ejecutar todas sus pruebas periodicamente.

    @b(Ejercicio 11.3): @c(TestRandomPalindromes) solo prueba palindromos.
    Escriba una prueba aleatoria que genere y verifique no-palindromos.

    @b(Ejercicio 11.4): Modificar @c(randomPalindrome) para probar el manejo de
    puntuacion y espacios de @c(IsPalindrome).

*** Seccion 11.2.2 <> Probar un Comando

    La heramienta @$(go test) es util para probar paquetes de librerias, pero
    con un poco de esfuerzo lo podemos usar para probar tambien los comandos. Un
    paquete llamado @c(main) normalmente produce un programa ejecutable, pero
    tambien puede ser importado como una libreria.

    Vamos a escribir una prueba para el programa @$(echo) de la @l(#Seccion
    2.3.2). Hemos dividido el programa en dos funciones: @c(echo) hace el
    trabajo real, mientras que @c(main) analiza y lee los valores bandera y los
    errores devueltos por @c(echo).

    ..figure > @l(gopl.io/ch11/echo/echo.go<>gopl.io/ch11/echo)

      ..src > go
        // Echo imprime sus argumentos de linea de comandos.
        package main

        import (
          "flag"
          "fmt"
          "io"
          "os"
          "strings"
        )

        var (
          n = flag.Bool("n", false, "omit trailing newline")
          s = flag.String("s", " ", "separator")
        )

        var out io.Writer = os.Stdout // modificado durante las pruebas

        func main() {
          flag.Parse()
          if err := echo(!*n, *s, flag.Args()); err != nil {
            fmt.Fprintf(os.Stderr, "echo: %v\n", err)
            os.Exit(1)
          }
        }

        func echo(newline bool, sep string, args []string) error {
          fmt.Fprint(out, strings.Join(args, sep))
          if newline {
            fmt.Fprintln(out)
          }
          return nil
        }
      < src..


    A partir de la prueba, llamaremos a @c(echo) con una variedad de argumentos
    y configuraciones de parametros bandera y comprobaremos que imprime la salida
    correcta en cada caso, por lo que hemos añadido parametros a @c(echo) para
    reducir su dependencia de las variables globales. Dicho esto, tambien hemos
    introducido otra variable global, @c(out), un @c(io.Writer) al que se
    escribira el resultado. Al tener @c(echo) escritura a traves de esta
    variable, no directamente a @c(os.Stdout), las pruebas pueden sustituir una
    implementacion @c(Writer) diferente que registra lo que se escrito para una
    inspeccion posterior. Aqui esta la prueba, en el archivo @f(echo_test.go):

    ..src > go
      package main
      import (
        "bytes"
        "fmt"
        "testing"
      )

      func TestEcho(t *testing.T) {
        var tests = []struct {
          newline bool
          sep     string
          args    []string
          want    string
        }{
          {true, "", []string{}, "\n"},
          {false, "", []string{}, ""},
          {true, "\t", []string{"one", "two", "three"}, "one\ttwo\tthree\n"},
          {true, ",", []string{"a", "b", "c"}, "a,b,c\n"},
          {false, ":", []string{"1", "2", "3"}, "1:2:3"},
        }

        for _, test := range tests {
          descr := fmt.Sprintf("echo(%v, %q, %q)",
            test.newline, test.sep, test.args)

          out = new(bytes.Buffer) // captura la salida
          if err := echo(test.newline, test.sep, test.args); err != nil {
            t.Errorf("%s failed: %v", descr, err)
            continue
          }
          got := out.(*bytes.Buffer).String()
          if got != test.want {
            t.Errorf("%s = %q, want %q", descr, got, test.want)
          }
        }
      }
    < src..

    Observe que el codigo de prueba esta en el mismo paquete que el codigo de
    produccion. Aunque el nombre del paquete es @c(main) y define una funcion
    @c(main), durante la prueba, este paquete actua como una libreria que expone
    la funcion @c(TestEcho) al controlador de pruebas; su funcion @c(main) es
    ignorada.

    Al organizar la prueba como una tabla, podemos agregar facilmente nuevos
    casos de prueba. Veamos que sucede cuando la prueba falla, agregando esta
    linea a la tabla:

    ..src > go
      {true, ",", []string{"a", "b", "c"}, "a b c\n"}, // NOTA: expectativa equivocada!
    < src..

    @$(go test) imprime

    ..srci > sh
      > go test gopl.io/ch11/echo
      --- FAIL: TestEcho (0.00s)
          echo_test.go:31: echo(true, ",", ["a" "b" "c"]) = "a,b,c", want "a b c\n"
      FAIL
      FAIL    gopl.io/ch11/echo   0.006s
    < srci..

    El mensaje de error describe el intento de operacion (utilizando la sintaxis
    similar a Go), el comportamiento real y el comportamiento esperado, en ese
    orden. Con un mensaje de error informativo como este, es posible que tenga
    una idea bastante buena sobre la causa raiz antes incluso de haber
    localizado el codigo fuente de la prueba.

    Es importante que el codigo que esta probando no llame a @c(log.Fatal) o
    @c(os.Exit), ya que estas detendran el proceso en seco; llamar a estas
    funciones debe ser considerado como derecho exclusivo de @c(main). Si algo
    totalmente inesperado ocurre y una funcion entra en panico, el controlador
    de pruebas se recuperara, aunque la prueba, por supuesto, se considerara un
    fallo. Errores previsibles, como los que resultan de mala entrada del
    usuario, archivos que faltan, o una configuracion inadecuada deben ser
    reportados mediante la devolucion de un valor @c(error) no-nil.
    Afortunadamente (aunque desafortunado como una ilustracion), nuestro ejemplo
    @$(echo) es tan simple que nunca regresara un error no-nil.

*** Seccion 11.2.3 <> Prueba de Caja Blanca

    Una forma de clasificar las pruebas es por el nivel de conocimiento que
    requieren del funcionamiento interno del paquete bajo prueba. Una prueba de
    @e(caja negla) no asume nada distinto sobre el paquete de lo expuesto por su
    API y especificado por su documentacion; el interior del paquete es opaco.
    En contraste, una prueba de @e(caja blanca) tiene un acceso privilegiado a
    las funciones internas y estructuras de datos del paquete y puede hacer
    observaciones y cambios que un cliente comun no puede. Por ejemplo, una
    prueba de caja blanca puede comprobar que las invariantes de los tipos de
    datos del paquete se mantienen despues de cada operacion. (El nombre @e(caja
    blanca) es tradicional, pero seria mas exacto @e(caja transparente)).

    Los dos enfoques son complementarios. Las pruebas de caja negra suelen ser
    mas robustas, requiriendo menos actualizaciones a medida que el software
    evoluciona. Tambien ayudan al autor de la prueba a empatizar con el cliente
    del paquete y pueden revelar defectos en el diseño del API. Por el
    contrario, las pruebas de caja blanca pueden proporcionar una cobertura mas
    detallada de las partes mas dificiles de la implementacion.

    Ya hemos visto ejemplos de ambos tipos. @c(TestIsPalindrome) llama solo a la
    funcion exportada @c(IsPalindrome) y es por lo tanto una prueba de caja
    negra. @c(TestEcho) llama a la funcion @c(echo) y actualiza la variable
    global @c(out), los cuales se deja sin exportar, por lo que es una prueba
    de caja blanca.

    Durante el desarrollo de @c(TestEcho), modificamos la funcion @c(echo) para
    utilizar la variable de nivel de paquete @c(out) cuando se escribe su
    salida, por lo que la prueba podria sustituir a la salida estandar con una
    implementacion alternativa que registra los datos para una inspeccion
    posterior. Utilizando la misma tecnica, podemos reemplazar otras partes del
    codigo de produccion con implementaciones @"(falsas) faciles de probar. La
    ventaja de las implementaciones falsas es que pueden ser mas sencillas de
    configurar, mas predecibles, mas fiables y mas faciles de observar. Tambien
    pueden evitar efectos secundarios indeseables, como actualizar una base de
    datos de produccion o cargar una tarjeta de credito.

    El siguiente codigo muestra la logica de comprobacion de cuotas en un
    servicio web que proporciona almacenamiento en red a los usuarios. Cuando
    los usuarios superan el 90% de su cuota, el sistema les envia un correo
    electronico de advertencia.

    ..figure > @l(gopl.io/ch11/storage1/storage.go<>gopl.io/ch11/storage1)

      ..src > go
        package storage

        import (
          "fmt"
          "log"
          "net/smtp"
        )

        var usage = make(map[string]int64)

        func bytesInUse(username string) int64 { return usage[username] }

        // configuracion del remitente del email.
        // NOTA: nunca ponga contraseñas en el codigo fuente!
        const sender = "notificaciones@ejemplo.com"
        const password = "correcthorsebatterystaple"
        const hostname = "smtp.ejemplo.com"

        const template = `Warning: you are using %d bytes of storage, %d%% of your quota.`

        func CheckQuota(username string) {
          used := bytesInUse(username)
          const quota = 1000000000 // 1GB
          percent := 100 * used / quota
          if percent < 90 {
            return // OK
          }
          msg := fmt.Sprintf(template, used, percent)
          auth := smtp.PlainAuth("", sender, password, hostname)
          err := smtp.SendMail(hostname+":587", auth, sender,
            []string{username}, []byte(msg))
          if err != nil {
            log.Printf("smtp.SendMail(%s) failed: %s", username, err)
          }
        }
      < src..


    Nos gustaria probarlo, pero no queremos que la prueba envie correo
    electronico real. Por lo tanto, movemos la logica de correo electronico a su
    propia funcion y almacenamos esa funcion en una variable de nivel de paquete
    sin exportar, @c(notifyUser).

    ..figure > @l(gopl.io/ch11/storage2/storage.go<>gopl.io/ch11/storage2)

      ..src > go
        var notifyUser = func(username, msg string) {
          auth := smtp.PlainAuth("", sender, password, hostname)
          err := smtp.SendMail(hostname+":587", auth, sender,
            []string{username}, []byte(msg))
          if err != nil {
            log.Printf("smtp.SendMail(%s) failed: %s", username, err)
          }
        }

        func CheckQuota(username string) {
          used := bytesInUse(username)
          const quota = 1000000000 // 1GB
          percent := 100 * used / quota
          if percent < 90 {
            return // OK
          }
          msg := fmt.Sprintf(template, used, percent)
          notifyUser(username, msg)
        }
      < src..


    Ahora podemos escribir una prueba que sustituye un simple mecanismo de
    notificacion falsa en lugar de enviar correo electronico real. Este registra
    el usuario notificado y el contenido del mensaje.

    ..src > go
      package storage
      import (
        "strings"
        "testing"
      )

      func TestCheckQuotaNotifiesUser(t *testing.T) {
        var notifiedUser, notifiedMsg string
        notifyUser = func(user, msg string) {
          notifiedUser, notifiedMsg = user, msg
        }

        // ...simular una condicion que utiliza 980MB...

        const user = "joe@ejemplo.org"
        CheckQuota(user)
        if notifiedUser == "" && notifiedMsg == "" {
          t.Fatalf("notifyUser not called")
        }
        if notifiedUser != user {
          t.Errorf("wrong user (%s) notified, want %s",
            notifiedUser, user)
        }
        const wantSubstring = "98% of your quota"
        if !strings.Contains(notifiedMsg, wantSubstring) {
          t.Errorf("unexpected notification message <<%s>>, "+
            "want substring %q", notifiedMsg, wantSubstring)
        }
      }
    < src..

    Hay un problema: despues de que esta funcion de prueba ha regresado,
    @c(CheckQuota) ya no funciona como deberia, ya que todavia esta usando la
    prueba falsa que implementa @c(notifyUsers). Debemos modificar la prueba
    para restaurar el valor anterior para que las pruebas posteriores no
    observen ningun efecto, y debemos hacerlo en todas las rutas de ejecucion,
    incluyendo pruebas que fallan y panicos. Naturalmente, esto sugiere un
    @c(defer).

    ..src > go
      func TestCheckQuotaNotifiesUser(t *testing.T) {
        // Guardar y restaurar notifiUser original
        saved := notifyUser
        defer func() { notifyUser = saved }()

        // Instala la prueba falsa notifyUser.
        var notifiedUser, notifiedMsg string
        notifyUser = func(user, msg string) {
          notifiedUser, notifiedMsg = user, msg
        }
        // ...resto de la prueba...
      }
    < src..

    Este patron se puede utilizar para guardar y restaurar temporalmente todo
    tipo de variables globales, incluidas banderas de linea de comandos,
    opciones de depuracion y parametros de rendimiento; para instalar y eliminar
    los ganchos que hacen que el codigo de produccion llame al codigo de prueba
    cuando sucede algo interesante; y para codificar el codigo de produccion en
    estados raros pero importantes, como tiempos muertos, errores e incluso
    intercalaciones especificas de actividades concurrentes.

    El uso de variables globales de esta manera es seguro solo porque @$(go
    test) normalmente no ejecuta pruebas multiples de forma concurrente.

*** Seccion 11.2.4 <> Paquetes de Pruebas Externos

    Considere el paquete @c(net/url), que proporciona un analizador de URL, y
    @c(net/http), que proporciona un servidor web y una libreria de cliente
    HTTP. Como es de esperar, el nivel superior de @c(net/http) depende del
    nivel inferior @c(net/url). Sin embargo, una de las pruebas en @c(net/url)
    es un ejemplo que demuestra la interaccion entre las URL y la libreria
    cliente HTTP. En otras palabras, una prueba al paquete de nivel inferior
    importa el paquete de nivel superior.

    ..figure > Figura 11.1. Una prueba de @c(net/url) depende de @c(net/http).

      ..img  > img/Figure-11.1.jpg

    Declarar esta funcion de prueba en el paquete @c(net/url) crearia un ciclo
    en el grafico de importacion de paquetes, tal como se representa por las flecha
    hacia arriba en la Figura 11.1, pero como se explico en la @l(#Seccion
    10.1), la especificacion Go prohibe los ciclos de importacion.

    Resolvemos el problema declarando la funcion de prueba en un @e(paquete de
    prueba externo), es decir, en un archivo en el directorio @c(net/url) cuya
    declaracion del paquete lee el paquete @c(url_test). El sufijo adicional
    @c(_test) es una señal para @$(go test) que debe construir un paquete
    adicional que contiene solo estos archivos y ejecutar sus pruebas. Puede ser
    util pensar en este paquete de prueba externo como si tuviera la ruta de
    importacion @c(net/url_test), pero no se pueden importar con este nombre ni
    con ningun otro.

    Debido a que las pruebas externas viven en un paquete separado, pueden
    importar paquetes auxiliares que tambien dependen del paquete que se esta
    probando; una prueba en el paquete no puede hacer esto. En terminos de las
    capas de diseño, el paquete de pruebas externo es logicamente mas alto que
    los dos paquetes de los que depende, como se muestra en la Figura 11.2.

    ..figure > Figura 11.2. Los paquetes de prueba externos rompen los ciclos de
      dependencia.

      ..img  > img/Figure-11.2.jpg

    Al evitar ciclos de importacion, los paquetes de prueba externos permiter
    que las pruebas, especialmente las @e(pruebas de integracion) (que ponen a
    prueba la interaccion de varios componentes), importen otros paquetes
    libremente, exactamente como haria una aplicacion.

    Podemos utilizar la herramienta @$(go list) para resumir que archivos fuente
    en un directorio Go son el codigo de produccion, pruebas en el paquete, y
    pruebas externas. Usaremos el paquete @c(fmt) como ejemplo. @c(GoFiles) es
    la lista de los archivos que contienen el codigo de produccion; estos son
    los archivos que @$(go build) incluira en su aplicacion:

    ..srci > sh
      > go list -f={{.GoFiles}} fmt
      [doc.go format.go print.go scan.go]
    < srci..

    @c(TestGoFiles) es la lista de archivos que tambien pertenecen al paquete
    @c(fmt), pero estos archivos, cuyos nombres terminan en @f(_test.go), se
    incluye solo en la construccion de las pruebas:

    ..srci > sh
      > go list -f={{.TestGoFiles}} fmt
      [export_test.go]
    < srci..

    Las pruebas del paquete por lo general residen en estos archivos, aunque
    inusualmente @c(fmt) no tiene ninguno; vamos a explicar el proposito de
    @c(export_test.go) en un momento.

    @c(XTestGoFiles) es la lista de los archivos que constituyen el paquete de
    prueba externo, @c(fmt_test), por lo que estos archivos debe importar el
    paquete @c(fmt) con el fin de usarlo. Una vez mas, se incluyen solo durante
    las pruebas:

    ..srci > sh
      > go list -f={{.XTestGoFiles}} fmt
      [fmt_test.go scan_test.go stringer_test.go]
    < srci..

    A veces un paquete de prueba externo puede necesitar acceso privilegiado a
    los internos del paquete bajo prueba, si por ejemplo una prueba de caja
    blanca debe vivir en un paquete separado para evitar un ciclo de
    importacion. En estos casos, se utiliza un truco: agregamos declaraciones a
    un archivo @f(_test.go) del paquete para exponer los componentes internos
    necesarios para la prueba externa. Este archivo ofrece asi una @"(puerta
    trasera) para la prueba del paquete. Si el archivo origen existe solo para
    este proposito y no contiene pruebas en si mismo, se le nombra a menudo
    @f(export_test.go).

    Por ejemplo, la implementacion del paquete @c(fmt) necesita la funcionalidad
    de @c(unicode.IsSpace) como parte de @c(fmt.Scanf). Para evitar la creacion
    de una dependencia indeseable, @c(fmt) no importa el paquete @c(unicode) y
    sus grandes tablas de datos; en cambio, contiene una implementacion mas
    sencilla, a la que llama @c(isSpace).

    Para asegurar que los comportamientos de @c(fmt.isSpace) y
    @c(unicode.IsSpace) no se separan, @c(fmt) prudentemente contiene una
    prueba. Se trata de una prueba externa, y por lo tanto no puede acceder a
    @c(isSpace) directamente, por lo que @c(fmt) abre una puerta trasera
    declarando una variable exportada que contiene la funcion interna
    @c(isSpace). Esta es la totalidad del archivo @f(export_test.go) del paquete
    @c(fmt).

    ..src > go
      package fmt

      var IsSpace = isSpace
    < src..

    Este archivo de prueba no define pruebas; simplemente declara el simbolo
    exportado @c(fmt.IsSpace) para el uso de la prueba externa. Este truco
    tambien se puede utilizar cada vez que una prueba externa necesita utilizar
    algunas de las tecnicas de prueba de caja blanca.

*** Seccion 11.2.5 <> Escribir Pruebas Efectivas

    Muchos recien llegados a Go se sorprenden por el minimalismo del framework
    de pruebas de Go. Los frameworks de otros lenguajes proporcionan mecanismos
    para la identificacion de las funciones de prueba (a menudo utilizan la
    reflexion o metadatos), ganchos para realizar operaciones de
    @"(configuracion) y @"(desmontaje) antes y despues de la ejecucion de
    pruebas, y librerias de funciones de utilidad para afirmar predicados
    comunes, comparar valores, formatear mensajes de error, y abortar una prueba
    fallida (a menudo utilizando excepciones). Aunque estos mecanismos pueden
    hacer las pruebas muy concisas, las pruebas resultantes a menudo parecen
    estar escritas en un lenguaje extranjero. Ademas, aunque pueden reportar
    @c(PASS) o @c(FAIL) correctamente, su forma puede ser hostil al infortunado
    mantenedor, con mensajes de error cripticos como @c("assert: 0 == 1") o
    pagina tras pagina de trazas de la pila.

    La actitud de Go a la pruebas esta en marcado contraste. Se espera que los
    autores de las pruebas hagan la mayor parte de este trabajo ellos mismos,
    definiendo funciones para evitar la repeticion, tal como lo harian para los
    programas ordinarios. El proceso de prueba no es un relleno de formatos; una
    prueba tiene una interfaz de usuario tambien, aunque una cuyos unicos
    usuarios son tambien sus mantenedores. Una buena prueba no explota al
    fracasar, en su lugar imprime una descripcion clara y sucinta del sintoma
    del problema, y tal vez otros hechos relevantes sobre el contexto.
    Idealmente, el mantenedor no deberia necesitar leer el codigo fuente para
    descifrar un fallo de prueba. Una buena prueba no debe terminar despues de
    un fallo, debe intentar reportar varios errores en una sola ejecucion, ya
    que el patron de fallas puede ser revelador.

    La funcion de asercion siguiente compara dos valores, genera un mensaje de
    error generico y detiene el programa. Es facil de usar y es correcta, pero
    cuando falla, el mensaje de error es casi inutil. No resuelve el dificil
    problema de proporcionar una buena interfaz de usuario.

    ..src > go
      import (
        "fmt"
        "strings"
        "testing"
      )

      // Una mala funcion de asercion.
      func assertEqual(x, y int) {
        if x != y {
          panic(fmt.Sprintf("%d != %d", x, y))
        }
      }

      func TestSplit(t *testing.T) {
        words := strings.Split("a:b:c", ":")
        assertEqual(len(words), 3)
        // ...
      }
    < src..

    En este sentido, las funciones de asercion sufren de abstraccion prematura:
    al tratar el fracaso de esta prueba en particular como una mera diferencia
    de dos numeros enteros, perdemos la oportunidad de proporcionar un contexto
    significativo. Podemos proporcionar un mejor mensaje a partir de los
    detalles concretos, como en el ejemplo siguiente. Solo una vez que surgen
    patrones repetitivos en una suite de pruebas dada es el momento de
    introducir abstracciones.

    ..src > go
      func TestSplit(t *testing.T) {
        s, sep := "a:b:c", ":"
        words := strings.Split(s, sep)
        if got, want := len(words), 3; got != want {
          t.Errorf("Split(%q, %q) returned %d words, want %d",
            s, sep, got, want)
        }
        // ...
      }
    < src..

    Ahora la prueba reporta la funcion que se llamo, sus entradas y el
    significado del resultado; identifica explicitamente el valor actual y la
    expectativa; y continua ejecutandose incluso si esta afirmacion falla. Una
    vez que hemos escrito una prueba de este tipo, el siguiente paso natural a
    menudo no es definir una funcion para reemplazar toda le sentencia @c(if),
    sino ejecutar la prueba en un bucle en el que varien @c(s), @c(sep), y
    @c(want), como en la prueba basada en tablas de @c(IsPalindrome).

    El ejemplo anterior no necesitaba funciones de utilidad, pero por supuesto
    eso no deberia impedirnos introducir funciones cuando ayuden a simplificar
    el codigo. (Veremos una funcion de utilidad, @c(reflect.DeepEqual), en la
    @l(#Seccion 13.3).) La clave para una buena prueba es empezar por la
    aplicacion de la conducta concreta que desea y solo entonces utilizar las
    funciones para simplificar el codigo y eliminar la repeticion. Los mejores
    resultados rara vez se obtienen comenzando con una libreria de funciones de
    pruebas abstractas y genericas.

    @b(Ejercicio 11.5): Extender @c(TestSplit) para utilizar una tabla de
    entradas y salidas esperadas.

*** Seccion 11.2.6 <> Evitar Pruebas Fragiles

    Una aplicacion que falla a menudo cuando se encuentra con entradas nuevas
    pero validas, se denomina @e(buggy); una prueba que falla falsamente cuando
    se hace un cambio de sonido al programa se denomina @e(fragil). Asi como un
    programa buggy frustra a sus usuarios, una prueba fragil exaspera a sus
    mantenedores. Las pruebas mas fragiles, que fallan por casi cualquier cambio
    en el codigo de produccion, bueno o malo, a veces se denominan pruebas de
    @e(detector de cambio) o de @e(status quo), y el tiempo dedicado a tratar
    con ellas puede consumir rapidamente cualquier beneficio que una vez
    parecian ofrecer.

    Cuando una funcion bajo prueba produce una salida compleja, como una cadena
    larga, una estructura de datos elaborada, o un archivo, es tentador
    comprobar que la salida es exactamente igual a algun valor @"(dorado) que se
    esperaba cuando se escribio la prueba. Pero a medida que el programa
    evoluciona, partes de la produccion probablemente cambian, probablemente de
    buenas forma, pero cambien sin embargo. Y no es solo la salida; las
    funciones con entradas complejas suelen romperse porque la entrada utilizada
    en una prueba ya no es valida.

    La manera mas facil de evitar las pruebas fragiles es comprobar solo las
    propiedades que le interesan. Pruebe las interfaces mas sencillas y estables
    de su programa con preferencia a sus funciones internas. Sea selectivo en
    sus afirmaciones. Por ejemplo, no compruebe si hay coincidencias exactas de
    cadenas, pero busque subsecciones relevantes que no cambien a medida que el
    programa evoluciona. A menudo vale la pena escribir una funcion sustancial
    para destilar una salida compleja hasta su esencia para que las afirmaciones
    sean confiables. A pesar de que puede parecer una gran cantidad de esfuerzo
    inicial, puede pagarse por si mismo rapidamente en el tiempo que de otro
    modo se gastaria reparando falsas pruebas de error.

** Seccion 11.3 <> Cobertura

   Por su naturaleza, las pruebas nunca son completas. Como lo dijo el
   influyente cientifico informatico Edsger Dijkstra: @"(Las pruebas muestran lo
   presente, no la ausencia de errores.) Ninguna cantidad de pruebas puede
   probar que un paquete esta libre de errores. En el mejor de los casos,
   aumentan nuestra confianza en que el paquete funciona bien en una amplia gama
   de escenarios importantes.

   El grado en que una suite de pruebas prueba un paquete se denomina
   @e(cobertura) de la prueba. La cobertura no se puede cuantificar
   directamente–la dinamica de todos los programas, excepto los mas triviales,
   esta mas alla de la medicion exacta–pero hay heuristicas que pueden ayudarnos
   a dirigir nuestros esfuerzos de pruebas a donde es mas probable que sean
   utiles.

   La @e(cobertura de sentencias) es la mas simple y mas utilizada de estas
   heuristicas. La cobertura de sentencias de una suite de pruebas es la
   fraccion de sentencias de origen que se ejecutan al menos una vez durante la
   prueba. En esta seccion, vamos a utilizar la herramienta @$(cover) de Go, que
   esta integrada en @$(go test), para medir la cobertura de sentencias y ayudar
   a identificar lagunas evidentes en las pruebas.

   El codigo siguiente es una prueba basada en tablas para el evaluador de
   expresiones que construimos en el @l(#Capitulo 7):

   ..figure > @l(gopl.io/ch7/eval/coverage_test.go<>gopl.io/ch7/eval)

     ..src > go
       func TestCoverage(t *testing.T) {
         var tests = []struct {
           input string
           env   Env
           want  string // error esperado de Parse/Check o resultado de Eval
         }{
           {"x % 2", nil, "unexpected '%'"},
           {"!true", nil, "unexpected '!'"},
           {"log(10)", nil, `unknown function "log"`},
           {"sqrt(1, 2)", nil, "call to sqrt has 2 args, want 1"},
           {"sqrt(A / pi)", Env{"A": 87616, "pi": math.Pi}, "167"},
           {"pow(x, 3) + pow(y, 3)", Env{"x": 9, "y": 10}, "1729"},
           {"5 / 9 * (F - 32)", Env{"F": -40}, "-40"},
         }

         for _, test := range tests {
           expr, err := Parse(test.input)
           if err == nil {
             err = expr.Check(map[Var]bool{})
           }
           if err != nil {
             if err.Error() != test.want {
               t.Errorf("%s: got %q, want %q", test.input, err, test.want)
             }
             continue
           }

           got := fmt.Sprintf("%.6g", expr.Eval(test.env))
           if got != test.want {
             t.Errorf("%s: %v => %s, want %s",
               test.input, test.env, got, test.want)
           }
         }
       }
     < src..


   En primer lugar, vamos a comprobar que la prueba pasa:

   ..srci > sh
     > go test -v -run=Coverage gopl.io/ch7/eval
     === RUN TestCoverage
     --- PASS: TestCoverage (0.00s)
     PASS
     ok      gopl.io/ch7/eval    0.011s
   < srci..

   Este comando muestra el mensaje de uso de la herramienta de cobertura:

   ..srci > sh
     > go tool cover
     Usage of 'go tool cover':
     Given a coverage profile produced by 'go test':
         go test -coverprofile=c.out
     Open a web browser displaying annotated source code:
         go tool cover -html=c.out
   < srci..

   El comando @$(go tool) ejecuta uno de los ejecutables de la cadena de
   herramientas Go. Estos programas viven en el directorio
   @c($GOROOT/pkg/tool/${GOOS}_${GOARCH}). Gracias a @$(go build), rara vez es
   necesario invocarlo directamente.

   Ahora corremos la prueba con la bandera @c(-coverprofile):

   ..srci > sh
     > go test -run=Coverage -coverprofile=c.out gopl.io/ch7/eval
     ok      gopl.io/ch7/eval    0.032s  coverage: 68.5% of statements
   < srci..

   Este indicador permite la recopilacion de datos de cobertura
   @e(instrumentando) el codigo de produccion. Es decir, modifica una copia del
   codigo fuente para que, antes de ejecutar cada bloque de sentencias, se
   establezca una variable booleana, con una variable por bloque. Justo antes de
   salir del programa modificado, se escribe el valor de cada variable en el
   archivo de registro especificado @f(c.out) e imprime un resumen de la
   fraccion de declaraciones que fueron ejecutados. (Si todo lo que necesita es
   el resumen, utilice @$(go test -cover).)

   Si @$(go test) se ejecuta con la bandera @c(-covermode=count), la
   instrumentacion para cada bloque incrementa un contador en lugar de
   establecer un valor booleano. El registro resultante del recuento de
   ejecucion de cada bloque permite comparaciones cuantitativas entre los
   bloques mas @"(calientes), que se ejecutan con mayor frecuencia, y los mas
   @"(frios).

   Despues de haber reunido los datos, corremos la herramienta @$(cover), que
   procesa el registro, genera un informe HTML, y lo abre en una nueva ventana
   del navegador (Figura 11.3).

   ..srci > sh
     > go tool cover -html=c.out
   < srci..

   ..figure > Figura 11.3. Un informe de cobertura.

     ..img  > img/Figure-11.3.jpg

   Cada declaracion es de color verde si estaba cubierta o rojo si no. Para
   mayor claridad, hemos sombreado el fondo del texto rojo. Podemos ver
   inmediatamente que ninguna de nuestras entradas prueba el operador unario del
   metodo @c(Eval). Si agregamos este nuevo caso de prueba a la tabla y volvemos
   a ejecutar los dos comandos anteriores, el codigo de expresion unario se
   convierte en verde:

   ..src > go
     {"-x * -x", Env{"x": 2}, "4"}
   < src..

   Sin embargo, las dos declaraciones @c(panic) permanecen de color rojo. Esto
   no debe ser sorprendente, porque se supone que estas declaraciones son
   inaccesibles.

   Alcanzar una cobertura del 100% de la declaracion suena como un objetivo
   noble, pero generalmente no es factible en la practica, ni es probable que
   sea un buen uso de esfuerzo. El hecho de que se ejecute una sentencia no
   significa que este libre de errores; las declaraciones que contienen
   expresiones complejas se deben ejecutar muchas veces con entradas diferentes
   para cubrir los casos interesantes. Algunos estados, como las declaraciones
   @c(panic) anteriores, no pueden ser alcanzados. Otros, como los que manejan
   errores esotericos, son dificiles de probar pero raramente alcanzados en la
   practica. Las pruebas son fundamentalmente un esfuerzo pragmatico, un
   equilibrio entre el costo de escritura de las pruebas y el costo de los
   fallos que podrian haber sido evitados por las pruebas. Las herramientas de
   cobertura pueden ayudar a identificar los puntos mas debiles, pero idear
   buenos casos de prueba requiere el mismo pensamiento riguroso que la
   programacion en general.

** Seccion 11.4 <> Funciones @c(Benchmark)

   Benchmarking es la practica de medir el rendimiento de un programa con una
   carga de trabajo fija. En Go, una funcion de referencia se parece a una
   funcion de prueba, pero con el prefijo @c(Benchmark) y un parametro
   @c(*testing.B) que proporciona la mayor parte de los mismos metodos que un
   @c(*testing.T), ademas algunos adicionales relacionados con la medicion del
   desempeño. Tambien expone un campo entero @c(N), que especifica el numero de
   veces que se realizara la operacion que se esta midiendo.

   Aqui tenemos el benchmark para @c(IsPalindrome) que llama @c(N) veces en un
   bucle.

   ..src > go
     import "testing"
     func BenchmarkIsPalindrome(b *testing.B) {
       for i := 0; i < b.N; i++ {
         IsPalindrome("A man, a plan, a canal: Panama")
       }
     }
   < src..

   Lo ejecutamos con el siguiente comando. A diferencia de las pruebas, los
   benchmarks por defecto no se ejecutan. El argumento @c(-bench) selecciona que
   deben ejecutarso los benchmark. Es una expresion regular que coincide con los
   nombres de las funciones @c(Benchmark), con un valor predeterminado que no
   coincide con ninguno de ellos. El patron @"c(.) hace que coincida con
   todos los benchmark en el paquete @c(word), pero ya que solo hay uno,
   @c(-bench=IsPalindrome) habria sido equivalente.

   ..srci > sh
     > cd $GOPATH/src/gopl.io/ch11/word2
     > go test -bench=.
     PASS
     BenchmarkIsPalindrome-8 1000000               1035 ns/op
     ok      gopl.io/ch11/word2      2.179s
   < srci..

   El Sufijo numerico de benchmark, @c(8) aqui, indica el valor de
   @c(GOMAXPROCS), lo cual es importante para los benchmark concurrentes.

   El informe nos dice que cada llamada a @c(IsPalindrome) tomo cerca de 1.035
   microsegundos, un promedio de mas de 1.000.000 ejecuciones. Puesto que el
   corredor referencia inicialmente no tiene idea de cuanto tiempo dura la
   operacion, realiza algunas mediciones iniciales utilizando valores pequeños
   de @c(N) y luego extrapola hasta un valor lo suficientemente grande para
   realizar una medicion de temporizacion estable.

   La razon por la que el bucle se implementa por la funcion benchmark, y no por
   el codigo de llamada en el controlador de prueba, es para que la funcion de
   referencia tenga la oportunidad de ejecutar cualquier codigo de configuracion
   de una sola vez fuera del bucle sin que esto se añada al tiempo medido de
   cada iteracion. Si este codigo de configuracion sigue perturbando los
   resultados, el parametro @c(testing.B) proporciona metodos para detener,
   reanudar y reiniciar el temporizador, pero estos rara vez son necesarios.

   Ahora que tenemos un punto de referencia y pruebas, es facil probar ideas
   para hacer el programa mas rapido. Quizas la optimizacion mas obvia es hacer
   que el bucle de @c(IsPalindrome) detenga la verificacion en el punto medio,
   para evitar hacer cada comparacion dos veces:

   ..src > go
     n := len(letters)/2
     for i := 0; i < n; i++ {
       if letters[i] != letters[len(letters)-1-i] {
         return false
       }
     }
     return true
   < src..

   Pero como suele ser el caso, una optimizacion obvia no siempre da el
   beneficio esperado. Este proporciono una mera mejora del 4% en un
   experimento.

   ..srci > sh
     > go test -bench=.
     PASS
     BenchmarkIsPalindrome-8 1000000                992 ns/op
     ok      gopl.io/ch11/word2      2.093s
   < srci..

   Otra idea es asignar previamente una gama suficientemente amplia para su uso
   por @c(letters), en lugar de expandirlo mediante llamadas sucesivas a append.
   Declaramos @c(letters) como un arreglo del tamaño adecuado, de esta manera,

   ..src > go
     letters := make([]rune, 0, len(s))
     for _, r := range s {
       if unicode.IsLetter(r) {
         letters = append(letters, unicode.ToLower(r))
       }
     }
   < src..

   Produce una mejora de casi 35%, y el marcador del benchmark ahora informa el
   promedio de mas de 2.000.000 de iteraciones.

   ..srci > sh
     > go test -bench=.
     PASS
     BenchmarkIsPalindrome-8 2000000                697 ns/op
     ok      gopl.io/ch11/word2      1.468s
   < srci..

   Como muestra este ejemplo, el programa mas rapido es a menudo el que hace
   menos asignaciones de memoria. La bandera @c(-benchmem) de linea de comandos,
   incluira estadisticas de asignacion de memoria en su informe. Aqui comparamos
   el numero de asignaciones antes de la optimizacion:

   ..srci > sh
     > go test -bench=. -benchmem
     PASS
     BenchmarkIsPalindrome    1000000  1026 ns/op    304 B/op  4 allocs/op
   < srci..

   Y despues de ella:

   ..srci > sh
     > go test -bench=. -benchmem
     PASS
     BenchmarkIsPalindrome    2000000   807 ns/op    128 B/op  1 allocs/op
   < srci..

   Consolidando las asignaciones en una sola llamada a make elimina el 75% de
   las asignaciones y reduce a la mitad la cantidad de memoria asignada.

   Los benchmark de este tipo nos dicen que el tiempo absoluto requerido para
   una operacion dada, pero en muchas configuraciones las preguntas de desempeño
   interesantes estan en los tiempos @e(relativos) de dos operaciones
   diferentes. Por ejemplo, si una funcion toma 1ms para procesar 1,000
   elementos, ¿cuanto tiempo tardara en procesar 10,000 o un millon? Tales
   comparaciones revelan el crecimiento asintotico del tiempo de funcionamiento
   de la funcion. Otro ejemplo: ¿cual es el mejor tamaño para un bufer de E/S?
   Los benchmarks del rendimiento de la aplicacion en un rango de tamaños pueden
   ayudarnos a elegir el buffer mas pequeño que ofrece un rendimiento
   satisfactorio. Un tercer ejemplo: ¿cual algoritmo funciona mejor para un
   trabajo determinado? Los benchmark que evaluan dos algoritmos diferentes con
   los mismos datos de entrada a menudo pueden mostrar las fortalezas y
   debilidades de cada uno en cargas de trabajo importantes o representativas.

   Los benchmarks comparativos son solo codigo regular. Por lo general toman la
   forma de una sola funcion parametrizada, llamada de varias funciones
   @c(Benchmark) con diferentes valores, como esto:

   ..src > go
     func benchmark(b *testing.B, size int) { /* ... */ }
     func Benchmark10(b *testing.B)   { benchmark(b,   10) }
     func Benchmark100(b *testing.B)  { benchmark(b,  100) }
     func Benchmark1000(b *testing.B) { benchmark(b, 1000) }
   < src..

   El parametro de @c(size), que especifica el tamaño de la entrada, varia a
   traves de los benchmark, pero es constante dentro de cada punto de
   referencia. Resista la tentacion de utilizar el parametro @c(b.N) como el
   tamaño de entrada. A menos que lo interprete como un recuento de iteracion
   para una entrada de tamaño fijo, los resultados de su benchmark no tendran
   sentido.

   Los patrones revelados por los benchmark comparativos son particularmente
   utiles durante el diseño del programa, pero no arrojamos los benchmark cuando
   el programa esta funcionando. A medida que el programa evoluciona, o su
   entrada crece, o se despliega en nuevos sistemas operativos o procesadores
   con caracteristicas diferentes, podemos reutilizar esos benchmark para
   revisar las decisiones de diseño.

   @b(Ejercicio 11.6): Escribir benchmarks para comparar la implementacion
   @c(PopCount) en la @l(#Seccion 2.6.2) con sus soluciones al Ejercicio 2.4 y
   Ejercicio 2.5. ¿En que punto el enfoque basado en tablas se equilibra?

   @b(Ejercicio 11.7): Escribir benchmark para @c(Add), @c(UnionWith), y otros
   metodos de @c(*IntSet) @%l(#Seccion 6.5<>§6.5) utilizando grandes entradas
   pseudoaleatorias. ¿Que tan rapido puede hacer que estos metodos se ejecuten?
   ¿Como afecta la eleccion del tamaño de la palabra al rendimiento? ¿Que tan
   rapido es @c(IntSet) en comparacion con una implementacion de conjunto basado
   en el tipo integrado de mapa?

** Seccion 11.5 <> Perfilado

   Los benchmark son utiles para medir el rendimiento de operaciones
   especificas, pero cuando estamos tratando de hacer un programa lento mas
   rapido, a menudo no tenemos idea por donde empezar. Todo programador conoce
   el aforismo de Donald Knuth acerca de la optimizacion prematura, que aparecio
   en @"(Structured Programming with go to Statements) en 1974. Aunque a menudo
   mal interpretado en el sentido de rendimiento, no importa, en su contexto
   original, podemos discernir un significado diferente:

   ..quote >
     No hay duda de que el grial de la eficiencia conduce al abuso. Los
     programadores pierden enormes cantidades de tiempo pensando o preocupandose
     por la velocidad de las partes no criticas de sus programas, y estos
     intentos de eficiencia realmente tienen un fuerte impacto negativo cuando
     se consideran la depuracion y el mantenimiento. @e(Debemos) olvidarnos de
     las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la
     optimizacion prematura es la raiz de todo mal.

     Sin embargo, no debemos dejar pasar nuestras oportunidades en ese critico
     3%. Un buen programador no se engañara en complacencia por tal
     razonamiento, el sera sabio mirando cuidadosamente el codigo critico; pero
     solo @e(despues) de que el codigo se ha identificado. A menudo es un error
     hacer juicios a priori sobre que partes de un programa son realmente
     criticos, ya que la experiencia universal de los programadores que han
     estado utilizando herramientas de medicion ha sido que sus suposiciones
     intuitivas fallan.
   < quote..

   Cuando deseamos prestar atencion a la velocidad de nuestros programas, la
   mejor tecnica para identificar el codigo critico es el @e(perfilado). El
   perfilado es un enfoque automatizado para la medicion del rendimiento basado
   en el muestreo de un numero de @e(eventos) de perfil durante la ejecucion,
   extrapolando luego de ellos durante una etapa de post-procesamiento; el
   resumen estadistico resultante se llama un @e(perfil).

   Go soporta muchos tipos de perfiles, cada uno de ellos relacionado con un
   aspecto diferente del rendimiento, pero todos ellos implican grabar una
   secuencia de eventos de interes, cada uno de los cuales tiene un seguimiento
   de pila que acompaña–la pila de llamadas de funcion activas en el momento del
   evento. La herramienta @$(go test) tiene soporte integrado para varios tipos
   de perfiles.

   Un @e(perfil de CPU) identifica las funciones cuya ejecucion requiere mas
   tiempo de CPU. El subproceso actualmente en ejecucion en cada CPU es
   interrumpido periodicamente por el sistema operativo cada pocos milisegundos,
   con cada interrupcion registrando un evento de perfil antes de que se reanude
   la ejecucion normal.

   Un @e(perfil de monticulo) identifica las declaraciones responsables de la
   asignacion de la mayoria de la memoria. La libreria de perfiles muestrea las
   llamadas a las rutinas de asignacion de memoria interna de manera que, en
   promedio, se registra un evento de perfil por cada 512 KB de memoria
   asignada.

   Un @e(perfil de bloqueo) identifica las operaciones responsable del bloqueo
   de las gorutinas mas largas, como las llamadas al sistema, envio y recepcion
   de canales, y adquisiciones de bloqueos. La libreria de perfilado registra un
   evento cada vez que una gorutina es bloqueada por una de estas operaciones.

   Recopilar un perfil para el codigo bajo prueba es tan facil como habilitar
   uno de los indicadores a continuacion. Tenga cuidado al usar mas de una
   bandera a la vez, sin embargo: la maquinaria para recoger un tipo de perfil
   puede sesgar los resultados de otros.

   ..srci > sh
     > go test -cpuprofile=cpu.out
     > go test -blockprofile=block.out
     > go test -memprofile=mem.out
   < srci..

   Es facil agregar soporte de perfilado a programas que no son de prueba,
   aunque los detalles de como lo hacemos varian entre las herramientas de linea
   de comandos de corta duracion y las aplicaciones de servidor de larga
   ejecucion. El perfilado es especialmente util en aplicaciones de larga
   duracion, por lo que las caracteristicas de generacion de perfiles en tiempo
   de ejecucion de Go pueden habilitarse bajo el control del programador
   utilizando la API @c(runtime).

   Una vez que hemos reunido un perfil, es necesario analizarlo usando la
   herramienta @$(pprof). Esta es una parte estandar de la distribucion Go, pero
   ya que no es una herramienta de uso diario, se accede indirectamente usando
   @$(go tool pprof). Tiene docenas de caracteristicas y opciones, pero el uso
   basico requiere solo dos argumentos, el ejecutable que produjo el perfil y el
   registro del perfil.

   Para que el perfil sea eficiente y para ahorrar espacio, el registro no
   incluye nombres de funciones; en su lugar, las funciones se identifican por
   sus direcciones. Esto significa que @$(pprof) necesita el ejecutable para que
   el registro tenga sentido. Aunque @$(go test) generalmente descarta el
   ejecutable de prueba una vez finalizada la prueba, cuando el perfilado se
   habilita guarda el archivo ejecutable como @f(Foo.test), donde @c(foo) es el
   nombre del paquete de prueba.

   Los siguientes comandos muestran como recopilar y mostrar un perfil de CPU
   simple. Hemos seleccionado uno de los benchmark del @c(net/http). Por lo
   general, es mejor hacer un perfil de benchmark especificos que se han
   construido para ser representativos de las cargas de trabajo que a uno le
   preocupan. En los benchmark los casos de prueba casi nunca son
   representativos, es por ello que las desactivo mediante el filtro
   @c(-run=NONE).

   ..srci > sh
     > go test -run=NONE -bench=ClientServerParallelTLS64
     ^   -cpuprofile=cpu.log net/http
     PASS
     BenchmarkClientServerParallelTLS64-8 1000
        3141325 ns/op  143010 B/op  1747 allocs/op
     ok      net/http       3.395s

     > go tool pprof -text -nodecount=10 ./http.test cpu.log
     2570ms of 3590ms total (71.59%)
     Dropped 129 nodes (cum <= 17.95ms)
     Showing top 10 nodes out of 166 (cum >= 60ms)
     flat    flat%   sum%     cum   cum%
     1730ms 48.19% 48.19%  1750ms 48.75%  crypto/elliptic.p256ReduceDegree
     230ms 6.41%   54.60%   250ms  6.96%  crypto/elliptic.p256Diff
     120ms 3.34%   57.94%   120ms  3.34%  math/big.addMulVVW
     110ms 3.06%   61.00%   110ms  3.06%  syscall.Syscall
      90ms 2.51%   63.51%  1130ms 31.48%  crypto/elliptic.p256Square
      70ms 1.95%   65.46%   120ms  3.34%  runtime.scanobject
      60ms 1.67%   67.13%   830ms 23.12%  crypto/elliptic.p256Mul
      60ms 1.67%   68.80%   190ms  5.29%  math/big.nat.montgomery
      50ms 1.39%   70.19%    50ms  1.39%  crypto/elliptic.p256ReduceCarry
      50ms 1.39%   71.59%    60ms  1.67%  crypto/elliptic.p256Sum
   < srci..

   La bandera @c(-text) especifica el formato de salida, en este caso, una tabla
   textual con una fila por cada funcion, ordenada para que las funciones @"(mas
   activas)–Las que consumen mas ciclos de CPU–aparecescan primero. La bandera
   @c(-nodecount=10) limita el resultado a 10 filas. Para los problemas de
   rendimiento bruto, este formato textual puede ser suficiente para identificar
   la causa.

   Este perfil nos dice que la criptografia de curva eliptica es importante para
   el rendimiento de este benchmark HTTPS en particular. Por el contrario, si un
   perfil esta dominado por funciones de asignacion de memoria desde el paquete
   @c(runtime), reducir el consumo de memoria puede ser una optimizacion que
   vale la pena.

   Para problemas mas sutiles, puede ser mejor usar una de las pantallas
   graficas de @$(pprof). Estas requieren GraphViz, que se puede descargar desde
   @l(www.graphviz.org). La bandera @c(-web) entonces crea un grafico dirigido
   de las funciones del programa, anotadas por sus numeros de perfil de la CPU y
   de colores para indicar las funciones mas calientes.

   Solo hemos arañado la superficie de las herramientas de perfilado de Go. Para
   obtener mas informacion, lea el articulo @"l(https://blog.golang.org/profiling-go-programs<>Profiling Go Programs) en el Blog
   de Go.

** Seccion 11.6 <> Funciones @c(Example)

   El tercer tipo de funcion tratada especialmente por @$(go test) es una
   funcion de ejemplo, cuyo nombre empieza con @c(Example). No tiene parametros
   ni resultados. Aqui un ejemplo para la funcion @c(IsPalindrome):

   ..src > go
     func ExampleIsPalindrome() {
       fmt.Println(IsPalindrome("A man, a plan, a canal: Panama"))
       fmt.Println(IsPalindrome("palindrome"))
       // Output:
       // true
       // false
     }
   < src..

   Las funciones de ejemplo sirven para tres propositos. El principal es la
   documentacion: un buen ejemplo puede ser una forma mas sucinta o intuitiva de
   transmitir el comportamiento de una funcion de libreria, que su descripcion
   en prosa, especialmente cuando se usa como recordatorio o referencia
   rapida. Un ejemplo tambien puede demostrar la interaccion entre varios tipos
   y funciones pertenecientes a una API, mientras que la documentacion en prosa
   siempre debe estar unida a un lugar, como una declaracion de tipo o funcion o
   el paquete en su conjunto. Y a diferencia de los ejemplos dentro de los
   comentarios, las funciones de ejemplo son codigo Go real, sujeto a
   comprobacion en tiempo de compilacion, para que no se vuelvan obsoletos a
   medida que el codigo evoluciona.

   Basado en el sufijo @c(Example) de la de funcion, el servidor de
   documentacion basado en la web @$(godoc) asocia funciones ejemplo con la
   funcion o el paquete que ejemplifican, por lo que @c(ExampleIsPalindrome) se
   mostrara con la documentacion para la funcion @c(IsPalindrome), y se asociara
   una funcion de ejemplo llamado simplemente @c(Example) asociado con el
   paquete @c(word) en su conjunto.

   El segundo proposito es que los ejemplos son pruebas ejecutables dirigidas
   por @$(go test). Si la funcion de ejemplo contiene un comentario final @c(//
   Output:) como el de arriba, el manejador de pruebas ejecutara la funcion y
   comprobar que lo que se imprime en la salida estandar coincide con el texto
   dentro de los comentarios.

   El tercer objetivo de un ejemplo es la experimentacion practica. El servidor
   @$(godoc) en @c(golang.org) utiliza la Zona de juegos para permitir al
   usuario editar y ejecutar cada funcion de ejemplo desde un navegador web,
   como se muestra en la Figura 11.4. Esta es a menudo la manera mas rapida de
   conseguir una sensacion para una funcion o caracteristica del lenguaje
   particular.

   ..figure > Figura 11.4. Un ejemplo interactiva de @c(strings.Join) en @$(godoc).

     ..img  > img/Figure-11.4.jpg


   Los dos capitulos finales del libro examinan los paquetes @c(reflect) y
   @c(unsafe), que pocos programadores Go utilizan regularmente–e incluso menos
   @e(necesitan) usarlos. Si aun no ha escrito ningun programa de Go sustancial,
   ahora seria un buen momento para hacerlo.

* Capitulo 12 <> Reflexion

  Go proporciona un mecanismo para actualizar variables e inspeccionar sus
  valores en tiempo de ejecucion, llamar a sus metodos y aplicar las operaciones
  intrinsecas a su representacion, todo sin conocer sus tipos en tiempo de
  compilacion. Este mecanismo se denomina @e(reflexion). La reflexion tambien
  nos permite tratar los propios tipos como valores de primera clase.

  En este capitulo, vamos a explorar las caracteristicas de reflexion de Go para
  ver la forma en que aumentan la expresividad del lenguaje, y en particular la
  forma en que son cruciales para la implementacion de dos APIs importantes: el
  formateo de cadenas proporcionado por @c(fmt), y el protocolo de codificacion
  proporcionado por los paquetes @c(encoding/json) y @c(encoding/xml). La
  reflexion es tambien esencial para el mecanismo de plantilla proporcionada por
  los paquetes @c(text/template) y @c(html/template) que vimos en la @l(#Seccion
  4.6). Sin embargo, es complejo razonar la reflexion y no es para uso casual,
  por lo que aunque estos paquetes se implementan mediante la reflexion, no
  exponen la reflexion en sus propias API.

** Seccion 12.1 <> ¿Por que la Reflexion?

   A veces necesitamos escribir una funcion capaz de tratar uniformemente con
   valores de tipos que no satisfacen una interfaz comun, no tienen una
   representacion conocida o no existen en el momento en que diseñamos la
   funcion–o incluso los tres.

   Un ejemplo familiar es la logica de formateo dentro de @c(fmt.Fprintf), que
   puede imprimir de manera util un valor arbitrario de cualquier tipo, incluso
   uno definido por el usuario. Tratemos de implementar una funcion como esta
   usando lo que ya sabemos. Para simplificar, nuestra funcion acepta un
   argumento y devuelve el resultado como una cadena como hace @c(fmt.Sprint),
   asi que vamos a llamarlo @c(Sprint).

   Empezamos con un @c(switch) de tipo que pone a prueba si el argumento define
   una metodo @c(String), y lo llaman si es asi. A continuacion, agregamos casos
   que ponen a prueba el tipo dinamico del valor en cada uno de los tipos
   basicos–@c(string), @c(int), @c(bool), etc–y realiza la operacion de formato
   adecuado en cada caso.

   ..src > go
     func Sprint(x interface{}) string {
       type stringer interface {
         String() string
       }
       switch x := x.(type) {
       case stringer:
         return x.String()
       case string:
         return x
       case int:
         return strconv.Itoa(x)
         // ...casos similares para int16, uint32, y demas...
       case bool:
         if x {
           return "true"
         }
         return "false"
       default:
         // array, chan, func, map, pointer, slice, struct
         return "???"
       }
     }
   < src..

   Pero, ¿como podemos hacer frente a otros tipos, como @c([]float64),
   @c(map[string][]string), y demas? Podriamos añadir mas casos, pero el numero
   de tales tipos es infinito. Y que pasa con los tipos con nombre, como
   @c(url.Values)? Incluso si el @c(switch) de tipo tenia un caso para su tipo
   subyacente @c(map[string][]string), no coincidira con con @c(url.Values)
   porque los dos tipos no son identicos, y el interruptor de tipo no puede
   incluir un caso para cada tipo como @c(url.Values) porque eso requeriria que
   esta libreria dependa de sus clientes.

   Sin una manera de inspeccionar la representacion de valores de tipos
   desconocidos, rapidamente nos quedamos atascados. Lo que necesitamos es
   reflexion.

** Seccion 12.2 <> @c(reflect.Type) y @c(reflect.Value)

   La reflexion es proporcionada por el paquete @c(reflect). Este define dos
   tipos importantes, @c(Type) y @c(Value). @c(Type) representa un tipo Go. Es
   una interfaz con muchos metodos para discriminar entre tipos e inspeccionar
   sus componentes, como los campos de una estructura o los parametros de una
   funcion. La unica aplicacion de @c(reflect.Type) es el descriptor de tipo
   @%l(#Seccion 7.5<>§7.5), la misma entidad que identifica el tipo dinamico de
   un valor interfaz.

   la funcion @c(reflect.TypeOf) acepta cualquier @c(interface{}) y devuelve su
   tipo dinamico como @c(reflect.Type):

   ..src > go
     t := reflect.TypeOf(3)  // un reflect.Type
     fmt.Println(t.String()) // "int"
     fmt.Println(t)          // "int"
   < src..

   La llamada @c[TypeOf(3)] anterior asigna el valor 3 al parametro
   @c(interface{}). Recuerde de la @l(#Seccion 7.5) que una asignacion de un
   valor concreto a un tipo de interfaz lleva a cabo una conversion de la
   interfaz implicita, que crea un valor interfaz que consta de dos componentes:
   su @e(tipo dinamico) es el tipo del operando @%c(int) y su @e(valor
   dinamico) es el valor del operando (3).

   Ya que @c(reflect.TypeOf) regresa el tipo dinamico de un valor de interfaz,
   siempre devuelve un tipo concreto. Asi, por ejemplo, el codigo que aparce a
   continuacion imprime @"c(*os.File), no @"c(*io.Writer). Mas tarde,
   veremos que @c(reflect.Type) es capaz de representar tipos de interfaz
   tambien.

   ..src > go
     var w io.Writer = os.Stdout
     fmt.Println(reflect.TypeOf(w)) // "*os.File"
   < src..

   Observe que @c(reflect.Type) satisface @c(fmt.Stringer). Como la impresion
   del tipo dinamico de un valor interfaz es util para depuracion y registro,
   @c(fmt.Printf) proporciona una abreviatura, @c(%T), que internamente utiliza
   @c(reflect.TypeOf):

   ..src > go
     fmt.Printf("%T\n", 3) // "int"
   < src..

   El otro tipo importante en el paquete @c(reflect) es @c(Value). Un
   @c(reflect.Value) puede contener un valor de cualquier tipo. La funcion
   @c(reflect.ValueOf) acepta cualquier @c(interface{}) y devuelve un valor
   @c(reflect.Value) que contiene el valor dinamico de la interfaz. Al igual que
   con @c(reflect.TypeOf), los resultados de @c(reflect.ValueOf) son siempre
   concretos, pero un @c(reflect.Value) pueden contener valores de interfaz
   tambien.

   ..src > go
     v := reflect.ValueOf(3)  // un reflect.Value
     fmt.Println(v)           // "3"
     fmt.Printf("%v\n", v)    // "3"
     fmt.Println(v.String())  // NOTA: "<int Value>"
   < src..

   Al igual que @c(reflect.Type), @c(reflect.Value) tambien satisface
   @c(fmt.Stringer), pero a menos que @c(Value) contenga un string, el resultado
   del metodo @c(String) solo revela el tipo. En su lugar, utilice el verbo
   @c(%v) del paquete @c(fmt), que maneja @c(reflect.Values) especialmente.

   Al llamar al metodo @c(Type) en un @c(Value) devuelve su tipo como
   @c(reflect.Type):

   ..src > go
     t := v.Type()           // un reflect.Type
     fmt.Println(t.String()) // "int"
   < src..

   La operacion inversa de @c(reflect.ValueOf) es el metodo
   @c(reflect.Value.Interface). Devuelve una @c(interface{}) que contiene el
   mismo valor concreto que @c(reflect.Value):

   ..src > go
     v := reflect.ValueOf(3) // un reflect.Value
     x := v.Interface()      // un interface{}
     i := x.(int)            // un int
     fmt.Printf("%d\n", i)   // "3"
   < src..

   Un @c(reflect.Value) y una @c(interface{}) pueden ambos contener valores
   arbitrarios. La diferencia es que una interfaz vacia oculta la representacion
   y las operaciones intrinsecas del valor que contiene y no expone ninguno de
   sus metodos, de modo que a menos que conozcamos su tipo dinamico y usemos una
   asercion de tipo para mirar dentro (como lo hicimos anteriormente), hay Poco
   que podemos hacer con el valor. Por el contrario, un @c(Value) tiene muchos
   metodos para inspeccionar su contenido, independientemente de su tipo. Vamos
   a utilizarlos para nuestro segundo intento de una funcion de formateo
   general, que llamaremos @c(format.Any).

   En lugar de un switch de tipo, usaremos @c(reflect.Value) y su metodo
   @c(Kind) para discriminar los casos. Aunque hay un numero infinito de tipos,
   solo hay un numero finito de @c(kinds) de tipo: los tipos basicos @c(Bool),
   @c(String), y todos los numeros; los tipos agregados @c(Array) y @c(Struct);
   los tipos de referencia @c(Chan), @c(Func), @c(Ptr), @c(Slice), y @c(Map);
   los tipos @c(Interface); y, finalmente, @c(Invalid), es decir, sin valor
   alguno. (El valor cero de una @c(reflect.Value) tiene una tipo @c(Invalid).)

   ..figure > @l(gopl.io/ch12/format/format.go<>gopl.io/ch12/format)

     ..src > go
       package format

       import (
         "reflect"
         "strconv"
       )

       // Any formatea cualquier valor como un string.
       func Any(value interface{}) string {
         return formatAtom(reflect.ValueOf(value))
       }

       // formatAtom formatea un valor sin inspeccionar su estructura interna.
       func formatAtom(v reflect.Value) string {
         switch v.Kind() {
         case reflect.Invalid:
           return "invalid"
         case reflect.Int, reflect.Int8, reflect.Int16,
           reflect.Int32, reflect.Int64:
           return strconv.FormatInt(v.Int(), 10)
         case reflect.Uint, reflect.Uint8, reflect.Uint16,
           reflect.Uint32, reflect.Uint64, reflect.Uintptr:
           return strconv.FormatUint(v.Uint(), 10)
         // ...Casos de punto flotante y complejos omitidos por brevedad...
         case reflect.Bool:
           return strconv.FormatBool(v.Bool())
         case reflect.String:
           return strconv.Quote(v.String())
         case reflect.Chan, reflect.Func, reflect.Ptr, reflect.Slice, reflect.Map:
           return v.Type().String() + " 0x" +
             strconv.FormatUint(uint64(v.Pointer()), 16)
         default: // reflect.Array, reflect.Struct, reflect.Interface
           return v.Type().String() + " value"
         }
       }
     < src..


   Hasta ahora, nuestra funcion maneja cada valor como una cosa indivisible, sin
   estructura interna–de ahi @c(formatAtom). Para los tipos de agregados
   (estructuras y matrices) y las interfaces se imprime unicamente el @e(tipo)
   del valor, y para los tipos de referencia (canales, funciones, punteros,
   slices, y mapas), se imprime el tipo y la direccion de referencia en
   hexadecimal. Esto es menos que ideal, pero sigue siendo una importante
   mejora, y ya que @c(Kind) se ocupa solo con la representacion subyacente,
   @c(format.Any) funciona tambien para los timpos con nombre. Por ejemplo:

   ..src > go
     var x int64 = 1
     var d time.Duration = 1 * time.Nanosecond
     fmt.Println(format.Any(x))                  // "1"
     fmt.Println(format.Any(d))                  // "1"
     fmt.Println(format.Any([]int64{x}))         // "[]int64 0x8202b87b0"
     fmt.Println(format.Any([]time.Duration{d})) // "[]time.Duration 0x8202b87e0"
   < src..

** Seccion 12.3 <> @c(Display), una Impresora Recursiva de Valor

   A continuacion veremos como mejorar la visualizacion de tipos compuestos. En
   lugar de tratar de copiar @c(fmt.Sprint) exactamente, vamos a construir una
   funcion de utilidad de depuracion llamada @c(Display) que, dado un valor
   @c(x) arbitrariamente complejo, imprime la estructura completa de ese valor,
   etiquetando cada elemento con el camino por el cual se encontro. Comencemos
   con un ejemplo.

   ..src > go
     e, _ := eval.Parse("sqrt(A / pi)")
     Display("e", e)
   < src..

   En la llamada anterior, el argumento de @c(Display) es un arbol sintactico
   del evaluador de expresiones en la @l(#Seccion 7.9). La salida de @c(Display)
   se muestra a continuacion:

   ..srci > sh
     Display e (eval.call):
     e.fn = "sqrt"
     e.args[0].type = eval.binary
     e.args[0].value.op = 47
     e.args[0].value.x.type = eval.Var
     e.args[0].value.x.value = "A"
     e.args[0].value.y.type = eval.Var
     e.args[0].value.y.value = "pi"
   < srci..

   Cuando sea posible, debe evitar exponer la reflexion en la API de un
   paquete. Definiremos un funcion sin exportacion @c(display) para hacer el
   trabajo real de la recursividad, y la exportacion @c(Display), un simple
   envoltorio alrededor de el que acepta un parametro @c(interface{}):

   ..figure > @l(gopl.io/ch12/display/display.go<>gopl.io/ch12/display)

     ..src > go
       func Display(name string, x interface{}) {
         fmt.Printf("Display %s (%T):\n", name, x)
         display(name, reflect.ValueOf(x))
       }
     < src..


   En @c(display), usaremos la funcion @c(formatAtom) que definimos anteriormente
   para imprimir valores elementales–tipos basicos, funciones y canales–pero
   vamos a utilizar los metodos de @c(reflect.Value) para mostrar repetidamente cada
   componente de un tipo mas complejo. A medida que la recursion desciende, la cadena de
   ruta que describe inicialmente el valor de partida (por ejemplo, @"c(e)),
   se incrementara para indicar como alcanzamos el valor actual (por
   ejemplo, @"c(e.args[0].value)).

   Como ya no pretendemos implementar @c(fmt.Sprint), utilizaremos el paquete
   @c(fmt) para mantener nuestro ejemplo corto.

   ..src > go
     func display(path string, v reflect.Value) {
       switch v.Kind() {
       case reflect.Invalid:
         fmt.Printf("%s = invalid\n", path)
       case reflect.Slice, reflect.Array:
         for i := 0; i < v.Len(); i++ {
           display(fmt.Sprintf("%s[%d]", path, i), v.Index(i))
         }
       case reflect.Struct:
         for i := 0; i < v.NumField(); i++ {
           fieldPath := fmt.Sprintf("%s.%s", path, v.Type().Field(i).Name)
           display(fieldPath, v.Field(i))
         }
       case reflect.Map:
         for _, key := range v.MapKeys() {
           display(fmt.Sprintf("%s[%s]", path, formatAtom(key)), v.MapIndex(key))
         }
       case reflect.Ptr:
         if v.IsNil() {
           fmt.Printf("%s = nil\n", path)
         } else {
           display(fmt.Sprintf("(*%s)", path), v.Elem())
         }
       case reflect.Interface:
         if v.IsNil() {
           fmt.Printf("%s = nil\n", path)
         } else {
           fmt.Printf("%s.type = %s\n", path, v.Elem().Type())
           display(path+".value", v.Elem())
         }
       default: // basic types, channels, funcs
         fmt.Printf("%s = %s\n", path, formatAtom(v))
       }
     }
   < src..


   Vamos a discutir los casos en orden.

   - Slices y arreglos :: La logica es la misma para ambos. El metodo @c(Len)
     devuelve el numero de elementos de un valor slice o arreglo, e @c[Index(i)]
     recupera el elemento en el indice @c(i), tambien como un @c(reflect.Value);
     entra en panico si @c(i) esta fuera de limites. Esto es analogo al
     @c[len(a)] nativo y a la operacion en secuencias @c(a[i]). La funcion
     @c(display) se invoca a si misma recursivamente en cada elemento de la
     secuencia, añadiendo la notacion subindice @"c([i]) a la trayectoria.

     Aunque @c(reflect.Value) tiene muchos metodos, solo unos pocos son seguros
     para llamar a cualquier valor dado. Por ejemplo, el metodo @c(Index) puede
     ser llamado en valores de tipo @c(Slice), @c(Array) o @c(String), pero
     entra en panico para cualquier otro tipo.

   - Estructuras :: El metodo @c(NumField) informa el numero de campos en la
     estructura, y @c[Field(i)] devuelve el valor del campo @c(i) como un
     @c(reflect.Value). La lista de campos incluye los promocionados desde
     campos anonimos. Para añadir la notacion de selector de campo @"c(.f) a
     la ruta, debemos obtener el @c(reflect.Type) de la estructura y tener
     acceso al nombre de su campo @c(i).

   - Mapas :: El metodo @c(MapKeys) devuelve un slice de @c(reflect.Values), uno
     por cada clave del mapa. Como de costumbre cuando se itera sobre un mapa,
     el orden no esta definido. @c[MapIndex(key)] devuelve el valor
     correspondiente a @c(key). Añadimos la notacion de subindice @"c([key])
     a la ruta. (Estamos cortando una esquina aqui el tipo de una clave del mapa
     no se limita a los tipos que @c(formatAtom) maneja mejor; arreglos,
     estructuras e interfaces tambien pueden ser claves validas de mapa.
     Extender este caso para imprimir la clave en su totalidad es el
     Ejercicio. 12.1.)

   - Punteros :: El metodo @c(Elem) devuelve la variable a la que apunta un
     puntero, de nuevo como un @c(reflect.Value). Esta operacion seria segura
     incluso si el valor del puntero es @c(nil), en cuyo caso el resultado
     tendria tipo @c(Invalid), pero utilizamos @c(IsNil) para detectar punteros
     nulos de manera explicita por lo que podemos imprimir un mensaje mas
     apropiado. Prefijamos el camino con un @"c(*) y un parentesis para
     evitar la ambigüedad.

   - Interfaces :: Una vez mas, utilizamos @c(IsNil) para probar si la interfaz
     es nil, y si no, recuperamos su valor dinamico utilizando @c[v.Elem()] e
     imprimimos su tipo y valor.


   Ahora que nuestra funcion @c(Display) esta completa, vamos a ponerla a
   trabajar. El tipo @c(Movie) a continuacion es una ligera variacion del
   mostrado en la @l(#Seccion 4.5):

   ..src > go
     type Movie struct {
       Title, Subtitle string
       Year            int
       Color           bool
       Actor           map[string]string
       Oscars          []string
       Sequel          *string
     }
   < src..

   Vamos a declarar un valor de este tipo y ver lo que hace @c(Display) con el:

   ..src > go
     strangelove := Movie{
       Title:    "Dr. Strangelove",
       Subtitle: "How I Learned to Stop Worrying and Love the Bomb",
       Year:     1964,
       Color:    false,
       Actor: map[string]string{
         "Dr. Strangelove":            "Peter Sellers",
         "Grp. Capt. Lionel Mandrake": "Peter Sellers",
         "Pres. Merkin Muffley":       "Peter Sellers",
         "Gen. Buck Turgidson":        "George C. Scott",
         "Brig. Gen. Jack D. Ripper":  "Sterling Hayden",
         `Maj. T.J. "King" Kong`:      "Slim Pickens",
       },
       Oscars: []string{
         "Best Actor (Nomin.)",
         "Best Adapted Screenplay (Nomin.)",
         "Best Director (Nomin.)",
         "Best Picture (Nomin.)",
       },
     }
   < src..

   La llamada @c[Display("strangelove", strangelove)] imprime:

   ..pre >
     Display strangelove (display.Movie):
     strangelove.Title = "Dr. Strangelove"
     strangelove.Subtitle = "How I Learned to Stop Worrying and Love the Bomb"
     strangelove.Year = 1964
     strangelove.Color = false
     strangelove.Actor["Gen. Buck Turgidson"] = "George C. Scott"
     strangelove.Actor["Brig. Gen. Jack D. Ripper"] = "Sterling Hayden"
     strangelove.Actor["Maj. T.J. \"King\" Kong"] = "Slim Pickens"
     strangelove.Actor["Dr. Strangelove"] = "Peter Sellers"
     strangelove.Actor["Grp. Capt. Lionel Mandrake"] = "Peter Sellers"
     strangelove.Actor["Pres. Merkin Muffley"] = "Peter Sellers"
     strangelove.Oscars[0] = "Best Actor (Nomin.)"
     strangelove.Oscars[1] = "Best Adapted Screenplay (Nomin.)"
     strangelove.Oscars[2] = "Best Director (Nomin.)"
     strangelove.Oscars[3] = "Best Picture (Nomin.)"
     strangelove.Sequel = nil
   < pre..

   Podemos utilizar @c(Display) para mostrar el funcionamiento interno de los
   tipos de librerias, como @c(*os.File):

   ..pre >
     Display("os.Stderr", os.Stderr)
     // Output:
     // Display os.Stderr (*os.File):
     // (*(*os.Stderr).file).fd = 2
     // (*(*os.Stderr).file).name = "/dev/stderr"
     // (*(*os.Stderr).file).nepipe = 0
   < pre..

   Observe que incluso los campos no exportados son visibles para la reflexion.
   Tenga en cuenta que la salida particular de este ejemplo puede variar entre
   plataformas y puede cambiar con el tiempo a medida que las librerias
   evolucionan. (Esos campos son privados por una razon!) Incluso podemos
   aplicar @c(Display) a un @c(reflect.Value) y verlo atravesar la
   representacion interna del descriptor de tipo de @c(*os.File). La salida de
   la llamada @c[Display("rV", reflect.ValueOf(os.Stderr))] se muestra a
   continuacion, aunque, por supuesto, su experiencia puede variar:

   ..pre >
     Display rV (reflect.Value):
     (*rV.typ).size = 8
     (*rV.typ).hash = 871609668
     (*rV.typ).align = 8
     (*rV.typ).fieldAlign = 8
     (*rV.typ).kind = 22
     (*(*rV.typ).string) = "*os.File"
     (*(*(*rV.typ).uncommonType).methods[0].name) = "Chdir"
     (*(*(*(*rV.typ).uncommonType).methods[0].mtyp).string) = "func() error"
     (*(*(*(*rV.typ).uncommonType).methods[0].typ).string) = "func(*os.File) error"
     ...
   < pre..

   Observe la diferencia entre estos dos ejemplos:

   ..src > go
     var i interface{} = 3
     Display("i", i)
     // Output:
     // Display i (int):
     // i = 3

     Display("&i", &i)
     // Output:
     // Display &i (*interface {}):
     // (*&i).type = int
     // (*&i).value = 3
   < src..

   En el primer ejemplo, @c(Display) llama a @c[reflect.ValueOf(i)], que
   devuelve un valor de tipo @c(Int). Como mencionamos en la @l(#Seccion 12.2),
   @c(reflect.ValueOf) siempre devuelve un valor de un tipo concreto ya que
   extrae el contenido de un valor interfaz.

   En el segundo ejemplo, @c(Display) llama a @c[reflect.ValueOf(&i)], que
   devuelve un puntero a @c(i), de tipo @c(Ptr). El caso del switch para @c(Ptr)
   llama a @c(Elem) en este valor, que devuelve un valor que representa la
   @e(variable) @c(i) en si, del tipo @c(Interface). Un @c(Value) obtenido
   indirectamente, como este, puede representar cualquier valor en absoluto,
   incluyendo interfaces. La funcion @c(display) se llama a si misma de forma
   recursiva y esta vez, imprime componentes separados para el tipo y valor
   dinamico de la interfaz.

   Tal como se aplica actualmente, @c(Display) nunca terminara si encuentra un
   ciclo en el grafico del objeto, como esta lista enlazada que se come su
   propia cola:

   ..src > go
     // une estructura que apunta a si misma
     type Cycle struct{ Value int; Tail *Cycle }
     var c Cycle
     c = Cycle{42, &c}
     Display("c", c)
   < src..

   @c(Display) imprime esta expansion cada vez mayor:

   ..src > go
     Display c (display.Cycle):
     c.Value = 42
     (*c.Tail).Value = 42
     (*(*c.Tail).Tail).Value = 42
     (*(*(*c.Tail).Tail).Tail).Value = 42
     ...ad infinitum...
   < src..

   Muchos programas Go contienen al menos algunos datos ciclicos. Hacer a
   @c(Display) robusto frente a estos ciclos es complicado, requiriendo
   contabilidad adicional para registrar el conjunto de referencias que se han
   seguido hasta ahora; tambien es costoso. Una solucion general requiere la
   caracteristicas @c(unsafe) del lenguaje, como veremos en la @l(#Seccion
   13.3).

   Los ciclos plantean un problema menor para @c(fmt.Sprint), ya que rara vez se
   intenta imprimir la estructura completa. Por ejemplo, cuando encuentra un
   puntero, rompe la recursion imprimiendo el valor numerico del puntero. Puede
   quedar atrapado tratando de imprimir un slice o un mapa que se contiene como
   un elemento, pero estos casos raros no garantizan el considerable problema
   adicional de la manipulacion de ciclos.

   @b(Ejercicio 12.1): Ampliar @c(Display) para que pueda mostrar mapas cuyas claves
   son estructuras o matrices.

   @b(Ejercicio 12.2): Hacer a @c(display) seguro de usar en estructuras de datos
   ciclicas limitando el numero de pasos necesarios antes de abandonar la
   recursividad. (En la @l(#Seccion 13.3), veremos otra forma de detectar
   ciclos).

** Seccion 12.4 <> Ejemplo: Codificacion de Expressions-S

   @c(Display) es una rutina de depuracion para la visualizacion de datos
   estructurados, pero no esta muy lejos de ser capaz de codificar u @e(ordenar)
   objetos Go arbitrarios como mensajes en una notacion portatil adecuada para
   la comunicacion entre procesos.

   Como vimos en la @l(#Seccion 4.5), la libreria estandar de Go es compatible
   con una variedad de formatos, incluyendo JSON, XML y ASN.1. Otra notacion que
   todavia se utiliza ampliamente son @e(expresiones-S), la sintaxis de Lisp. A
   diferencia de las otras notaciones, las expresiones-S no son compatibles con
   la libreria estandar de Go, no menos porque no tienen una definicion
   universalmente aceptada, a pesar de varios intentos de estandarizacion y la
   existencia de muchas implementaciones.

   En esta seccion, definiremos un paquete que codifica objetos Go arbitrarios
   usando una notacion de expresiones-S que admita las siguientes construcciones:

   +-------------+-----------------------------------------------------+
   | @c(42)      | entero                                              |
   +-------------+-----------------------------------------------------+
   | @c("hello") | cadena  (con notacion en estilo Go)                 |
   +-------------+-----------------------------------------------------+
   | @c(foo)     | symbolo (un nombre sin cita)                        |
   +-------------+-----------------------------------------------------+
   | @c[(1 2 3)] | lista   (zero o mas elementos entre parentesis)     |
   +-------------+-----------------------------------------------------+

   Los booleanos tradicionalmente se codifican utilizando el simbolo @c(t) para
   verdadero, y la lista vacia @c[()] o el simbolo @c(nil) para falso, pero
   por simplicidad, nuestra implementacion los ignora. Tambien ignora canales y
   funciones, ya que su estado es opaco a la reflexion. Y no hace caso de
   numeros reales y complejos de punto flotante e interfaces. Agregar soporte
   para ellos es el @l(#Ejercicio 12.3).

   Vamos a codificar los tipos de Go usando expresiones-S como sigue. Los
   enteros y las cadenas se codifican de la manera obvia. Los valores Nil se
   codifican como el simbolo @c(nil). Los arrays y slices se codifican
   utilizando la notacion de lista.

   Las estructuras se codifican como una lista de campos enlazados, siendo cada
   enlace de campo una lista de dos elementos cuyo primer elemento (un simbolo)
   es el nombre del campo y cuyo segundo elemento es el valor del campo. Los
   mapas tambien se codifican como una lista de pares, siendo cada par la clave
   y el valor de una entrada de mapa. Tradicionalmente, las expresiones-S
   representan listas de pares clave/valor utilizando una sola celula @e(cons)
   @c[(clave . valor)] para cada par, en lugar de una lista de dos elementos, pero
   para simplificar la decodificacion ignoraremos la notacion de lista punteada.

   La codificacion se realiza por una sola funcion recursiva, @c(encode), que se
   muestra continuacion. Su estructura es esencialmente la misma que la de
   @c(Display) en la seccion anterior:

   ..figure > @l(gopl.io/ch12/sexpr/encode.go<>gopl.io/ch12/sexpr)

     ..src > go
       func encode(buf *bytes.Buffer, v reflect.Value) error {
         switch v.Kind() {
         case reflect.Invalid:
           buf.WriteString("nil")

         case reflect.Int, reflect.Int8, reflect.Int16,
           reflect.Int32, reflect.Int64:
           fmt.Fprintf(buf, "%d", v.Int())

         case reflect.Uint, reflect.Uint8, reflect.Uint16,
           reflect.Uint32, reflect.Uint64, reflect.Uintptr:
           fmt.Fprintf(buf, "%d", v.Uint())

         case reflect.String:
           fmt.Fprintf(buf, "%q", v.String())

         case reflect.Ptr:
           return encode(buf, v.Elem())

         case reflect.Array, reflect.Slice: // (value ...)
           buf.WriteByte('(')
           for i := 0; i < v.Len(); i++ {
             if i > 0 {
               buf.WriteByte(' ')
             }
             if err := encode(buf, v.Index(i)); err != nil {
               return err
             }
           }
           buf.WriteByte(')')

         case reflect.Struct: // ((name value) ...)
           buf.WriteByte('(')
           for i := 0; i < v.NumField(); i++ {
             if i > 0 {
               buf.WriteByte(' ')
             }
             fmt.Fprintf(buf, "(%s ", v.Type().Field(i).Name)
             if err := encode(buf, v.Field(i)); err != nil {
               return err
             }
             buf.WriteByte(')')
           }
           buf.WriteByte(')')

         case reflect.Map: // ((key value) ...)
           buf.WriteByte('(')
           for i, key := range v.MapKeys() {
             if i > 0 {
               buf.WriteByte(' ')
             }
             buf.WriteByte('(')
             if err := encode(buf, key); err != nil {
               return err
             }
             buf.WriteByte(' ')
             if err := encode(buf, v.MapIndex(key)); err != nil {
               return err
             }
             buf.WriteByte(')')
           }
           buf.WriteByte(')')

         default: // float, complex, bool, chan, func, interface
           return fmt.Errorf("unsupported type: %s", v.Type())
         }
         return nil
       }
     < src..


   La funcion @c(Marshal) envuelve el codificador en una API similar a los de
   otros paquetes @c(encoding/...):

   ..src > go
     // Marshal codifica un valor Go en forma de expresion-S.
     func Marshal(v interface{}) ([]byte, error) {
       var buf bytes.Buffer
       if err := encode(&buf, reflect.ValueOf(v)); err != nil {
         return nil, err
       }
       return buf.Bytes(), nil
     }
   < src..

   Aqui esta la salida que @c(Marshal) aplica a la variable @c(strangelove) de
   la @l(#Seccion 12.3):

   ..src > lisp
     ((Title "Dr. Strangelove") (Subtitle "How I Learned to Stop Worrying and Love the Bomb") (Year 1964) (Actor (("Grp. Capt. Lionel Mandrake" "Peter Sellers") ("Pres. Merkin Muffley" "Peter Sellers") ("Gen. Buck Turgidson" "George C. Scott") ("Brig. Gen. Jack D. Ripper" "Sterling Hayden") ("Maj. T.J. \"King\" Kong" "Slim Pickens") ("Dr. Strangelove" "Peter Sellers"))) (Oscars ("Best Actor (Nomin.)" "Best Adapted Screenplay (Nomin.)" "Best Director (Nomin.)" "Best Picture (Nomin.)")) (Sequel nil))
   < src..

   Toda la salida aparece en una linea larga con espacios minimos, por lo que es
   dificil de leer. Esta es la misma salida formateada manualmente de acuerdo
   con las convenciones de expresion-S. Escribir una bonita impresora para las
   expresiones-S se deja como un ejercicio (desafiante); la descarga de
   @c(gopl.io) incluye una version simple.

   ..src > lisp
     ((Title "Dr. Strangelove")
      (Subtitle "How I Learned to Stop Worrying and Love the Bomb")
      (Year 1964)
      (Actor (("Grp. Capt. Lionel Mandrake" "Peter Sellers")
              ("Pres. Merkin Muffley" "Peter Sellers")
              ("Gen. Buck Turgidson" "George C. Scott")
              ("Brig. Gen. Jack D. Ripper" "Sterling Hayden")
              ("Maj. T.J. \"King\" Kong" "Slim Pickens")
              ("Dr. Strangelove" "Peter Sellers")))
      (Oscars ("Best Actor (Nomin.)"
               "Best Adapted Screenplay (Nomin.)"
               "Best Director (Nomin.)"
               "Best Picture (Nomin.)"))
      (Sequel nil))
   < src..

   Al igual las funciones @c(fmt.Print), @c(json.Marshal) y @c(Display),
   @c(sexpr.Marshal) entrara en un bucle infinito se llama con datos ciclicos.

   En la @l(#Seccion 12.6), esbozaremos la implementacion de la funcion de
   decodificacion de expreciones-S correspondiente, pero antes de llegar alli,
   primero debemos entender como se puede usar la reflexion para actualizar las
   variables del programa.

   @b(Ejercicio 12.3): Implementar los casos faltantes de la funcion @c(encode).
   Codifique booleanos como @c(t) y @c(nil), numeros de punto flotante
   utilizando la notacion de Go, y los numeros complejos como @m(1+2i) como
   @c[#C(1.0 2.0)]. Las interfaces se pueden codificar como un par de nombre de
   tipo y un valor, por ejemplo @c[("[]int" (1 2 3))], pero cuidado que esta
   notacion es ambigua: el metodo @c(reflect.Type.String) puede devolver la
   misma cadena para diferentes tipos.

   @b(Ejercicio 12.4): Modifique @c(encode) para imprimir expresiones-S con el
   estilo mostrado anteriormente.

   @b(Ejercicio 12.5): Adapte @c(encode) para producir JSON en lugar de
   expresiones-S. Pruebe su codificador utilizando el descodificador estandar,
   @c(json.Unmarshal).

   @b(Ejercicio 12.6): Adapte @c(encode) para que a manera de optimizacion, no
   codifique un campo cuyo valor es el valor cero de su tipo.

   @b(Ejercicio 12.7): Crear un API de streaming para la codificacion de
   expresiones-S, siguiendo el estilo de @c(json.Encoder) @%l(#Seccion
   4.5<>§4.5).

** Seccion 12.5 <> Configurar Variables con @c(reflect.Value)

   Hasta el momento, la reflexion solo ha @e(interpretado) los valores en
   nuestro programa de diversas maneras. El punto de esta seccion, es
   @c(cambiarlos).

   Recordemos que algunas expresiones como @c(x), @c(x.f[1]), y @c(*p) denotan
   variables, pero otras como @c(x + 1) y @c[f(2)] no. Una variable es una
   ubicacion de almacenamiento @e(direccionable) que contiene un valor, y su
   valor puede ser actualizado a traves de esa direccion.

   Una distincion similar se aplica a @c(reflect.Values). Algunos son
   direccionables; otros no lo son. Considere las siguientes declaraciones:

   ..src > go
     x := 2                     // valor   tipo   variable?
     a := reflect.ValueOf(2)    // 2       int    no
     b := reflect.ValueOf(x)    // 2       int    no
     c := reflect.ValueOf(&x)   // &x      *int   no
     d := c.Elem()              // 2       int    si (x)
   < src..


   El valor dentro de @c(a) no es direccionable. Se trata simplemente de una
   copia del entero 2. Lo mismo es cierto para @c(b). El valor dentro de @c(c)
   tambien es no direccionable, siendo una copia del valor de puntero @c(&x). De
   hecho, @c(reflect.Value) devuelto por @c[reflect.ValueOf(x)] no es
   direccionable. Pero @c(d), derivado de @c(c) mediante la desreferenciacion
   del puntero un su interior, se refiere a una variable y es, por tanto
   direccionable. Podemos utilizar este enfoque, llamando a
   @c[reflect.ValueOf(&x).Elem()], para obtener un @c(Value) direccionable de
   cualquier variable @c(x).

   Podemos pregruntar a @c(reflect.Value) si es direccionable a traves de su
   metodo @c(CanAddr):

   ..src > go
     fmt.Println(a.CanAddr()) // "false"
     fmt.Println(b.CanAddr()) // "false"
     fmt.Println(c.CanAddr()) // "false"
     fmt.Println(d.CanAddr()) // "true"
   < src..

   Obtenemos un @c(reflect.Value) direccionable siempre indirectamente atravez
   de un puntero, incluso si partimos de un @c(Value) no-direccionable. Todas
   las reglas habituales de direccionabilidad tienen analogos para la
   reflexion. Por ejemplo, ya que la expresion de indexacion de un slice
   @c(e[i]) sigue implicitamente un puntero, es direccionable incluso si la
   expresion @c(e) no lo es. Por analogia, @c[reflect.ValueOf(e).Index(i)] se
   refiere a una variable, y por tanto es direccionable incluso si
   @c[reflect.ValueOf(e)] no lo es.

   Para recuperar la variable de un @c(reflect.Value) direccionable requiere
   tres pasos. En primer lugar, llamamos a @c[Addr()], que devuelve un valor que
   contiene un puntero a la variable. Despues, llamamos a @c[Interface()] en
   este @c(Value), que devuelve un valor @c[interface{}] que contiene el
   puntero. Finalmente, si sabemos el tipo de la variable, podemos usar una
   asercion de tipo para recuperar el contenido de la interfaz como un puntero
   comun. A continuacion, podemos actualizar la variable a traves del puntero:

   ..src > go
     x := 2
     d := reflect.ValueOf(&x).Elem()    // d referencia a la variable x
     px := d.Addr().Interface().(*int)  // px := &x
     *px = 3                            // x = 3
     fmt.Println(x)                     // "3"
   < src..

   O bien, podemos actualizar la variable a la que hace referencia
   @c(reflect.Value) directamente, sin necesidad de utilizar un puntero,
   llamando al metodo @c(reflect.Value.Set):

   ..src > go
     d.Set(reflect.ValueOf(4))
     fmt.Println(x) // "4"
   < src..

   Las mismas comprobaciones de asignabilidad que normalmente se realizan por el
   compilador se realizan en tiempo de ejecucion por los metodos
   @c[Set]. Arriba, la variable y el valor tienen el tipo @c(int), pero si la
   variable habia sido un @c(int64), el programa entrara en panico, por lo que
   es crucial asegurarse de que el valor sea asignable al tipo de la variable:

   ..src > go
     d.Set(reflect.ValueOf(int64(5))) // panico: int64 no es asignable a int
   < src..

   Y, por supuesto, llamando a @c(Set) sobre un @c(reflect.Value) no
   direccionable tambien entra en panico:

   ..src > go
     x := 2
     b := reflect.ValueOf(x)
     b.Set(reflect.ValueOf(3)) // panico: se utiliza Set con un valor no direccionable
   < src..

   Hay variantes de @c(Set) especializadas para ciertos grupos de tipos basicos:
   @c(SetInt), @c(SetUint), @c(SetString), @c(SetFloat), y demas:

   ..src > go
     d := reflect.ValueOf(&x).Elem()
     d.SetInt(3)
     fmt.Println(x) // "3"
   < src..

   En algunos aspectos, estos metodos son mas tolerantes. @c(SetInt), por
   ejemplo, tendra exito siempre y cuando el tipo de la variable sea algun tipo
   de entero con signo, o incluso un tipo con nombre cuyo tipo subyacente es un
   entero con signo, y si el valor es demasiado grande sera truncado en silencio
   para ajustarse. Pero pise con cuidado: llamar a @c(SetInt) en un
   @c(reflect.Value) que se refiere a una variable @c[interface{}] entrara en
   panico, aunque @c(Set) tendria exito.

   ..src > go
     x := 1
     rx := reflect.ValueOf(&x).Elem()
     rx.SetInt(2)                     // OK, x = 2
     rx.Set(reflect.ValueOf(3))       // OK, x = 3
     rx.SetString("hello")            // panic: string no es asignable a int
     rx.Set(reflect.ValueOf("hello")) // panic: string no es asignable a int

     var y interface{}
     ry := reflect.ValueOf(&y).Elem()
     ry.SetInt(2)                     // panico: SetInt llamada con un Valoe interface
     ry.Set(reflect.ValueOf(3))       // OK, y = int(3)
     ry.SetString("hello")            // panico: SetString llamada en un Value interface
     ry.Set(reflect.ValueOf("hello")) // OK, y = "hello"
   < src..

   Cuando aplicamos @c(Display) a @c(os.Stdout), encontramos que la reflexion
   puede leer los valores de los campos no exportados de estructuras que son
   inaccesibles segun las reglas usuales del lenguaje, como el campo @c(fd int)
   de una estructura @c(os.File) en una plataforma Unix. Sin embargo, la
   reflexion no puede actualizar estos valores:

   ..src > go
     stdout := reflect.ValueOf(os.Stdout).Elem() // *os.Stdout, una variable os.File
     fmt.Println(stdout.Type())                  // "os.File"
     fd := stdout.FieldByName("fd")
     fmt.Println(fd.Int()) // "1"
     fd.SetInt(2)          // panico: capo sin exportar
   < src..

   Un @c(reflect.Value) direccionable registra si se obtuvo al atravesar el
   campo sin exportar de una estructura y, si es asi, no permite la
   modificacion. En consecuencia, @c(CanAddr) no suele ser la comprobacion
   correcta a utilizar antes de establecer una variable. El metodo relacionado
   @c(CanSet) informa si un @c(reflect.Value) es direccionable @e(y) asignable:

   ..src > go
     fmt.Println(fd.CanAddr(), fd.CanSet()) // "true false"
   < src..

** Seccion 12.6 <> Ejemplo: Descodificar Expresiones-S

   Por cada funcion @c(Marshal) proporcionada por los paquetes @c(encoding/...)
   de la libreria estandar, hay una funcion correspondiente @c(Unmarshal) que
   realiza la decodificacion. Por ejemplo, como vimos en la @l(#Seccion 4.5),
   dado un slice de bytes que contiene datos codificados JSON para nuestro tipo
   @c(Movie) @%l(#Seccion 12.3<>§12.3), podemos decodificarlo asi:

   ..src > go
     data := []byte{/* ... */}
     var movie Movie
     err := json.Unmarshal(data, &movie)
   < src..

   la funcion @c(Unmarshal) utiliza la reflexion para modificar los campos de la
   variable @c(movie) actual, creando nuevos mapas, estructuras, y slices segun
   lo determinado por el tipo @c(Movie) y el contenido de los datos entrantes.

   Ahora vamos a poner en practica una simple funcion @c(Unmarshal) para
   expresiones-S, analoga a la funcion estandar @c(json.Unmarshal) utilizada
   anteriormente, y la inversa de nuestra anterior @c(sexpr.Marshal). Debemos
   advertirle que una implementacion robusta y general requiere mucho mas codigo
   del que encajaria comodamente en este ejemplo, que ya es largo, asi que hemos
   tomado muchos atajos. Soportamos solo un subconjunto limitado de
   expresiones-S y no manejamos errores con gracia. El codigo pretende ilustrar
   la reflexion, no el analisis.

   El lexer utiliza el tipo @c(Scanner) del paquete @c(text/scanner) para romper
   una corriente de entrada en una secuencia de tokens como comentarios,
   identificadores, literales de cadena, y literales numericos. El metodo
   @c(Scan) del escaner avanza el escaner y devuelve el tipo del siguiente
   token, que tiene el tipo @c(rune). La mayoria de los tokens, como @c['('],
   consisten en una sola runa, pero el paquete @c(text/scanner) representa el
   tipo de tokens de caracteres multiples @c(Ident), @c(String), e @c(Int)
   usando pequeños valores negativos del tipo @c(rune). Despues de una llamada a
   @c(Scan) que devuelve uno de estos tipos de token, el metodo @c(TokenText) de
   escaner devuelve el texto del token.

   Ya que un analizador tipico puede tener que inspeccionar el token actual
   varias veces, pero el metodo @c(Scan) avanza el escaner, envolvemos el
   escaner en un tipo auxiliar llamado @c(lexer) que realiza un seguimiento del
   token recientemente devuelto por @c(Scan).

   ..figure > @l(gopl.io/ch12/sexpr/decode.go<>gopl.io/ch12/sexpr)

     ..src > go
       type lexer struct {
         scan  scanner.Scanner
         token rune // el token actual
       }

       func (lex *lexer) next()        { lex.token = lex.scan.Scan() }
       func (lex *lexer) text() string { return lex.scan.TokenText() }

       func (lex *lexer) consume(want rune) {
         if lex.token != want { // NOTA: No es un ejemplo de buen manejo de errores.
           panic(fmt.Sprintf("got %q, want %q", lex.text(), want))
         }
         lex.next()
       }
     < src..


   Ahora pasemos al analizador sintactico. Consiste en dos funciones
   principales. La primera, @c(read), lee la expresion-S que comienza con el
   token actual y actualiza la variable referida por el @c(reflect.Value v)
   direccionable.

   ..src > go
     func read(lex *lexer, v reflect.Value) {
       switch lex.token {
       case scanner.Ident:
         // Los unicos identificadores validos son
         // "nil" y campos con nombre en estructuras.
         if lex.text() == "nil" {
           v.Set(reflect.Zero(v.Type()))
           lex.next()
           return
         }
       case scanner.String:
         s, _ := strconv.Unquote(lex.text()) // NOTA: ignorando errores
         v.SetString(s)
         lex.next()
         return
       case scanner.Int:
         i, _ := strconv.Atoi(lex.text()) // NOTA: ignorando errores
         v.SetInt(int64(i))
         lex.next()
         return
       case '(':
         lex.next()
         readList(lex, v)
         lex.next() // consume ')'
         return
       }
       panic(fmt.Sprintf("unexpected token %q", lex.text()))
     }
   < src..

   Nuestras expresiones-S utilizan identificadores para dos propositos
   distintos, nombres de campo en estructuras y el valor de un puntero
   @c(nil). La funcion @c(read) solo se ocupa de este ultimo caso. Cuando
   @c(scanner.Ident) se encuentra con @"c(nil), establece @c(v) a el valor
   cero de su tipo usando la funcion @c(reflect.Zero). Para cualquier otro
   identificador, informa de un error. la funcion @c(readList), que veremos en
   un momento, maneja identificadores utilizados como nombres de campo
   estructura.

   Un token @c['('] indica el comienzo de una lista. La segunda funcion,
   @c(readList), decodifica una lista en una variable de tipo compuesto–un mapa,
   estructura, slice, o arreglo–dependiendo el tipo de variable Go que estamos
   rellenando actualmente. En cada caso, el bucle mantiene el analisis de
   elementos hasta encontrar el parentesis de cierre correspondiente, @c[')'],
   detectado por la funcion @c(endList).

   La parte interesante es la recursion. El caso mas sencillo es un arreglo.
   Hasta que se ve el cierre @c[')'], utilizamos @c(Index) para obtener la
   variable para cada elemento del arreglo y hacer una llamada recursiva a
   @c(read) para rellenarla. Como en muchos otros casos de error, si los datos
   de entrada hacen que el decodificador se indexe mas alla del final del
   arreglo, el descodificador entrara en panico. Un metodo similar se utiliza
   para los slices, excepto que debemos crear una nueva variable para cada
   elemento, rellenarlo y, a continuacion, añadirlo a la porcion.

   Los bucles de estructuras y mapas deben analizar una sublista @c[(key value)]
   en cada iteracion. Para las estructuras, la clave es un simbolo que
   identifica el campo. Analogo al caso de los arreglos, obtenemos la variable
   existente para el campo struct usando @c(FieldByName) y realizamos una
   llamada recursiva para llenarla. Para los mapas, la clave puede ser de
   cualquier tipo, y de forma analoga al caso de los slices, creamos una nueva
   variable, rellenandola de forma recursiva y finalmente insertamos el nuevo
   par clave/valor en el mapa.

   ..src > go
     func readList(lex *lexer, v reflect.Value) {
       switch v.Kind() {
       case reflect.Array: // (item ...)
         for i := 0; !endList(lex); i++ {
           read(lex, v.Index(i))
         }

       case reflect.Slice: // (item ...)
         for !endList(lex) {
           item := reflect.New(v.Type().Elem()).Elem()
           read(lex, item)
           v.Set(reflect.Append(v, item))
         }

       case reflect.Struct: // ((name value) ...)
         for !endList(lex) {
           lex.consume('(')
           if lex.token != scanner.Ident {
             panic(fmt.Sprintf("got token %q, want field name", lex.text()))
           }
           name := lex.text()
           lex.next()
           read(lex, v.FieldByName(name))
           lex.consume(')')
         }

       case reflect.Map: // ((key value) ...)
         v.Set(reflect.MakeMap(v.Type()))
         for !endList(lex) {
           lex.consume('(')
           key := reflect.New(v.Type().Key()).Elem()
           read(lex, key)
           value := reflect.New(v.Type().Elem()).Elem()
           read(lex, value)
           v.SetMapIndex(key, value)
           lex.consume(')')
         }

       default:
         panic(fmt.Sprintf("cannot decode list into %v", v.Type()))
       }
     }

     func endList(lex *lexer) bool {
       switch lex.token {
       case scanner.EOF:
         panic("end of file")
       case ')':
         return true
       }
       return false
     }
   < src..

   Finalmente, terminamos el analizador en una funcion exportada @c(Unmarshal),
   que se muestra a continuacion, que esconde algunas de las asperezas de la
   aplicacion. Los errores encontrados durante el analisis dan lugar a un
   panico, por lo que @c(Unmarshal) utiliza una llamada diferida para
   recuperarse del panico @%l(#Seccion 5.10<>§5.10) y devolvera un mensaje de
   error.

   ..src > go
     // Unmarshal analiza datos de expresiones-S y rellena la variable
     // cuya direccion esta en el puntero out no-nil.
     func Unmarshal(data []byte, out interface{}) (err error) {
       lex := &lexer{scan: scanner.Scanner{Mode: scanner.GoTokens}}
       lex.scan.Init(bytes.NewReader(data))
       lex.next() // obtiene el primer token
       defer func() {
         // NOTA: esto no es un ejemplo ideal del manejo de errores.
         if x := recover(); x != nil {
           err = fmt.Errorf("error at %s: %v", lex.scan.Position, x)
         }
       }()
       read(lex, reflect.ValueOf(out).Elem())
       return nil
     }
   < src..

   Una implementacion de calidad de produccion nunca debe entrar en panico por
   ninguna entrada y debe informar un error informativo para cada contratiempo,
   tal vez con un numero de linea o desplazamiento. No obstante, esperamos que
   este ejemplo transmita una idea de lo que esta sucediendo bajo el capo de
   paquetes como @c(encoding/json), y como se puede utilizar la reflexion para
   poblar las estructuras de datos.

   @b(Ejercicio 12.8): La funcion @c(sexpr.Unmarshal), como @c(json.Unmarshal),
   requiere la entrada completa en un slice de bytes antes de que pueda comenzar
   la decodificacion. Defina un tipo @c(sexpr.Decoder) que como @c(json.Decoder),
   permita que una secuencia de valores sea decodificada desde un @c(io.Reader).
   Cambie @c(sexpr.Unmarshal) para utilizar este nuevo tipo.

   @b(Ejercicio 12.9): Escriba una API basada en tokens para decodificar
   expresiones-S, siguiendo el estilo de @c(xml.Decoder) @%l(#Seccion
   7.14<>§7.14). Necesitara cinco tipos de tokens: @c(Symbol), @c(String),
   @c(Int), @c(StartList) y @c(EndList).

   @b(Ejercicio 12.10): Extienda @c(sexpr.Unmarshal) para manejar booleanos,
   numeros de punto flotante, e interfaces codificadas con su solucion al
   Ejercicio 12.3. (Sugerencia: para decodificar interfaces, se necesitara una
   asignacion del nombre de cada tipo soportado a su @c(reflect.Type)).

** Seccion 12.7 <> Accediendo a Etiquetas de Campo en Estructuras

   En la @l(#Seccion 4.5) utilizamos @e(etiquetas de campo) de estructura para
   modificar la codificacion de valores JSON de estructuras Go. La etiqueta de
   campo @c(json) nos permite escoger nombres de campos alternativos y suprimir
   la salida de los campos vacios. En esta seccion, veremos como acceder a las
   etiquetas de campo utilizando reflexion.

   En un servidor web, lo primero que hace la mayoria de las funciones del
   controlador HTTP es extraer los parametros de la peticion en variables
   locales. Vamos a definir una funcion de utilidad, @c(params.Unpack), que
   utiliza etiquetas de campos de estructura para que los manipuladores de la
   escritura HTTP @%l(#Seccion 7.7<>§7.7) sean mas convenientes.

   En primer lugar, vamos a mostrar como se utiliza. La funcion @c(search) a
   continuacion, es un controlador HTTP. Se define una variable llamada @c(data)
   de un tipo de estructura anonima cuyos campos corresponden a los parametros
   de la peticion HTTP. Las etiquetas de campo de la estructura especifican los
   nombres de los parametros, que a menudo son cortos y cripticos, ya que el
   espacio es precioso en una URL. la funcion @c(Unpack) llena la estructura del
   la solicitud, por lo que los parametros se puede acceder convenientemente y
   con un tipo apropiado.

   ..figure > @l(gopl.io/ch12/search/main.go<>gopl.io/ch12/search)

     ..src > go
       import "gopl.io/ch12/params"

       // search implementa la busqueda del /punto-final de la URL.
       func search(resp http.ResponseWriter, req *http.Request) {
         var data struct {
           Labels     []string `http:"l"`
           MaxResults int      `http:"max"`
           Exact      bool     `http:"x"`
         }
         data.MaxResults = 10 // establecer por defecto
         if err := params.Unpack(req, &data); err != nil {
           http.Error(resp, err.Error(), http.StatusBadRequest) // 400
           return
         }

         // ...resto del manejador...
         fmt.Fprintf(resp, "Search: %+v\n", data)
       }
     < src..


   La funcion @c(Unpack) de abajo hace tres cosas. En primer lugar, llama a
   @c[req.ParseForm()] para analizar la solicitud. Posteriormente, @c(req.Form)
   contiene todos los parametros, independientemente de si el cliente HTTP
   utiliza el metodo de solicitud GET o POST.

   A continuacion, @c(Unpack) construye una correlacion del nombre @e(efectivo)
   de cada campo a la variable para ese campo. El nombre efectivo puede diferir
   del nombre real si el campo tiene una etiqueta. El metodo @c(Field) de
   @c(reflect.Type) devuelve un @c(reflect.StructField) que proporciona
   informacion sobre el tipo de cada campo, como su nombre, tipo, y la etiqueta
   opcional. El campo @c(Tag) es un @c(reflect.StructTag), que es un tipo de
   cadena que proporciona un metodo @c(Get) para analizar y extraer la subcadena
   de una clave particular, como @c(http:"...") en este caso.

   ..figure > @l(gopl.io/ch12/params/params.go<>gopl.io/ch12/params)

     ..src > go
       // Unpack rellena los campos de la estructura apuntada por ptr
       // con los parametros de la solicitud HTTP en req.
       func Unpack(req *http.Request, ptr interface{}) error {
         if err := req.ParseForm(); err != nil {
           return err
         }

         // Construye un mapa de los campos marcados con un nombre efectivo.
         fields := make(map[string]reflect.Value)
         v := reflect.ValueOf(ptr).Elem() // la estructura variable
         for i := 0; i < v.NumField(); i++ {
           fieldInfo := v.Type().Field(i) // un reflect.StructField
           tag := fieldInfo.Tag           // un reflect.StructTag
           name := tag.Get("http")
           if name == "" {
             name = strings.ToLower(fieldInfo.Name)
           }
           fields[name] = v.Field(i)
         }

         // Actualiza el campo de estructura para cada parametro en la solicitud
         for name, values := range req.Form {
           f := fields[name]
           if !f.IsValid() {
             continue // ingorar los parametros HTTP no reconocidos
           }
           for _, value := range values {
             if f.Kind() == reflect.Slice {
               elem := reflect.New(f.Type().Elem()).Elem()
               if err := populate(elem, value); err != nil {
                 return fmt.Errorf("%s: %v", name, err)
               }
               f.Set(reflect.Append(f, elem))
             } else {
               if err := populate(f, value); err != nil {
                 return fmt.Errorf("%s: %v", name, err)
               }
             }
           }
         }
         return nil
       }
     < src..


   Finalmente, @c(Unpack) itera sobre los pares nombre/valor de los parametros
   HTTP y actualiza los campos de estructura correspondientes. Recuerde que el
   mismo nombre de parametro puede aparecer mas de una vez. Si esto sucede, y el
   campo es un slice, entonces todos los valores de ese parametro se acumulan en
   el slice. De lo contrario, el campo se sobrescribe repetidamente para que
   solo el ultimo valor tenga algun efecto.

   la funcion @c(populate) se encarga de establecer un unico campo @c(v) (o un
   unico elemento de un campo de slice) a partir de un valor de parametro. Por
   ahora, solo admite cadenas, enteros con signo y booleanos. Soportar otros
   tipos se deja como un ejercicio.

   ..src > go
     func populate(v reflect.Value, value string) error {
       switch v.Kind() {
       case reflect.String:
         v.SetString(value)

       case reflect.Int:
         i, err := strconv.ParseInt(value, 10, 64)
         if err != nil {
           return err
         }
         v.SetInt(i)

       case reflect.Bool:
         b, err := strconv.ParseBool(value)
         if err != nil {
           return err
         }
         v.SetBool(b)

       default:
         return fmt.Errorf("unsupported kind %s", v.Type())
       }
       return nil
     }
   < src..

   Si añadimos el manejador @c(server) a un servidor web, esto podria ser una
   sesion tipica:

   ..srci > sh
     > go build gopl.io/ch12/search
     > ./search &
     > ./fetch 'http://localhost:12345/search'
     Search: {Labels:[] MaxResults:10 Exact:false}
     > ./fetch 'http://localhost:12345/search?l=golang&l=programming'
     Search: {Labels:[golang programming] MaxResults:10 Exact:false}
     > ./fetch 'http://localhost:12345/search?l=golang&l=programming&max=100'
     Search: {Labels:[golang programming] MaxResults:100 Exact:false}
     > ./fetch 'http://localhost:12345/search?x=true&l=golang&l=programming'
     Search: {Labels:[golang programming] MaxResults:10 Exact:true}
     > ./fetch 'http://localhost:12345/search?q=hello&x=123'
     x: strconv.ParseBool: parsing "123": invalid syntax
     > ./fetch 'http://localhost:12345/search?q=hello&max=lots'
     max: strconv.ParseInt: parsing "lots": invalid syntax
   < srci..

   @b(Ejercicio 12.11): Escribir la funcion correspondiente @c(Pack). Dando un
   valor de estructura, @c(Pack) debe devolver una direccion URL que incorpore
   los valores de los parametros de la estructura.

   @b(Ejercicio 12.12): Extender la notacion de etiqueta de campo para expresar
   requisitos de validez de parametros. Por ejemplo, es posible que una cadena
   tenga que ser una direccion de correo electronico valida o un numero de
   tarjeta de credito, y un numero entero puede tener que ser un codigo postal
   valido de los Estados Unidos. Modifique @c(Unpack) para comprobar estos
   requisitos.

   @b(Ejercicio 12.13): Modificar el codificador @%l(#Seccion 12.4<>§12.4) y
   decodificador @%l(#Seccion 12.6<>§12.6) de expresiones-S para que cumplan la
   etiqueta de campo @c(sexpr:"...") de una manera similar a @c(encoding/json)
   @%l(#Seccion 4.5<>§4.5).

** Seccion 12.8 <> Visualizando los Metodos de Type

   Nuestro ultimo ejemplo de reflexion utiliza @c(reflect.Type) para imprimir el
   tipo de un valor arbitrario y enumerar sus metodos:

   ..figure > @l(gopl.io/ch12/methods/methods.go<>gopl.io/ch12/methods)

     ..src > go
       // Print imprime el conjunto de metodos del valor x.
       func Print(x interface{}) {
         v := reflect.ValueOf(x)
         t := v.Type()
         fmt.Printf("type %s\n", t)

         for i := 0; i < v.NumMethod(); i++ {
           methType := v.Method(i).Type()
           fmt.Printf("func (%s) %s%s\n", t, t.Method(i).Name,
             strings.TrimPrefix(methType.String(), "func"))
         }
       }
     < src..


   Ambos @c(reflect.Type) y @c(reflect.Value) tienen un metodo llamado
   @c(Method). Cada llamada @c[t.Method(i)] devuelve una instancia de
   @c(reflect.Method), una estructura que describe el nombre y tipo de un unico
   metodo. Cada llamada @c[v.Method(i)] devuelve un @c(reflect.Value) que
   representa un valor metodo @%l(#Seccion 6.4<>§6.4), es decir, un metodo
   vinculado a su receptor. Utilizando el metodo @c(reflect.Value.Call) (que no
   tenemos espacio para mostrar aqui), es posible llamar a @c(Values) de tipo
   @c(Func) como este, pero este programa solo necesita su @c(Type).

   Estos son los metodos que pertenecen a dos tipos, @c(time.Duration) y
   @c(*strings.Replacer):

   ..src > go
     methods.Print(time.Hour)
     // Output:
     // type time.Duration
     // func (time.Duration) Hours() float64
     // func (time.Duration) Minutes() float64
     // func (time.Duration) Nanoseconds() int64
     // func (time.Duration) Seconds() float64
     // func (time.Duration) String() string

     methods.Print(new(strings.Replacer))
     // Output:
     // type *strings.Replacer
     // func (*strings.Replacer) Replace(string) string
     // func (*strings.Replacer) WriteString(io.Writer, string) (int, error)
   < src..

** Seccion 12.9 <> Una Palabra de Precaucion

   Hay mucho mas sobre la API de reflexion que el espacio que tenemos para
   mostrar, pero los ejemplos anteriores dan una idea de lo que es posible. La
   reflexion es una herramienta poderosa y expresiva, pero debe ser usada con
   cuidado, por tres razones.

   La primera razon es que el codigo basado en reflexion puede ser fragil. Para
   cada error que podria hacer que un compilador informe un error de tipado, hay
   una forma correspondiente de usar incorrectamente la reflexion, pero mientras
   que el compilador informa del error en tiempo de la construccion, un error de
   reflexion se informa durante la ejecucion como un panico, posiblemente mucho
   despues de haber escrito el programa o incluso mucho despues de que ha
   comenzado su ejecucion.

   Si la funcion @c(readList) @%l(#Seccion 12.6<>§12.6), por ejemplo, debe leer
   una cadena de la entrada al rellenar una variable de tipo @c(int), la llamada
   a @c(reflect.Value.SetString) entrara en panico. La mayoria de los programas
   que utilizan la reflexion tienen riesgos similares, y se requiere mucho
   cuidado para realizar un seguimiento del tipo, capacidad de direccionamiento,
   y asignabilidad de cada @c(reflect.Value).

   La mejor manera de evitar esta fragilidad es asegurar que el uso de la
   reflexion esta totalmente encapsulado dentro de su paquete y, si es posible,
   evitar @c(reflect.Value) en favor de tipos especificos en la API de su
   paquete, para restringir las entradas a valores legales. Si esto no es
   posible, realice comprobaciones dinamicas adicionales antes de cada operacion
   riesgosa. A modo de ejemplo en la libreria estandar, cuando @c(fmt.Printf)
   aplica un verbo a un operando inadecuado, no entra misteriosamente en panico,
   por que imprime un mensaje de error informativo. El programa aun tiene un
   error, pero es mas facil de diagnosticar.

   ..src > go
     fmt.Printf("%d %s\n", "hello", 42) // "%!d(string=hello) %!s(int=42)"
   < src..

   La reflexion tambien reduce la seguridad y la precision de las herramientas
   automatizadas de refactorizacion y analisis, ya que no pueden determinar o
   confiar en la informacion de tipado.

   La segunda razon para evitar la reflexion es que como los tipos sirven como
   una forma de documentacion y las operaciones de reflexion no pueden estar
   sujetas a la verificacion de tipado estatico, el codigo altamente reflexivo
   es a menudo dificil de entender. Siempre documente cuidadosamente los tipos
   esperados y otros invariantes de las funciones que aceptan una
   @c(interface{}) o @c(reflect.Value).

   La tercera razon es que las funciones basadas en la reflexion pueden ser de
   uno o dos ordenes de magnitud mas lentas que el codigo especializado para un
   tipo particular. En un programa tipico, la mayoria de las funciones no son
   relevantes para el rendimiento general, por lo que es bueno usar la reflexion
   cuando haga mas claro el programa. Las pruebas son particularmente adecuadas
   para la reflexion ya que la mayoria de las pruebas utilizan conjuntos de
   datos pequeños. Pero para las funciones en rutas criticas, es mejor evitar la
   reflexion.

* Capitulo 13 <> Programacion de Bajo Nivel

  El diseño de Go garantiza una serie de propiedades de seguridad que limitan
  las formas en que un programa Go puede @"(ir mal). Durante la compilacion, la
  comprobacion de tipado detecta la mayoria de los intentos de aplicar una
  operacion a un valor inadecuado para su tipo, por ejemplo, restando una cadena
  de otra. Las estrictas reglas para las conversiones de tipos impiden el acceso
  directo a los tipos nativos como cadenas, mapas, slices y canales.

  Para errores que no se pueden detectar de forma estatica, como accesos a un
  arreglo fuera de limites o desreferencias de puntero nulo, las comprobaciones
  dinamicas aseguran que el programa termina inmediatamente con un error
  informativo siempre que se produce una operacion prohibida. La gestion
  automatica de memoria (recoleccion de basura) elimina errores de @"(uso luego
  de la liberacion), asi como la mayoria de las perdidas de memoria.

  Muchos detalles de la implementacion son inaccesibles para los programas de
  Go. No hay manera de descubrir el diseño de memoria de un tipo agregado como
  una estructura, o el codigo maquina para una funcion, o la identidad del hilo
  del sistema operativo en el que se esta ejecutando la actual gorutina. De
  hecho, el planificador de Go mueve libremente las gorutinas de un hilo a
  otro. Un puntero identifica una variable sin revelar la direccion numerica de
  la variable. Las direcciones pueden cambiar a medida que el recolector de
  basura mueve las variables; los punteros se actualizan de forma transparente.

  Juntas, estas caracteristicas hacen que los programas de Go, especialmente los
  que fallan, sean mas predecibles y menos misteriosos que los programas en C,
  la quintaesencia de los lenguajes de bajo nivel. Al ocultar los detalles
  subyacentes, tambien hace que los programas Go sean altamente portatiles, ya
  que la semantica del lenguaje es en gran medida independiente de cualquier
  compilador, sistema operativo o arquitectura de la CPU en particular. (No es
  totalmente independiente: algunos detalles se filtran, como el tamaño de la
  palabra del procesador, el orden de evaluacion de ciertas expresiones y el
  conjunto de restricciones de implementacion impuestas por el compilador).

  Ocasionalmente, podemos optar por renunciar a algunas de estas garantias
  utiles para lograr el maximo rendimiento posible, para interoperar con
  librerias escritas en otros lenguajes o para implementar una funcion que no
  puede expresarse en Go puro.

  En este capitulo, vamos a ver como el paquete @c(unsafe) nos permite saltar
  las reglas habituales, y como utilizar la herramienta @$(cgo) para crear
  enlaces Go para librerias de C y llamadas al sistema operativo.

  Los enfoques descritos en este capitulo no deben utilizarse frivolamente. Sin
  la atencion cuidadosa a los detalles, pueden causar el tipo de fracasos
  impredecibles, inescrutables, no locales con los cuales los programadores de C
  son infelizmente familiarizados. El uso de @c(unsafe) tambien anula la
  garantia de la compatibilidad de Go con versiones futuras, ya que, ya sea
  intencional o no, es facil depender de detalles de implementacion no
  especificados que pueden cambiar de forma inesperada.

  El paquete @c(unsafe) es bastante magico. Aunque parece ser un paquete regular
  y se importa de la manera habitual, es realmente implementado por el
  compilador. Proporciona acceso a una serie de caracteristicas nativas de
  lenguaje que normalmente no estan disponibles porque exponen detalles del
  diseño de memoria de Go. La presentacion de estas caracteristicas como un
  paquete por separado hace que las raras ocasiones en que se necesita mas
  conspicuo. Ademas, algunos entornos pueden restringir el uso del paquete
  @c(unsafe) por razones de seguridad.

  El paquete @c(unsafe) se utiliza ampliamente en paquetes de bajo nivel como
  @c(runtime), @c(os), @c(syscall), y @c(net) que interactuan con el sistema
  operativo, pero casi nunca es necesario en programas ordinarios.

** Seccion 13.1 <> @c(unsafe.Sizeof), @c(Alignof), y @c(Offsetof)

   la funcion @c(unsafe.Sizeof) informa el tamaño en bytes de la representacion
   de su operando, que puede ser una expresion de cualquier tipo; la expresion
   no se evalua. Una llamada a @c(Sizeof) es una expresion constante de tipo
   @c(uintptr), por lo que el resultado puede ser utilizado como la dimension de
   un tipo de matriz, o para calcular otras constantes.

   ..src > go
     import "unsafe"
     fmt.Println(unsafe.Sizeof(float64(0))) // "8"
   < src..

   @c(Sizeof) informa solo el tamaño de la parte fija de cada estructura de
   datos, como el puntero y longitud de una cadena, pero no partes indirectas
   como el contenido de la cadena. Los tamaños tipicos para todos los tipos Go
   no agregados se muestran a continuacion, aunque los tamaños exactos pueden
   variar segun la cadena de herramientas. Para la portabilidad, hemos dado los
   tamaños de los tipos de referencia (o tipos que contienen referencias) en
   terminos de palabras, donde una palabra son 4 bytes en una plataforma de 32
   bits y 8 bytes en una plataforma de 64 bits.

   Las computadoras cargan y almacenan los valores de memoria mas efecientemente
   cuando esos valores estan correctamente @e(alineados). Por ejemplo, la
   direccion de un valor de un tipo de dos bytes como @c(int16) debe ser un
   numero par, la direccion de un valor de cuatro bytes como una runa debe ser
   un multiplo de cuatro, y la direccion de un valor de ocho bytes como un
   @c(float64), @c(uint64), o un puntero de 64 bits debe ser un multiplo de
   ocho. Los requisitos de alineacion de multiplos mayores son inusuales,
   incluso para los tipos de datos mas grandes como @c(complex128).

   Por esta razon, el tamaño de un valor de un tipo agregado (una estructura o
   arreglo) es al menos la suma de los tamaños de sus campos o elementos, pero
   puede ser mayor debido a la presencia de @"(agujeros). Los agujeros son
   espacios no utilizados añadidos por el compilador para asegurar que el
   siguiente campo o elemento este correctamente alineado con respecto al inicio
   de la estructura o arreglo.

   +---------------------------------------------------------------+-------------------------------------------------------+
   | Tipo                                                          | Tamaño                                                |
   +===============================================================+=======================================================+
   | @c(bool)                                                      | 1 byte                                                |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(int)@m(N), @c(uint)@m(N), @c(float)@m(N), @c(complex)@m(N) | @m(N) / 8 bytes (por ejemplo, @c(float64) es 8 bytes) |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(int), @c(uint), @c(uintptr)                                | 1 palabra                                             |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(*T)                                                        | 1 palabra                                             |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(string)                                                    | 2 palabras (data, len)                                |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c([]T)                                                       | 3 palabras (data, len, cap)                           |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(map)                                                       | 1 palabra                                             |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(func)                                                      | 1 palabra                                             |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(chan)                                                      | 1 palabra                                             |
   +---------------------------------------------------------------+-------------------------------------------------------+
   | @c(interface)                                                 | 2 palabras (type, value)                              |
   +---------------------------------------------------------------+-------------------------------------------------------+


   La especificacion del lenguaje no garantiza que el orden en que se declaran
   los campos es el orden en el que se exponen en la memoria, por lo que en
   teoria un compilador es libre de reordenarlos, aunque al escribir esto,
   ninguno lo hace. Si los tipos de campos de una estructura son de diferentes
   tamaños, puede ser mas eficiente en espacio declarar los campos en un orden
   que los empaquete tan firmemente como sea posible. Las tres estructuras abajo
   tienen los mismos campos, pero la primera requiere hasta un 50% mas de
   memoria que las otras dos:

   ..src > go
                                       // 64-bit       32-bit
     struct{ bool; float64; int16 }    // 3 palabras   4 palabras
     struct{ float64; int16; bool }    // 2 palabras   3 palabras
     struct{ bool; int16; float64 }    // 2 palabras   3 palabras
   < src..

   Los detalles del algoritmo de alineacion estan mas alla del alcance de este
   libro, y ciertamente no vale la pena preocuparse por cada estructura, pero un
   enpaque eficiente puede hacer que las estructuras de datos asignadas
   frecuentemente sean mas compactas y por lo tanto mas rapidas.

   La funcion @c(unsafe.Alignof) informa la alineacion requerida del tipo de su
   argumento. Al igual que @c(Sizeof), se puede aplicar a una expresion de
   cualquier tipo, y produce una constante. Normalmente, los tipos booleanos y
   numericos estan alineados con su tamaño (hasta un maximo de 8 bytes) y todos
   los demas tipos estan alineados con palabras.

   La funcion @c(unsafe.Offsetof), cuyo operando debe ser un selector de campo
   @c(x.f), calcula el desplazamiento del campo de @c(f) con respecto al
   comienzo de su estructura contenedora @c(x), representando los agujeros, si
   los hay.

   La Figura 13.1 muestra una variable de la estructura @c(x) y su disposicion
   de memoria tipica en 32 y 64 bits en implementaciones Go. Las regiones grises
   son agujeros.

   ..src > go
     var x struct {
       a bool
       b int16
       c []int
     }
   < src..

   ..figure > Figura 13.1. Agujeros en una estructura.

     ..img  > img/Figure-13.1.jpg


   La siguiente tabla muestra los resultados de aplicar las tres funciones
   @c(unsafe) al mismo @c(x) y a cada uno de sus tres campos:

   - Plataforma tipica de 32 bits ::

     ..pre >
       Sizeof(x)   = 16  Alignof(x)   = 4
       Sizeof(x.a) =  1  Alignof(x.a) = 1  Offsetof(x.a) = 0
       Sizeof(x.b) =  2  Alignof(x.b) = 2  Offsetof(x.b) = 2
       Sizeof(x.c) = 12  Alignof(x.c) = 4  Offsetof(x.c) = 4

   - Plataforma tipica de 64 bits ::

     ..pre >
       Sizeof(x)   = 32  Alignof(x)   = 8
       Sizeof(x.a) =  1  Alignof(x.a) = 1  Offsetof(x.a) = 0
       Sizeof(x.b) =  2  Alignof(x.b) = 2  Offsetof(x.b) = 2
       Sizeof(x.c) = 24  Alignof(x.c) = 8  Offsetof(x.c) = 8

   A pesar de sus nombres, estas funciones en realidad no son inseguras, y
   pueden ser utiles para entender el diseño de la memoria en bruto en un
   programa al optimizar el espacio.

** Seccion 13.2 <> @c(unsafe.Pointer)

   La mayoria de los tipos de puntero se escriben @c(*T), es decir, @"(un
   puntero a una variable de tipo @c(T)). El tipo @c(unsafe.Pointer) es un tipo
   especial de puntero que puede contener la direccion de cualquier variable.
   Por supuesto, no podemos aplicar indireccion a traves de un
   @c(unsafe.Pointer) usando @c(*p), porque no sabemos que tipo de expresion
   debe tener. Como los punteros ordinarios, @c(unsafe.Pointers) es comparable y
   pueden compararse con @c(nil), que es el valor cero del tipo.

   Un puentor @c(*T) ordinario puede convertirse en un @c(unsafe.Pointer), y un
   @c(unsafe.Pointer) convertirse de nuevo a un puntero ordinario, no
   necesariamente del mismo tipo @c(*T). Por ejemplo, al convertir un puntero
   @c(*float64) en un @c(*uint64), podemos inspeccionar el patron de bits de una
   variable de punto flotante:

   ..src > go
     package math

     func Float64bits(f float64) uint64 { return *(*uint64)(unsafe.Pointer(&f)) }

     fmt.Printf("%#016x\n", Float64bits(1.0)) // "0x3ff0000000000000"
   < src..

   A traves del puntero resultante, podemos actualizar el patron de bits
   tambien. Esto es inofensivo para una variable de punto flotante, ya que
   cualquier patron de bits es legal, pero en general, las conversiones
   @c(unsafe.Pointer) nos permiter escribir valores arbitrarios en memoria y asi
   subvertir el sistema de tipos.

   Un @c(unsafe.Pointer) tambien se puede convertir en un @c(uintptr) que
   mantiene el valor numerico del puntero, dejandonos realizar aritmetica de
   direcciones. (Recuerde del @l(#Capitulo 3) que un @c(uintptr) es un entero
   sin signo lo suficientemente ancho como para representar una direccion.) Esta
   conversion tambien se puede aplicar a la inversa, pero de nuevo, la
   conversion de un @c(uintptr) a un @c(unsafe.Pointer) puede subvertir el
   sistema de tipos ya que no todos los numeros son direcciones validas.

   Muchos valores @c(unsafe.Pointer) son, por tanto, intermediarios para
   convertir punteros ordinarios en direcciones numericas brutas y viceversa. El
   ejemplo a continuacion toma la direccion de la variable @c(x), añade el
   desplazamiento de su campo @c(b), convierte la direccion resultante en
   @c(*int16), y por medio de este puntero se actualiza @c(x.b):

   ..figure > @l(gopl.io/ch13/unsafeptr/main.go<>gopl.io/ch13/unsafeptr)

     ..src > go
       var x struct {
         a bool
         b int16
         c []int
       }

       // equivalente a pb := &x.b
       pb := (*int16)(unsafe.Pointer(
         uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b)))
       *pb = 42

       fmt.Println(x.b) // "42"
     < src..


   Aunque la sintaxis es engorrosa–quiza no es malo, ya que estas
   caracteristicas deben utilizarse con moderacion–no se sienta tentado a
   introducir variables temporales de tipo @c(uintptr) para romper las
   lineas. Este codigo es incorrecto:

   ..src > go
     // NOTA: sutilmente incorreto!
     tmp := uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b)
     pb := (*int16)(unsafe.Pointer(tmp))
     *pb = 42
   < src..

   La razon es muy sutil. Algunos recolectores de basura mueven las variables en
   la memoria para reducir la fragmentacion o la contabilidad. Los recolectores
   de basura de este tipo lo conocen como @e(mover GCs). Cuando se mueve una
   variable, todos los punteros que contienen la direccion de la antigua
   ubicacion deben actualizarse para apuntar a la nueva. Desde la perspectiva
   del colector de basura, un @c(unsafe.Pointer) es un puntero y por lo tanto su
   valor debe cambiar a medida que se mueve la variable, pero un @c(uintptr) es
   solo un numero por lo que su valor no debe cambiar. El codigo anterior es
   incorrecta por que @e(oculta un puntero) del recolector de basura en la
   variable no puntero @c(tmp). En el momento que la segunda instruccion se
   ejecuta, la variable @c(x) podria haberse movido y el numero de @c(tmp) ya no
   seria la direccion @c(&x.b). La tercera declaracion ataca una ubicacion de
   memoria arbitraria con el valor 42.

   Existen innumerables variaciones patológicas sobre este tema. Despues de que
   esta declaracion se ha ejecutado:

   ..src > go
     pT := uintptr(unsafe.Pointer(new(T))) // NOTA: incorrecto!
   < src..

   no hay punteros que referencien la variable creada por @c(new), por lo que el
   recolector de basura tiene derecho a reciclar su almacenamiento cuando esta
   declaracion se complete, despues de lo cual @c(pT) contiene la direccion
   donde estaba la variable, pero ya no.

   Ninguna implementacion actual de Go utiliza un recolector de basura en
   movimiento (aunque futuras implementaciones podrian), pero esto no es motivo
   de complacencia: las versiones actuales de Go mueven @e(algunas) variables en
   la memoria. Recuerde de la @l(#Seccion 5.2) que las pilas de gorutina crecen
   segun sea necesario. Cuando esto sucede, todas las variables de la pila
   antigua pueden ser reubicadas en una nueva pila mas grande, por lo que no
   podemos confiar en que el valor numerico de la direccion de una variable
   permanezca invariable durante toda su vida util.

   En el momento de escribir esto, hay poco clara orientacion sobre lo que los
   programadores Go pueden esperar despues de una convercion @c(unsafe.Pointer)
   a @c(uintptr) (en el repositorio vea la issue 7192), por lo que recomendamos
   encarecidamente que asuma el minimo necesario. Trate todos los valores
   @c(uintptr) como si almacenaran la @e(antigua) direccion de una variable, y
   minimice el numero de operaciones entre la conversion de un @c(unsafe.Pointer)
   a un @c(uintptr) y el uso de ese @c(uintptr). En nuestro primer ejemplo
   anterior, las tres operaciones–la conversion a un @c(uintptr), la suma la
   compensacion de campo, y la conversion de nuevo–aparecieron dentro de una
   sola expresion.

   Cuando se llama a una funcion de libreria que devuelve un @c(uintptr), como
   las que se muestran a continuacion del paquete @c(reflect), el resultado debe
   ser convertido inmediatamente a un @c(unsafe.Pointer) para asegurarse de que
   sigue apuntando a la misma variable.

   ..src > go
     package reflect
     func (Value) Pointer() uintptr
     func (Value) UnsafeAddr() uintptr
     func (Value) InterfaceData() [2]uintptr // (index 1)
   < src..

** Seccion 13.3 <> Ejemplo: Equivalencia profunda

   La funcion @c(DeepEqual) del paquete @c(reflect) informa si dos valores son
   @"(profundamente) iguales. @c(DeepEqual) compara los valores basicos como si
   fuera el operador @c(==); para los valores compuestos, los recorre
   recursivamente, comparando los elementos correspondientes. Debido a que
   funciona para cualquier par de valores, incluso los que no son comparables
   con @c(==), este encuentra un uso amplio en pruebas. La siguiente prueba
   utiliza @c(DeepEqual) para comparar dos valores @c([]string):

   ..src > go
     func TestSplit(t *testing.T) {
       got := strings.Split("a:b:c", ":")
       want := []string{"a", "b", "c"};
       if !reflect.DeepEqual(got, want) { /* ... */ }
     }
   < src..

   Aunque @c(DeepEqual) es conveniente, sus distinciones pueden parecer
   arbitrarias. Por ejemplo, no considera un mapa nil igual a un mapa vacio
   no-nil, ni un slice nil igual a uno vacio no-nil:

   ..src > go
     var a, b []string = nil, []string{}
     fmt.Println(reflect.DeepEqual(a, b)) // "false"

     var c, d map[string]int = nil, make(map[string]int)
     fmt.Println(reflect.DeepEqual(c, d)) // "false"
   < src..

   En esta seccion vamos a definir una funcion @c(Equal) que compara valores
   arbitrarios. Al igual que @c(DeepEqual), compara slices y mapas en base a sus
   elementos, pero a diferencia de @c(DeepEqual), considera un slice nil (o
   mapa) igual a uno no-nil vacio. La recursion basica sobre los argumentos se
   puede hacer con reflexion, usando un enfoque similar a @c(Display) del
   programa que vimos en la @l(#Seccion 12.3). Como de costumbre, definimos una
   funcion no exportada, @c(equal), para la recursion.  Por el momento no se
   preocupe por el parametro @c(seen). Para cada par de valores @c(x) y @c(y) a
   comparar, @c(equal) verifica que ambos (o ninguno) son validos y comprueba
   que tienen el mismo tipo. El resultado de la funcion se define como un
   conjunto de casos de conmutacion que comparan dos valores del mismo tipo. Por
   motivos de espacio, hemos omitido varios casos, ya que el patron debe ser
   familiar por ahora.

   ..figure > @l(gopl.io/ch13/equal/equal.go<>gopl.io/ch13/equal)

     ..src > go
       func equal(x, y reflect.Value, seen map[comparison]bool) bool {
         if !x.IsValid() || !y.IsValid() {
           return x.IsValid() == y.IsValid()
         }
         if x.Type() != y.Type() {
           return false
         }

         // ...ciclo de verificacion omitido (mostrado mas adelante)...

         switch x.Kind() {
         case reflect.Bool:
           return x.Bool() == y.Bool()

         case reflect.String:
           return x.String() == y.String()

         // ...casos numericos omitidos por brevedad...

         case reflect.Chan, reflect.UnsafePointer, reflect.Func:
           return x.Pointer() == y.Pointer()

         case reflect.Ptr, reflect.Interface:
           return equal(x.Elem(), y.Elem(), seen)

         case reflect.Array, reflect.Slice:
           if x.Len() != y.Len() {
             return false
           }
           for i := 0; i < x.Len(); i++ {
             if !equal(x.Index(i), y.Index(i), seen) {
               return false
             }
           }
           return true

         // ...struct and map cases omitted for brevity...
         }
         panic("unreachable")
       }
     < src..


   Como de costumbre, no exponemos el uso de la reflexion en la API, por lo que
   la funcion exportada @c(Equal) debe llamarla con @c(reflect.ValueOf) en sus
   argumentos:

   ..src > go
     // Equal informa si x e y son profundamente iguales.
     func Equal(x, y interface{}) bool {
       seen := make(map[comparison]bool)
       return equal(reflect.ValueOf(x), reflect.ValueOf(y), seen)
     }

     type comparison struct {
       x, y unsafe.Pointer
       t
       reflect.Type
     }
   < src..

   Para asegurar que el algoritmo termina incluso para estructuras de datos
   ciclicas, debe registrar que pares de variables ya ha comparado y evitar
   compararlas una segunda vez. @c(Equal) asigna un conjunto de estructuras
   @c(comparison), cada una con la direccion de dos variables (representado como
   valores @c(unsafe.Pointer)) y el tipo de comparacion. Necesitamos registrar
   el tipo ademas de las direcciones porque las diferentes variables pueden
   tener la misma direccion. Por ejemplo, si @c(x) y @c(y) son ambos arreglos,
   @c(x) y @c(x[0]) tienen la misma direccion, como lo hacen @c(y) y @c(y[0]), y
   es importante distinguir si hemos comparado @c(x) y @c(y) o @c(x[0]) y
   @c(y[0]).

   Una vez @c(equal) ha establecido que sus argumentos tienen el mismo tipo, y antes
   de que ejecute el switch, se comprueba si se esta comparando dos variables
   que ya ha visto y, si es asi, termina la recursion.

   ..src > go
     // verificacion de ciclo
     if x.CanAddr() && y.CanAddr() {
       xptr := unsafe.Pointer(x.UnsafeAddr())
       yptr := unsafe.Pointer(y.UnsafeAddr())
       if xptr == yptr {
         return true // referencias identicas
       }
       c := comparison{xptr, yptr, x.Type()}
       if seen[c] {
         return true // ya visto
       }
       seen[c] = true
     }
   < src..

   Aqui esta nuestra funcion @c(Equal) en accion:

   ..src > go
     fmt.Println(Equal([]int{1, 2, 3}, []int{1, 2, 3}))        // "true"
     fmt.Println(Equal([]string{"foo"}, []string{"bar"}))      // "false"
     fmt.Println(Equal([]string(nil), []string{}))             // "true"
     fmt.Println(Equal(map[string]int(nil), map[string]int{})) // "true"
   < src..

   Incluso funciona en entradas ciclicas similares a la que hizo que la funcion
   @c(Display) de la @l(#Seccion 12.3) quedara atascada en un bucle:

   ..src > go
     // Lista circular enlazada a -> b -> a and c -> c.
     type link struct {
       value string
       tail *link
     }
     a, b, c := &link{value: "a"}, &link{value: "b"}, &link{value: "c"}
     a.tail, b.tail, c.tail = b, a, c
     fmt.Println(Equal(a, a)) // "true"
     fmt.Println(Equal(b, b)) // "true"
     fmt.Println(Equal(c, c)) // "true"
     fmt.Println(Equal(a, b)) // "false"
     fmt.Println(Equal(a, c)) // "false"
   < src..

   @b(Ejercicio 13.1): Definir una funcion de comparacion de profundidad que
   considere los numeros (de cualquier tipo) iguales si difieren en menos de
   una parte en mil millones.

   @b(Ejercicio 13.2): Escribir una funcion que informe si su argumento es una
   estructura de datos ciclica.

** Seccion 13.4 <> Llamar Codigo C con @$(cgo)

   Un programa Go puede necesitar utilizar un controlador de hardware
   implementado en C, consultar una base de datos enbebida implementada en C++ o
   utilizar algunas rutinas de algebra lineal implementadas en Fortran. C ha
   sido durante mucho tiempo la lingua franca de la programacion, por lo que
   muchos paquetes destinados a un uso generalizado exportan una API compatible
   con C, independientemente del lenguaje de su implementacion.

   En esta seccion, vamos a construir un simple programa de compresion de datos
   que utiliza @$(cgo), una herramienta que crea enlaces de Go para funciones C.
   Estas herramientas se llaman @e(interfaces de funcion externa) (FFIs), y
   @$(cgo) no es el unico para los programas Go. SWIG
   (@l(http://swig.org/<>swig.org)) es otro; proporciona caracteristicas mas
   complejas para integrarse con las clases de C++, pero no lo mostraremos aqui.

   El subarbol @c(compress/...) de la libreria estandar proporciona compresores
   y descompresores de los algoritmos de compresion mas populares, incluyendo
   LZW (usado por el comando Unix @$(compress)) y DEFLATE (usado por el comando
   GNU @$(gzip)). Las APIs de estos paquetes varian ligeramente en detalles,
   pero todos ellos proporcionan un envoltorio para un @c(io.Writer) que
   comprime los datos escritos en ellos, y un envoltorio para un @c(io.Reader)
   que descomprime los datos leidos de estos. Por ejemplo:

   ..src > go
     package gzip // compress/gzip

     func NewWriter(w io.Writer) io.WriteCloser
     func NewReader(r io.Reader) (io.ReadCloser, error)
   < src..

   El algoritmo bzip2, que se basa en la elegante transformacion de
   Burrows-Wheeler, corre mas lento que gzip pero produce una compresion
   significativamente mejor. El paquete @c(compress/bzip2) proporciona un
   descompresor para bzip2, pero en este momento el paquete no proporciona
   ningun compresor. La construccion de uno desde cero es una tarea sustancial,
   pero hay una implementacion en C de codigo abierto bien documentada con alto
   rendimiento, el paquete @c(libbzip2) desde @l(http://bzip.org/<>bzip.org).

   Si la libreria de C fuera pequeña, simplemente la portariamos a Go puro, y si
   su rendimiento no fuera critico para nuestros propositos, estariamos mejor
   invocando un programa en C como un subproceso de ayuda utilizando el paquete
   @c(os/exec). Es cuando se necesita utilizar una libreria compleja, de
   rendimiento critico con un API C compacto que puede tener sentido envolverla
   usando @$(cgo). El resto de este capitulo, trabajaremos con un ejemplo.

   Desde el paquete C @c(libbzip2), necesitamos el tipo de estructura
   @c(bz_stream), que contiene los buferes de entrada y salida, y tres funciones
   de C: @c(BZ2_bzCompressInit), que asigna buffers del flujo;
   @c(BZ2_bzCompress), que comprime los datos de bufer de entrada al bufer de
   salida; y @c(BZ2_bzCompressEnd), que libera los bufferes. (No se preocupe por
   la mecanica del paquete @c(libbzip2), el proposito de este ejemplo es mostrar
   como las piezas encajan entre si.)

   Vamos a llamar a las funciones @c(BZ2_bzCompressInit) y @c(BZ2_bzCompressEnd)
   C directamente desde Go, pero para @c(BZ2_bzCompress), vamos a definir una
   funcion de envoltorio en C, para mostrar como se hace. El archivo de codigo
   fuente C vive al lado del codigo Go en nuestro paquete:

   ..figure > @l(gopl.io/ch13/bzip/bzip2.c<>gopl.io/ch13/bzip)

     ..src > c
       /* Este archivo es gopl.io/ch13/bzip/bzip2.c,            */
       /* un simple envoltorio para libbzip2 adecuado para cgo. */
       #include <bzlib.h>

       int bz2compress(bz_stream *s, int action,
                       char *in, unsigned *inlen, char *out, unsigned *outlen) {
         s->next_in = in;
         s->avail_in = *inlen;
         s->next_out = out;
         s->avail_out = *outlen;
         int r = BZ2_bzCompress(s, action);
         *inlen -= s->avail_in;
         *outlen -= s->avail_out;
         s->next_in = s->next_out = NULL;
         return r;
       }
     < src..


   Ahora veamos el codigo Go, cuya primera parte se muestra a continuacion. La
   declaracion @c(import "C") es especial. No hay ningun paquete C, pero esta
   importacion hace que @$(go build) preprocese el archivo con la herramienta
   @$(cgo) antes de que el compilador Go lo vea.

   ..src > go
     // El paquete bzip proporciona un writer que utiliza compresion bzip2 (bzip.org).
     package bzip

     /*
     #cgo CFLAGS: -I/usr/include
     #cgo LDFLAGS: -L/usr/lib -lbz2
     #include <bzlib.h>
     int bz2compress(bz_stream *s, int action,
                     char *in, unsigned *inlen, char *out, unsigned *outlen);
     */
     import "C"

     import (
       "io"
       "unsafe"
     )

     type writer struct {
       w      io.Writer // flujo de salida subyacente
       stream *C.bz_stream
       outbuf [64 * 1024]byte
     }

     // NewWriter devuelve un writer para flujos bzip2 comprimidos.
     func NewWriter(out io.Writer) io.WriteCloser {
       const (
         blockSize = 9
         verbosity = 0
         workFactor = 30
       )
       w := &writer{w: out, stream: new(C.bz_stream)}
       C.BZ2_bzCompressInit(w.stream, blockSize, verbosity, workFactor)
       return w
     }
   < src..

   Durante el preprocesamiento, @$(cgo) genera un paquete temporal que contiene
   declaraciones Go correspondientes a todas las funciones de C y los tipos
   utilizados por el archivo, como @c(C.bz_stream) y @c(C.BZ2_bzCompressInit).
   La herramienta @$(cgo) descubre este tipo invocando el compilador de C de una
   manera especial sobre el contenido del comentario que precede a la
   declaracion de importacion.

   El comentario tambien puede contener directivas @c(#cgo) que especifican
   opciones adicionales a la cadena de herramientas C. Los valores @c(CFLAGS) y
   @c(LDFLAGS) aportan argumentos adicionales a los comandos de compilacion y
   enlace para que puedan localizar el archivo de cabecera @c(bzlib.h) y la
   libreria de archivo @c(libbz2.a). El ejemplo supone que estos se instalan
   debajo de @c(/usr) en su sistema. Es posible que necesite modificar o
   eliminar estos indicadores para su instalacion.

   @c(NewWriter) realiza una llamada a la funcion C @c(BZ2_bzCompressInit) para
   inicializar los buferes de la secuencia. El tipo @c(writer) incluye otro
   bufer que se utilizara para drenar el bufer de salida del descompresor.

   El metodo @c(Write), se muestra a continuacion, alimenta el compresor con
   @c(data), llamando a la funcion @c(bz2compress) en un bucle hasta que todos
   los datos se han consumido. Observe que el programa Go puede acceder tipos C
   como @c(bz_stream), @c(char), y @c(uint), funciones de C como
   @c(bz2compress), e incluso macros del preprocesador C como a objetos como
   @c(BZ_RUN), todo a traves de la notacion @c(C.x). El tipo @c(C.uint) es
   distinto del tipo @c(uint) de Go, incluso si ambos tienen el mismo tamaño.

   ..src > go
     func (w *writer) Write(data []byte) (int, error) {
       if w.stream == nil {
         panic("closed")
       }
       var total int // bytes escritos sin comprimir

       for len(data) > 0 {
         inlen, outlen := C.uint(len(data)), C.uint(cap(w.outbuf))
         C.bz2compress(w.stream, C.BZ_RUN,
           (*C.char)(unsafe.Pointer(&data[0])), &inlen,
           (*C.char)(unsafe.Pointer(&w.outbuf)), &outlen)
         total += int(inlen)
         data = data[inlen:]
         if _, err := w.w.Write(w.outbuf[:outlen]); err != nil {
           return total, err
         }
       }
       return total, nil
     }
   < src..

   Cada iteracion del bucle @c(bz2compress) pasa la direccion y longitud de la
   porcion restante de la variable @c(data), y la direccion y capacidad de
   @c(w.outbuf). Las dos variables de longitud son pasadas por sus direcciones,
   no por sus valores, por lo que la funcion C puede actualizarlas para indicar
   la cantidad de datos sin comprimir que se consumio y la cantidad de datos
   comprimidos producidos. Cada trozo de datos comprimido se escribe en el
   @c(io.Writer) subyacente.

   El metodo @c(Close) tiene una estructura similar a @c(Write), utilizando un
   bucle para eliminar cualquier resto de datos comprimidos del bufer de salida
   del flujo.

   ..src > go
     // Cierra los datos comprimidos y cierra el flujo.
     // No cierra el io.Writer subyacente.
     func (w *writer) Close() error {
       if w.stream == nil {
         panic("closed")
       }
       defer func() {
         C.BZ2_bzCompressEnd(w.stream)
         w.stream = nil
       }()
       for {
         inlen, outlen := C.uint(0), C.uint(cap(w.outbuf))
         r := C.bz2compress(w.stream, C.BZ_FINISH, nil, &inlen,
           (*C.char)(unsafe.Pointer(&w.outbuf)), &outlen)
         if _, err := w.w.Write(w.outbuf[:outlen]); err != nil {
           return err
         }
         if r == C.BZ_STREAM_END {
           return nil
         }
       }
     }
   < src..

   Al finalizar, @c(Close) llama a @c(C.BZ2_bzCompressEnd) para liberar los
   buferes de flujo, utilizando @c(defer) para asegurar que esto sucede en todas
   las rutas de retorno. En este punto el puntero @c(w.stream) ya no es seguro
   de desreferenciar. Para estar a la defensiva, lo ponemos a @c(nil), y
   agregamos chequeos explicitos de nil en cada metodo, por lo que el programa
   entra en panico si el usuario llama por error un metodo despues de @c(Close).

   No solo @c(writer) no es concurrentemente seguro, sino que las concurrentes a
   @c(Close) y @c(Write) podria hacer que el programa se bloquee en el codigo
   C. Correjir esto es el Ejercicio 13.3.

   El siguiente programa, @c(bzipper), es un comando @c(bzip2) compresor que
   utiliza nuestro nuevo paquete. Se comporta como el comando @$(bzip2) presente
   en muchos sistemas Unix.

   ..figure > @l(gopl.io/ch13/bzipper/main.go<>gopl.io/ch13/bzipper)

     ..src > go
       // Bzipper lee la entrada, lo comprime como bzip2, y lo escribe en la salida.
       package main

       import (
         "io"
         "log"
         "os"

         "gopl.io/ch13/bzip"
       )

       func main() {
         w := bzip.NewWriter(os.Stdout)
         if _, err := io.Copy(w, os.Stdin); err != nil {
           log.Fatalf("bzipper: %v\n", err)
         }
         if err := w.Close(); err != nil {
           log.Fatalf("bzipper: close: %v\n", err)
         }
       }
     < src..


   En la sesion a continuacion, utilizamos @$(bzipper) para comprimir
   @c(/usr/share/dict/words) el diccionario del sistema, de 938,848 bytes a
   335,405 bytes–aproximadamente un tercio de su tamaño original–luego lo
   descomprimimos con el comando del sistema @$(bunzip2). El hash SHA256 es el
   mismo antes y despues, dandonos confianza de que el compresor esta
   funcionando correctamente. (Si usted no tiene @$(sha256sum) en su sistema,
   utilice su solucion al Ejercicio 4.2.)

   ..srci > sh
     > go build gopl.io/ch13/bzipper
     > wc -c < /usr/share/dict/words
     938848
     > sha256sum < /usr/share/dict/words
     126a4ef38493313edc50b86f90dfdaf7c59ec6c948451eac228f2f3a8ab1a6ed -
     > ./bzipper < /usr/share/dict/words | wc -c
     335405
     > ./bzipper < /usr/share/dict/words | bunzip2 | sha256sum
     126a4ef38493313edc50b86f90dfdaf7c59ec6c948451eac228f2f3a8ab1a6ed -
   < srci..

   Hemos demostrado la vinculacion de una libreria C con un programa Go. Yendo
   en la otra direccion, tambien es posible compilar un programa Go como un
   archivo estatico que se puede vincular en un programa C o como una libreria
   compartida que puede cargarse dinamicamente por un programa C. Solo hemos
   arañado la superficie de @$(cgo), y hay mucho mas que decir acerca de la
   gestion de memoria, punteros, devoluciones de llamada, el manejo de señales,
   cadenas, @c(errno), finalizadores, y la relacion entre gorutinas y los hilos
   del sistema operativo, gran parte de ello muy sutil. En particular, las
   reglas para pasar correctamente punteros de Go a C o viceversa son complejas,
   por razones similares a las que discutimos en la @l(#Seccion 13.2), y aun no
   autoritariamente especificadas. Para mas informacion, comience con
   @l(https://golang.org/cmd/cgo).

   @b(Ejercicio 13.3): Utilice @c(sync.Mutex) para hacer @c(bzip.writer) seguro
   para el uso concurrente por multiples gorutinas.

   @b(Ejercicio 13.4): Depender de librerias C tiene sus inconvenientes.
   Proporcione una implementacion alternativa en puro Go de @c(bzip.NewWriter)
   que utilice el paquete @c(os/exec) para ejecutar @c(/bin/bzip2) como un
   subproceso.

** Seccion 13.5 <> Otra Palabra de Precaucion

   Terminamos el capitulo anterior con una advertencia sobre las desventajas de
   la interfaz de reflexion. Esa advertencia se aplica incluso con mas fuerza al
   paquete @c(unsafe) descrito en este capitulo.

   Los lenguajes de alto nivel aislan a los programas y programadores no solo de
   los detalles arcanos de los conjuntos de instrucciones individuales de
   computadora, sino de la dependencia de las irrelevancias, como la memoria en
   la que vive una variable, el tamaño del tipo de datos, y otros detalles de
   implementacion del anfitrion. Debido a esa capa aislante, es posible escribir
   programas que son seguros y robustos y que se ejecutaran en cualquier sistema
   operativo sin cambios.

   El paquete @c(unsafe) permite a los programadores cruzar a traves del
   aislamiento para utilizar alguna caracteristica crucial, pero de otro modo
   inaccesible, o tal vez para lograr un mayor rendimiento. El costo suele ser
   la portabilidad y la seguridad. Nuestro consejo sobre como y cuando usar
   @c(unsafe) son paralelos a los comentarios de Knuth para la optimizacion
   prematura, que hemos citado en la @l(#Seccion 11.5). La mayoria de los
   programadores nunca necesitaran utilizar @c(unsafe) en absoluto. Sin embargo,
   ocasionalmente habra situaciones en las que algun fragmento de codigo critio
   puede ser escrito mejor usando @c(unsafe). Si el estudio y la medicion
   cuidadosa indican que @c(unsafe) realmente es el mejor enfoque, restrinja el
   fragmento lo mayor posible, para que la mayor parte del programa ignore su
   uso.

   Por ahora, ponga los dos ultimos capitulos en la parte de atras de su mente.
   Escriba algunos programas importantes en Go. Evite @c(reflect) y @c(unsafe);
   Vuelva a estos capitulos solamente si debe hacerlo.

   Mientras tanto, Feliz programacion con Go. Esperamos que disfrutes
   escribiendo en Go tanto como nosotros.