Lamentablemente tengo que volver al asunto de las comillas.
Pues vamos allá.
La cuestión es que si uno intenta hacer un programa de computadora,
ya no hay signos, sino caracteres, y las comillas se usan con otro significado,
que puede llegar a ser justo el opuesto del uso gramatical dado en este hilo.
¿Y eso qué tiene que ver? El uso de las comillas que he explicado en este hilo, es un apéndice, si quieres llamarlo así, a la gramática española. Sirve para que un lector de este hilo interprete correctamente las frases que puede leer en él. Por ejemplo, tú leías "0 es un signo de ARP" y te sorprendías porque yo decía que eso es verdadero y pensabas que antes yo había dicho justo lo contrario, porque no interpretabas correctamente las frases
0 es un signo de ARP.
"0" es un signo de ARP.
Pero ahora ya sabes cómo hay que entender cada una de ellas (por el uso de las comillas que hacemos al hablar en español en este hilo) y no dudarás en afirmar que la primera es verdadera y la segunda falsa. Si es así, entiendes perfectamente el uso de las comillas en la jerga española que usamos en este hilo.
Ahora bien, en todo lo que sigue estás mezclando el lenguaje C con el español. Si escribes en C, tendrás que usar la gramática de C, no la gramática española. ¿Qué sentido tiene comparar cómo se dice algo en español y cómo se dice en C?
Si traduces a C algo dicho en español, como "multiplica todos los números desde el 1 hasta un n dado", la traducción no se parecerá en nada a la frase española. No puedes buscar cómo se dice en C "hasta" o "todos". No habrá ninguna correspondencia superficial entre la forma de expresar la instrucción en español y la forma de expresarla en C. Igualmente, tú estás buscando analogías entre dos cosas que no tienen nada que ver.
Lo cual me hace dar cuenta por qué me enredé en esa discusión.
En contextos diferentes hay que ver cómo se traducen las cosas correctamente.
Ya que hemos convenido que los signos de \(L_{arp}\) significarán 8 entidades del Universo,
voy a elegir a esas entidades como ocho fichas que tienen pintados los octetos en binario que son códigos ASCII o UNICODE de los caracteres cuyo glifo luce como los signos de \(L_{arp}\).
Además, los signos "\(\kappa\)" y "\(\rho\)" los he cambiado por sus versiones latinas "k" y "r", porque son más accesibles en ASCII, y además yo puedo elegir los elementos que yo quiera para mi conjunto. 
No sé dónde dices que has cambiado eso, porque en todo lo que sigue no mencionas ningún nombre de ningún signo. Sólo usas tus propios signos. En tu conjunto no has puesto ni \( r \) ni \( \rho \). Has puesto cadenas de ceros y unos. No le veo sentido a que digas que puedes usar "k" y "r" porque puedes elegir los signos que quieras para tu conjunto y luego definas un conjunto en el que no usas ni "k" ni "r". No es que sea importante en sí mismo, pero parece indicar que tienes alguna confusión de fondo.
He aquí los objetos de mi conjunto de ocho elementos:
\[
\fbox{00110000},\fbox{01010011},\fbox{01110000},\fbox{01100011},
\fbox{01101011},\fbox{01110010},\fbox{01111000},\fbox{00111101}.
\]
Bien. Puedes elegir los que tú quieras.
Podría haber elegido otros objetos, pero quiero mantener el símil con la representación en memoria, porque esa será la implementación real después de todo.
Es cierto que puedes elegir los signos que quieras, y precisamente por eso, pensando en implementar \( \mathcal L_{\rm arp} \) en un ordenador, usar esos nombres que has elegido es lo menos eficiente que podrías haber hecho. Hubiera sido mucho más eficiente que eligieras ocho caracteres que no ocho cadenas de ocho caracteres cada una. Pero eso ya es cuestión de gustos (y de que no te importe la eficiencia al programar).
Por la manera que hemos llevado la discusión, pareciera que no puedo nunca poner explícitamente en forma escrita esos objetos, porque al ser signos,
van entre comillas, puesto que estoy hablando de ellos.
Es como decir que no puedes poner explícitamente en forma escrita ninguna palabra inglesa, porque al no ser palabras españolas, van entre comillas. Eso es cierto si hablas en español. Entonces, con nuestro convenio, tienes que decir que "red" es un adjetivo y que "mountain" es un sustantivo. Pero puedes usar esas palabras sin comillas simplemente escribiendo en inglés. Si escribes en inglés, tendrás que poner entre comillas las palabras españolas que menciones, pero no las inglesas.
Igualmente podrías escribir un libro en el lenguaje \( \mathcal L_{\rm arp} \) que, con los signos que has elegido, sería una sucesión de líneas, cada una de las cuales sólo tendría ceros y unos. En ese caso, si el libro está escrito en \( \mathcal L_{\rm arp} \) (no en español), no tendrías que poner nunca comillas, entre otras cosas porque las comillas no son signos de \( \mathcal L_{\rm arp} \).
En todo caso, si escribieras un libro bilingüe, con las páginas pares en \( \mathcal L_{\rm arp} \) y las impares en español, sólo tendrías que usar comillas en las páginas impares cuando hicieras referencia a algún pasaje de una página impar.
Pero bueno. No sé. No puedo poner una fotografía entre comillas, ni un audio de Beethoven entre comillas.
Porque es algo muy excepcional que hablando en un idioma puedas intercalar en el texto el objeto del que hablas.
Acá solamente estoy ilustrando gráficamente que me estoy refiriendo
a unas supuestas fichas con octetos binarios pintados en el lomo,
y que andan por ahí.
De hecho, lo cierto es que no serán fichas, sino una configuración electrónica de una tarjeta RAM, que en ocho posiciones consecutivas adquiere un voltaje alto o bajo (los famosos bits de un byte).
Ese byte, en su forma electrónica del mundo real, digamos,
serán los signos de \(L_{arp}\).
No es nada práctico tomar como signos cosas que no se pueden escribir en un papel (o en una pantalla de ordenador). Aunque teóricamente es posible, estás rozando el ejemplo que puse de tomar como signo "una representación del Everest a escala 1:1".
Si quieres programar un ordenador para que manipule signos, sería preferible que, dentro de tu libertar para elegir los signos que quieras, elijas unos que estén en el teclado de tu ordenador.
Al mismo tiempo, son unidades de información en el entorno de ejecución de un programa escrito en C o en C++ (a estos efectos, ambos lenguajes tienen especificaciones parecidas).
Pero eso es como usar una calculadora para clavar un clavo en una pared. Puedes usarla (si es lo suficientemente resistente y no te importa que deje de funcionar), pero no está pensada para eso. Cualquier lenguaje de programación está preparado para entender como signos los caracteres que sabe manejar. Si tienes un lenguaje que entiende el código ASCII, ¿por qué no usas como signos caracteres del código ASCII y aprovechas las capacidades del lenguaje de programación que tienes? Lo que haces sólo tendría sentido si estuvieras programando una CPU usando lenguaje máquina, y te vieras obligado a hacer referencias directas a las posiciones de memoria en la RAM o en el disco duro.
Ahora bien, en el entorno de ejecución de un programa
uno no tiene cadenas de caracteres,
sino arrays (posiciones contiguas de memoria) de bytes.
En tanto y en cuenta se tomen como lo que son,
a saber, bytes, o bien se amontonen como arrays de bytes sin significado alguno,
no veo necesidad de que lleven comillas, pues estoy usando las figuras en los rectángulos
para representar a esos objetos por sí mismos (serían su propio significado 
).
Cuando quiera usarles para representar el número tres, ahí si los entrecomillaríamos:
Eso no tiene ningún sentido. Es como si te planteas cómo es en C la tercera persona del singular del pretérito imperfecto de indicativo del verbo "sumar". El lenguaje C te permite sumar, pero no puedes expresar en él conceptos gramaticales como "persona", "número", "pretérito imperfecto", etc., e igualmente no tiene ningún sentido que busques en C un elemento gramatical del español como son las comillas.
En todo caso, eso te debería preocupar si quieres que tu programa en C genere una respuesta para el usuario del tipo: "El número que has introducido es impar". Ahí puedes preocuparte de que C escriba "número" con acento en la u, y cosas parecidas, pero eso para C no son más que cadenas de caracteres que imprime cuando le dices que lo haga, sin entender nada de que las palabras esdrújulas llevan acento.
El siguiente array de bytes
"\(\fbox{01010011}\fbox{01010011}\fbox{01010011}\fbox{00110000}\)"
significará el número natural tres.
Y acá es donde yo veo importante distinguir entre un signo y una cadena de signos de longitud 1.
Puede que tu implementación en un ordenador requiera hacer la distinción, como se requiere en muchos contextos de la matemática formal, pero si simplemente quieres hablar de tus signos, sin preocuparte de cómo los tiene que entender un ordenador, no hay necesidad de establecer la distinción. De hecho, nada te impide programar un ordenador para que tome como signos determinadas cadenas de caracteres de longitud 1, de modo que las cadenas de signos serán cadenas de caracteres de longitud mayor o igual que 1. Y con esa implementación los signos serán cadenas de signos de longitud 1, literalmente.
Y es que si yo me refiero a \(\fbox{01010011}\)
como un objeto que pertenece a un conjunto,
no le veo sentido tener que ponerle comillas.
Pero es que ahí estás introduciendo una distorsión en todo el asunto, porque pretendes que tus signos sean algo que no se puede escribir en un papel, por lo que en el fondo (y no estoy seguro de que con total coherencia), estás usando "\(\fbox{01010011}\)", no como uno de tus signos, sino como un nombre que le das en español a uno de tus signos, el cual no puede ponerse en un papel por la misma razón que no podrías si hubieras tomado como signo un audio de Beethoven.
Y una vez más mi diagnóstico es que tu problema es que tratas de trabajar con una generalidad inmanejable amparándote en la ambigüedad inherente a conceptos básicos como el de "signo". La cuestión no es qué hacer con tus signos que fuerzan todo por su imposibilidad de representarlos en un papel. La cuestión es, ¿y si en vez de tomar esos signos abstractos con los que es tan difícil trabajar y que te generan tantos problemas filosóficos tomas como signos "a", "b", "c", "d", "e", "f", "g", "h", en qué quedan todos tus problemas?
Imagina que, en lugar de darte libertad para que elijas los signos que quieras, yo hubiera empezado el hilo diciendo: tomaremos como signos de \( \mathcal L_{\rm arp} \) los ocho signos siguientes:
"a", "b", "c", "d", "e", "f", "g", "h"
a los cuales nos referiremos con los nombres siguientes, respectivamente:
0, S, p, c, \( \kappa \), \( \rho \), x, =.
Sólo con que hubiera empezado así, te podría decir que todo lo que estás diciendo no viene a cuento, porque los signos de \( \mathcal L_{\rm arp} \) no son los que tú has elegido, sino que son los ocho que he dicho yo.
Si he dicho que los signos pueden ser cualesquiera, es porque no importa si alguien, en lugar de
"a", "b", "c", "d", "e", "f", "g", "h"
prefiere
"x", "y", "ñ", "s", "tt", "8", "?", "+"
pero una cosa es no concretar algo cuya especificación es irrelevante y otra muy distinta que aproveches la ambigüedad de la palabra "signo" que admite muchos ejemplos claramente manejables para meter unos signos tan abstractos que te generan toda clase de dudas filosóficas.
Insisto en que lo más sencillo si te vas a poner a filosofar así, es que modifiques el primer mensaje en el que hablo de ARP y consideres que los signos de ARP son, por definición,
"a", "b", "c", "d", "e", "f", "g", "h"
y así desaparecen todos tus problemas. Lo que ocurre es que en realidad esa restricción es arbitraria e innecesaria, mientras tomes como signos cualquier otro juego alternativo de signos que sean fácilmente manejables, como ocho caracteres cualesquiera de los que un ordenador sabe manejar.
Pero, volviendo a lo que planteas, si entendemos que "\(\fbox{01010011}\)" es realmente el nombre que usas para referirte a un signo abstracto (que para ti es un estado posible de una posición de memoria de un ordenador), entonces, efectivamente, "\(\fbox{01010011}\)" no necesita comillas, porque no es realmente uno de tus signos (porque has tenido la idea peregrina de elegir signos que no caben en un papel), sino que es el nombre en español que le das a uno de tus signos. Si lo entendemos así, habría que decir que \(\fbox{01010011}\) es un signo de \( \mathcal L_{\rm arp} \), el mismo al que también podemos llamar "S", si no me he confundido al mirar tu lista. Así, podríamos decir que
\(\fbox{01010011}\) es un signo de \( \mathcal L_{\rm arp} \), también llamado S.
Sin poner comillas, y con esto no estoy cambiando el criterio que expliqué en los mensajes anteriores, sino que lo estoy siguiendo al pie de la letra. Tú tienes que decidir si "\(\fbox{01010011}\)" tiene sentido hablando en español. Si me dices que tiene sentido, y que es la forma que tienes de nombrar uno de tu signos abstractos, entonces yo te digo que lo que procede es escribir
\(\fbox{01010011}\) es un signo de \( \mathcal L_{\rm arp} \)
sin comillas. Pero entonces también te digo que
"\(\fbox{01010011}\)" no es un signo de \( \mathcal L_{\rm arp} \), sino que es el nombre que le has dado a uno de los signos de \( \mathcal L_{\rm arp} \), un nombre inútil, porque sería más práctico que te refirieras a él como "S", ya que, así, "\(\fbox{01010011}\)" y "S" son sinónimos. Son dos formas de nombrar un signo que no podemos poner entre comillas porque no cabe en un papel, o en una pantalla de ordenador.
Su significado es el de un octeto de ocho bits,
Si te refieres a su significado en español, entonces es como te digo, no tienes que ponerle comillas, porque ya es una palabra española que nombra a un signo que no puedes escribir con comillas porque has tenido la idea peregrina de tomar como signo algo no imprimible. Es teóricamente posible porque nunca necesitaremos imprimir o escribir los signos, pero eso te genera todas las confusiones que te está generando.
y como tal no tiene sentido decir que es una cadena de signos de longitud 1.
¿Por qué no tiene sentido? Eso sí, ¿me hablas de "\(\fbox{01010011}\)" o de \(\fbox{01010011}\)? Porque lo que yo te digo es que \(\fbox{01010011}\) es una cadena de signos de longitud 1, mientras que "\(\fbox{01010011}\)" no lo es, sino que es un nombre peregrino que has dado en español a uno de tus signos no imprimibles. Es como si hubieras tomado como signo un carácter ASCII no imprimible, que los hay, como bien sabrás.
Sólo cuando tengo la intención de usarlo como signo es que puedo
decir que tiene el atributo de longitud igual a 1.
Mala cosa sería que un atributo de algo dependiera de nuestras intenciones. Muy poco objetivo sería ese atributo. Una vez has decidido que un signo de tu lenguaje sea una cosa no imprimible a la que podemos llamar "\(\fbox{01010011}\)" o "S", podemos decir que
\(\fbox{01010011}\) (o, lo que es lo mismo, S) es una cadena de signos de longitud 1, pero eso no contradice que "\(\fbox{01010011}\)" no sea una cadena de signos de longitud 1. Se trata de un nombre que puedes identificar con una cadena de signos de otro alfabeto (cuyos signos son "0" y "1") y entonces es una cadena de signos de longitud 8. En otras palabras, estás nombrando un signo (o una cadena de signos de longitud 1) de \( \mathcal L_{\rm arp} \)) con una cadena de signos de longitud 8 de otro alfabeto.
El símil aquí sería decidir mirar un trozo de memoria RAM como una sucesión de bytes,
en cuyo caso se podría hablar de la longitud del array de bytes en cuestión.
No sé si no me pierdo ya aquí, pero tal vez estás diciendo lo mismo que acabo de decir, que si tomas como uno de tus signos un array de bytes, entonces una cosa es que ese array de bytes es una cadena de signos de \( \mathcal L_{\rm arp} \) de longitud 1, lo cual no tiene nada que ver con que el signo tenga otra longitud como array de bytes.
Es como si tomo como signo S esto: "suc". Entonces "suc" es un signo de \( \mathcal L_{\rm arp} \), luego es una cadena de signos de longitud 1, y eso no está reñido con que el signo conste de tres letras latinas.
Puede ser un poco extraño, luego,
decir que el significado de una sucesión de bytes es una entidad mental,
como el caso del número natural tres.
No veo qué tiene de extraño.
La computadora no tiene manera de hacer esa asociación
(aunque Elon Musk anda cerca de lograrlo). 
Así que ese significado habría que dárselo, todavía, sólo desde la mente.
Es que ésa es la gracia del asunto, que una computadora pueda manejar el lenguaje de \( \mathcal L_{\rm arp} \) sin necesidad de que sepa nada sobre el significado de las cadenas de signos que maneja.
En cualquier caso, al menos creo haber logrado
dar con lo que sería la manera correcta de una representación
en computadora de los signos del lenguaje formal, como se explican en el hilo.
No. Lo que has hecho ha sido desvirtuar toda la teoría tomando como signos unos objetos que están en el límite de lo que es aceptable tomar como signos. Lo razonable sería que tomaras como signos ocho caracteres Unicode, si te preocupa tanto la precisión. Si no te preocupara tanto, te diría que podrías tomar ocho garabatos cualesquiera que pudieras hacer en un papel con la condición de que al leerlos tuvieras claro cuál es cual.
No obstante, quiero notar acá que, cuando agrego comillas para hablar
del array de bytes per se, y sus propiedades como array (que serían equivalentes a las propiedades de una sucesión de signos),
no son comillas que pondría en la memoria RAM.
Es decir, no usaría bytes extra para representar comillas ahí.
Son comillas mentales, por decirlo así, o que podría poner acá en el texto escrito,
puesto que son comillas del lenguaje español,
y no algo que tenga sentido en la memoria RAM, ni tampoco en la sintaxis del lenguaje de programación.
Es que plantear que el ordenador use comillas es como plantear que el ordenador tiene que conjugar verbos y establecer concordancias de género y número entre sustantivos y adjetivos. No sé en qué están pensando para pretender que un ordenador maneje conceptos de la gramática española. Eso sólo tendría sentido si estuvieras programando a un ordenador para que lea textos en español y los entienda, pero eso está muy lejos de lo que estamos considerando aquí. Sólo estamos hablando de que un ordenador maneje correctamente el lenguaje \( \mathcal L_{\rm arp} \), no que sea capaz de leer un hilo en español en el que se habla de dicho lenguaje. Sólo para esto haría falta instruir al ordenador sobre el uso de las comillas.
Ahora bien.
En el código fuente de un programa en C o C++,
uno puede especificar arrays de bytes de varias maneras,
pero la manera más sencilla es por medio de una construcción sintáctica
denominada cadena literal.
Aquí, llamativamente, se usan comillas dobles para denotar una cadena literal.
Estamos, pues, ahora en terreno sintáctico, vale decir,
en lo que se denomina entorno de traducción,
que es donde se especifican las reglas del lenguaje C o C++.
No sé si me pierdo, pero me parece que estás tratando de traducir a C la gramática española. Si yo te describo un algoritmo, como "Dados dos números naturales, calcula su máximo común divisor", no pretenderás implementar en C el uso de las palabras "Dados", "dos", "números", etc., ni en qué queda la coma que he puesto a mitad de la frase, etc. Sencillamente, el algoritmo que hagas hará lo que se le pide, pero no verás en el rastro de que "Dados" es un participio masculino plural del verbo "dar" ni nada de todo esto, igual que no puedes esperar ver unas comillas en un programa en C. En un programa en C usarás las comillas como requiere la gramática de C y para lo que ésta lo requiere. No puedes esperar ver ahí ningún reflejo de los convenios gramaticales apropiados para un hilo que habla de \( \mathcal L_{\rm arp} \).
Una cadena literal es una construcción sintáctica
por la cual una sucesión finita de caracteres se encierran entre comillas dobles.
Así, "hola" es una cadena literal, y también lo es "otro-ejemplo".
Si hablo de la cadena literal "hola", estoy refiriéndome a un objeto
del lado sintáctico del lenguaje de programación que esté usando.
Lo que me llama la atención es que puedo hablar de ella,
al igual que Carlos dice que uno puede hablar de una palabra entrecomillada,
diciendo por ejemplo que "hola" tiene cuatro letras,
mientras en C uno diría que la cadena literal "hola" tiene 4 caracteres.
Y al igual que "Sp" (en el idioma de Ivorra)
no es la cadena de signos formada por una ese y una pe,
la cadena literal "Sp" en C ó C++
no es lo mismo que el array que contiene los bytes \(\fbox{01010011},\fbox{01110000}\).
Si bien la analogía parece coincidir,
creo que es pura casualidad hasta acá,
y los contextos son diferentes.
En cuanto a lo que el lenguaje C se refiere,
lo que sucede es bien concreto:
el compilador de C, al ejecutarse,
realiza una traducción del objeto sintáctico "Sp", digamos,
y lo convierte en el array de bytes: \(\fbox{01010011},\fbox{01110000}\).
Así, una cadena literal (que siempre va entrecomillada)
se traduce en un array de bytes.
Y creo yo que entre ambos contextos, el idioma español y el lenguaje C,
puede mantenerse hasta aquí un paralelismo que funciona bien.
____________________________________________
Sin embargo, en la exposición de Carlos sucede algo diferente,
y es que a las cadenas de signos se le dan nombres,
que serían palabras nuevas para nombrar entidades que serán,
después de todo, sucesiones finitas de signos,
y que en el contexto de programación serían arrays de bytes.
En C ó C++ también puede hacerse algo así,
mediante variables de tipo array de caracteres,
o de tipo puntero a caracteres.
No creo que nada de lo que dices aquí tenga ninguna relevancia. Estás comparando la gramática de C con la gramática española. Las diferencias serán muchas más que los parecidos, pero eso es anecdótico. Parece como si quisieras programar a un ordenador para que lea el hilo y lo entienda, cuando lo único relevante aquí es que es posible programar un ordenador para que maneje el lenguaje \( \mathcal L_{\rm arp} \) sin necesidad de entender nada, no ya del propio lenguaje —que también— sino mucho menos de la forma en que hablamos de él en español.
Así como Carlos usa la palabra SS0 para denotar la misma sucesión de signos que denotaría con la cadena "SS0",
Esto hace aguas por todas partes. Para empezar yo no uso SS0 (y nunca lo usaré) para denotar ninguna sucesión de signos. SS0 ES una sucesión de signos que puede usarse en \( \mathcal L_{\rm arp} \) para denotar el número natural dos.
En todo caso, puedes decir que uso la palabra "SS0" para denotar (obviamente) la misma sucesión de signos que denotaría con "SS0", aunque yo no llamaría cadena a "SS0", porque "SS0" no es una cadena de signos de \( \mathcal L_{\rm arp} \). Vale que podríamos decir que es una cadena de signos del alfabeto latino, pero mejor reservar la palabra "cadena" para las cadenas de signos de \( \mathcal L_{\rm arp} \).
análogamente nosotros usaríamos una variable SS0 para denotar el mismo array de bytes que denotaríamos con la cadena literal "SS0":
Pero es que no tiene ningún sentido que trates de establecer analogías entre la gramática española y la gramática de un lenguaje de programación. Cualquier parecido será pura coincidencia superficial y sin valor.
const char SS0[] = "SS0";
Acá me siento algo confundido,
si es que quiero mantener la analogía entre lo que explica Carlos
y que hace el lenguaje C.
¿Y por qué no buscas una analogía entre lo que hace el lenguaje C y la filosofía confuciana? Es que no tiene por qué haber ninguna analogía entre las gramáticas de dos lenguajes, y mucho menos si uno es un lenguaje natural y otro un lenguaje de programación.
Para empezar, en C no es exactamente lo mismo un identificador, como SS0,
que una cadena literal como "SS0".
De todas maneras, al traducir al entorno de ejecución,
ambos objetos sintácticos serán traducidos
al array de bytes \(\fbox{01010011} \fbox{01010011} \fbox{00110000}\).
Sin embargo Carlos diría que SS0 (en español) "es" el array de bytes \(\fbox{01010011} \fbox{01010011} \fbox{00110000}\)
mientras que "SS0" es una palabra de tres letras que, de paso,
se usará para representar un array de tres bytes, digamos.
En el lenguaje C, tanto SS0 como "SS0" son objetos sintácticos,
y que lleven comillas o no sólo indica que son objetos de clasificación sintáctica diferente
(un identificador y una cadena literal, respectivamente),
que luego tendrán la virtud de traducirse a la misma cosa.
Pero, por ejemplo, en C sería falso argumentar que el significado de "SS0" es SS0.
En cambio, el significado (la semántica en tiempo de ejecución del programa en C),
tanto de "SS0" como de SS0, es el mismo:
\(\fbox{01010011} \fbox{01010011} \fbox{00110000}\).
______________________
Para peor, el lenguaje C contiene en su especificación
un metalenguaje, que se llama preprocesador de C,
el cual tiene sus propias reglas,
y se usa para traducir un cierto código fuente a lenguaje C puro.
En este preprocesador uno puede estipular clásulas de sustitución, en forma de macros,
como las siguientes:
#define SSSS0 "SSSS0"
En este caso, el identificador SSSS0 se estaría usando,
en la etapa del procesador,
como una manera de expresar, como sinónimo, a la cadena literal "SSSS0".
Se podría decir que la semántica del indentificador SSSS0 es el objeto sintáctico "SSSS0".
Aquí estamos en una situación opuesta a la que se tiene en el hilo principal,
porque allí SSSS0 (en español) no es capaz de sustituir a la cadena entrecomillada "SSSS0",
ya que en realidad "es lo mismo que" (hablando español)
\(\fbox{01010011} \fbox{01010011} \fbox{01010011} \fbox{01010011}\fbox{00110000}\).
Todo esto se resume en la obviedad de que la gramática del lenguaje C no es la gramática española. También podrías añadir a tu comparación que en español hay tres conjugaciones verbales y en C no hay ninguna, etc., etc.
Lo que me chirría o preocupa en todo esto son aquellas ocasiones
en que Carlos afirma que todo esto se puede llevar a cabo en un ordenador.
En rigor, no es cierto.
Y me parece que hay que establecer claramente cómo se traduce de un contexto al otro.
Depende de a qué te refieres con "todo esto". Yo afirmo que es posible programar un ordenador para que opere con el lenguaje \( \mathcal L_{\rm arp} \), no para que entienda textos en español sobre el lenguaje de \( \mathcal L_{\rm arp} \).
De todos modos, sería más claro que no hicieras enmiendas a la totalidad de lo que diga, sino que concretaras cualquier cosa que yo diga y que te parezca dudosa. En este caso, ¿cuándo he dicho yo que algo es programable y tú lo cuestiones? Dime qué cosa digo yo que es programable y te escribiré un programa que lo demuestre.
Por ejemplo, hasta ahora no has aludido a nada del hilo que sea posterior a la definición de los signos de \( \mathcal L_{\rm arp} \) y de las cadenas de signos. Te pongo a continuación un programa en Python que hace todo lo que tiene sentido hacer con estos únicos conceptos: le das una entrada y el programa te dice si es o no una cadena de signos de \( \mathcal L_{\rm arp} \) y, en caso afirmativo, cuál es su nombre y su longitud.
Voy a tomar como signos de \( \mathcal L_{\rm arp} \) los que tú has elegido (aunque eso supone una complicación innecesaria en la antítesis de la eficiencia, pues sería mucho más práctico tomar como signos ocho caracteres imprimibles cualesquiera). Eso sí, yo estoy entendiendo que "\(\fbox{01010011}\)" es literalmente un signo de \( \mathcal L_{\rm arp} \) y no el nombre de un signo, que es lo que en el fondo estabas considerando tú. (En realidad omitiré el recuadro, porque eso no se puede introducir con el teclado.)
El programa es éste:
nombre = {"00110000" : "0", "01010011" : "S", "01110000" : "p",
"01100011": "c", "01101011" : "\u03ba", "01110010" : "\u03c1",
"01111000" : "x", "00111101" : "="}
signos = tuple(nombre.keys())
entrada = input("Escribe una cadena de signos: ")
def primersigno(c):
"""Separa el primer signo de la cadena c del resto de la cadena."""
lectura = ""
for s in signos:
if c.startswith(s):
lectura = s
if lectura != "":
resto = c[len(lectura):]
else:
resto = c
return (lectura, resto)
def lee(c):
"""Calcula el nombre de la cadena c hasta donde tiene sentido y
devuelve un resto con lo que no ha podido interpretar."""
pendiente = True
resto = c
lectura = ""
while pendiente:
p = primersigno(resto)
if p[0] == "":
pendiente = False
else:
lectura = lectura + nombre[p[0]]
resto = p[1]
if resto == "":
pendiente = False
return (lectura, resto)
l = lee(entrada)
if entrada != "":
print("""Has escrito "{}".""".format(entrada))
if l[1] == "":
print("""Se trata de la cadena de signos {}, de longitud {}."""\
.format(l[0],len(l[0])))
elif l[0] != "":
print("""Eso no es una cadena de signos de ARP.
Empieza por {}, pero tiene un resto "{}" sin sentido.""".format(l[0], l[1]))
else: print("""Eso no es una cadena de signos de ARP.""")
Empieza con un diccionario que asigna a cada uno de tus signos su nombre en español (donde introduzco \( \kappa, \rho \) a través de sus nombres en Unicode. Si prefieres usar unos signos distintos, sólo tienes que modificar ese diccionario y el resto del programa vale igual, porque los signos concretos que elijas son irrelevantes para todo. He aquí un par de ejemplos de su funcionamiento:
=================== RESTART: /Users/ivorra/Desktop/Arg.py ===================
Escribe una cadena de signos: 011010110101001101100011010100110101001100110000
Has escrito "011010110101001101100011010100110101001100110000".
Se trata de la cadena de signos κScSS0, de longitud 6.
>>>
=================== RESTART: /Users/ivorra/Desktop/Arg.py ===================
Escribe una cadena de signos: 01110010011100101111101100011
Has escrito "01110010011100101111101100011".
Eso no es una cadena de signos de ARP.
Empieza por ρρ, pero tiene un resto "1111101100011" sin sentido.
>>>
Como ves, la salida del programa está en español (lo cual no significa que el programa entienda el español, sino que son respuestas enlatadas con sintaxis prefijada) y respeta perfectamente el criterio sobre el uso de comillas.
Si yo digo que es posible programar a un ordenador para que determine si una entrada dada es o no una cadena de signos y que, en su caso, escriba su nombre y calcule su longitud, me refiero ni más ni menos que a lo que acabo de hacer, y ya está hecho, y el uso de las comillas en la respuesta en español enlatado no han sido ningún problema.
Lo más que podría añadir (sin salir de la porción del hilo de la que me estás hablando) es una función que yuxtaponga dos cadenas dadas, pero eso tampoco ofrece ninguna dificultad.
¿En qué quedan todas las dificultades filosóficas que has discutido en tu mensaje?
Cuando avances un poco más en el hilo, podremos programar también un algoritmo para que el ordenador decida si una cadena dada es o no un numeral, y en tal caso que escriba su nombre, y luego si es o no un funtor y de qué rango, etc. Todo eso lo puede hacer sin dificultad un ordenador y no hay ningún problema en que dé su respuesta en español enlatado poniendo las comillas que toca igual que pondrá acentos en las palabras que lo requieran.
Eso sí, el programa está escrito en Pyhon y sigue la sintaxis de Python. No trates de buscar en las instrucciones del programa ningún rastro de la gramática española (más allá de las cadenas con las respuestas enlatadas), porque las comillas se usan como lo requiere Python y no como en español, por lo que no verás los usos de las comillas en español igual que no verás conjugaciones ni verbos ni nada parecido.
Por supuesto, es un programa en Python y es correcto porque hace lo que se espera que haga. Y eso es totalmente independiente de dónde y cómo guarda el ordenador la cadena de signos que se le introduce. Estaría bien aunque no existiera en el mundo ningún ordenador implementado para ejecutar un programa Pyhton. Si dentro de mil años la humanidad desconoce por completo cómo funcionaban los ordenadores y cómo era posible que un ordenador leyera un programa en Python y lo ejecutara, cualquiera que leyera un libro que explique la sintaxis de Python (sin decir nada de qué hace un ordenador para ejecutar un programa) podría mirar mi programa y reconocer que sirve para determinar si una cadena dada es o no una cadena de signos de \( \mathcal L_{\rm arp} \) y en caso afirmativo calcule su nombre, y todo ello aunque dicha persona del futuro fuera incapaz de construir un ordenador que ejecute el programa.
Por eso, cualquier consideración sobre qué hace un ordenador para almacenar los signos y las cadenas de signos, es totalmente irrelevante para lo que nos ocupa. Cuando hablo de que un ordenador puede hacer tal o cual cosa, me refiero únicamente a que es posible diseñar un programa en un lenguaje de programación que haga tal cosa, con independencia de que existan o no ordenadores que lo ejecuten. Lo que importa es que la existencia del algoritmo garantiza que el concepto está definido objetivamente.
