2010-05-10 26 views
31

Sé que existe el perl regex que es una especie de estándar menor de facto, pero ¿por qué nadie ha presentado un conjunto universal de símbolos estándar, sintaxis y comportamientos?¿Por qué no hay un estándar de expresión regular?

+2

Me he hecho la misma pregunta muchas veces, y nunca he encontrado una buena respuesta. Estoy feliz de haber encontrado www.regular-expressions.info – chilltemp

Respuesta

16

Hay un estándar por IEEE associated with the POSIX effort. La verdadera pregunta es "¿por qué no todos lo siguen?"? La respuesta es probablemente que no es tan complejo como PCRE con respecto a la concordancia codiciosa y qué no.

+6

Y la pregunta de seguimiento quizás sea entonces: * ¿por qué no se renovó/extendió el estándar POSIX para incluir más sintaxis? * Porque entonces tal vez la gente podría tratar de seguirlo. –

+0

@PeterBoughton: sin dudas ... ahora todo lo que tenemos que hacer es hacer que todos acuerden lo lejos que queremos llegar. Soy de la opinión de que estarías mejor con un analizador completo que la mayoría de los RE extendidos que existen. Si necesita comentarios en su RE, entonces es demasiado complicado para una RE. –

+0

Bueno, sí y no. Mientras que un analizador completo podría ser una mejor opción, generalmente no es un código conciso (a menos que haya una DSL compacta/generalizada para generar analizadores sintácticos) y, aparte, cualquier norma debería cubrir lo que se usa (aunque no necesariamente sea un enfoque sensato) –

2

Porque hacer estándares es difícil. Es casi imposible conseguir suficientes personas para ponerse de acuerdo en algo que lo convierta en un estándar oficial, y mucho menos en algo tan complejo como la expresión regular. Los estándares defacto son mucho más fáciles de conseguir.

Ejemplo: HTML 5 no se espera que se convierta en un estándar oficial hasta el año 2022. Pero el borrador de la especificación ya está disponible, y las características principales del estándar comenzarán a aparecer en los navegadores mucho antes de que el estándar sea oficial.

+2

Solo una nota sobre: ​​HTML5: si bien se espera que sea una recomendación oficial solo para el año 2022, se espera que se convierta en una recomendación para 2012. CSS2 (¡no 3!) todavía está en la etapa de recomendación de candidatos, pero es bastante ampliamente implementado en este punto. HTML5 será perfectamente útil MUCHO antes de 2022. – ceejayoz

+9

Me pregunto si los autos voladores en 2022 soportarán HTML5. – Chris

+0

CSS 2 no es una recomendación de candidato, es una recomendación completa, y lo ha sido desde 1998. CSS 2.1 es una recomendación de candidato, y ha estado en ese estado desde mediados de 2007. –

0

Perl fue el primero (o casi lo mismo que el primero), y aunque es perl y todos nos encanta, es antiguo que algunas personas sintieron que necesitaba más pulido (es decir, características). Aquí es donde entraron los nuevos tipos.

Están comenzando a nomalizar, la expresión regular utilizada en .NET es muy similar a la expresión regular utilizada en otros idiomas, creo que lentamente la gente está empezando a unificarse, pero algunos están acostumbrados a su perl maneras y no quiere cambiar.

+0

Perl fue inventado en 1987 según Wikipedia. No puedo encontrar una fecha para grep, pero te aseguro que fue mucho antes. Puede haber implementaciones en Unix que fueron incluso anteriores. –

+1

Perl llegó bastante tarde en el juego (http://en.wikipedia.org/wiki/Regular_expression#History). Henry Spencer escribió la mayoría de las agallas a finales de los 80 antes de que se incorporara a principios de Perl. Pero la implementación de Spencer era reemplazar una implementación patentada ya existente. –

+0

Gracias por las correcciones chicos. Sabía que Perl era viejo, pero no estaba seguro de si era el más viejo. El punto sigue en pie, está evolucionando, y creo que lentamente están comenzando a converger. – Aren

0

Solo una conjetura: nunca hubo una versión lo suficientemente popular como para ser considerada el estándar canónico, y no hubo una implementación estándar. Todos los que vinieron y lo reimplantaron tenían sus propias ideas sobre cómo hacerlo "mejor".

8

En realidad, hay es un estándar de expresión regular (POSIX), pero es horrible. Así que las personas amplían su motor de RE para adaptarse a las necesidades de su aplicación. PCRE (expresiones regulares compatibles con Perl) es un pseudo-estándar para expresiones regulares que son compatibles con el motor de RE de Perl. Esto es particularmente relevante porque puede insertar el motor de Perl en otras aplicaciones.

+6

Crappy de qué manera? –

1

He investigado esto y no he podido encontrar nada concreto. Supongo que es porque la expresión regular es tan a menudo una herramienta que funciona con las herramientas EN y, por lo tanto, necesariamente tendrá plataformas y herramientas específicas.

Por ejemplo, en Visual Studio, puede usar expresiones regulares para buscar y reemplazar cadenas en su código fuente. Han agregado cosas como: yo para unir un identificador. En otras plataformas en otras herramientas, los identificadores pueden no ser un concepto aplicable. De hecho, quizás otras plataformas y herramientas reserven el carácter de dos puntos para escapar de la expresión.

Diferencias como esta hacen que sea particularmente difícil de estandarizar.

+3

Un punto válido, pero un estándar no estandarizaría "así es como se corresponde un identificador", sino que "aquí se explica cómo ampliar los símbolos coincidentes personalizados", o lo que sea, para que las extensiones se puedan implementar de manera consistente/predecible entre plataformas. –

+0

@ Peter Buen punto, el estándar podría generalizarse para acomodar tales cosas. Sin embargo, eso haría más difícil de leer e implementar (a su punto, ahuyentando a las personas más sensatas :)). – Chris

-3

Debido a que muchas personas tienen miedo de las expresiones regulares, por lo que no se han extendido lo suficiente como para que suficientes personas sensatas piensen en la idea y estén en condiciones de implementarla.

Incluso si se formara un cuerpo de normas y tratara de unificar los diferentes sabores, demasiadas personas discutirían obstinadamente su propio enfoque, ya sea mejor o no, porque muchos programadores son molestos así.

Cuestiones relacionadas