On Thu, Sep 17, 2009 at 11:56:38AM -0300, Claudio Freire wrote:
> El problema de los while True y los breaks es que hacen el análisis de
> correctitud y terminación por invariantes casi imposible.
Que yo sepa, esto no es cierto.
> Están deprecados en el mundo de la programación porque es muy difícil,
> leyéndolos, asegurar que no es un loop infinito, y que cuando sale el
> invariante (si hay) se cumple.
Esto tampoco. Por un lado, lo de "deprecados" creo que no tiene mucho sentido
real, ya que se siguen usando todo el tiempo. No se quien los declaro asi,
pero en la practica es algo que no se manifiesta ni un poquitito.
Por otro lo de asegurar los invariantes creo que no es cierto. Dependiendo de
cuan formal te quieras poner, te pueden hacer mas o menos dificiles las cosas,
pero creo que la complicacion no pasa porque haya o no breaks o continues.
Si te interesa revisarlos en runtime vos podes revisar invariantes antes y
despues de cada funcion, como hace Eiffel por ejemplo (o como se puede hacer
muy facilmente en Python, por ejemplo
http://blitiri.com.ar/git/?p=pymisc;a=blob;f=contract.py), independientemente
si adentro de una funcion usas break, continue, goto, assembler o lo que mas
te guste.
Ademas, demostrar la correctitud de un algoritmo es distinto que demostrar la
correctitud de una implementacion. Al demostrar la correctitud de una
implementacion (cosa que practicamente nadie (o digamos "muy poca gente" para
que nadie se ofenda =) hace) una de las cosas que mas te complica la vida es
la mutabilidad y no tanto el flujo, y por eso es muy comun que las
formalizaciones se hagan usando lenguajes mas o menos funcionales.
Aparte, si te interesara realmente formalizarlo, hay muchas transformaciones
automaticas que vos le podes hacer a un codigo con breaks y continues para
transformarlo en uno sin, si es que eso te sirve.
Pero de cualquier manera, para mi, si vos no vas realmente a demostrarlo (cosa
que, te repito, practicamente nadie hace), es mucho mejor concentrarte en que
tu codigo sea claro y legible para un humano, ya que cuando haya un bug va a
ser un humano el que tenga que entender tu codigo para arreglarlo.
Y si lo vas a demostrar no estarias escribiendo en Python ;)
Gracias,
Alberto
---------------------------------------------------------------------
Para dar de baja la suscripcion, mande un mensaje a:
pyar-unsubscribe@???
Para obtener el resto de direcciones-comando, mande un mensaje a:
pyar-help@???
PyAr - Python Argentina - Sitio web:
http://www.python.com.ar/
(text/plain)