Hace poco hice Waterloo CCC y creo que Haskell es el lenguaje perfecto para responder este tipo de preguntas. Aún lo estoy aprendiendo. Sin embargo, estoy luchando un poco con la entrada.Haskell: lea un archivo por línea
Aquí es lo que estoy usando:
import IO
import System.Environment
import System.FilePath
…
main = do
name <- getProgName
args <- getArgs
input <- readFile $
if not (null args)
then head args
else dropExtension name ++ ".in"
let (k:code:_) = lines input
putStrLn $ decode (read k) code
Como se puede ver, estoy leyendo de la ruta del archivo de línea de comandos o desde j1.in
dada, por ejemplo, si este programa se llama j1.hs
y compilado a j1
.
Solo estoy interesado en las dos primeras líneas del archivo, por lo que he usado la coincidencia de patrones para obtener esas líneas y vincularlas a k
y code
, en este ejemplo. Y entonces leo k
como un entero y lo paso y la cadena de código a mi función decode
, que imprimo.
Me pregunto si readFile
está cargando todo el archivo en la memoria, lo que sería malo. Pero luego comencé a pensar, tal vez porque Haskell es flojo, solo lee las dos primeras líneas porque eso es todo lo que se pide más adelante. ¿Estoy en lo cierto?
Además, si hay algo con ese ejemplo de código que podría ser mejor o más idiomático, házmelo saber.
En un tutorial 'hSetBuffering stdin LineBuffering' vi utilizado para stdin porque la entrada solo se ingresaría una línea a la vez; ¿habría un equivalente para la entrada de archivos? Si existe, ¿tendría sentido usarlo o se consideraría una optimización prematura? – mk12
No estoy de acuerdo con su punto de que la E/S esencialmente perezosa solo es útil cuando es trivial. Un ejemplo de una característica muy útil de la E/S perezosa, en configuraciones pesadas de E/S, es que, de manera predeterminada, el manejo de datos está en su lugar, lo que significa que es muy eficiente para grandes volúmenes de datos. – amindfv
@amindfv: Él no dice que la E/S perezosa es _inútil_ para los grandes programas, él dice que es _ malo_. Lo que quiere decir es que la IO lenta a menudo conduce a pérdidas de recursos (aquí el archivo nunca se cierra porque no se lee hasta el final) que son difíciles de corregir en programas grandes y complejos. Se deben preferir soluciones basadas en principios para la transmisión (como Iteratee o el Conduit más reciente) porque le dan un mejor control. – Jedai