Adjunto el final de Paradigmas tomado el 01/08/2015

Les paso también mi resolución, pero tengan en cuenta que me saqué un 6, con lo cual seguramente haya cosas que estén mal.
Úsenlo de guía y corrijan lo que les parezca.

EJERCICIO 1
1. Dependerá de como esté impliementado el método "first" dado que el select devolverá una colección vacía y se intentará traer el primer elemento de esa colección.
2. No hay efectos colaterales. No hay ninguna variable global que esté siendo asignada de manera destructiva.
3.a. En la versión en Prolog, al ser inversible, puedo consultar con la variable Alumno sin ligar y el predicado me generará todos los valores posibles. En el caso de Haskell, solo mostrará el primer alumno que tenga nota 10.
3.b. En el caso de Prolog, si no hay ninguno me devolverá falso: por el concepto de universo cerrado, todo lo que no está en la base de conocimiento se considera falso. En el caso de Haskell, dependerá de como esté implementada la función "head", dado que el filter devolverá una lista vacía y se intentará traer la cabeza de esa lista.

EJERCICIO 2
1.
promedio[] = 0
promedio xs = sum xs / length xs

?- f [([8,7,6], "Sabrina"), ([1,2,3], "Ariel"), ([10, 5, 6], "Nicolas")] promedio 4
> ["Sabrina", "Nicolas"]

?- f [("Bacciadonne", 25), ("Cortese", 27)] head 'B'
> [27]

2.
f xs func valor = [snd x | x <- xs, aplicayCompara func valor (fst x)]
aplicayCompara f v x = f x > v

3. Es mas declarativa porque usa listas por comprensión. No es necesario el uso de guardas, sino que toda la lógica se concentra en la forma de armar la lista resultante. Además, en el uso de la función auxiliar, también estamos delegando la responsabilidad de aplicar la función recibida y la comparación en otra función, razón por la cual hay menos pasos algorítmicos en f y esto la hace mas declarativa.

EJERCICIO 3
1. No estoy de acuerdo. Si bien es cierto que los nombres de los métodos son iguales en todas las clases, no se aprovecha el polimorfismo pues se consulta una por una las colecciones que son homogéneas (todas tienen objetos de la misma clase).
Para aprovechar el polimorfismo yo haría que la ListaReproduccion tenga una colección de listas, álbumes y canciones juntas. Y la función duración se implementaría de esta forma:

#ListaReproduccion
>> duracion
^ coleccion sum: [:unObjeto | unObjeto duracion].

De esta manera, cualquier objeto de la colección dentro de la lista, entiende el mensaje duración y lo resuelve de acuerdo a como se codificó su propio método, y ahí si se aprovecha el polimorfismo.

(Acá también hice un diagrama de clases donde puse que ListaReproduccion tenía un atributo "coleccion" y un método "duracion" y de esa clase salían fechas a sí misma, a Album y a Cancion con el asterisco que indica que contiene una colección de objetos de esas clases)

2.a.
duracion (Coleccion, DuracionTotal):-
findall(D, (member(C, Coleccion), duracion(C, D)), Duraciones),
sumlist(Duraciones, DuracionTotal).

2.b. Este punto creo que no lo contesté.

3.a. El problema es que de esta forma, el usuario no podrá cambiar su condición de pago/gratuito, porque una vez que se instanció como objeto de una clase, no podrá pasarse a otra.

3.b.
#Usuario
vi: listaReproduccion
vi: tipo
>> agregarSiPuede: unElemento
(self tipo = 'pago' | listaReproduccion duracion <= 60)
ifTrue: [listaReproduccion agregar: unElemento].

En el ejercicio 1) punto 2), puede ser que haya efecto colateral dependiendo de lo que devuelve el metodo buenAlumno? Si miCurso no tiene alumnos con nota 10, entonces no va a existir efecto colateral ya que la coleccion de ayudantes no se va a cambiar. En cambio si miCurso si tiene alumnos con 10, va a existir efecto colateral dado que va a haber un cambio en la coleccion de ayudantes.

De esta forma estaria bien justificado?