Julia: idea loca: cambiar la palabra clave `type`

Hacer que la palabra type pueda usar en otros contextos sería genial.

Me gusta mutable por coherencia.

Si se hace esto, debe hacerse lo antes posible para que pueda incluirse en 0.6

Si esto va a suceder, use lo que todos reconocen antes de pensar: struct

También creo que type es un poco incómodo. Cuando se lo explico a otras personas, suelo decir "como una estructura", así que +1 para eso.

Si esto va a suceder, use lo que todos reconocen antes de pensar: struct

Pensé que immutable era como una estructura.

+1 por mutable

immutable tiene el diseño de memoria de una estructura C
type tiene la mutabilidad de una estructura C

Por lo tanto, la estructura está relacionada con ambos. Creo que mutable lugar de struct es mejor para aclarar esto.

Cualquier variable es mutable. Asignar esa etiqueta a un nombre universalmente reconocido (un struct ) parece casi claro para mí.

Para alguien que viene de Fortran, la palabra clave type ya es natural.
Para alguien que viene de C, la palabra clave struct sería natural.
Para alguien que usa immutable mucho, la palabra clave opuesta mutable sería natural.

Así que quizás deberíamos dejarlo como está.

struct{mutable}
struct{immutable}

o

record{mutable}
record{immutable}

si se desea una forma más descriptiva.

Si usamos struct entonces la sintaxis para inmutables puede ser immutable struct (con la parte struct opcional al menos inicialmente).

Sospecho que los programadores de Fortran están familiarizados con el término "estructura".

+1 por mutable debido a la coherencia. Si se eligiera struct , ¿la coherencia no impondría cambiar inmutable a algo como const struct ? ;)

Creo que struct y immutable struct serían bastante buenos en realidad; struct es un término muy familiar y solo necesitaríamos agregar una palabra clave nueva. Permitir mutable struct podría tener sentido, aunque no es estrictamente necesario.

Debo aclarar que creo que struct ser un sustantivo es una ventaja. Sería mejor no usar solo adjetivos para nombrar estas cosas.

Tener que agregar struct a immutable struct agrega ruido de línea innecesario, más aún habiendo estado acostumbrado a no tener que escribir esto.

Otoh, creo que Fortran tiene una palabra clave type que hace algo muy similar a lo que hace el nuestro. Sin embargo, no soy reacio a cambiar esto.

@KristofferC arriba tiene razón: también me encuentro diciendo "estructura" al explicar qué es esto. Incluso en discusiones internas type ha sido un problema; alguien dirá "supongamos que x es un tipo", y no está claro si significa "cosa declarada con la palabra clave type " o "tipo" en otro sentido.

Si estos nombres están realmente sobre la mesa ( s/type/new name/ parece un poco desagradable), sugiero que aprovechemos al máximo esta oportunidad para hacer que la declaración predeterminada sea inmutable.
Entonces struct reemplazaría immutable , y mutable [struct] reemplazaría type.

Solo como un pensamiento, otro posible término para mutable también podría ser Ref .

Otro nombre posible sería composite , ya que un término genérico de CS para esto es un tipo compuesto . Pero todavía prefiero mutable Foo y immutable Foo a mutable struct Foo y immutable struct Foo - el struct (o composite , o class , o lo que sea) parece superfluo.

: +1: a sustantivo (s)

Siempre me gustó type más que struct en Julia (aunque mi experiencia es _C_), porque los tipos de datos de Julia son mucho más poderosos y sutiles y creo que "struct" podría ser un poco simplista por la idea. También siento que, dado que este es un nuevo lenguaje, no deberíamos estar sujetos a las convenciones a las que están acostumbrados los programadores experimentados; también debería considerar "cuál sería la mejor palabra para explicar esto a una persona cuya primera lengua es Julia".

También me encuentro diciendo "estructura" al explicar qué es esto

Imagínese presentar a un recién llegado a struct T luego decirle T::DataType y puede enviar usando ::Type{T} , todo mientras explica el "poderoso sistema de tipos" de Julia. Creo que esto es solo patear el cubo más adelante.

ser un sustantivo es una ventaja

: +1: a sustantivo (s)

Probablemente valga la pena señalar que los adjetivos de familias en lengua latina como "mutable" también pueden ser sustantivos gramaticalmente en su propio idioma. Por eso cuando preguntamos "cuál es la forma nominal de mutable", nos encogemos de hombros. Pero siempre decimos "una variable" y en lenguaje de Julia diría "introduzcamos un inmutable para esto". Desafortunadamente, al principio se siente incómodo debido a las raíces germánicas de la gramática inglesa, pero esto sucede muy a menudo en inglés (porque también nos basamos en francés y latín), pero te acostumbras con el tiempo.

Finalmente, dado que el tema es "idea loca", estas palabras clave construyen más o menos un nuevo DataType entonces, ¿podríamos eliminar las palabras clave por completo y simplemente usar un constructor?

# Similar-ish to current
MyType = DataType(
    a::Int,
    b::Float64
)

# A DataFrame-like constructor
MyType = DataType(a = Int, b = Float64)

Supongo que estos tendrían que ser analizados especialmente (estáticamente) como ccall y solo se pueden llamar en el nivel superior por ahora. (Además, no estoy seguro de si necesitaríamos Mutable <: DataType y Immutable <: DataType y BitsType <: DataType para cubrir todas las posibilidades, y probablemente const para el enlace).

Pensé que inmutable era como una estructura.

inmutable tiene el diseño de memoria de una estructura C
tipo tiene la mutabilidad de una estructura C

Bien ... creo que estaba pensando en Swift, donde:

Esta es la mayor diferencia entre estructuras y clases. Se copian las estructuras y se hace referencia a las clases. ... Así, se pasarán como valores y no como referencia en el caso de objetos grandes.

que suena como immutable vs type , y es solo la referencia la que permite la mutabilidad en el contexto de la semántica de los enlaces de Julia.

DataType incluye todos los tipos nominales: abstract , bitstypes, estructuras inmutables y mutables. Por lo tanto, no agrega mucha claridad reemplazar type con DataType . También saco una conclusión diferente del escenario del "recién llegado": ::Type y ::DataType seleccionan superconjuntos de las cosas definidas por type T , por lo que no es una locura que tengan nombres diferentes . " struct es un tipo de Type " tiene más sentido que " type es un tipo de Type ".

Estoy de acuerdo en que los adjetivos pueden servir en la práctica como sustantivos. Se puede decir, por ejemplo, "esto es inmutable". Creo que son insuficientemente descriptivos. En lugar de decirle qué es la cosa, simplemente le dice que sea lo que sea, puede / no puede mutarlo.

Me gustan structure y mutable structure por tipos. tal vez a = 1 y mutable a = 1 para la asignación de variables. Salir de la idea de querer consistencia, sin abreviaturas e inmutabilidad por defecto.

Editar: tal vez constant lugar de const en el caso de mutabilidad por defecto

O una versión que implica tener menos palabras clave sería struct frente a const struct . Hacer que todas las variables sean constantes de forma predeterminada sería demasiado perturbador en este punto, creo.

Creo que son insuficientemente descriptivos. En lugar de decirle qué es, simplemente le dice que sea lo que sea, puede / no puede mutarlo.

Ese es un buen punto, pero consideraría que el comportamiento de referencia frente al comportamiento de "valor" es mucho más importante e interesante de describir que "¿es una estructura o un tipo de bits?" (principalmente porque bitstype no aparece con mucha frecuencia; cada tipo de Julia que he creado es una estructura). La inmutabilidad es solo una consecuencia de la semántica vinculante y el paso por valor.

Para obviar completamente la necesidad de struct vs bitstype también podríamos incluir esta idea de @quinnj que fue

immutable 32 Int32 <: Integer

o podría tener campos sin adornar como cantidad de bits

immutable Int32 <: Integer
   32
end

que (en general, cuando se mezcla con campos con nombre) también podría ser útil para insertar relleno cuando sea necesario.

Entonces es solo una elección entre un tipo de valor (lo que actualmente es inmutable) frente a un tipo de referencia (lo que actualmente es mutable, pero potencialmente con campos const en el futuro, que es otra razón para no llamarlo mutable ) y se necesitan nombres apropiados para distinguirlos. Y finalmente, usar struct para el tipo de referencia de valor confundirá a los programadores de Swift ...

Es cierto que bitstype ha desaparecido desde que se introdujo immutable . Pero hay más cosas para distinguir que la estructura y los bits: hay tipos abstractos, tuplas (también inmutables) y probablemente registros inmutables en el futuro.

Originalmente elegimos immutable ya que pensamos que sería la característica distintiva más visible: a diferencia de otros objetos, no se pueden modificar. De hecho, _no_ siempre se pasan por valor; inmutabilidad significa que no se puede notar la diferencia. Algunos immutable s están insertados en matrices y otros objetos, y otros no. La inmutabilidad significa que la diferencia no causa problemas para el código simple de julia; solo se convierte en un problema cuando el diseño de la memoria realmente importa, por ejemplo, para la interoperabilidad de C.

De hecho, _no_ siempre se pasan por valor

¡Buen punto! Sin embargo, hay planes para cambiar eso, ¿verdad?

Supongo que estoy diciendo que necesitará un conjunto de palabras clave a prueba de futuro que reflejen algunos conceptos a prueba de futuro, ya que nos estamos acercando a 1.0. Cuando los inmutables están en línea, parece que podría ser un momento razonable para cambiarles el nombre a algo que sea útil con respecto a la semántica resultante (y si esa semántica ayuda con FFI, eso es aún mejor).

No creo que la gente confunda nuevas palabras clave de definición de tipos concretos con abstract , Tuple sy "records" (que, si te refieres a la tupla propuesta con nombres de campo, creo También escuché que se hace referencia a ellos como "estructuras" anteriormente ...).

El propósito real de la noción de "pasar por valor" es responder a la pregunta de qué sucede cuando f(x) modifica (en cierto sentido) x : ¿modifica el mismo x la persona que llama pasó, o la modificación es solo local? Julia nunca ha tenido, y nunca tendrá (espero), tipos, argumentos o funciones que difieran con respecto a este comportamiento. Todo es "pasar por compartir". Para nosotros, el paso por valor solo existe en el nivel ABI, pero esa discusión solo pertenece a la sección FFI del manual. No estoy seguro de que alguna vez tengamos un tipo de tipo que siempre se pasa por valor o siempre en línea, ya que puede funcionar peor para objetos grandes.

De todos modos, creo que immutable y mutable son opciones viables para las palabras clave.

Es cierto que el tipo de bits prácticamente ha desaparecido desde que se introdujo inmutable

Si bien las personas no suelen tener la necesidad de crear nuevos tipos de bits, la diferencia entre los tipos de bits existentes y los inmutables comunes es muy significativa en el nivel primitivo, ya que el ABI para estos son bastante distintos. Simplemente sucede que la mayoría de las veces los usuarios quieren la estructura inmutable, no el tipo de bits, al definir un nuevo tipo de datos concreto.

FWIW, dado que no ha habido mucho apoyo para no cambiar las cosas, creo que type y immutable están bien tal como están.

(La sintaxis do me molesta, aunque ... ;-)

Todo es "pasar por compartir".

Puedo respetar eso, y gracias por la discusión.

Todo es "pasar por compartir".

En esa nota, solo una observación: si tuviéramos const palabras clave en declaraciones de tipo, immutable vuelve completamente innecesario:

type Complex{T}
    const re::T
    const im::T
end

(el compilador podría determinar que este tipo es inmutable automáticamente, y los usuarios pueden llegar a comprender que los tipos const nos permiten compilar en un código más rápido). Entonces type o struct tienen sentido. setfield! se puede desactivar en los campos const en el caso mixto.

¿Qué pasa con type y const type ? - La palabra clave type suena más elegante para mí que struct y con struct asocio un diseño de memoria técnica y no un objeto ~ que tiene, por ejemplo, constructores internos. Como el tipo compuesto es '... con mucho el tipo definido por el usuario más utilizado en Julia ...', tal vez no sea tan malo si 'el tipo es un tipo de tipo'? En la comunicación, el uso de 'tipo compuesto' debería aclarar, al igual que yo diría 'tipo abstracto'. Con respecto al ruido de línea, 'tipo constante' no es peor que 'inmutable'.

No estoy seguro de la (leve) diferencia en el significado de const con variables vs. tipos. - En todo caso tipo e inmutable siempre me dio un pequeño contratiempo mental. ¡Es bueno ver este problema aquí!

El principal problema con el uso de struct sería que las personas naturalmente podrían hacer suposiciones a las que están acostumbradas de C / C ++ que no son necesariamente ciertas en Julia, por ejemplo, un tipo compuesto mutable no se almacena por valor en una matriz inmutable es.

¿Qué paradigmas representan immutable más elegancia que type ? Por ejemplo, "hacer la transición" atómica del estado de múltiples campos simultáneamente sin requerir primitivas de sincronización al instanciar un nuevo inmutable del original con los campos deseados actualizados.

¿Por qué debería separarse el tipo en dos categorías distintas en el punto de su definición en lugar de en el punto de su envío / uso (más como const en C ++)? Usando solo type / struct / composite para definir tipos compuestos e introduciendo una construcción Immutable{T} para promover mutable a inmutable, podríamos tener:

type CompositeType end
f(x::Immutable{CompositeType}) = x
a = f(CompositeType())
b = f(a)

Además, ¿podría considerarse aquí un cambio a abstract y bitstype ? AFAICT el uso de "abstracto" es como un adjetivo, no como un sustantivo. Debe haber al menos una coherencia lingüística entre las palabras clave de tipo: todos los sustantivos, todos los adjetivos, etc. bitstype podría expresarse mejor como bits o primitive .

Por favor, no convierta esto en un hilo abierto para discutir cambios en la ortografía (¡o semántica!) De las palabras clave de Julia. En este punto, el barco ha navegado con el _ comportamiento_ básico de type y immutable . La única pregunta que surge aquí es si podemos tener una ortografía de type y immutable que refleje mejor su similitud.

Sigo apoyando mutable vs immutable , o simplemente lo dejo como está, como las dos opciones más razonables en este momento. Cualquier otra cosa sería inútilmente disruptiva.

@andyferris Me gusta mucho esa idea; alguna combinación de struct y const sería buena. Si vamos por ese camino, también me gustaría poder decir const struct o const type , (1) para evitar tener que escribir const en cada campo, (2 ) para que no tengamos que agregar la nueva característica de inmutabilidad por campo de inmediato. Si alguna vez queremos agregar esa característica, sería bueno tener un vocabulario consistente disponible para ello.

En la comunicación, el uso de 'tipo compuesto' debe aclarar

Una de nuestras técnicas favoritas para nombrar ha sido explicar una cosa a alguien en una oración, luego seleccionar la palabra o dos que parezcan estar haciendo más trabajo. Entonces, para mí, esto sería un voto por composite .

¿Por qué debería separarse el tipo en dos categorías distintas en el punto de su definición en lugar de en el punto de su envío / uso (más como const en C ++)?

Eso es fácil: ofrecer garantías globales. En C ++, un objeto "const" aún puede cambiar debajo de usted si alguien tiene una referencia no constante a él.

Además, ¿podría considerarse aquí un cambio a abstract y bitstype?

Hacer una proposición. En cuanto a bitstype , la palabra clave se usa muy raramente, por lo que no querría robar una pequeña palabra útil como bits por ella.

immutable -> const type también me parece bien. Combinado con type -> composite o struct , si realmente queremos liberar type .

No estoy muy contento con toda la pérdida de código que esto causará, particularmente porque no puede ser compatible con @compat , sin embargo. Si debemos hacer esto, creo que la ruta de actualización debería ser algo como (1) introducir nuevos sinónimos de palabras clave en 0.6 pero _no_ desaprobar los antiguos (debido a la falta de @compat ), luego (2) desaprobar los antiguos en 0,7.

Por bitstype , ¿qué tal llamar a esto un tipo primitive ? El nombre actual es un poco molesto debido a su similitud con an isbits composite type

Me gusta la forma en que Julia ha evitado a menudo algunas de las abreviaturas estilo "def / func / elif" de algunos otros lenguajes. (Dn w abreviaturas, kthx.) Entonces mutable gana sobre struct para mí.

FWIW, OCaml usa type para registros y variantes (estructuras y uniones) y alias. ML estándar usa datatype , creo.

La simetría es buena, pero encuentro mutable insuficientemente descriptivo; immutable también, para el caso (me gusta la idea de const type ).

Como señala Steve, esto provocará una rotación de código bastante mala en toda la comunidad. Y el beneficio es dudoso.

Definitivamente veo el caso de const type ; sería la palabra clave net -1 y aclararía la relación entre tipo e inmutable. Sin embargo, sería muy bueno poder usar type de otras formas. Sin ese beneficio, es mucho más difícil justificar un cambio. Sin embargo, actualizar el código para esto debería ser muy fácil; la sintaxis de type es tal que básicamente no se puede usar en ningún otro contexto.

+1 por composite / const composite .

Siento que primitive vs composite es un gran diferenciador, con const palabras clave agregadas según sea necesario.

¿Necesitamos const primitive para distinguir de algunos bits que pueden cambiar (y por coherencia)? Tan simétricamente tendríamos

primitive        # something new... 
const primitive  # bitstype
composite        # type
const composite  # immutable

El problema de ser un tipo primitivo mutable tendría que implementarse ... (por supuesto, esto podría ser en una fecha posterior, pero querríamos bitstype -> const primitive _ahora_ si eso fuera para convertirse en una cosa. Siendo más simple, podría ser un buen objetivo de "práctica" para llevar mutables a la pila, pero no soy un experto en eso).

De manera similar, la idea de agregar const a los campos individuales de un compuesto se puede implementar fácilmente en una fecha posterior, y aún mejor, es un cambio que no se rompe.

Si vamos por ese camino, también me gustaría poder decir const struct o const type, (1) para evitar tener que escribir const en cada campo, (2) para que no tengamos que agregar la nueva característica de inmutabilidad por campo de inmediato. Si alguna vez queremos agregar esa característica, sería bueno tener un vocabulario consistente disponible para ello.

Tiene perfecto sentido para mí.

Busqué el tipo de datos composite y encontré que al menos Ada y Visual Basic también incluyen tipos de matriz debajo de él. (De lo contrario, se encontró un poco al azar: Haskell: listas y tuplas (sin embargo, se ha solicitado una definición); Python: listas, tuplas, dictados; Lisp: listas, vector, tablas hash, clases definidas por el usuario, estructura).

Por lo tanto, ahora me pregunto qué tan precisa es la composición para el type bastante estructurado. (Pero no soy un científico informático, me falta el vocabulario / visión amplia).

Mmm, eso podría ser correcto: este tipo particular de tipo siempre parece llamarse estructura, estructura o registro (o clase u objeto), siendo "compuesto" un término más amplio. Hay muchos ejemplos en http://rosettacode.org/wiki/Compound_data_type

Sería bueno recuperar type como identificador y usar un nombre más específico. La rotura de casi todos los paquetes triviales escritos antes de ~ 0.6 sería muy desafortunado, no estoy seguro de cómo sopesar eso.

La idea de reutilizar la palabra clave const es bastante convincente ya que enfatiza la equivalencia de los enlaces de variables const en el ámbito global con los enlaces const de campos dentro de inmutables. Esto parece una buena unificación y una mejor denominación que immutable .

En cuanto a los nombres para reemplazar type , struct parece evitar la ambigüedad bastante bien (con frecuencia encuentro que las frases "un tipo mutable" y "tipo inmutable" suenan demasiado similares).

Lo siguiente se ve bastante bien, supongo:

struct A
    a::Float64
end

const struct B
    b::Float64
end

Sería bueno recuperar el tipo como identificador y usar un nombre más específico.

Me hago eco de este sentimiento.

Si vamos a cambiar los nombres, ¿cómo se manejaría la desaprobación? ¿Seguirán siendo válidos type y immutable en 0.6 y probablemente 1.0 con advertencias? ¿Puede Compat.jl manejar esto de forma transparente? Un poco de literatura en la red (publicaciones en blogs, tutoriales, etc.) mostrará advertencias: molestias menores para un recién llegado.

Aún podríamos reservar type y immutable por más tiempo de lo habitual para facilitar la transición.

Estamos antes de la 1.0: el momento de cambiar esto es ahora o nunca. Tener la palabra clave anterior por más tiempo disponible es ciertamente bueno para garantizar una transición sin problemas. No mezclaría la discusión sobre el nombre real con el dolor que implicará la transición.

Personalmente, estoy a favor de llamarlo struct . Una vez dicho esto

No mezclaría la discusión sobre el nombre real con el dolor que implicará la transición.

Si el cambio es demasiado doloroso, votaría en contra del cambio. Si bien un cambio anterior a 1.0 es justificable, compararlo con cualquier interrupción causada es, en mi opinión, lo correcto.

@stevengj tuvo una buena sugerencia sobre cómo hacer la desaprobación, y parece que @amitmurthy llegó a la misma conclusión (mantenga las palabras clave más tiempo del que normalmente lo haríamos). Si bien todos hemos estado usando este lenguaje por un tiempo, todavía es temprano y no debemos tener miedo de hacer el cambio. Esta también es solo una búsqueda y reemplazo fáciles.

Seguiré adelante y votaré por struct . Creo que este es uno de esos cambios que generará muchos rumores y quejas, pero en realidad no es muy difícil arreglar paquetes / código de usuario ... simplemente hazlo y la gente lo resolverá.

immutable -> const type parece ser el camino de menor resistencia, y en mi opinión definitivamente debería hacerse. Creo que esto explica las cosas mucho mejor.

type -> composite es más preciso que type pero menos preciso que struct , aunque tiene menos jerga que struct (para nuevos programadores). Pasa la prueba de Jeff "escribe una oración para explicárselo a un novato" y recupera la palabra clave type . En el lado negativo, no creo que composite aparezca en otros idiomas, así que ir solo.

type -> struct es más preciso, pero posiblemente structure sería más bonito que una abreviatura (estoy tratando de pensar en una abreviatura tan fea como struct en otra parte del idioma y quedó vacío; supongo que eye() es una tradición bastante repugnante desde la perspectiva del idioma inglés).

bitstype -> primitive tiene sentido si se cambia type .

@tbreloff tiene razón: los desarrolladores principales han demostrado buen gusto en el pasado y, al final, la gente seguirá su ejemplo. ¡Hazlo pronto!

Me pregunto si, dado que immutable debería ser el estándar a menos que necesite mutar explícitamente, si el cambio de nombre debería ser:

• immutable -> struct
• type -> mutable

Entonces, el nombre común / esperado es la mejor práctica, y hay un nombre explícito y claro para solicitar mutabilidad.

Me gusta bitstype -> primitive también ...

No creo que const deba ser el valor predeterminado. Las optimizaciones que reducen la funcionalidad no deberían ser las predeterminadas.

+1 por struct y const struct .

El término composite es un poco más descriptivo, pero struct es corto y muy comúnmente conocido como tipo compuesto.

Prefiero no robar una palabra real para algo tan poco utilizado como bitstype . ¿Quizás primtype o primitivetype ?

Si no vamos a cambiar bitstype por un nombre claramente mejor como primitive entonces creo que dejarlo como está probablemente sea mejor.

-1 a struct . No uso este término para explicar qué es una definición de tipo a menos que esté hablando con un programador de C, y luego solo para mencionar que el diseño es compatible y comparar / contrastar sus propiedades.

-1 a const . C tomó esta dirección de tener palabras clave absolutamente mínimas, y ahora estamos atrapados con muchas palabras clave que tienen significados sensibles al contexto. Realmente no creo que const sea ​​la propiedad clave de estos tipos, sino que son tipos de valor (a diferencia de los tipos de referencia).

Sin embargo, yendo en otra dirección, ¿qué tal si usamos la palabra clave new ?

new abstract Abstract
new value Value <: Abstract
    Value() = new()
end
new primitive 8 BitsByte <: Abstract
new record Object <: Abstract
    Object() = new()
end
new function WhyNot # equivalent to `function WhyNot end`

El problema con el "tipo de valor" es que es algo que solo las personas que están muy familiarizadas con el idioma pueden entender. Para los nuevos usuarios, el hecho de que los campos sean inmutables es el hecho _ semántico_ al que se enfrentan inmediatamente; todo lo demás es un detalle de implementación. Entonces prefiero const .

Veo adónde va con el registro , pero honestamente creo que esta terminología es incluso menos común que struct (incluso si busca en Google "tipo de registro ruby" vs "tipo de estructura ruby", o sustituye python o perl otro lenguaje que no sea C). También existe el problema de que record es una palabra en inglés bastante útil que sería una pena reservar como palabra clave, mientras que struct no es probable que se necesite para nada más en un programa.

struct es de uso muy común; mirando por encima de rosettacode es utilizado por:

algol, C, C #, C ++, lisp, D, elixir, adelante, adelante, maxima, raqueta, herrumbre, semilla7, rápido, visual básico ( structure )

record es utilizado por:

ada, clojure, delphi, pascal, erlang, icono, modula-2, algunos esquemas

record parece ser el preferido en idiomas más antiguos; En estos días, a medida que la programación funcional se ha vuelto más popular, tiende a referirse a registros de tipo estructural.

Curiosamente, aunque seed7 usa new struct .

Es un poco triste ver que struct (¿son tan malas las tres letras adicionales para completar la palabra?) Convertirlo en un idioma que hasta ahora ha tenido function lugar de func , y así. No es algo por lo que nadie vaya a rechazar un idioma, pero aún así ...

structure se usa de hecho en PL / I y visual basic. VB también tiene structure immutable . Sin embargo, struct es tan común que siento que casi se ha convertido en una palabra nueva.

Me pregunto si también hay un problema de habla nativa aquí. Para mí, que estoy muy acostumbrado a la palabra struct en este contexto es structure que se siente más extraño. Por la misma razón func suena horrible y function natural.

¿No se ha convertido struct en un término autónomo debido a su uso en varios lenguajes de programación? La palabra structure es (al menos para mí como nativo alemán) mucho más abstracta. Por ejemplo, esa jerarquía de tipos tiene una cierta "estructura".

func es para mí un término autónomo, sino solo una abreviatura.

func no es para mí un término autónomo, sino solo una abreviatura.

¿Cómo es que struct no es solo una abreviatura también? ¿No es literalmente la abreviatura de estructura, o simplemente entendí mal el término? Estás más acostumbrado que func . Muchas cosas son "términos autónomos" y comunes en muchos idiomas, pero eso no significa necesariamente que Julia deba seguir una tradición si es mejor no hacerlo. Entonces es solo una pelea por lo que es mejor o peor, y eso es solo una cuestión de gustos.

De todos modos, preferiría mutable , así que no me importa _ demasiado_ si es una estructura o estructura. mutable evitaría escribir const todo el tiempo por lo que ahora es immutable .

Pero, incluso si termina siendo struct o incluso strct o stct o strctr , es muy poco probable que cambie a Julia por cualquier otro idioma para mi trabajo, entonces ... :)

Lo siento si esto no tiene sentido en inglés: pero no es struct una abreviatura de construct . Al menos en alemán, la palabra Konstrukt tiene mucho más sentido para describir lo que es un tipo compuesto.

En inglés, no poder decir si construct es un sustantivo o un verbo probablemente impidió su uso en lenguajes de programación basados ​​en inglés :) El uso de mayúsculas en alemán es útil allí.

struct es su propia palabra de la misma manera que TV, ASAP y LOL son palabras. Rara vez escucho a la gente decir "estructura". En mi experiencia, la palabra es "estructura" tanto hablada como escrita.

Por cierto: Matlab usa la palabra struct , si eso hace alguna diferencia.

OTOH, como se indicó anteriormente, en C # y Swift struct corresponde a un tipo de valor (a diferencia de class ). Por lo tanto, usar una terminología similar para los tipos mutables e inmutables no ayudaría realmente a las personas familiarizadas con estos lenguajes. No estoy seguro de si ese es un punto decisivo ...

mutable / immutable suena como la opción más explícita, que debería ser bastante obvia para los recién llegados.

Dada la gran cantidad de idiomas diferentes que usan struct , no creo que se requiera tener una semántica idéntica para usar ese nombre.

Me gusta type y const type lo mejor, pero eso no libera la palabra clave type . Como no sé qué está planeado para type , no sé qué tan grande es ese costo.

Pero dado que la parte type ya está implícita en abstract , quizás usar mutable y immutable por sí mismos tenga más sentido. Y es menos escribir que immutable struct y un pequeño cambio (escriba -> mutable).

la estructura de la palabra es (al menos para mí como nativo alemán) mucho más abstracta.

Mientras discutimos sobre el lenguaje, todos subestiman la cantidad de abreviaturas que es struct . Es la abreviatura de "estructura de datos". Del mismo modo, yo diría que type es la abreviatura de "tipo de datos". Me atrevo a decir que una matriz o un búfer también es una estructura de datos, al igual que una lista vinculada, y así sucesivamente, pero struct tiene raíces tempranas como una de las primeras estructuras de datos comunes y dentro de la computación ha llegado a tener un un significado más específico por sí mismo (y, por lo tanto, para los programadores nativos del inglés o no, no suena tan abstracto como structure ).

-1 a struct . No uso este término para explicar qué es una definición de tipo a menos que esté hablando con un programador de C, y luego solo para mencionar que el diseño es compatible y comparar / contrastar sus propiedades.

Me siento exactamente así sobre struct . Siento que le estaríamos presentando un nuevo término a Julia sin ninguna razón específica.

-1 a const . C tomó esta dirección de tener palabras clave absolutamente mínimas, y ahora estamos atrapados con muchas palabras clave que tienen significados sensibles al contexto. Realmente no creo que const sea la propiedad clave de estos tipos, sino que son tipos de valor (a diferencia de los tipos de referencia).

Jeff me explicó (muy amablemente) anteriormente que semánticamente no nos importa si las cosas son valores o referencias o lo que sea, estos son detalles de implementación, no semántica y en una futura edad de oro _no nos importará_. Las cosas se "pasan por compartir" de la forma que desee el compilador (con algunas garantías de FFI según sea necesario). En los últimos días ya lo llamé "compartir por magia" y siento que esto ha sido una revelación para mí alivia un montón de presión mental en la que (idealmente) no debería tener que pensar ( @vtjnash , ha visto cómo he luchado con valores y referencias y cómo el compilador y GC los implementan y así sucesivamente en otros paquetes y subprocesos).

Los enlaces pueden cambiar o ser constantes (usamos const pero constant también es bastante lindo). De manera similar, los enlaces de campos dentro de un tipo de datos compuestos pueden cambiar o son constantes. Es por eso que sugerí anteriormente adjuntar const explícitamente a cada campo: hizo que la semántica fuera muy clara (al menos para mí).

En mi opinión, no deberíamos necesitar usar palabras elegantes como "mutabilidad" e "inmutable" para hablar de estas cosas. Algo puede rebotarse en un nuevo objeto o es constante. Eliminar la necesidad de palabras complejas en inglés como struct y immutable completo de nuestro discurso sobre Julia (no solo el código) debería verse como algo bueno (un objetivo, incluso).

También siento que "estructura" es su propia palabra (es decir, lo que significa en C) mientras que "estructura" es probablemente una "estructura de datos", porque si te refieres a un tipo de registro, dirías "estructura". Pero estoy mostrando mis raíces C aquí.

También está en ceceo común; defstruct .

Probablemente más trivial que la mayoría de los otros puntos aquí, pero siempre que estemos perdiendo bicicletas: cuando se dicen en voz alta, las frases immutable object y a mutable object suenan molestamente similares. Haría que conversar sobre el sistema de tipos de Julia sea más difícil de lo necesario. EDITAR: Parece que esto ya se mencionó en este hilo .

+1 a type -> struct y immutable -> const struct . No creo haber conocido a nadie que pudiera confundirse con esto, especialmente después de una explicación superficial.

Reemplazar type es realista para v0.6 y poco realista para v0.8. Deberíamos hacer esto. Es una oportunidad para suavizar y mejorar el talento natural de Julia para una comunicación clara y rapidez expresiva. Los tipos funcionan bien para crear software que funcione. Una mejor denominación de las cosas típicas resuena poderosamente y le llevará a Julia un futuro con más historia.

Sugiero dejar struct sin usar. En C, una estructura es un contenedor sintáctico para una secuencia fija de campos de tipo fijo. Julia no es C, y poner un C-ismo en el discurso juliano empujaría la naturaleza efímera de Julia fuera de una discusión seria sobre los mejores usos y mejores formas de conceptualizar aspectos de Julia.

Además, "inmutable" y "mutable" son demasiado concordantes visualmente. Podemos hacerlo mejor.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff Como estándares de la

@ararslan La guía estándar de la comunidad sobre Julia parece haber cambiado, ahora evitando la aplicación de pronombres literarios. Gracias por traer esto a mi atención. :Grillo:

Usar el pronombre femenino no es, en sí mismo, nada malo (e inevitable en muchos idiomas), pero parece que a muchos les resulta irresistible pasar de usar el término "ella" a hablar de Julia como una cita caliente, por lo que parece mejor evite la tentación por completo tanto como sea posible.

gracias

El jueves 3 de noviembre de 2016 a las 4:29 p.m. Stefan Karpinski [email protected]
escribió:

Usar el pronombre femenino no es, en sí mismo, nada malo (e inevitable en muchos
idiomas), pero parece que a muchos les resulta irresistible dejar de usar
el término "ella" para hablar de Julia como una cita caliente, por lo que parece mejor
evite la tentación por completo tanto como sea posible.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

Con respecto al tema que nos ocupa, personalmente estoy indeciso sobre cuál consideraría el mejor cambio. Pero me parece extraño hablar sobre el asombroso sistema _type_ de Julia y luego especificar que la palabra clave utilizada para construir un tipo es en realidad struct lugar de type . Creo que podría animar a la gente a hablar de tipos como estructuras, lo que eventualmente conduciría a un cambio en el lenguaje utilizado para describir a Julia, por ejemplo, discutir el asombroso sistema de estructuras de Julia.

la palabra clave utilizada para construir un tipo es en realidad estructura en lugar de tipo

Pero la palabra clave no se trata realmente de construir tipos; por ejemplo, la expresión Tuple{Int} también construye un tipo. Sería genial si las cosas actualmente definidas con type siempre se denominaran struct s, ya que entonces no habría confusión sobre cómo Real es un tipo, y Union{Int8,Int16} es un tipo, etc.

sí, estoy editando mi nota anterior y acabo de escribir sobre eso. Podría ser
omnipresentemente perjudicial para el "cuidado y la alimentación" de Julia y el
desarrollo futuro del poder expresivo y la concisión. ¿Debería ser la puerta
abierto para legitimar la consideración del sistema de tipos de Julia como
andamios en estructuras C, la guerra está perdida.

El jueves 3 de noviembre de 2016 a las 4:38 p. M., Alex Arslan [email protected]
escribió:

Con respecto al tema en cuestión, personalmente estoy indeciso sobre lo que
consideraría el mejor cambio. Pero me parece extraño hablar de
Asombroso sistema _type_ de Julia y luego especifique que la palabra clave solía
construir un tipo es en realidad una estructura en lugar de un tipo. Creo que podría
animar a la gente a hablar de tipos como estructuras, y eventualmente
a un cambio en el lenguaje utilizado para describir a Julia, por ejemplo, discutir la
asombroso sistema _struct_.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

Sería genial si las cosas actualmente definidas con type siempre se denominaran struct s, ya que entonces no habría confusión sobre cómo Real es un tipo, y Union{Int8,Int16} es un tipo, etc.

¿Hay confusión con respecto a eso actualmente? Supongo que mucho me pareció obvio, aunque quizás me he perdido las discusiones al respecto.

@ararslan : El término type es demasiado genérico para lo que está construido actualmente. Lo que construimos actualmente con la palabra clave type es una estructura que consta de tipos compuestos. Pero hay muchos otros tipos dentro de Julia que no se construyen usando la palabra clave type .

No, no creo que haya demasiada confusión sobre eso actualmente, pero tampoco todos pensarían que todos los tipos de julia son estructuras si usáramos la palabra clave struct .

Bien, buen punto.

y Union {Int8, Int16} es un tipo

¡Ah! Había olvidado que Union también existe. Lo que hace que el argumento de struct ( Struct ?) Sea más convincente, en mi opinión. Sin embargo, todavía no me gustan mutable y immutable .

Encuentro _struct_ ignominioso y realmente creo que llevar a Julia a él, con el tiempo, empujaría hacia abajo al zeitgeist en evolución. El principio es un antagonismo entre la exposición de bits en movimiento y la expresión de maybes computacionales como fusiones de orden superior y gestalts más profundos. Que usar struct no llevaría a todos a pensar en tipos de estructuras no viene al caso. ... déjame sobredramatizar ...

No puedo argumentar que escribir sobre Einstein como empleado de patentes disminuye la apreciación de sus contribuciones. De ello no se sigue que, en un curso donde las referencias a Albert Einstein enfatizan la importancia de su tiempo como empleado de patentes, más de unos pocos estudiantes incluirían algún sentido de eso en conversaciones futuras. Que algo sea so no asegura que se comporte solo so después de mudarse a una nueva escuela.

Si hay un caso convincente para usar _struct_, debería haber un caso mejor para uno de

a structure es una interrelación significativa de partes, una composición informada
un construct es una estructura útil de relevancia, un diseño que mejora el valor

un structure inmutable es un compuesto perdurable
un structure mutuo es una predelección no fija
un construct inmutable es una eventualidad establecida
un construct mutable es una restricción intencional en el contexto

Necesitamos tanto la forma de hablar "bits en lugares y puertas" y la "estructuración de datos revela información ontológica" y eso puede estar disponible como forma de hablar modificador de transformación. Los participantes de la comunidad que son talentos de CS y la mayoría de los demás expertos en dominios que programan en general tienen un manejo completo de bytes, memoria, lógica, operaciones instruidas, etc. La otra forma de hacer que el deseo, la creatividad, las posibilidades y la imaginación se conviertan en software que funciona bien y es bien vale la pena el trabajo, que se comparte menos. Cualquier decisión sobre la denominación de términos debe llegar a fomentar esa conversación.

¿Qué pasa con class y immutable ?

Conozco la clase de Delphi y pensé que sería imposible aquí, pero en el lenguaje de Niza, que tiene múltiples métodos, se usa como palabra clave ( enlace ). Y, si leo los manuales correctamente, también en Haskell y Dylan. Pasa la prueba de "la clase es un tipo de tipo" y todavía es bastante vaga (como 'tipo' hoy), algo que me gusta. En el video 'Una descripción general de matrices e iteración' a las 15:00 - 15:20 min, Tim Holy (accidentalmente) dice 'clase', un detalle sin importancia pero que, sin embargo, tal vez muestra que la clase no sería totalmente ajena en el contexto de Julia.

De lo contrario, reftype y immutable ? El término reftype se mencionó en el comentario inicial y se ha ignorado desde entonces. ¿Por qué? Para mí suena bastante bien, libera la letra y transporta el significado de referencia.

(No entendí el propósito de la palabra clave "nuevo". ¿No podría omitirse "nuevo" en todas las líneas sin cambios? Los términos "valor" y "registro" serían palabras clave y reemplazarían el término "inmutable" utilizado actualmente. y 'tipo', ¿verdad?)

@swissr la única diferencia (que la mayoría de los usuarios deberían conocer) entre estos dos tipos es que los campos en uno pueden cambiar y en el otro los campos no. Sería lógico que sus nombres indicaran su única distinción semántica. (Como se mencionó, las implementaciones que usan valores y referencias son fluidas, por ejemplo, un compilador mejorado podría pasar tipos grandes isbits por referencia automáticamente como una optimización y, a la inversa, pequeños mutables podrían moverse a la pila en ciertas situaciones).

Con respecto a type vs struct , veo que puedo hacer tipos de datos abstractos con abstract , Union{} , typealias y así sucesivamente ( en el caso de Tuple{} es discutible si es un tipo nuevo o simplemente un tipo parametrizado), pero realmente los únicos _tipos concretos definidos por el usuario_ son creados por bitstype , type y immutable . La sintaxis de estos es inconfundible con las definiciones abstractas en el sentido de que definen los datos que contienen de alguna manera, y los abstractos no. Cambiar immutable a const type parecería aclararme la situación.

Me preocupa el lenguaje y la propagación de la palabra técnica struct con la única razón de ser tradición, cuando tenemos la oportunidad de crear un lenguaje de programación que se discute en términos sencillos. Un ejemplo de donde creo que esto no ayudará es cuando creo un tipo de contenedor como Symmetric{Matrix{T}} - No quiero que mis discusiones sean, "Creé este struct con un solo campo que ... "cuando puedo decir" Hice un Symmetric envoltorio type por Matrix "(tenga en cuenta que la mitad de esa oración es sintaxis real). ¿Una "estructura de envoltura"? Suena un poco tonto, ¿y quién crea una estructura con un campo? De hecho, ¿qué pasa con los singleton sin campos? Una fracción considerable de types y immutables no está definida para crear ninguna estructura de datos (no trivial) sino con el propósito expreso de usar el poderoso sistema de tipo y envío con envoltorios y singletons. En mi opinión, este es el aspecto más interesante, poderoso y expresivo de Julia (combinado con el hecho de que es _rápido_).

Siento que todo el poder de struct solo sería evidente de inmediato para los metaprogramadores experimentados de plantillas de C ++ que saben que pueden implementar rasgos, etc., con estructuras, y eso es un poco vergonzoso.

"Tipo" tiene un significado técnico bastante específico en la teoría de tipos.

Si el objetivo / ventaja es liberar type , ¿qué tal:

const datatype  # immutable
datatype        # type

Son tipos concretos, por lo que probablemente contienen datos, y es una (de muchas) formas de construir un DataType .

"Tipo" tiene un significado técnico bastante específico en la teoría de tipos.

La introducción a la wiki suena exactamente como Type{} (que acepta DataType y TypeConstructor , Union , etc.) (EDITAR: no es que piense que tal cambio vale la pena la interrupción)

kind no es la palabra correcta aquí.

Siento que la mayoría de las veces el mejor enfoque es simplemente aprender un campo
vocabulario estándar en lugar de intentar reemplazarlo con algo que
adivinar será más fácil.

Esta decisión no afecta el habla informal. Todavía puedes decir con sensatez "yo
definido un tipo ". El uso de una palabra clave más específica hace que sea más fácil
necesitas ser preciso.

Buen punto, Jeff. Tenga en cuenta que _ creo_ que const struct y struct serían una mejora con respecto a immutable vs type (pero eso no significa que no debamos buscar algo aún mejor).

Cuando piensas que la estructura es esa percepción más como una estructura o como una construcción, ¿ninguna o ambas?

@andyferris mi const struct y struct serían una mejora. Fue otro intento de buscar términos posibles al querer evitar 'const', preservar 'inmutable' y mantener fuera 'struct' (estaba al tanto de la implementación mencionada, pero pensé, si es correcta en, digamos, más del 80% de los casos, está bien) .

¿Qué tal fieldtype (o fieldstype )? Es paralelo a bitstype y coherente con fieldnames() .

Cañada,
Me gusta la verosimilitud. fieldstype es la mejor opción porque usar una forma plural donde algo puede ser singular o plural es apropiado.
- Jeffrey

class podría estar bien; originalmente lo rechazamos debido a su asociación con OO basado en clases con métodos dentro de objetos. Yo diría que struct es más preciso.

No veo struct tan corto para nada; es exactamente lo que se llama este tipo de estructuras de datos en este momento. De manera algo divertida, lisp tiene cons , que puede haber sido originalmente una abreviatura de construct , pero la gente lo olvidó bastante rápido y empezó a hablar de "celdas de contras".

Creo que deberíamos seguir rechazando class . Usar ese término invitaría a una gran cantidad de expectativas de programación orientada a objetos que van en contra del estilo de Julia.

No veo struct tan corto para nada, pero me preocupa que la referencia implícita a las estructuras de C implique que las de Julia serían tipos de valor, lo que no lo son, por supuesto. Con ese fin, actualmente me estoy inclinando un poco hacia record ya que tiene muchas menos connotaciones inmediatas.

Para aclarar un punto que puede no estar claro, creo que usar const record o const struct solo es viable si se interpreta en el sentido de ser la abreviatura de mapear const en todos los campos , lo que implica que nos gustaría admitir el marcado de campos individuales como const . Entonces, lo que estoy diciendo es que podríamos tener estos:

record T0
    f::A
    g::B
end

record T1
    const f::A
    g::B
end

record T2
    f::A
    const g::B
end

record T3
    const f::A
    const g::B
end

const record T4
   f::A
   g::B
end

Aquí T3 y T4 en realidad describen tipos equivalentes, es decir, escribir const record es una abreviatura de todos los campos que son const . Si esta no es la interpretación, entonces creo que la combinación de inmutabilidad con constness es algo peligrosa, ya que esto ya es una fuente común de confusión conceptual y si agregamos a esa confusión terminológica, no vamos a ayudar.

Aquí T3 y T4 en realidad describen tipos equivalentes, es decir, escribir un registro const es una abreviatura de todos los campos que son const.

Si hacemos que const record signifique lo que immutable significa ahora, esto podría no ser cierto. const record describiría un tipo de referencia para el cual no se puede cambiar ninguno de los campos. Mientras que el actual immutable es un tipo de valor.

Consulte https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 y el siguiente comentario para una discusión sobre record .

@vtjnash Ese es un buen punto, pero es similar a lo que sucede ahora donde un immutable convierte en un tipo de "referencia" si contiene alguna referencia.

Creo que el hecho de que record sea ​​menos común está bien, el hecho de que sea una palabra útil como sustantivo y verbo es más problemático.

¿Qué tal nuple ? Abreviatura de "tupla con nombre", por supuesto.

Me gusta la sugerencia hecha arriba de

const datatype  # immutable
datatype        # type

mejor hasta ahora. Evita traer una palabra antigua con bagaje histórico y me parece completamente claro. Seguro que no es el único tipo de datos en julia pero es el más común definido por los usuarios normales.

¿Hay planes para cambiar también la terminología para explicar esto en la documentación, más concretamente cambiar los títulos de capítulos como este ? Si no, creo que me gusta composite y immutable composite o const composite mejor. Dado que const también se usa para constantes globales, elegiría const o immutable para ambos, con una ligera preferencia por const porque es más corta. Al menos, la palabra compuesta no les resultará familiar a la mayoría de los recién llegados, lo que obligará a echar un vistazo a la documentación y evitará suposiciones falsas debido a la similitud con un nombre C. Las suposiciones falsas con respecto a const parecen menos probables, ya que cualquiera que esté acostumbrado a eso en C ++ sabe que no debe asumir nada.

Además, la ventaja de usar dos palabras para indicar la inmutabilidad libera un posible futuro const abstract y const bitstype caso de que surja la necesidad.

Si hacemos que registro constante signifique lo que significa inmutable ahora, esto podría no ser cierto. const record describiría un tipo de referencia para el que no se puede cambiar ninguno de los campos. Mientras que el actual inmutable es un tipo de valor.

UH oh. Pensé que el valor o no de immutable se definió en el nivel de implementación, y todo lo que el usuario debe considerar es que los campos no se pueden rebotar. Pasar por valor (o no) es entonces una cuestión puramente ABI, donde el compilador debería, en principio, ser libre de elegir lo que sea más eficiente. Para mí, la semántica visible del usuario de inmutable parece exactamente equivalente a aplicar la semántica actual de const a todos los campos de un tipo.

¿Estoy _todavía_ confundido acerca de la semántica de nivel de usuario prevista de inmutable, o estás hablando de detalles de implementación aquí?

¿Qué tal nuple? Abreviatura de "tupla con nombre", por supuesto.

También puede ir con record , ¿verdad? Por ejemplo, una tupla con nombre es lo que es record en Erlang. Y creo que también en el mundo de las bases de datos.

Pero si Julia se superpone más con personas que también conocen C , struct es un cambio más apropiado.

Personalmente, encuentro record algo extraño y poco claro. En el mundo de las bases de datos, un registro es una fila en una tabla; eso parece que sería un conflicto confuso con algo tan general como un tipo de Julia (inmutable o no).

Después de releer este hilo, me inclino por composite por type . Mantiene la "regla de una oración" de Jeff y no ha habido tantos votos negativos para ella. Que el término no se use tanto en otros idiomas no es un problema en mi opinión. Y composite es realmente la palabra más descriptiva que se puede encontrar para eso. Esa es la razón por la que la documentación se refiere a estas cosas como composite types .

Viniendo de Fortran, sigo pensando que la palabra clave type está bien,
y un cambio mínimo sensato sería immutable -> const type .

Pero si type realmente tiene que irse,
composite y const composite parecen ser las siguientes mejores opciones.

immutable -> const type ciertamente parece viable: simultáneamente evita la interrupción, elimina una palabra clave y agrega claridad al lenguaje.

Puede ser triste no poder usar type pero, para ser sincero, el que quiero usar es Type todos modos. Nueve de cada diez veces mis variables de tipo son parámetros para el envío estático, no variables DataType para análisis de tipo dinámico (la excepción son las funciones generadas). No es cierto para las personas que escriben inference.jl, pero en realidad no son el "público objetivo" del idioma, por así decirlo.

Pregunta relacionada: ¿es viable usar type ya que está en el nivel superior, pero dentro de una función (donde siempre es inválida, actualmente) permitir que sea un nombre de variable? O aún más, la estructura de una definición de tipo es bastante específica ... ¿podríamos detectar definiciones de tipo como sintaxis específica mientras permitimos que incluso las variables (o funciones) globales estén vinculadas a type ?

Es decir, ¿podemos deshacernos del comportamiento de las palabras clave manteniendo la sintaxis para definir un tipo?

(improbable en mi opinión) hay un fuerte riesgo asociado: se vuelve demasiado fácil para que la lexicografía idiosincrásica distraiga. Y esas micro-continuidades faltantes son destructivas para facilitar la colaboración y la comunicación clara.

@ c42f :

¿Todavía estoy confundido acerca de la semántica de nivel de usuario prevista de inmutable, o estás hablando de detalles de implementación aquí?

No, no lo eres, estaba siendo descuidado. Los inmutables no son realmente tipos de valor, pero los mutables ciertamente no lo son y sentí que usar los mismos términos que C podría sugerir que lo son.

Me acabo de dar cuenta de que en el contexto de C no está claro si tiene sentido llamar a las estructuras "tipos de valor", ya que la situación real es que C es un lenguaje de paso por valor. Así que podría decirse que son las convenciones de paso y asignación las que son diferentes, no los tipos de datos en sí.

Estoy totalmente a favor de promulgar el cambio que abre este tema. La utilidad supera cualquier preferencia visceral de que se utilice uno en lugar de otro de los términos candidatos.

_a pesar de que_

ya que la situación real es que C

capta muy bien por qué, de los términos candidatos, struct es el menos favorecido

Esta es la historia que estoy vendiendo: "Tanto en C como en julia, un struct es una estructura de datos que asigna un conjunto fijo de nombres de campo a valores de varios tipos. Pero cuando los pasas, C es pass -by-value y julia se pasa por compartir ".

Esa cuenta no es onerosa y es completamente precisa. Todo lo que contiene se puede buscar en Google con éxito. Ningún teórico del PL se quejaría de ello, y los no teóricos del PL aprenderían algo escuchándolo.

Compro esa historia. Aunque me pregunto, ¿se mencionan aquí algunos términos de los que un teórico de PL _ se quejaría_? Me gusta pensar que Julia encaja perfectamente en ese nicho que satisface tanto a los teóricos como a los no teóricos de PL, por lo que encontrar un equilibrio entre la corrección y la claridad general aquí parece crucial.

Bueno, no quiero poner palabras en la boca de nadie; Solo quería abordar la idea de que struct podría ser confuso debido a que las estructuras son "tipos de valor".

Creo que immutable debería seguir siendo una palabra clave de una sola palabra. No me gusta const type o const struct o immutable struct . Utilizo mucho immutable y creo que sería bastante incómodo que estas declaraciones fueran dos palabras cuando casi todo lo demás es una palabra. No en el sentido de mecanografiar, ya que no es una preocupación real; pero en el sentido de que tener inmutable como una "etiqueta" lo hace sentir de segunda clase.

@TotalVerb No creo que sea muy compatible con el hecho de que

type MyType
    const field::Int
end

debería comportarse exactamente como

immutable MyType
    field::Int
end

hace ahora.

Teniendo en cuenta eso, tener un const type (o const struct , const composite , o lo que sea) transmitir el const a cada campo como un atajo parece útil (aunque no es estrictamente necesario) característica. Espero que en el futuro el compilador ni siquiera sepa cuál ha escrito ( const type o const delante de cada campo; el primero podría transformarse en el segundo mediante el analizador). En ese momento, ¿por qué quedarse con immutable ?

tener inmutable como una "etiqueta" lo hace sentir de segunda clase.

Si entiendo correctamente a Jeff y Stefan, entonces, sí, immutable es solo una etiqueta que dice que los campos de un tipo son enlaces constantes. Ser constante (_realmente_ constante, no como C) ayuda al compilador a realizar optimizaciones, y si los campos en sí son constantes o primitivas de forma recursiva (es decir, isbits ) le ayuda a realizar aún más optimizaciones. Es bueno saberlo, pero no es semánticamente importante. Vincular la semántica al comportamiento actual podría dificultar la mejora de ese comportamiento en el futuro.

Pero hay una diferencia semántica importante: los tipos inmutables son valores y, por lo tanto, se puede asumir con seguridad que la identidad de un objeto está especificada por sus campos. Un objeto de tipo inmutable no tiene, desde la perspectiva del usuario, ninguna "característica de identificación" especial que no sea accesible desde sus campos. Cualquier objeto de un tipo mutable no singleton, por otro lado, claramente tiene esta "identidad" invisible. El hecho de que muchos tipos inmutables se almacenen como objetos en caja y, por lo tanto, tengan esta identidad adicional internamente, es irrelevante para la semántica.

En mi opinión, no es solo una _optimización_ para hacer

immutable Complex{T} ... end

en vez de

type Complex{T} ... end

porque muchos aspectos del comportamiento visible del usuario cambian: === , el valor predeterminado == , objectid , hash , etc. Simplemente no es correcto decir que los tipos inmutables proporcionan un subconjunto de la funcionalidad de los tipos mutables; por el contrario, el hecho mismo de ser inmutables proporciona importantes garantías que permiten que los tipos inmutables sean más poderosos.

Antes de que la comunidad se establezca en const y struct , solo quería hacer un enchufe más por constant y structure .

1) ¡Solo tres letras adicionales para palabras reales!
2) A pesar de las afirmaciones de que struct ha vuelto idiomático
2a) Alguien que está migrando desde R (como yo) podría estar confundido
2b) Alguien que es nuevo en programación (aquellos que necesitan más ayuda) puede estar confundido

Solo por diversión, palabras tontas con las que la estructura podría confundirse:
indestructibilidad
obstruccionismo
postestructuralismo
la superestructura (oh hola Marx)

y const:
Constantinopla
constelación
Boa constrictor
inconstitucional

¿Existe la PL belleza / poder ganado por la multicontextualidad inmutable y constante de este tipo: inmutable nunca difundir (proyectando su naturaleza) a través / dentro de su referente resuelto y constante difusión a través de referentes incrustados que no son inmutables, como si fuera un adverbio o gerundio?

La misma pregunta, en otras palabras:

Por el momento, el uso de variables en el ámbito global es problemático y el trick para solucionar es envolver el valor variable en un vector constante con una sola entrada. En ese caso, const no se transmite. Se aplicaría una versión de transmisión de const ? Implica constness al valor de la entrada en el vector, así como al vector. De manera similar, una declaración de tipo que tiene campos que pueden contener valores que envuelven o encierran otros tipos de valor. Un tipo inmutable ahora no confiere inmutabilidad a los valores de sus campos (y no a ningún valor que pueda alcanzarse indirectamente a través de sus campos). Hay afaik una elegancia y una capacidad útil que viene con una versión de transmisión de una palabra clave que significa "una vez construido / inicializado, el valor atribuido a este elemento [oa elementos de este tipo] no cambia [no se permite cambiar]" .

El tipo inmediato (sin transmisión) se usa ampliamente, y asumiendo que algo de lo que la gente hace con Julia se vuelve mucho más fácil para que la compilación previa de Julia sea mejor / más rápida / más simple de usar o de confiar con la introducción constness difusible, entonces eso debe reproducirse bien con el tipo inmediato. Me pregunto si esta es una forma que aporta _ bondad adicional del lenguaje de programación teórico_ (facilidad de expresión, poder de representación, ...): la constidad de la transmisión se transmite a través de valores de tipos que tienen tipos de referencia incrustados y / o tienen tipos contenidos indirectamente hasta (a) alcanzar un valor que no tiene incrustaciones o contenedores internos o (b) alcanzar un valor es en sí mismo (independientemente o de otra manera) de un tipo que no tiene constidad de transmisión.

Pensando más en esto, el único cambio que realmente creo que vale la pena romper es bitstype -> primitive , principalmente por lo molesto que es llamar a algo isbits .

En cuanto al punto real de esta discusión, type y immutable , en este punto, la opción que encuentro que más me gusta es no cambiar en absoluto; type para construir un tipo es claro, immutable para construir un tipo inmutable es claro. Sin embargo, aceptaré felizmente todo lo que nos den nuestros señores supremos, ya que confío implícitamente en su juicio sobre lo que es mejor para el idioma en el futuro.

¿Hay alguna razón para no usar fijo en lugar de constante o constante? Para mí, al menos, parece una descripción mucho más clara.

@JeffreySarnoff Es difícil implicar const ness a una cosa a la que puedes obtener una referencia (es decir, un puntero). La semántica de "compartir" de Julia significa que cualquier cosa que el compilador no pueda demostrar que es verdaderamente inmutable debe ser un tipo de referencia. Cuando vincula dicha referencia al campo de un const type ( immutable ), no hay prueba de que esta referencia no exista en otro lugar y, por lo tanto, no hay prueba de que los datos a los que se hace referencia sean constantes.

Creo que cambiar este comportamiento sería un cambio realmente fundamental en el lenguaje de Julia.

@andyferris Gracias por esa clara respuesta.

¿Hay alguna razón para no usar fixed lugar de const o constant ? Para mí, al menos, parece una descripción mucho más clara.

Me preguntaba si había algo mejor que const o constant que refleja que es el enlace lo que es permanente, y no (necesariamente) que los datos dentro del objeto enlazado sean inmutables. fixed va de alguna manera hacia eso, pero no lo he visto en otros idiomas (de nuevo, tampoco he notado la semántica de enlace / intercambio de Julia en otros idiomas).

Tal vez algo como bind (por ejemplo, bind x = 2 ) ... el diccionario de sinónimos sugiere glue ... esto se está volviendo bastante especulativo ...

La idea de reemplazar const con algo más preciso es tentadora. Sin embargo, nos gustaría que se aplicara con sensatez tanto a la declaración de tipo a como a la asignación de una variable individual. fixed struct tiene algún sentido, pero son los campos de la estructura los que son fijos en lugar de la declaración de tipo. Desafortunadamente, bound struct ( tied struct ?) Parece bastante confuso. Por alguna razón, const parece más claro cuando se aplica a un tipo.

Querríamos que se aplicara con sensatez tanto a la declaración de tipo a como a una asignación de variable individual.

Creo que sería productivo apuntar a eso

type A
    const x::Int  # fixed, bind, bound, tied, glue
end

tiene sentido. Tener un atajo delante de type , struct o lo que sea sería solo un atajo que significa lo anterior.

Podría tener sentido hacer de esto una macro, como otras decoraciones importantes que cambian el carácter de una cosa, como @generated . Eso eliminaría otra palabra clave ...

+1 por type -> composite , aunque en realidad cualquier cambio de type suena genial.

Ojalá pudiera votar sobre los problemas de GitHub sin tener que agregar un nuevo comentario al hilo ... Mi voto es por mutable y immutable , es bastante ordenado y limpio. struct se usa en exceso y no enfatiza la parte de mutabilidad.

PD: ¿Alguien sabe o puede contribuir a GitHub y agregar una función de votación? Les pregunté en la página "Contáctanos", pero probablemente perdí mi correo electrónico.

Habiendo cambiado recientemente a Julia con experiencia en muchos otros lenguajes, preferiría no ver a Julia adoptar la nomenclatura estilo C y sacar todos los confusos problemas de const-ness de C / C ++. En cambio, dar a una declaración de tipo de datos una noción que refleje de alguna manera la intención de ser un tipo de valor o un tipo de referencia compartido me habría ayudado significativamente, en lugar de simplemente referirme a la mutabilidad.

Mi expectativa inicial en Julia habría sido un simple type para comportarse de manera similar a un objeto inmutable de estilo C struct o Python, ya que Julia parece tener mucho que ver con un estilo y velocidad de programación funcional.
Todavía me confunde la asimetría en la redacción de type ... y immutable... , pero obtengo un DataType de typeof(SomeType) , o el significado real de 'bitstype ', y la necesidad de una palabra clave typealias lugar de una simple instrucción Alias = DataType .

Por lo tanto, votaría por datatype , lo que sería consistente con typeof(SomeType) == DataType , y rompería la irritante similitud con ::Type{} . Decorar el tipo mutable con composite [datatype] podría resaltar su naturaleza especial y posiblemente más cara en comparación con los 'tipos de bits' fundamentales.

tirando de todos los confusos problemas de const-ness de C / C ++

Ningún cambio de nombre de esta palabra clave haría eso. Esos problemas tienen que ver con la comprobación estática y las transmisiones, que no están involucradas aquí en absoluto.

la intención de ser un tipo de valor o un tipo de referencia compartido me habría ayudado significativamente, en lugar de simplemente referirme a la mutabilidad

No entiendo completamente esto. Si un objeto es inmutable, no hay forma de saber si se pasa por valor o referencia, entonces, ¿cómo puede ser fundamental la distinción valor / referencia?

datatype no es una mala elección. Pero no creo que datatype vs composite datatype sea ​​una buena forma de transmitir la distinción de mutabilidad.

@JeffBezanson , con const-ness similar a C, me refería a la expectativa posiblemente implícita del tipo Julia de tener el mismo comportamiento que en C / C ++: inmutable solo después de la construcción, modificable de todos modos mediante conversión, a veces sin efecto en absoluto para argumentos de función o tipos de retorno. Por lo tanto, al elegir palabras clave que probablemente no se refieran a C / C ++ es una buena opción, por lo tanto, no const struct

Con respecto a 'valor frente a referencia': me tomó bastante tiempo entender por qué un tipo inmutable incrusta los miembros directamente y produce un código ensamblador rápido agradable y compacto, pero 'tipo' no lo hizo y aún contiene todas las llamadas a objetos. O en otras palabras, por qué normalmente querría usar un NTuple cuando apunto a la velocidad. Por lo tanto, al leer 'inmutable' y 'mutable' habría esperado el significado como un 'parámetro' en Fortran, pero no también el cambio en el diseño o el tipo de implementación del tipo de datos real.
Probablemente, la mayoría de las veces uno podría querer tener una semántica de 'valor inmutable' para pequeños tipos compuestos como un complejo, pero 'mutable y de referencia / no copia' para grandes conjuntos de datos como matrices, etc.
Entonces, la intención subyacente probablemente no sea la mutabilidad, sino evitar copiar datos.

Sin embargo, esa fue mi experiencia cuando aprendí la maquinaria de bajo nivel de Julia para obtener código ensamblador rápido, pero no sé cómo reflejarlo mejor al nombrar palabras clave y cómo combinar o expresar eso solo con mutabilidad.

Entiendo de dónde vienes @mjw, he estado allí, pero creo que es mejor que desaprendas todo lo que sabes sobre C / C ++. Aquí, es el const -ness lo que es inmutable y si algo se apila o se asigna dinámicamente, y si se pasa por referencia o valor, son libres de variar y serán opciones de optimización para el compilador. Puede crear un lenguaje donde todo se asigne dinámicamente y se pase por referencia, y esta es la forma predeterminada de Julia (para valores encuadrados, implementa "pasar por compartir" incluso si el tipo es desconocido). Usted (y el resto de nosotros) notan que los pequeños inmutables son mucho más rápidos porque ahí es donde actualmente se implementan las optimizaciones. Este es el resultado de la semántica de immutable que facilita las optimizaciones.

Pero, en realidad, preferiría que los inmutables grandes se pasasen por referencia (tal vez mediante punteros de pila, donde eso tiene sentido, pero probablemente sea mejor asignar en pila un NTuple{1_000_000} ) y que se asignen en pila pequeños mutables de tamaño conocido (nuevamente, cuando sea posible). Incluso la recolección de basura podría determinarse estáticamente en algunos casos, permitiendo que el espacio de pila se reutilice dentro de los bucles, por ejemplo. Los imagino como oportunidades de optimización futuras que requieren un análisis de escape (y ninguno de ellos afecta la semántica del lenguaje, solo el rendimiento).

Creo que lo que estoy diciendo es que las palabras clave deben reflejar la semántica que se mantendrá constante durante una década o dos, no detalles de implementación que cambiarán en un par de años (es decir, pequeños modificables eficientes e inmutables grandes eficientes).

Me refiero a la expectativa posiblemente implícita del tipo Julia de tener el mismo comportamiento que en C / C ++

Esta podría ser una razón suficientemente buena en sí misma para considerar const -> constant , para ser honesto. Creo que const podría ser nuestra única palabra clave abreviada en este momento, lo que la hace extraña de todos modos.

una declaración simple Alias = DataType .

Estoy bastante seguro de que esto está absolutamente bien donde tiene sentido, pero no permitirá modificaciones más complejas del tipo, por ejemplo, typealias RealMatrix{T<:Real} Matrix{T} , ni debería hacerlo (es un enlace simple, no crea un nuevo Type con los nuevos TypeVar s). A menos que quieras definirlo al revés: RealMatrix = Matrix{T <: Real} y generalizar lo que hace apply por un TypeVar (es decir, hace un TypeConstructor ) ... en realidad esa es una idea interesante (pero tiene problemas de sintaxis, razón por la cual typealias es agradable ...).

@andyferris , ya 'desaprendí', pero para otros usuarios nuevos puede ser más fácil superar la fase de 'por qué Julia es tan lenta a pesar de la compilación'. Elegir palabras clave que apoyen un rápido desarrollo de un modelo mental de esos detalles puede ser un gran atractivo para los nuevos usuarios que no tienen demasiada experiencia en informática. Sin olvidar palabras clave 'simples' para evitar otras barreras del lenguaje hablado.

@mjw Genial, y estoy de acuerdo con todo eso. :)

Te diré algo, probemos lo más parecido que podamos a una encuesta utilizando la mejor funcionalidad de GitHub: emojis de reacción.

Aquí he tabulado, sin ningún orden en particular, las sugerencias que parecen tener el mayor apoyo. Reacciona usando el emoji especificado para votar por esa sugerencia. Creo que esto requiere acceder a GitHub a través de un navegador de escritorio; Los emojis de reacción AFAIK no se han implementado en la interfaz móvil. Haga clic en la cara en la esquina superior derecha de esta publicación para acceder al menú de emojis.

| type | immutable | reaccionar con |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (Risa) |
| composite | const composite | : tada: (Hurra) |
| datatype | const datatype | 😕 (Confundido) |
| type | const type | ❤️ (Corazón) |

No votar corresponde a un voto implícito de nuple , por supuesto. :Cara de burla:

Debo decir que no soy un gran fanático de tomar decisiones polémicas como esta "democráticamente". Si la discusión se ha desarrollado sin consenso, simplemente cedería a la decisión de los BDFL.

Buen punto, @TotalVerb. Como dije antes, estaría totalmente bien si los poderes fácticos nos dieran lo que creen que es mejor. Me parece que el hilo está dando vueltas un poco y el punto de probaría esto y vería qué pasa. Lo veo como una forma de mostrar más claramente cuál es el consenso, pero definitivamente creo que la decisión final debería dejarse en manos de nuestros jefes supremos, independientemente de cuál sea realmente el consenso de la comunidad.

Personalmente, no creo que me guste tener dos palabras estéticamente ( const type ). También se siente un poco semánticamente disonante. Cuando decimos const x = 1 . Queremos decir que x es constante. Cuando decimos const type; x; end queremos decir que las instancias de este tipo no cambian después de la construcción. De la interpolación directa, parece que decir que algo es un tipo constante significa que el tipo en sí no cambia (que ya es el caso ahora). Ver también:

type foo
end
const bar = foo

Entonces bar es constante y siempre es foo, pero no es un const type . Se siente como wrt para la semántica existente de const (aplicando a los enlaces), los nombres de los tipos ya son constantes.

Sospecho que no hay palabras clave que sean concisas, transmitan la semántica deseada y es poco probable que sean deseables como nombres de variables. La terminología que creo que se acerca más a estos objetivos es mutable datatype , immutable datatype y abstract datatype para los tres tipos de tipos declarados.

Me gustaría que además de type y immutable hubiera un tipo de valor mutable adicional.
He visto algunas discusiones en algún lugar sobre problemas, pero básicamente en este momento es imposible manejar de manera eficiente escenarios como este (corríjame si me perdí algo):

immutable T
    a::Int
    b::Float64
    ...
end

t = Vector{T}(10)
t[2].a = 5    # error here
# instead
c = t[2]
t[2] = T(5, c.b, ...)   # works  

El código crea una ordenada matriz de tipos de valor sizeof(T) * 10 , pero para cambiar algún campo es necesario reasignar todo T(...) , que suele tener entre 3 y 5 campos.
Entonces, básicamente, mis 5 centavos:
type - Referencia recopilada por GC
immutable - tipo de valor (pila asignada) que es imposible de cambiar
mutable - tipo de valor que es posible cambiar, especialmente en matrices

tipo de valor que es posible cambiar

Creo que este es un objetivo imposible de lograr, ya que permitir cambios es precisamente lo que le da a algo una identidad de objeto.

Quizás le gustaría este enfoque en su lugar: # 11902

excepto para separar mutables e inmutables , sería mejor si dividimos valores y referencias .

abstract Node{T}
immutable Link{T} <: Node{T}
    value :: T
    next :: ref{Link{T}} # next :: Link{T} will be an error: Recursive type
end

No es necesario complicar demasiado el lenguaje con una distinción artificial entre valores y referencias. Los tipos mutables e inmutables son semánticamente mucho más simples; el hecho de que un tipo sea un tipo de valor es simplemente una optimización.

@Keno tiene un buen punto

Personalmente, no creo que me guste tener dos palabras estéticamente (tipo constante). También se siente un poco semánticamente disonante. Cuando decimos constante x = 1. Queremos decir que x es constante. Cuando decimos tipo constante; X; end, queremos decir que las instancias de este tipo no cambian después de la construcción. De la interpolación directa, parece que decir que algo es un tipo constante significa que el tipo en sí no cambia (que ya es el caso ahora)

Como mencioné anteriormente, creo que la semántica "correcta" viene dada por

type Complex{T}
    const re::T
    const im::T
end
z = Complex(1,2)

Aquí z.re comporta como cuando escribimos algo parecido a const z.re = 1 , por lo que no hay confusión semántica sobre exactamente qué enlace es const .

Como afirma @JeffBezanson , esto no es realmente conveniente para una gran cantidad de campos y no es compatible con la implementación actual de tipos. Las estructuras parcialmente mutables y parcialmente constantes pueden implementarse o no en el futuro. Sin embargo, hay una sintaxis que tiene sentido tanto en la actualidad como en el futuro:

<strong i="19">@const</strong> type Complex{T}
   re::T
   im::T
end

La forma actual en que esto se implementa, una macro puede cambiar de type a immutable en el AST. En el futuro, si se implementan estructuras parcialmente constantes, entonces la macro aún puede realizar las manipulaciones al AST agregando const a cada campo, y quedará claro para todos y cada uno que son los enlaces de campo que son constantes. Estéticamente, es mejor que dos palabras clave seguidas: hacemos cosas similares para las funciones ( @generated , @inline , @proagate_inbounds , etc.).

@const fácilmente podría ser @immutable o algo similar ( <strong i="31">@immutable</strong> type Val{T}; end dice OK, IMO) y la idea macro es compatible con struct , composite , y así.

@ be5invis sí, esta es una forma habitual en muchos lenguajes, por ejemplo, en C # hay struct , que se comporta de muchas formas como immutable : se pasa por copia a las funciones, se asigna explícitamente en matrices (no referencias a objetos gestionados por GC como en el caso de class | type ). Sin embargo, es _mutable_, y en las matrices se puede modificar con un solo campo.
Lo que sí creo es que en el caso de immutable hay una combinación de 2 propiedades:

1. Inmutabilidad (para realizar una programación funcional adecuada)
2. Comportarse como un tipo de valor en el nivel inferior

Básicamente, me encantaría ver la introducción de un tipo con solo la propiedad 2. Esto no interrumpirá la base de código existente (queda immutable ), pero para aquellos que escriben algo rápido con una participación mínima de GC sería valioso .

@johnmyleswhite gracias por # 11902, sigo creyendo que no debería ser tan feo

@wgreenr Como se mencionó anteriormente, y se ha discutido muchas veces, eso no es posible. Tampoco está realmente relacionado con la discusión en este tema.

Todo es posible, pero introducir tipos de valores cambiantes sería tremendamente disruptivo y una muy mala idea. Puedo entender por qué es una idea aparentemente simple y atractiva, pero agregar un tipo nuevo y completamente diferente de semántica de objetos y bifurcar el gráfico de tipos en semántica de referencia y valor no va a mejorar el lenguaje. Lo que lograría es hacer imposible escribir código genérico de forma segura, ya que el mismo código haría cosas muy diferentes dependiendo de la semántica desconocida. Hay una extensa discusión con ejemplos aquí . El objetivo de # 11902 es recuperar los beneficios de los tipos de valores mutables sin arruinar las cosas.

No estoy seguro de si vale la pena mencionarlo; pero en C / C ++ 'struct' también implica algo sobre el diseño de los datos. Por otro lado, con frecuencia vale la pena reorganizar los miembros de la estructura para obtener un mejor diseño de la memoria. Si está considerando un cambio rotundo en la sintaxis, podría valer la pena tener un mecanismo para diferenciar de alguna manera entre 'estructuras' (ordenadas -> interoperabilidad de C) e 'inmutables (potencialmente podrían ordenarse de cualquier manera).

Soy bastante nueva en Julia, así que lo siento si me perdí algo obvio.

Personalmente, no tengo ninguna preferencia real por los nombres; sin embargo, me sorprende que nadie pareciera haber sugerido "concreto", dado que ya existe "abstracto".

Para agregar otra sugerencia, lo siguiente me parece mejor:

• Utilice struct lugar de immutable .

• Utilice struct! lugar de type . Cuando se habla inglés, esto debería denominarse "estructura mutable".

  • (Quizás) permitir que algunos de los campos dentro de un struct! se marquen como const .

Algunas justificaciones y pensamientos:

1) A menos que me haya perdido algo obvio, nunca querrá usar una función con ! para manipular un valor de un tipo inmutable. Si eso es incorrecto (por ejemplo, si hay un caso importante en el que el tipo inmutable se refiere a uno mutable, y la función con ! cambia), esta sugerencia puede no ser buena.

2) Creo que los tipos inmutables generalmente deberían preferirse a los mutables, ya que están sujetos a más optimizaciones y tienen un comportamiento más predecible para el programador.

3) Para que esto funcione, probablemente sea un requisito previo implementar las optimizaciones para que los tipos inmutables sean al menos tan eficientes como los tipos mutables en casi todos los casos. En particular, el compilador debe ser inteligente al pasar grandes tipos inmutables por referencia.

ACTUALIZACIÓN : Solía ​​tener record lugar de struct , pero record! se parece demasiado a un verbo. Algunas otras opciones que me vienen a la mente: newtype , typedef (que confundirá a los programadores de C durante 10 segundos), composite o concrete como sugirió alguien arriba .

¿Es probable que suceda algo en este espacio antes de que se congele la función v0.6?

Probablemente no, dado que no se ha tomado ninguna decisión (al menos públicamente) y estamos a solo ~ 10 días de la congelación.

No he seguido esto con cuidado, pero un comentario es que si / cuando esto cambie, me gustaría solicitar que primero tengamos un informe realmente bueno del número de línea / archivo ofensivo en su lugar. O al menos el módulo; en 0.5 todavía es a veces difícil incluso averiguar qué paquete tiene @deprecate d _binding .

xref https://github.com/JuliaLang/julia/pull/20418#issuecomment -277475415