El comentario de OscarRyz es muy pertinente.
Los lenguajes específicos de dominio, son lo que el término expresa: específicos del dominio, y para que eso se materialice tienen que atender el lenguaje que usan los especialistas en ese dominio. El lenguaje por tanto tiene que considerar la sintaxis y la semántica de las expresiones que se usan en ese dominio.
Cuando expreso que deben considerar el lenguaje "natural" del dominio, no me estoy refiriendo al lenguaje natural, el que usamos para comunicarnos los seres humanos. Me refiero al lenguaje que es natural en el dominio para escribir las soluciones a los problemas que se desean resolver.
MatLab por ejemplo usa un lenguaje específico de dominio para resolver problemas de matemáticas y otros afines, AutoCad hace los mismo para sus cosas y así podríamos mencionar otros dominios.
Por supuesto que hay dominios particulares para cosas particulares que queremos resolver en el espacio de solución (el espacio de la computadora). Es el caso que menciona OscarRyz cuando hace referencia a lenguajes declarativos usados para la construcción (build) de proyectos. En esos casos las herramientas de construcción ofrecen un lenguaje propio para escribir las "recetas" de construcción.

Con respecto a las clases case y la programación funcional. Sigo en mi otro comentario

Aquí la segunda parte de este post, donde presentamos el uso de las clases case para hacer pattern matching sobre objetos. Habrán más partes. Ya no me alcanza con dos.
Seguimos el ejemplo de las expresiones aritméticas. Veamos como podemos usar las técnicas de clases case y pattern matching para simplificar expresiones aritméticas.
Consideremos tres reglas de simplificación:

• Simplificar la negación doble:
  UnOp ("-", UnOp("-", e))  => e
• Simplificar la suma con 0:
  BinOp("+",e, Number(0) ) => e
• Simplificar la multiplicación por la unidad
  BinOp("*",e, Number(1) ) =>e

Las propias expresiones para estas tres reglas podrían ser usadas por un algoritmo que determine si una expresión de entrada concreta, por ejemplo BinOp("+",Var("x"), Number(0) ) se corresponde (hace match) con la parte izquierda de algunas de las reglas de producción anteriores. Podemos pensar que los antecedentes de esas reglas son expresiones "regulares" que pueden contrastarse con esa expresión concreta para determinar si esta última satisface la "expresión regular".
Definamos entonces una función parcial para realizar ese pattern matching y un ejemplo simple para hacer uso de ella:

Al ejecutar el programa el resultado es:

Como comentamos con anterioridad, una función parcial está definida para un conjunto limitado de los elementos del dominio, que se asocian con un elemento del codominio. En el ejemplo, los elementos del dominio aceptados son aquellas expresiones aritméticas de tipo  Expr+ 0 y Expr * 1. Para el resto de las expresiones, la función no está definida.
PartialFunction está definido con un trait y un objeto acompañante:

Es una función unaria (function1) donde el dominio no incluye necesariamente todos los valores de tipo A. Como toda función, es contravariante en el tipo del argumento y covariante en el tipo de resultado.
Para ella se definen varios métodos útiles para la composición de funciones y por supuesto el método:

que devuelve verdadero si la función está definida para ese argumento o falsa si no está definida:

El resultado sería false, mientras que:

El resultado sería true
Con los métodos de PartialFunction podemos resolver problemas interesantes de composición de objetos y de pattern matching. Pero eso se merece otro post.
Podríamos escribir un código similar definiendo un método que use una expresión match:

Usamos en este caso el patrón wildcard (_) que hace match con cualquier expresión, pero que no introduce un nombre de variable para poder referirnos a ese valor en la parte derecha de la regla de producción. Esa regla cubre entonces todos los valores que antes se excluían del dominio y deja de ser parcial.
simplifyTop es un método y no una función pero puede usarse en el lugar que se espera una función gracias a que el compilador realiza la coerción necesaria. Podemos por supuesto hacerlo nosotros cuando lo necesitamos.
To be continued .......

Este tópico quedó en cierto sentido incompleto. Para completarlo, es necesario continuar con los tipos de pattern matching que Scala soporta, y también hablar de los extractores que generalizan la descomposición y análisis de datos usando pattern matching.
Sigo con el ejemplo de las expresiones aritméticas para describir los tipos de pattern matching. Uso el término en inglés pues los términos en español "apareamiento o casamiento de patrones" no me checan. Cuesta trabajo imaginarse a las estructuras de datos apareándose.

Los tipos de patrones en Scala

Son varios los tipos de patrones que podemos usar en Scala. Una clasificación posible es la siguiente:

• Patrones wildcard
• Patrones constantes
• Patrones variables
• Patrones constructores
• Patrones de secuencia
• Patrones de tuplas
• Patrones tipados

La anterior no es la única clasificación que se puede hacer,pero es una conveniente para discutir esta técnica.
Recordemos que cuando hacemos pattern matching utilizamos la expresión match. La sintaxis de esta expresión es:

Recordemos cosas importantes de match

La expresión match es similar a la sentencia switch de muchos lenguajes de programación (Java entre ellos), pero con algunas diferencias:

• match es una expresión y no una sentencia: devuelve un valor. Esto es importante para dar soporte al estilo objeto funcional de Scala. Conviene repetir lo que ya hemos dicho en otras ocasiones: En un lenguaje funcional, todas las computaciones se realizan mediante la evaluación de expresiones que producen un valor. Las expresiones son términos sintácticos y los valores que ellas producen al ser evaluadas son entidades abstractas que tomamos como respuestas.
• Las expresiones alternativas de una expresión match nunca "caen" en el siguiente caso. No hay necesidad entonces de escribir sentencias "break" después de cada alternativa.
• Si ninguno de los patrones de las alternativas que componen la expresión match se satisface, se dispara una excepción de tipo  MatchError.
  Cuando creamos una función parcial compuesta por una secuencia de expresiones case, podemos usar el método isDefinedAt(...) de las funciones parciales como un mecanismo de programación defensiva para evitar el disparo de la excepción.

La secuencia de alternativas de match se escriben como reglas de producción que comienzan con la palabra reservada case:

El símbolo => es también una palabra reservada del lenguaje.
Evaluamos la expresión match evaluando cada alternativa en el orden que aparecen. si el patrón en la la regla hace match con el selector de la expresión, se evalúa entonces la expresión del lado derecho de la regla y su valor es devuelto por la expresión match. Repetimos uno de los ejemplos,donde es evidente que la primera regla se satisface.

Los patrones wildcard

El patrón wildcard representado por el guión bajo (_) hace match con cualquier valor (objeto). Es útil para expresar el caso de default cuando el resto de las reglas no cubren todos los valores posibles que puede tener el selector de la expresión match. Es una mala práctica aunque útil para propósitos de scripting y depuración cuando trabajamos con instancias de clases case como selectores de una expresión match, y queremos asegurarnos que se incluyen todos los casos posibles, aunque esos casos no han terminado de "programarse".
A veces no podemos hacer eso, debido a que no tenemos un comportamiento de default definido para la expresión match. Necesitamos asegurarnos que las alternativas cubren todos los casos posibles del valor del selector. Las clases selladas (sealed) tienen ese objetivo.
Los patrones wildcard pueden usarse para ignorar partes de un objeto. Por ejemplo, si el selector de la siguiente expresión se asocia con un valor de tipo Expr, podemos entonces determinar si se trata de una expresión binaria con:

¿Qué sucedería en el siguiente código?

Los patrones constantes

Un patrón constante hace solamente match consigo mismo. Como constantes en el patrón podemos usar cualquier literal, cualquier val y cualquier objeto singleton. El siguiente ejemplo muestra el uso de algunos patrones constantes:

El ejemplo muestra el uso de literales y de dos objetos: Solitario, definido en el ejemplo y Nil, parte de Scala.
Si ejecutamos:

Observa que Solitario está definido como un case object, de manera que obtenemos de "gratis" su representación textual sin necesidad de definir el método toString(). El compilador lo hace por nosotros.
Siempre suceden cosas "extrañas". Se me ocurrió escribir el siguiente código,que compila sin problemas:

Y después de escribirlo y entrarme algunas dudas sobre List() y Nil para indicar listas vacías, lo reescribí de la siguiente forma:

Y entonces ese código no compiló indicando la línea  case Nil => ..... como "unreachable code".
Puedes echarle un vistazo a algunas opiniones sobre eso en StackOverFlow.

Patrones variables

Un patrón variable hace match con cualquier objeto o valor. Entonces, ¿cuál es la diferencia con el patrón wildcard que también hace match con cualquier objeto?
La diferencia es importante: Scala hace binding de la variable con lo que sea el objeto y en la parte derecha de la regla podemos hacer uso de ella para "interactuar" con el objeto.
El método simplifyTop(expr:Expr) del ejemplo de expresiones aritméticas que estamos usando ilustra esa asociación entre el patrón variable y la parte correspondiente del selector:

En el código se desea simplificar expresiones binarias convirtiendo  var + 0 en  var y convirtiendo  var * 1 en var . Se simplifica también un expresión unaria de tipo  - - var en  var.
La variable expr del patrón variable se asocia con la parte correspondiente de la representación del objeto.
Sigue otro ejemplo, que por supuesto jamás escribiríamos para obtener el principio y el resto de una lista, pero que ilustra los patrones variables:

Si cambiamos el patrón del primer case del ejemplo anterior por x::xs, teniendo ahora el siguiente código:

El resultado es el mismo. Conviene saber la diferencia entre x::xs y ::(x,xs). Lo dejo de tarea.

Nota: El método  format( text; String, xs: Any*) en el objeto scala. Predef está "deprecated", pero es irrelevante en estos ejemplos.

¿Cómo identificar los patrones variables de los patrones constantes?

Scala necesita una regla léxica para distinguir las constantes o valores de las variables en los patrones variables y los patrones constantes. El siguiente código no compila:

El eror se anuncia como:

Si ahora escribimos:

el código compila y se obtiene el resultado:

La regla léxica entonces es: utilizar nombres que comiencen con una letra minúscula para patrones variables y nombres que comiencen con mayúscula para patrones variables.
El libro de Odersky ilustra esa regla con los valores Pi y E definidos en el objeto paquete scala.math

¿Cuál es el resultado?
OOPS, ¿Qué es un objeto paquete (package object)? Lo dejo de tarea.

¿Qué sucede si escribimos los siguiente?

¿Cual sería el resultado?

Apenas he descrito los patrones variables y los patrones constantes y ya se hizo muy largo este post. Mejor le paro aquí y sigo con este rollo en otra entrada.