2011-04-28 19 views
22

En mi opinión, el poder de la pureza funcional se logra cuando las rutas de código profundas se pueden verificar como libres de efectos secundarios. ¿Cuáles son las experiencias de las personas en la escala del árbol de códigos que pueden estar dentro de un especificador puro, y qué ocurre con el nivel de reutilización del código?Programación funcional pura en D

Algunas cosas Manché:

std.algorithm en su mayoría no se marca como pure, pero potencialmente podría ser lo más puro posible, ya sea por una versión pura de algoritmos que exigen pureza de la función de creación de instancias o mixin, o bien por la pureza el propio especificador es polimórfico estático.
Los convertidores útiles como to!string(someInt) no son actualmente puros.

estructuras definidas por el usuario parecen tener problemas (como se ilustra abajo) con:
1. destructores puros en una estructura anidada
2. una función postblit puro incluso en un struct no anidada

El código siguiente Actualmente da múltiples errores en la DMD 2.052 ganan 32 bits

struct InnerStruct 
{ 
    pure this(this) {} 
    pure ~this() {} 
} 

struct OuterStruct 
{ 
    InnerStruct innerStruct; 
    pure this(this) {} 
    pure ~this() {} 
} 

pure void somePureFunc() 
{ 
    OuterStruct s1 = OuterStruct(); // pure nested destructor does not compile 
    OuterStruct s2 = s1; 
    InnerStruct is1 = InnerStruct(); // pure non-nested destructor seems to compile 
    InnerStruct is2 = is1; // pure non-nested postblit does not compile 
} 

void main() 
{ 
    somePureFunc(); 
} 
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '__cpctor' 
pure_postblit.d(20): Error: pure function 'somePureFunc' cannot call impure function '__cpctor' 
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '~this' 
pure_postblit.d(17): Error: pure function 'somePureFunc' cannot call impure function '~this' 

Respuesta

21

en teoría, el punto de pure en D es que se supone que debe permitir gu garantiza que una función es libre de efectos secundarios independientemente de cómo se implemente esa función. Hay dos clases de pureza en D:

  • Todas las funciones marcadas pure son débilmente puro. No pueden acceder a ningún estado mutable global (variables globales, variables locales de subprocesos, variables static, etc.) o realizar E/S. Sin embargo, pueden mutar sus argumentos. El objetivo de estas funciones es que pueden ser llamadas desde funciones fuertemente puras (detalladas a continuación) sin violar las garantías de una fuerte pureza.

  • Todas las funciones que son débilmente puras y no tienen ningún argumento con mutable indirección son muy puras. Los constructores de tipo const y immutable se pueden usar para garantizar esto. (Cuando se trata de estructuras y clases, el puntero this se considera un parámetro.) Las funciones muy puras tienen todas las agradables propiedades de las que habla la programación funcional, incluso si se implementan usando el estado mutable. Una función fuertemente pura siempre devuelve el mismo valor para cualquier argumento dado y no tiene efectos secundarios observables. Las funciones fuertemente puras son referencialmente transparentes, lo que significa que su valor de retorno puede sustituirse por una llamada a ellas con un conjunto dado de parámetros sin afectar el comportamiento observable. Cualquier función fuertemente pura se puede ejecutar con seguridad en paralelo con cualquier otra función fuertemente pura.

Por desgracia, la interacción entre el código genérico y pure (así como const y immutable) es bastante pobre. Ha habido varias propuestas para solucionar esto, pero ninguna ha sido aceptada aún.
\ std.algorithm está escrito para ser lo más genérico posible, por lo que no puede requerir que sus funciones lambda y los rangos que acepta sean puros. Además, las características del sistema tipo que se agregaron en D2 son generalmente las características con más errores en el lenguaje, porque se han priorizado más elementos básicos antes de solucionar los problemas relevantes. En este momento, pure básicamente no se puede usar excepto en casos triviales como std.math.

+0

Gracias por sus comentarios. Observé la definición débil de pureza hace un tiempo cuando experimenté, y es claramente muy poderosa, permitiendo la programación de OO completamente mutable en código puro, y al crear thunks de evaluación diferida o programar promesas, etc. la forma fuerte puede afirmarse fácilmente por meta -programación en los calificadores de tipo. Creo que para que la visión altamente concurrente despegue realmente, mucho más debe ser capaz de estar dentro de un envoltorio puro. Los problemas de destructor y postblit que mencioné me están afectando más ya que necesito hacer una referencia de recuento en código puro, ¿cree que son errores? – John

+0

@John: Sí, estos son probablemente errores. – dsimcha

Cuestiones relacionadas