Julia: idée folle: changer le mot-clé `type`

Rendre le mot type utilisable dans d'autres contextes serait génial.

J'aime bien mutable pour la cohérence.

Si cela est fait, cela devrait être fait le plus tôt possible afin qu'il puisse être inclus dans 0.6

Si cela se produit, utilisez ce que tout le monde reconnaît avant de penser: struct

Je pense aussi que type est un peu gênant. Quand je l'explique à d'autres personnes, je dis généralement "comme une structure" donc +1 pour ça.

Si cela se produit, utilisez ce que tout le monde reconnaît avant de penser: struct

Je pensais que immutable était comme une structure?

+1 pour mutable

immutable a la disposition mémoire d'une structure C
type a la mutabilité d'une structure C

Ainsi struct est lié aux deux. Je pense que mutable au lieu de struct est préférable de clarifier cela.

Toute variable est modifiable. Attribuer cette étiquette à un nom universellement reconnu (un struct ) semble tout sauf clair pour moi.

Pour quelqu'un venant de Fortran, le mot-clé type est déjà naturel.
Pour quelqu'un venant de C, le mot-clé struct serait naturel.
Pour quelqu'un qui utilise beaucoup immutable , le mot-clé opposé mutable serait naturel.

Alors peut-être devrions-nous le laisser tel quel.

struct{mutable}
struct{immutable}

ou

record{mutable}
record{immutable}

si une forme plus descriptive est souhaitée.

Si nous utilisons struct alors la syntaxe des immuables peut être immutable struct (la partie struct étant facultative au moins initialement).

Je soupçonne que les programmeurs Fortran sont familiers avec le terme «struct».

+1 pour mutable raison de la cohérence. Si struct était choisi, la cohérence ne dicterait-elle pas de changer d'immuable en quelque chose comme const struct ? ;)

Je pense que struct et immutable struct seraient plutôt bons en fait; struct est un terme très familier et nous n'aurions besoin d'ajouter qu'un nouveau mot clé. Autoriser mutable struct peut également avoir du sens, même si ce n'est pas strictement obligatoire.

Je devrais préciser que je pense que struct être un nom est un avantage. Il serait préférable de ne pas utiliser uniquement des adjectifs pour nommer ces choses.

Le fait de devoir ajouter struct à immutable struct ajoute un bruit de ligne inutile, d'autant plus d'avoir été habitué à ne pas avoir à taper ceci.

Otoh, je crois que Fortran a un mot-clé type qui fait quelque chose de très similaire à ce que le nôtre fait. Je ne suis pas opposé à ce que cela change, cependant.

@KristofferC ci-dessus a raison: je me type a été un problème; quelqu'un dira "suppose que x est un type", et il n'est pas clair si cela signifie "chose déclarée avec le mot clé type " ou "type" dans un autre sens.

Si ces noms sont vraiment sur la table ( s/type/new name/ semble légèrement odieux), je suggérerais que nous souhaitons tirer le meilleur parti de cette opportunité pour rendre la déclaration par défaut immuable.
Donc struct remplacerait immutable , et mutable [struct] remplacerait type.

Juste comme une pensée, un autre terme possible pour mutable pourrait également être Ref .

Un autre nom possible serait composite , car un terme CS générique pour cela est un type composite . Mais je préfère toujours mutable Foo et immutable Foo à mutable struct Foo et immutable struct Foo - le struct (ou composite , ou class , ou autre) semble superflu.

: +1: au (x) nom (s)

J'ai toujours aimé type plus que struct en Julia (même si mon arrière-plan est _C_), car les types de données de Julia sont beaucoup plus puissants et subtils et je pense que "struct" pourrait être un peu simpliste pour l'idée. J'ai aussi l'impression que puisque c'est un nouveau langage, nous ne devrions pas être liés par la convention à laquelle les programmeurs chevronnés sont habitués - vous devriez également considérer "quel serait le meilleur mot pour expliquer cela à une personne dont la langue maternelle est Julia".

Je me surprends aussi à dire "struct" en expliquant ce que c'est

Imaginez introduire un nouveau venu dans struct T puis lui dire T::DataType et vous pouvez distribuer en utilisant ::Type{T} , tout en expliquant le "système de types puissant" de Julia. Je pense que c'est juste un coup de pied dans le seau plus loin sur la route.

être un nom est un avantage

: +1: au (x) nom (s)

Il vaut probablement la peine de noter que les adjectifs de la famille de la langue latine comme "mutable" sont grammaticalement également autorisés à être des noms dans leur propre langue. C'est pourquoi, lorsque nous demandons «quelle est la forme nominale de mutable», nous haussons les épaules. Mais nous disons toujours "une variable" et en Julia-speak je dirais "introduisons un immuable pour cela". Malheureusement, cela semble gênant au début à cause des racines germaniques de la grammaire anglaise - mais cela arrive très souvent en anglais (car nous sommes également basés sur le français et le latin) mais on s'y habitue avec le temps.

Enfin, puisque le sujet est une "idée folle", ces mots-clés construisent plus ou moins un nouveau DataType donc pourrions-nous supprimer complètement les mots-clés et utiliser simplement un constructeur?

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

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

Je suppose que ceux-ci devraient être analysés spécialement (statiquement) comme ccall is et ils ne peuvent être appelés qu'au niveau supérieur pour le moment. (Aussi - je ne sais pas si nous aurions besoin de Mutable <: DataType et Immutable <: DataType et BitsType <: DataType pour couvrir toutes les possibilités, et probablement const pour la liaison).

Je pensais qu'immuable était comme une structure?

immutable a la disposition mémoire d'une structure C
type a la mutabilité d'une structure C

Bien ... je pense que je pensais à Swift, où:

C'est la plus grande différence entre les structures et les classes. Les structures sont copiées et les classes sont référencées. ... Ainsi, ils seront passés en tant que valeurs et non en tant que référence dans le cas d'objets volumineux.

ce qui ressemble à immutable vs type , et ce n'est que la référence qui permet la mutabilité dans le contexte de la sémantique des liaisons de Julia.

DataType inclut tous les types nominaux: abstract , bitstypes, structures immuables et mutables. Il n'est donc pas très clair de remplacer type par DataType . Je tire également une conclusion différente du scénario "nouveau venu": ::Type et ::DataType sélectionnent des sur-ensembles des choses définies par type T , donc ce n'est pas fou pour eux d'avoir des noms différents . " struct est un type de Type " a plus de sens que " type est un type de Type ".

Je suis d'accord que les adjectifs peuvent en pratique servir de noms. On peut dire par exemple "ceci est un immuable". Je pense simplement qu'ils ne sont pas suffisamment descriptifs. Plutôt que de vous dire ce que la chose est, cela vous dit simplement que quoi que ce soit, vous pouvez / ne pouvez pas la muter.

J'aime les types structure et mutable structure . peut-être a = 1 et mutable a = 1 pour l'affectation de variables. Partir de l'idée de vouloir de la cohérence, pas d'abréviations et de l'immuabilité par défaut.

Edit: peut-être constant au lieu de const dans la mutabilité par défaut

Ou une version qui implique moins de mots-clés serait struct vs const struct . Rendre toutes les variables const par défaut serait trop perturbateur à ce stade, je pense.

Je pense simplement qu'ils ne sont pas suffisamment descriptifs. Plutôt que de vous dire ce qu'est la chose, cela vous dit simplement que quoi que ce soit, vous pouvez / ne pouvez pas la muter.

C'est un bon point - mais je considérerais le comportement de référencement par rapport au comportement de «valeur» _much_ plus important et intéressant à décrire que «est-ce une structure ou un type de bit?» (principalement parce que bitstype n'apparaît pas très fréquemment - chaque type de Julia que j'ai créé est une structure). L'immuabilité n'est qu'une conséquence de la sémantique de liaison et du passage par valeur.

Pour éviter complètement le besoin de struct vs bitstype nous pourrions également inclure cette idée de @quinnj qui était

immutable 32 Int32 <: Integer

ou vous pourriez avoir des champs non ornés en nombre de bits

immutable Int32 <: Integer
   32
end

qui (en général lorsqu'il est mélangé avec des champs nommés) pourrait également être utile pour insérer un remplissage si nécessaire.

Ensuite, c'est juste un choix entre un type de valeur (ce qui est actuellement immuable) et un type de référence (ce qui est actuellement mutable - mais potentiellement avec des champs const à l'avenir, ce qui est une autre raison de ne pas l'appeler mutable ) et des noms appropriés sont nécessaires pour les distinguer. Et enfin, utiliser struct pour le type de référence de valeur déroutera les programmeurs Swift ...

Il est vrai que bitstype a pratiquement disparu depuis l'introduction de immutable . Mais il y a plus de choses à distinguer que struct et bits: il existe des types abstraits, des tuples (également immuables) et des enregistrements probablement immuables dans le futur.

Nous avons initialement choisi immutable car nous pensions que ce serait la caractéristique distinctive la plus visible: contrairement à d'autres objets, vous ne pouvez pas les modifier. En fait, ils ne sont pas toujours passés par valeur; l'immuabilité signifie que vous ne pouvez pas faire la différence. Certains immutable sont intégrés dans des tableaux et d'autres objets, et d'autres non. L'immuabilité signifie que la différence ne pose aucun problème pour le code julia simple; cela ne devient un problème que lorsque la disposition de la mémoire compte vraiment, par exemple pour l'interopérabilité C.

En fait, ils ne sont _pas_ toujours passés par valeur

Bon point! Cependant, il y a des plans pour changer cela, non?

Je suppose que je dis que vous aurez besoin d'un ensemble de mots-clés à l'épreuve du temps qui reflètent certains concepts à l'épreuve du temps, car nous nous rapprochons de la version 1.0. Lorsque les immuables sont incorporés, il semble que ce soit un moment raisonnable pour les renommer en quelque chose qui est utile en ce qui concerne la sémantique résultante (et si cette sémantique aide avec FFI, c'est encore mieux).

Je ne pense pas que les gens obtiendront de nouveaux mots-clés de définition de type concrets confondus avec abstract , Tuple s et "records" (ce qui, si vous voulez dire la chose de type tuple proposée avec des noms de champ, je pense J'ai aussi entendu parler de "structs" plus tôt ...).

Le vrai but de la notion de "passage par valeur" est de répondre à la question de savoir ce qui se passe quand f(x) modifie (dans un certain sens) x : modifie-t-il la même chose x l'appelant est passé ou la modification est-elle uniquement locale? Julia n'a jamais eu et n'aura jamais (je l'espère), des types, des arguments ou des fonctions qui diffèrent par rapport à ce comportement. Tout est "passe par partage". Pour nous, le passage par valeur n'existe qu'au niveau ABI, mais cette discussion n'appartient qu'à la section FFI du manuel. Je ne suis pas sûr que nous aurons jamais un type de type toujours passé par valeur ou toujours en ligne, car cela peut être pire pour les gros objets.

Quoi qu'il en soit, je pense que immutable et mutable sont des options viables pour les mots clés.

Il est vrai que le bitstype a pratiquement disparu depuis l'introduction de l'immuable

Bien que les individus n'aient généralement pas besoin de créer de nouveaux types de bits, la différence entre les types de bits existants et les immuables communs est très significative au niveau primitif puisque l'ABI pour ceux-ci est assez distincte. Il se trouve que la plupart du temps, les utilisateurs veulent la structure immuable, pas le type de bit, lors de la définition d'un nouveau type de données concret.

FWIW, comme il n'y a pas eu beaucoup de support pour ne pas changer les choses, je pense que type et immutable sont bien tels qu'ils sont.

(La syntaxe do me dérange, cependant ... ;-)

Tout est "passe par partage".

Je peux respecter cela - et merci pour la discussion.

Tout est "passe par partage".

Sur cette note, juste une observation - si nous avions des mots-clés const dans les déclarations de type, alors immutable devient complètement inutile:

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

(le compilateur pourrait déterminer que ce type est automatiquement immuable, et les utilisateurs peuvent comprendre que les types const nous permettent de compiler vers un code plus rapide). Alors type ou struct font sens. setfield! peut être désactivé sur les champs const dans le cas mixte.

Qu'en est-il de type et const type ? - Le mot-clé type me semble plus élégant que struct et avec struct j'associe en quelque sorte une mise en page de mémoire technique et non un objet ~ ayant par exemple des constructeurs internes. Comme le type composite est '... de loin le type défini par l'utilisateur le plus couramment utilisé dans Julia ...', ce n'est peut-être pas si mal si 'type est un type de type'? Dans la communication en utilisant «type composite» devrait clarifier, comme je dirais «type abstrait». En ce qui concerne le bruit de ligne, «type const» n'est pas pire que «immuable».

Je ne suis pas sûr de la (légère) différence dans la signification de const entre les variables et les types. - En tout cas type et immuable m'a toujours donné un petit hoquet mental. C'est bien de voir ce numéro ici!

Le principal problème avec l'utilisation de struct serait que les gens pourraient naturellement faire des hypothèses auxquelles ils sont habitués à partir de C / C ++ qui ne sont pas nécessairement vraies dans Julia, par exemple un type composite mutable n'est pas stocké par valeur dans un tableau alors qu'un immuable est.

Quels paradigmes représentent immutable plus élégamment que type ? Par exemple, "transitionner" atomiquement l'état de plusieurs champs simultanément sans nécessiter de primitives de synchronisation en instanciant un nouveau immuable à partir de l'original avec les champs souhaités mis à jour.

Pourquoi le type devrait-il être séparé en deux catégories distinctes au point de leur définition plutôt qu'au point de leur distribution / utilisation (plus comme const en C ++)? En utilisant uniquement type / struct / composite pour définir des types composites et en introduisant une construction Immutable{T} pour promouvoir mutable en immuable, nous pourrions avoir:

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

De plus, un changement de abstract et bitstype pourrait-il être envisagé ici? AFAICT l'utilisation du terme "abstrait" est un adjectif, pas un nom. Il devrait y avoir au moins une cohérence linguistique entre les mots-clés de type: tous les noms, tous les adjectifs, etc. bitstype pourrait être mieux indiqué comme juste bits ou primitive .

S'il vous plaît, ne transformons pas cela en un fil de discussion ouvert pour discuter des changements d'orthographe (ou de sémantique!) Des mots-clés Julia. À ce stade, le navire a navigué sur le comportement de base de type et immutable . La seule question soulevée ici est de savoir si nous pouvons avoir une orthographe de type et immutable qui reflète mieux leur similitude.

Je continue à prendre en charge mutable vs immutable , ou tout simplement le laisser tel quel, comme les deux options les plus raisonnables à ce stade. Tout le reste serait inutilement perturbateur.

@andyferris J'aime vraiment cette idée; une combinaison de struct et const serait bonne. Si nous allons dans cette direction, je voudrais aussi pouvoir dire const struct ou const type , (1) pour éviter d'avoir à écrire const sur chaque champ, (2 ) afin que nous n'ayons pas à ajouter la nouvelle fonctionnalité d'immuabilité par champ tout de suite. Si jamais nous voulons ajouter cette fonctionnalité, il serait bon de disposer d'un vocabulaire cohérent.

Dans la communication utilisant le `` type composite '' devrait clarifier

L'une de nos techniques préférées pour nommer a été d'expliquer une chose à quelqu'un en une phrase, puis de choisir le mot ou deux qui semble faire le plus de travail. Donc, pour moi, ce serait un vote pour composite .

Pourquoi le type devrait-il être séparé en deux catégories distinctes au point de leur définition plutôt qu'au point de leur distribution / utilisation (plus comme const en C ++)?

C'est simple: offrir des garanties globales. En C ++, un objet "const" peut encore changer sous vous si quelqu'un a une référence non-const.

De plus, pourrait-on envisager ici un changement vers l'abstrait et le type de bits?

Faire une proposition. Quant à bitstype , le mot-clé est très rarement utilisé donc je ne voudrais pas voler un petit mot utile comme bits pour cela.

immutable -> const type me semble également correct. Combiné avec type -> composite ou struct , si nous voulons vraiment libérer type .

Je ne suis pas très heureux de tout le désabonnement de code que cela entraînera, d'autant plus qu'il ne peut pas être pris en charge par @compat , cependant. Si nous devons faire cela, je pense que le chemin de mise à niveau devrait être quelque chose comme (1) introduire de nouveaux synonymes de mots-clés dans la version 0.6 mais _ne pas_ déprécier les anciens (à cause du manque de @compat ), alors (2) obsolète les anciens en 0.7.

Pour bitstype , que diriez-vous d'appeler cela un type primitive ? Le nom actuel est un peu ennuyeux en raison de sa similitude avec an isbits composite type

J'aime la façon dont Julia a souvent évité certaines des abréviations de style "def / func / elif" de certaines autres langues. (Dn w abrévs, kthx.) Donc mutable emporte sur struct pour moi.

FWIW, OCaml utilise type pour les enregistrements et les variantes (structs et unions) et les alias. Le ML standard utilise datatype je pense.

La symétrie est agréable, mais je trouve que mutable n'est pas suffisamment descriptif; immutable aussi, d'ailleurs (j'aime l'idée de const type ).

Comme Steve le souligne, cela entraînera une très mauvaise rotation du code dans la communauté. Et l'avantage est douteux.

Je vois certainement le cas pour const type ; ce serait le mot-clé net -1, et clarifierait la relation entre type et immuable. Ce serait vraiment bien de pouvoir utiliser type d'une autre manière. Sans cet avantage, il est beaucoup plus difficile de justifier un changement. Cependant, la mise à jour du code devrait être très simple; la syntaxe de type est telle qu'elle ne peut être utilisée dans aucun autre contexte.

+1 pour composite / const composite .

J'ai le sentiment que primitive vs composite est un excellent différenciateur, avec des mots-clés const ajoutés si nécessaire.

Avons-nous besoin de const primitive pour distinguer certains bits qui peuvent changer (et pour la cohérence)? Donc symétriquement nous aurions

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

Le problème étant un type primitif mutable devrait être implémenté ... (bien sûr, cela pourrait éventuellement être à une date ultérieure, mais nous voudrions bitstype -> const primitive _now_ si cela se passait pour devenir une chose. Pour être plus simple, cela pourrait être une bonne cible de «pratique» pour amener les mutables à la pile, mais je ne suis pas un expert en la matière).

De même, l'idée d'ajouter const à des champs individuels d'un composite peut facilement être implémentée à une date ultérieure, et mieux encore, c'est un changement sans rupture.

Si nous allons dans cette direction, je voudrais aussi pouvoir dire const struct ou const type, (1) pour éviter d'avoir à écrire const sur chaque champ, (2) afin que nous n'ayons pas à ajouter la nouvelle fonctionnalité de immuabilité par champ tout de suite. Si jamais nous voulons ajouter cette fonctionnalité, il serait bon de disposer d'un vocabulaire cohérent.

Cela me semble parfaitement sensé.

J'ai recherché le type de données composite et j'ai trouvé qu'au moins Ada et Visual Basic subsument également les types de tableaux en dessous. (Sinon, un peu au hasard, trouvé: Haskell: listes et tuples (cependant une définition a été demandée); Python: listes, tuples, dicts; Lisp: listes, vecteur, tables de hachage, classes définies par l'utilisateur, structure).

Ainsi je me demande maintenant à quel point le composite est précis pour le type plutôt structure-like? (Mais je ne suis pas informaticien, je manque de vocabulaire / de vue étendue).

Hmm, cela pourrait être juste: ce type particulier de type semble toujours être appelé une structure, une structure ou un enregistrement (ou une classe ou un objet), avec "composite" étant un terme plus large. Il existe de nombreux exemples sur http://rosettacode.org/wiki/Compound_data_type

Ce serait bien de récupérer type comme identifiant et d'utiliser un nom plus spécifique. La rupture de presque tous les paquets triviaux écrits avant ~ 0.6 serait super malheureuse, je ne sais pas comment peser cela.

L'idée de réutiliser le mot-clé const est assez convaincante car elle met l'accent sur l'équivalence des liaisons de variable const à portée globale avec les liaisons const des champs à l'intérieur des immuables. Cela semble être une bonne unification et une meilleure dénomination que immutable .

Quant aux noms à remplacer type , struct semble assez bien éviter toute ambiguïté (je trouve souvent que les expressions «un type mutable» et «un type immuable» semblent trop similaires).

Ce qui suit semble assez joli je suppose:

struct A
    a::Float64
end

const struct B
    b::Float64
end

Ce serait bien de récupérer le type comme identifiant et d'utiliser un nom plus spécifique.

Je fais écho à ce sentiment.

Si nous allons changer de nom, comment la dépréciation serait-elle gérée? Est-ce que type et immutable seront toujours valides dans 0.6 et probablement 1.0 avec des avertissements? Peut Compat.jl gérer cela de manière transparente. Un peu de littérature sur le net (articles de blog, tutoriels, etc.) affichera des avertissements - des ennuis mineurs pour un nouveau venu.

Nous pourrions encore réserver type et immutable plus longtemps que d'habitude pour faciliter la transition.

Nous sommes pré 1.0: le temps de changer cela est maintenant ou jamais. Avoir l'ancien mot-clé plus disponible est certainement bon pour assurer une transition en douceur. Je ne confondrais pas la discussion sur la dénomination réelle avec la douleur que la transition impliquera.

Personnellement, je suis tout à fait d' struct pour l'appeler

Je ne confondrais pas la discussion sur la dénomination réelle avec la douleur que la transition impliquera.

Si le changement est trop douloureux, je voterais contre le changement. Bien qu'un changement pre1.0 soit justifiable, il est judicieux pour l'OMI de le comparer à toute perturbation causée.

@stevengj avait une bonne suggestion sur la façon de @amitmurthy soit arrivé à la même conclusion (gardez les mots-clés plus longtemps que nous le ferions normalement). Bien que nous utilisions tous ce langage depuis un certain temps, nous n'en sommes encore qu'à nos débuts et nous ne devrions pas avoir peur de faire le changement. Celui-ci est simplement une recherche et un remplacement faciles.

Je vais aller de l'avant et voter pour struct . Je pense que c'est l'un de ces changements qui créera beaucoup de buzz et de plaintes, mais il n'est en fait pas très difficile de corriger les paquets / le code utilisateur ... faites-le et les gens le comprendront.

immutable -> const type semble être le chemin de moindre résistance, et l'OMI devrait certainement être fait. Je pense que cela explique les choses beaucoup mieux.

type -> composite est plus précis que type mais moins précis que struct , tout en étant moins jargon-y que struct (à nouveaux programmeurs). Il réussit le test d'écriture d'une phrase de Jeff pour l'expliquer à un débutant et récupère le mot clé type . En revanche, je ne pense pas que composite apparaît dans d'autres langues, alors nous faire cavalier seul.

type -> struct est le plus précis, mais peut-être structure serait plus joli qu'une abréviation (j'essaie de penser à une abréviation aussi moche que struct ailleurs dans la langue et est venu vide - je suppose que eye() est une tradition assez dégoûtante du point de vue de la langue anglaise).

bitstype -> primitive sens si type est modifié.

@tbreloff a raison - les développeurs de base ont fait preuve de bon goût dans le passé et, à la fin, les gens suivront leur exemple. Faites-le vite!

Je me demande si, puisque immutable devrait être la norme à moins que vous n'ayez explicitement besoin de muter, si le changement de nom devrait être:

• immutable -> struct
• type -> mutable

Ensuite, le nom commun / attendu est la meilleure pratique, et il existe un nom explicite et clair pour demander la mutabilité.

J'aime aussi bitstype -> primitive ...

Je ne pense pas que const devrait être la valeur par défaut. Les optimisations qui réduisent les fonctionnalités ne doivent pas être la valeur par défaut.

+1 pour struct et const struct .

Le terme composite est un peu plus descriptif mais struct est court et très communément appelé type composite.

Je préfère ne pas voler un vrai mot pour quelque chose d'aussi rarement utilisé que bitstype . Peut-être primtype ou primitivetype ?

Si nous n'allons pas changer bitstype en un nom clairement meilleur comme primitive alors je pense que le laisser tel quel serait probablement mieux.

-1 à struct . Je n'utilise pas ce terme pour expliquer ce qu'est une définition de type à moins que je ne parle à un programmeur C, et seulement pour mentionner que la mise en page est compatible et pour comparer / contraster leurs propriétés.

-1 à const . C est allé dans cette direction en ayant des mots-clés absolument minimaux, et maintenant nous sommes coincés avec de nombreux mots-clés ayant une signification contextuelle. Je ne pense pas vraiment que const soit la propriété clé de ces types, mais plutôt qu'il s'agit de types valeur (par opposition aux types référence).

Dans une autre direction, pourquoi ne pas utiliser le mot-clé 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`

Le problème avec le «type de valeur» est que c'est quelque chose que seules les personnes qui connaissent assez bien la langue peuvent comprendre. Pour les nouveaux utilisateurs, le fait que les champs soient immuables est le fait _sémantique_ auquel ils sont immédiatement confrontés; tout le reste est un détail de mise en œuvre. Donc je préfère const .

Je vois où vous allez avec record , mais honnêtement je pense que cette terminologie est encore moins courante que struct (même si vous google "record type ruby" vs "struct type ruby", ou remplacez python ou perl ou certains autre langage non-C). Il y a aussi le problème que record est un mot anglais assez utile qu'il serait dommage de réserver comme mot-clé, alors que struct n'est probablement pas nécessaire pour autre chose dans un programme.

struct est très couramment utilisé; en regardant par-dessus le rosettacode, il est utilisé par:

algol, C, C #, C ++, lisp, D, élixir, aller, aller, maxima, raquette, rouille, seed7, swift, visual basic ( structure )

record est utilisé par:

ada, clojure, delphi, pascal, erlang, icône, modula-2, certains schémas

record semble être préféré dans les langues plus anciennes; ces jours-ci, la programmation fonctionnelle étant devenue plus populaire, elle a tendance à se référer aux enregistrements structurellement typés.

Il est intéressant de noter que seed7 utilise new struct .

Un peu triste de voir struct (les trois lettres supplémentaires pour compléter le mot sont-elles vraiment si mauvaises?) En faire une langue qui a jusqu'à présent eu function au lieu de func , etc. Ce n'est pas quelque chose que quiconque rejettera une langue, mais quand même ...

structure est en fait utilisé en PL / I et en visual basic. VB a également structure immutable . Cependant, struct est si courant que je sens qu'il est presque devenu un nouveau mot en soi.

Je me demande s'il y a aussi un problème de langue maternelle ici. Pour moi, qui suis très habitué au mot struct dans ce contexte, c'est structure qui me semble plus étrange. Pour la même raison, func semble horrible et function naturel.

struct n'est-il pas devenu un terme autonome en raison de son utilisation dans divers langages de programmation? Le mot structure est (du moins pour moi en tant que natif allemand) beaucoup plus abstrait. Par exemple, cette hiérarchie de types a une certaine «structure».

func n'est pas pour moi un terme autonome mais juste une abréviation.

func n'est pas pour moi un terme autonome mais juste une abréviation.

En quoi struct n'est-il pas seulement une abréviation? N'est-il pas littéralement synonyme de structure ou ai-je simplement mal compris le terme? Vous y êtes juste plus habitué que func . Beaucoup de choses sont des "termes autonomes" et communs à de nombreuses langues, mais cela ne signifie pas nécessairement que Julia devrait suivre une tradition s'il vaut mieux ne pas le faire. Ensuite, c'est juste une lutte pour ce qui est meilleur ou pire, et c'est à peu près une question de goût.

Quoi qu'il en soit, je préférerais mutable , donc je me fiche de _too_ profondément si c'est struct ou structure. mutable éviterait d'écrire const tout le temps pour ce qui est maintenant immutable .

Mais, même si cela finit par être struct ou même strct ou stct ou strctr il est très peu probable que je change Julia pour une autre langue pour mon travail, alors ... :)

Désolé si cela n'a pas de sens en anglais: Mais struct n'est-il pas une abréviation de construct . Au moins en allemand, le mot Konstrukt beaucoup plus de sens pour décrire ce qu'est un type composite.

En anglais, le fait de ne pas pouvoir dire si construct est un nom ou un verbe a probablement empêché son utilisation dans les langages de programmation basés en anglais :) L'utilisation allemande des majuscules y est utile.

struct est son propre mot de la même manière que TV, ASAP et LOL sont des mots. J'entends rarement les gens dire «structure». D'après mon expérience, le mot est «struct» à la fois parlé et écrit.

BTW: Matlab utilise le mot struct , si cela fait une différence.

OTOH, comme indiqué ci-dessus, en C # et Swift struct correspond à un type valeur (par opposition à class ). Donc, utiliser une terminologie similaire pour les types mutables et immuables n'aiderait pas vraiment les personnes familiarisées avec ces langages. Je ne sais pas si c'est un point décisif ...

mutable / immutable sonne comme le choix le plus explicite, ce qui devrait être assez évident pour les nouveaux arrivants.

Étant donné le grand nombre de langues différentes qui utilisent struct , je ne pense pas qu'une sémantique identique soit nécessaire pour utiliser ce nom.

J'aime type et const type le meilleur, mais cela ne libère pas le mot-clé type . Comme je ne sais pas ce qui est prévu pour type , je ne sais pas quel est le coût.

Mais comme la partie type est déjà implicite dans abstract , peut-être utiliser mutable et immutable par eux-mêmes est le plus logique. Et c'est moins typant que immutable struct et un petit changement (type -> mutable).

la structure des mots est (du moins pour moi en tant que natif allemand) beaucoup plus abstraite.

Pendant que nous nous disputons sur la langue, tout le monde sous-estime la quantité d'abréviation qui est de struct . C'est l'abréviation de «structure de données». De même, je dirais que type est l'abréviation de "type de données". J'ose dire qu'un tableau ou un tampon est aussi une structure de données, tout comme une liste chaînée, et ainsi de suite, mais struct a ses premières racines comme l'une des premières structures de données communes et dans l'informatique, il en est venu à avoir un une signification plus spécifique (et donc pour les programmeurs natifs de l'anglais ou autre, cela ne semble pas aussi abstrait que structure ).

-1 à struct . Je n'utilise pas ce terme pour expliquer ce qu'est une définition de type à moins que je ne parle à un programmeur C, et seulement pour mentionner que la mise en page est compatible et pour comparer / contraster leurs propriétés.

Je ressens exactement la même chose à propos de struct . Je pense que nous allons introduire un nouveau terme pour Julia sans raison particulière.

-1 à const . C est allé dans cette direction en ayant des mots-clés absolument minimaux, et maintenant nous sommes coincés avec de nombreux mots-clés ayant une signification contextuelle. Je ne pense pas vraiment que const soit la propriété clé de ces types, mais plutôt qu'ils sont des types valeur (par opposition aux types référence).

Jeff m'a expliqué (très gentiment) ci-dessus que sémantiquement, nous ne nous soucions pas de savoir si les choses sont des valeurs ou des références ou autre - ce sont des détails d'implémentation et non de la sémantique et dans un futur âge d'or, nous ne nous en soucierons pas. Les choses sont «passées par partage» de la manière voulue par le compilateur (avec certaines garanties FFI si nécessaire). Au cours des derniers jours, j'ai déjà appelé cela "partager par magie" et je pense que cela a été une révélation pour moi soulage un tas de pression mentale à laquelle (idéalement) je ne devrais pas avoir besoin de penser ( @vtjnash vous avez vu comment j'ai eu du mal avec les valeurs et les références et comment celles-ci sont implémentées par le compilateur et GC et ainsi de suite dans d'autres packages et threads).

Les liaisons peuvent changer ou être constantes (nous utilisons const mais constant est également assez mignon). De même, les liaisons des champs à l'intérieur d'un type de données composite peuvent changer ou être constantes. C'est pourquoi j'ai suggéré plus tôt d'attacher explicitement const à chaque champ - cela rendait la sémantique limpide (du moins pour moi).

OMI, nous ne devrions pas avoir besoin d'utiliser des mots fantaisistes comme «mutabilité» et «immuable» pour parler de ces choses. Quelque chose peut être rebondi vers un nouvel objet, ou bien il est constant. Supprimer complètement le besoin de mots complexes en anglais comme struct et immutable de notre discours sur Julia (pas seulement le code) devrait être considéré comme une bonne chose (même un objectif).

J'ai aussi l'impression que "struct" est son propre mot (ce qui signifie ce qu'il signifie en C) alors que "structure" est probablement une "structure de données" - parce que si vous vouliez dire un type d'enregistrement, vous diriez "struct". Mais je montre mes racines C ici.

C'est aussi en commun lisp; defstruct .

Probablement plus trivial que la plupart des autres points ici, mais tant que nous faisons du vélo: Lorsqu'ils sont prononcés à haute voix, les phrases immutable object et a mutable object sonnent ennuyeusement similaires. Cela rendrait la conversation sur le système de types de Julia plus difficile que nécessaire. EDIT: Il semble que cela ait déjà été évoqué dans ce fil .

+1 à type -> struct et immutable -> const struct . Je ne pense pas avoir rencontré quelqu'un qui serait dérouté par cela, surtout après une explication superficielle.

Le remplacement de type est réaliste pour la v0.6 et irréaliste pour la v0.8. On devrait faire ça. C'est l'occasion de rendre plus fluide et d'améliorer le talent naturel de Julia pour une communication claire et une rapidité expressive. Les types fonctionnent tellement bien pour créer des logiciels qui fonctionnent. Une meilleure dénomination des choses typiques résonne fortement et portera pour Julia un avenir plus riche.

Je suggère de laisser struct inutilisé. En C, une structure est un conteneur syntaxique pour une séquence fixe de champs à type fixe. Julia n'est pas C, et tirer un C-isme dans le discours julien pousserait la nature épiphémère de Julia en dehors d'une discussion sérieuse sur les meilleures utilisations et les meilleures façons de conceptualiser des aspects de Julia.

De plus, «immuable» et «mutable» sont trop concordants visuellement. On peut faire mieux.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff En normes de la

@ararslan Le guide standard de la communauté sur Julia semble avoir changé, évitant maintenant l'application des pronoms littéraires. Merci d'avoir attiré mon attention là-dessus. :criquet:

L'utilisation du pronom féminin n'est pas mal en soi (et inévitable dans de nombreuses langues), mais il semble que beaucoup trouvent irrésistible de passer de l'utilisation du terme «elle» à celle de parler de Julia comme d'un rendez-vous chaud, il semble donc préférable de éviter la tentation autant que possible.

THX

Le jeu.3 novembre 2016 à 16:29, Stefan Karpinski [email protected]
a écrit:

L'utilisation du pronom féminin est, en soi, pas mal (et inévitable dans de nombreux
langues), mais il semble que beaucoup trouvent irrésistible de ne plus utiliser
le terme «elle» pour parler de Julia comme d'un rendez-vous chaud, il semble donc préférable de
éviter la tentation autant que possible.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

En ce qui concerne le problème en question, je suis personnellement indécis sur ce que je considérerais comme le meilleur changement. Mais il me semble étrange de parler du système incroyable de _type_ de Julia et de spécifier ensuite que le mot clé utilisé pour construire un type est en fait struct plutôt que type . Je pense que cela pourrait encourager les gens à parler des types comme des structures à la place, conduisant finalement à un changement dans le langage utilisé pour décrire Julia, par exemple en discutant du système incroyable de _struct_ de Julia.

le mot clé utilisé pour construire un type est en fait struct plutôt que type

Mais le mot clé ne concerne pas vraiment la construction de types - par exemple, l'expression Tuple{Int} construit également un type. Ce serait génial si les choses actuellement définies avec type étaient toujours appelées struct s, car il n'y aurait aucune confusion quant à la façon dont Real est un type, et Union{Int8,Int16} est un type, etc.

oui, je suis en train de modifier ma note précédente et je viens d'écrire à ce sujet. Ce serait
préjudiciable aux «soins et à l’alimentation» de Julia et de la
développement futur de la puissance expressive et de la concision. La porte devrait-elle être
ouvert pour rendre légitime la considération du système de types de Julia comme
échafaudage sur des structures C, la guerre est perdue.

Le jeu 3 novembre 2016 à 16:38, Alex Arslan [email protected]
a écrit:

En ce qui concerne le problème, je suis personnellement indécis sur ce que je
envisagerait le meilleur changement. Mais ça me semble étrange d'en parler
L'étonnant système _type_ de Julia, puis spécifiez que le mot clé utilisé pour
construire un type est en fait une structure plutôt qu'un type. Je pense que ça pourrait
encourager les gens à parler des types comme des structures à la place, ce qui
à un changement dans le langage utilisé pour décrire Julia, par exemple en discutant de Julia
système _struct_ étonnant.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

Ce serait formidable si les choses actuellement définies avec type étaient toujours appelées struct s, car il n'y aurait aucune confusion quant à la façon dont Real est un type, et Union{Int8,Int16} est un type, etc.

Y a-t-il une confusion à ce sujet actuellement? Je suppose que cela me semblait évident, même si j'ai peut-être raté des discussions à ce sujet.

@ararslan : Le terme type est juste beaucoup trop générique pour ce qui est actuellement construit. Ce que nous construisons actuellement avec le mot clé type est une structure composée de types composites. Mais il existe de nombreux autres types dans Julia qui ne sont pas construits à l'aide du mot clé type .

Non, je ne pense pas qu'il y ait trop de confusion à ce sujet actuellement, mais tout le monde ne penserait pas non plus que tous les types julia sont des structures si nous utilisions le mot-clé struct .

D'accord, bon point.

et Union {Int8, Int16} est un type

Ah. J'avais oublié que Union existe aussi. Ce qui rend l'argument pour struct ( Struct ?) Plus convaincant, IMO. Je n'aime toujours pas mutable et immutable cependant.

Je trouve _struct_ ignominieux et je crois vraiment qu'y porter Julia entraînerait, avec le temps, le vent en évolution vers le bas. Le principe est un antagonisme entre l'exposition de bits en mouvement et l'expression de maybes informatiques en tant que mélanges d'ordre supérieur et gestalts plus profonds. Le fait d'utiliser struct ne conduirait pas tout le monde à penser aux types d'une structure n'est pas pertinent. ... laissez-moi dramatiser ...

Je ne peux pas affirmer qu'écrire sur Einstein en tant que commis aux brevets diminue l'appréciation de ses contributions. Il ne s'ensuit pas que, dans un cours où les références à Albert Einstein temphasent l'importance de son temps en tant que commis aux brevets, plus d'un petit nombre d'étudiants en donneraient un sens dans une conversation future. Qu'une chose soit so ne garantit pas qu'elle se comporte seulement so après avoir déménagé dans une nouvelle école.

S'il existe un cas convaincant pour l'utilisation de _struct_, il devrait y avoir un meilleur cas pour l'un des

a structure est une interrelation significative de parties, une composition informée
a construct est une structuration utile de la pertinence, un design valorisant

un structure immuable est un composite perdurant
un mutuable structure est une prédélection non fixée
un construct immuable est une éventualité établie
un mutable construct est une contrainte intentionnelle sur le contexte

Nous avons besoin à la fois de la façon de parler «bits dans les lieux et à travers les portes» et la «structuration des données révèle des informations ontologiques» et qui peuvent être rendues disponibles comme façon de parler modificateur de transformation. Les participants de la communauté qui sont des talents CS et la plupart des autres experts du domaine qui programment dans le large ont une maîtrise approfondie des octets, de la mémoire, de la logique, des opérations instruites, etc. L'autre façon de faire du désir, de la créativité, des possibilités et de l'imagination un logiciel qui fonctionne bien et est vaut bien le travail - qui est moins partagé. Toute décision concernant la dénomination des termes doit être prise pour encourager ce discours.

Qu'en est-il de class et immutable ?

Je connais la classe de Delphi et je pensais que ce serait impossible ici, mais dans le langage niçois, qui a plusieurs méthodes, il est utilisé comme mot-clé ( lien ). Et - si je lis correctement les manuels - également dans Haskell et Dylan. Il passe le test "classe est un type de type" et est encore assez vague (comme "type" aujourd'hui), ce que j'aime. Dans la vidéo `` Un aperçu des tableaux et des itérations '' à 15:00 - 15:20 min, Tim Holy dit (accidentellement) `` classe '', un détail sans importance mais montre néanmoins peut-être que la classe ne serait pas totalement étrangère dans le contexte de Julia.

Sinon, reftype et immutable ? Le terme reftype a été mentionné dans le commentaire initial et a été ignoré depuis. Pourquoi? Pour moi, cela sonne assez bien, libère le type et transporte le sens de référence.

(Je n'ai pas compris le but du mot clé "nouveau". Le mot "nouveau" ne pouvait-il pas être omis dans toutes les lignes sans changement? Les termes "valeur" et "enregistrement" seraient des mots clés et remplaceraient le terme "immuable" actuellement utilisé et 'type', non?)

@swissr, la seule différence (dont la plupart des utilisateurs doivent être conscients) entre ces deux types est que les champs de l'un peuvent changer et ceux de l'autre ne le peuvent pas. Il serait logique que leurs noms indiquent leur seule distinction sémantique. (Comme mentionné, les implémentations utilisant des valeurs et des références sont fluides - par exemple, un compilateur amélioré peut passer automatiquement de gros types isbits par référence en tant qu'optimisation, et inversement de petits mutables peuvent se déplacer vers la pile dans certaines situations).

Concernant type vs struct , je vois que je peux créer des types de données abstraits avec abstract , Union{} , typealias et ainsi de suite ( dans le cas de Tuple{} c'est discutable s'il s'agit d'un nouveau type ou simplement d'un type paramétré), mais vraiment les seuls _ types concrets définis par l'utilisateur_ sont créés par bitstype , type et immutable . La syntaxe de ceux-ci est indubitable par rapport aux définitions abstraites en ce sens qu'elles définissent les données qu'elles contiennent d'une manière ou d'une autre, et les données abstraites ne le font pas. Changer immutable en const type me semble clarifier la situation.

Je m'inquiète du langage et de la propagation du mot technique struct avec la seule raison étant la tradition, lorsque nous avons l'occasion de créer un langage de programmation qui est discuté en termes simples. Un exemple où je pense que cela n'aidera pas est lorsque je crée un type de wrapper comme Symmetric{Matrix{T}} - Je ne veux pas que mes discussions soient, "J'ai créé ce struct avec un seul champ qui ... "quand je peux dire" j'ai fait un Symmetric wrapper type pour Matrix "(notez que la moitié de cette phrase est une syntaxe réelle). Une "structure wrapper"? Cela semble un peu idiot - et qui crée une structure avec un seul champ? D'ailleurs, qu'en est-il des singletons sans champs? Une fraction non négligeable de types et immutables n'est pas définie pour créer une structure de données (non triviale) mais plutôt dans le but exprès d'utiliser le puissant système de type et de répartition avec des wrappers et des singletons. IMO c'est l'aspect le plus intéressant, le plus puissant et le plus expressif de Julia (combiné au fait qu'il est _fast_).

Je pense que toute la puissance de struct ne serait immédiatement apparente que pour les métaprogrammeurs expérimentés en modèle C ++ qui savent qu'ils peuvent implémenter des traits, etc., avec des structures, et c'est un peu dommage.

«Kind» a une signification technique assez spécifique dans la théorie des types.

Si l'objectif / avantage est de libérer type alors que diriez-vous:

const datatype  # immutable
datatype        # type

Ce sont des types concrets donc ils contiennent probablement des données, et c'est une (parmi tant d'autres) façons de construire un DataType .

«Kind» a une signification technique assez spécifique dans la théorie des types.

L'introduction au wiki ressemble exactement à Type{} (qui accepte DataType et TypeConstructor , Union , etc.) (EDIT: pas que je pense un tel changement vaut la perturbation)

kind n'est pas le bon mot ici.

Je pense que le plus souvent, la meilleure approche consiste simplement à apprendre un domaine
vocabulaire standard au lieu d'essayer de le remplacer par quelque chose que vous
deviner sera plus facile.

Cette décision n'affecte pas le discours informel. Vous pouvez toujours dire raisonnablement "je
défini un type ". L'utilisation d'un mot-clé plus spécifique facilite simplement la
vous devez être précis.

Bon point, Jeff. Veuillez noter que je pense que const struct et struct seraient une amélioration par rapport à immutable vs type (mais cela ne veut pas dire que nous ne devrions pas rechercher quelque chose d'encore mieux).

Quand vous pensez que struct est-ce perçu plus comme une structure ou comme une construction, ni ni ni les deux?

@andyferris mon const struct et struct seraient une amélioration. C'était une autre tentative pour rechercher des termes possibles lorsque vous vouliez éviter `` const '', préserver `` immuable '' et garder `` struct '' (était au courant de l'implémentation mentionnée mais pensait que si elle est correcte dans 80% des cas, c'est ok) .

Que diriez-vous de fieldtype (ou fieldstype )? Il est parallèle à bitstype et cohérent avec fieldnames() .

Glen,
J'aime la vraisemblance. fieldstype est le meilleur choix car l'utilisation d'une forme plurielle où quelque chose peut être singulier ou pluriel est appropriée.
--Jeffrey

class pourrait être correct; nous l'avons initialement rejeté en raison de son association avec l'OO basé sur les classes avec des méthodes à l'intérieur des objets. Je dirais que struct est plus précis.

Je ne vois pas struct comme court pour quoi que ce soit; c'est exactement ce que l'on appelle ces types de structures de données à ce stade. De façon assez amusante, lisp a cons , qui peut être à l'origine une abréviation pour construct , mais les gens l'ont oublié assez rapidement et ont juste commencé à parler de "cellules contre".

Je pense que nous devrions continuer à rejeter class . L'utilisation de ce terme inviterait toute une série d'attentes OOP qui vont à l'encontre du style Julia.

Je ne vois pas struct comme une abréviation de quoi que ce soit, mais je crains que la référence implicite aux structures de C implique que celles de Julia seraient des types valeur, ce qui n'est pas le cas, bien sûr. Pour cela, je penche actuellement un peu vers record car il a beaucoup moins de connotations immédiates.

Pour clarifier un point qui n'est peut-être pas clair, je pense que l'utilisation de const record ou const struct n'est viable que si elle est interprétée dans le sens d'abréger le mappage de const sur tous les champs , ce qui implique que nous souhaitons prendre en charge le marquage des champs individuels comme const . Donc, ce que je dis, c'est que nous pourrions avoir ceux-ci:

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

Ici, T3 et T4 décrivent en fait des types équivalents - ie écrire const record est juste un raccourci pour tous les champs étant const . Si ce n'est pas l'interprétation, je pense que la confusion entre l'immuabilité et la constness est un peu dangereuse car c'est déjà une source courante de confusion conceptuelle et si nous ajoutons à cette confusion terminologique, nous n'allons pas aider les choses.

Ici, T3 et T4 décrivent en fait des types équivalents - c'est-à-dire que l'écriture d'un enregistrement const n'est qu'un raccourci pour tous les champs const.

Si nous faisons en sorte que const record signifie ce que immutable signifie maintenant, cela pourrait ne pas être vrai. const record décrirait un type de référence pour lequel aucun des champs ne peut être modifié. Alors que le courant immutable est un type valeur.

Voir https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 et le commentaire suivant pour une discussion sur record .

@vtjnash C'est un bon point, mais c'est similaire à ce qui se passe maintenant où un immutable devient un type "référence" s'il contient des références.

Je pense que le fait que record soit moins courant est correct, le fait que ce soit un mot utile à la fois comme nom et comme verbe est plus problématique.

Que diriez-vous de nuple ? Abréviation de "tuple nommé", bien sûr.

J'aime la suggestion faite ci-dessus de

const datatype  # immutable
datatype        # type

meilleur jusqu'à présent. Cela évite de ramener un vieux mot avec un bagage historique et me semble tout à fait clair. Bien sûr, ce n'est pas le seul type de données de Julia, mais c'est le plus courant défini par les utilisateurs normaux.

Est-il prévu de changer également la terminologie pour expliquer cela dans la documentation, plus précisément de changer les titres de chapitres comme celui-ci ? Sinon, je pense que j'aime mieux composite et immutable composite ou const composite . Puisque const est également utilisé pour les constantes globales, je choisirais soit const ou immutable pour les deux, avec une légère préférence pour const car c'est plus court. Au moins, le mot composite ne semblera pas familier à la plupart des nouveaux arrivants, ce qui oblige à regarder la documentation et évite les fausses hypothèses dues à la similitude avec un nom C. Les fausses hypothèses concernant const semblent moins probables, puisque quiconque est habitué à cela en C ++ sait ne rien supposer.

De plus, l'avantage d'utiliser deux mots pour indiquer l'immuabilité libère un futur possible const abstract et const bitstype si le besoin se présente.

Si nous faisons en sorte que const record signifie ce que signifie immuable maintenant, cela pourrait ne pas être vrai. Const record décrirait un type de référence pour lequel aucun des champs ne peut être modifié. Alors que l'immuable actuel est un type valeur.

Oh oh. Je pensais que la valeur ou non de immutable était définie au niveau de l'implémentation, et tout ce que l'utilisateur est censé prendre en compte est que les champs ne peuvent pas être rebondis. Passer par valeur (ou non) est alors un pur problème ABI, où le compilateur devrait en principe être libre de choisir ce qui est le plus efficace. Pour moi, la sémantique visible par l'utilisateur d'immuable semble exactement équivalente à l'application de la sémantique actuelle de const à tous les champs d'un type.

Suis-je encore confus au sujet de la sémantique de niveau utilisateur prévue pour immuable, ou parlez-vous des détails d'implémentation ici?

Et nuple? Abréviation de "tuple nommé", bien sûr.

Peut-être aussi bien utiliser record , non? Par exemple, un tuple nommé est ce qu'est un record dans Erlang. Et je pense aussi dans le monde des bases de données.

Mais si Julia a plus d'un chevauchement avec des gens qui savent aussi C , struct est un changement plus approprié.

Personnellement, je trouve record bizarre et peu clair. Dans le monde des bases de données, un enregistrement est une ligne dans une table; cela semble être un conflit déroutant avec quelque chose d'aussi général qu'un type Julia (immuable ou non).

Après avoir relu ce fil, je me penche vers composite pour type . Il maintient Jeffs "règle d'une phrase" et il n'y a pas eu autant de votes négatifs pour cela. Que le terme ne soit pas tellement utilisé dans d'autres langues n'est pas un problème à mon avis. Et composite est vraiment le mot le plus descriptif que l'on puisse trouver pour cela. C'est la raison pour laquelle la documentation fait référence à ces choses comme composite types .

Venant de Fortran, je pense toujours que le mot-clé type est très bien,
et un changement raisonnable minimum serait immutable -> const type .

Mais si type doit vraiment partir,
composite et const composite semblent être les meilleurs choix suivants.

immutable -> const type semble certainement viable: cela évite à la fois les perturbations, supprime un mot-clé et ajoute de la clarté au langage.

Il peut être triste de ne pas pouvoir utiliser type mais pour être honnête, celui que je veux utiliser est de toute façon Type . Neuf fois sur dix, mes variables de type sont des paramètres pour la distribution statique et non des variables DataType pour l'analyse de type dynamique (l'exception étant les fonctions générées). Ce n'est pas vrai pour les gens qui écrivent inference.jl mais ils ne sont pas vraiment le «public cible» de la langue, si vous voulez.

Question connexe: est-il vraiment viable d'utiliser type tel quel au niveau supérieur, mais à l'intérieur d'une fonction (où il est toujours invalide, actuellement), lui permet-il d'être un nom de variable? Ou encore plus, la structure d'une définition de type est assez spécifique ... pourrions-nous détecter les définitions de type comme syntaxe spécifique tout en permettant même aux variables globales (ou fonctions) d'être liées à type ?

Ie peut-on se débarrasser du comportement des mots clés tout en conservant la syntaxe pour définir un type?

(imo improbable) il y a un risque fort attaché: il devient trop facile pour la lexicographie idiosyncratique de distraire. Et ces micro-continuités manquantes sont destructrices pour faciliter la collaboration et une communication claire.

@ c42f :

Suis-je toujours confus au sujet de la sémantique de niveau utilisateur prévue pour immuable, ou parlez-vous des détails de mise en œuvre ici?

Non, tu n'es pas - j'étais bâclé. Les immuables ne sont pas vraiment des types de valeur, mais les mutables ne le sont certainement pas et j'ai senti que l'utilisation des mêmes termes que C pourrait suggérer qu'ils le sont.

Je viens de réaliser que dans le contexte de C, il n'est pas clair s'il est logique d'appeler des structures "types de valeur", puisque la situation réelle est que C est un langage passe-par-valeur. Donc, on peut soutenir que ce sont les conventions de passage et d'attribution qui sont différentes, pas les types de données eux-mêmes.

Je suis entièrement en faveur de l'adoption du changement que ce numéro ouvre. L'utilité l'emporte sur toute préférence viscérale que l'un plutôt qu'un autre des termes candidats soit utilisé.

_bien que_

puisque la situation réelle est que C

saisit bien pourquoi, parmi les termes candidats, struct est mon moins favorisé

Voici l'histoire que je vends: "En C et en julia, un struct est une structure de données qui mappe un ensemble fixe de noms de champs à des valeurs de différents types. Mais lorsque vous les transmettez, C est passé -par-valeur et julia est le partage au passage. "

Ce récit est à la fois non onéreux et parfaitement exact. Tout ce qu'il contient peut être recherché avec succès sur Google. Aucun théoricien du PL ne s'en plaindrait, et les non-théoriciens du PL apprendraient quelque chose en l'entendant.

J'achète cette histoire. Bien que je me demande, y a-t-il des termes mentionnés ici dont un théoricien PL se plaindrait? J'aime à penser que Julia s'intègre parfaitement dans cette niche qui satisfait à la fois les théoriciens du PL et les non-théoriciens, il semble donc crucial de trouver un équilibre entre l'exactitude et la clarté générale.

Eh bien, je ne veux mettre les mots dans la bouche de personne; Je voulais juste aborder l'idée que struct pourrait être déroutant car les structures sont des "types valeur".

Je pense que immutable devrait rester un mot-clé à un seul mot. Je n'aime pas const type ou const struct ou immutable struct . J'utilise beaucoup immutable et je pense que ce serait vraiment assez gênant pour ces déclarations d'être deux mots alors que tout le reste est un seul mot. Pas dans le sens de la saisie, car ce n'est pas un réel problème; mais dans le sens où le fait d'avoir immuable comme une "balise" lui donne l'impression d'être de seconde classe.

@TotalVerb Je ne pense pas que ce soit très compatible avec le fait que

type MyType
    const field::Int
end

devrait se comporter exactement comme

immutable MyType
    field::Int
end

fait maintenant.

Étant donné que, avoir un const type (ou const struct , const composite , ou autre) diffuser le const à chaque champ comme un raccourci semble être utile (bien que pas strictement nécessaire). J'espère qu'à l'avenir le compilateur ne saura même pas lequel vous avez tapé ( const type ou const devant chaque champ - le premier pourrait se transformer en le second par l'analyseur). À ce stade, pourquoi garder immutable ?

avoir immuable comme un «tag» le fait sentir de seconde classe.

Si je comprends bien Jeff et Stefan alors, oui, immutable est juste une balise qui dit que les champs d'un type sont des liaisons constantes. Être constant (_really_ constant, pas comme C) aide le compilateur à faire des optimisations, et si les champs eux-mêmes sont des constantes ou des primitives récursivement (ie isbits ) cela l'aide à faire encore plus d'optimisations. C'est bon à savoir, mais pas sémantiquement important. Lier la sémantique au comportement actuel pourrait rendre plus difficile l'amélioration de ce comportement à l'avenir.

Mais il y a une différence sémantique importante: les types immuables sont des valeurs, et on peut donc supposer en toute sécurité que l'identité d'un objet est spécifiée par ses champs. Un objet d'un type immuable n'a, du point de vue de l'utilisateur, aucune "caractéristique d'identification" spéciale non accessible depuis ses champs. Tout objet d'un type mutable non singleton, d'autre part, a clairement cette «identité» invisible. Le fait que de nombreux types immuables soient stockés en tant qu'objets en boîte, et par conséquent aient en fait cette identité supplémentaire en interne, n'est pas pertinent pour la sémantique.

À mon avis, ce n'est pas qu'une _optimisation_ à faire

immutable Complex{T} ... end

au lieu de

type Complex{T} ... end

parce que de nombreux aspects du comportement visible par l'utilisateur changent: === , la valeur par défaut == , objectid , hash , etc. Il n'est tout simplement pas correct de dire cela les types immuables fournissent un sous-ensemble des fonctionnalités des types mutables; au contraire, le fait même qu'ils soient immuables fournit des garanties importantes qui permettent aux types immuables d'être plus puissants.

Avant que la communauté ne s'installe sur const et struct , je voulais juste créer un autre plug pour constant et structure .

1) Juste trois lettres supplémentaires pour les mots réels!
2) Malgré les affirmations selon lesquelles struct est devenu idiomatique
2a) Quelqu'un qui migre de R (comme moi) pourrait être confus
2b) Quelqu'un qui est nouveau dans la programmation (ceux qui ont le plus besoin d'aide) pourrait être confus

Juste pour le plaisir, des mots stupides pour lesquels la structure pourrait être confondue:
indestructibilité
obstructionnisme
post-structuralisme
la superstructure (oh salut Marx)

et const:
Constantinople
constellation
Boa constrictor
inconstitutionnel

Y a-t-il une beauté / puissance PL acquise par immuable multicontextuel et const de ce type: immuable ne diffusant jamais (projetant sa nature) à travers / à l'intérieur de son référent résolu et const diffusant à travers des référents embarqués qui ne sont pas immuables, comme s'il s'agissait d'un adverbe ou d'un gérondif?

La même question, en d'autres termes:

Pour le moment, l'utilisation de variables dans une portée globale est problématique et le trick à contourner consiste à envelopper la valeur variable dans un vecteur const avec une seule entrée. Dans ce cas, const n'est pas diffusé. Une version de diffusion de const s'appliquerait? Impliquerait constness à la valeur de l'entrée dans le vecteur ainsi qu'au vecteur. De même, une déclaration de type qui a des champs qui peuvent contenir des valeurs qui encapsulent ou entourent d'autres types de valeur. Un type immuable ne confère plus d'immuabilité aux valeurs de ses champs (et non aucune valeur qui peut être indirectement atteinte via ses champs). Il y a une élégance et une capacité utiles qui viennent avec une version de diffusion d'un mot-clé qui signifie "une fois construit / initialisé, la valeur attribuée à cet élément [ou aux éléments de ce type] ne change pas [ne peut pas être modifié]" .

Le tri immédiat (non-radiodiffusion) est largement utilisé, et en supposant que certains de ce que les gens font avec Julia devient beaucoup plus facile pour la précompilation de Julia de rendre meilleur / plus rapide / plus simple à utiliser ou à compter avec l'introduction constness diffusable, alors cela doit jouer bien avec le tri immédiat. Je me demande si c'est une manière qui apporte des bontés supplémentaires au langage de programmation théorique (facilité d'expression, pouvoir de représentation, ...): la constness de diffusion diffuse à travers des valeurs de types qui ont des types de référence incorporés et / ou ont des types indirectement contenus jusqu'à (a) atteindre une valeur qui n'a pas d'incorporations internes ou de conteneurs ou (b) atteindre une valeur est elle-même (indépendamment ou non) d'un type qui n'a pas de constance de diffusion.

En y réfléchissant davantage, le seul changement qui, à mon avis, vaut vraiment la peine d'être cassé est bitstype -> primitive , principalement pour la façon dont il est ennuyeux d'appeler quelque chose isbits .

Quant au vrai point de cette discussion, type et immutable , à ce stade, l'option que je trouve que j'aime le plus est aucun changement; type pour construire un type est clair, immutable pour construire un type immuable est clair. Cependant, je prendrai volontiers tout ce que nos seigneurs suprêmes nous donneront, car je fais implicitement confiance à leur jugement sur ce qui est le mieux pour la langue à l'avenir.

Y a-t-il une raison de ne pas utiliser fixe plutôt que const ou constant? Pour moi du moins, cela me semble une description beaucoup plus claire.

@JeffreySarnoff Il est difficile d'impliquer const ness à une chose sur laquelle vous pouvez obtenir une référence (c'est-à-dire un pointeur). La sémantique de «partage» de Julia signifie que tout ce que le compilateur ne peut pas prouver être vraiment immuable doit être un type de référence. Lorsque vous liez une telle référence au champ d'un const type ( immutable ), il n'y a aucune preuve que cette référence n'existe pas ailleurs et donc aucune preuve que les données auxquelles il est fait référence sont constantes.

Je pense que changer ce comportement serait un changement vraiment fondamental de la langue Julia.

@andyferris Merci pour cette réponse claire.

Y a-t-il une raison de ne pas utiliser fixed plutôt que const ou constant ? Pour moi du moins, cela me semble une description beaucoup plus claire.

Je me demandais s'il y avait quelque chose de mieux que const ou constant qui reflète que c'est la liaison qui est permanente, et pas (nécessairement) que les données à l'intérieur de l'objet lié sont immuables. fixed va dans ce sens, mais je n'ai pas vu cela dans d'autres langues (encore une fois, je n'ai pas non plus remarqué la sémantique de liaison / partage de Julia dans d'autres langues).

Peut-être quelque chose comme bind (par exemple bind x = 2 ) ... le thésaurus suggère glue ... cela devient assez spéculatif ...

L'idée de remplacer const par quelque chose de plus précis est séduisante. Cependant, nous souhaitons qu'il s'applique de manière raisonnable à la fois à la déclaration de type a et à une affectation de variable individuelle. fixed struct du sens, mais ce sont les champs de la structure qui sont fixes plutôt que la déclaration de type. Malheureusement, bound struct ( tied struct ?) Semble plutôt flou. Pour une raison quelconque, const me semble plus clair lorsqu'il est appliqué à un type.

Nous voudrions qu'il s'applique de manière raisonnable à la fois à la déclaration de type a et à une affectation de variable individuelle.

Je pense qu'il serait productif de viser cela

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

logique. Avoir un raccourci devant type , struct ou quoi que ce soit ne serait qu'un raccourci qui signifie ce qui précède.

Il pourrait être judicieux d'en faire une macro, comme d'autres décorations importantes qui changent le caractère d'une chose, comme @generated . Cela supprimerait encore un autre mot-clé ...

+1 pour type -> composite , bien que tout changement par rapport à type sonne bien.

J'aimerais pouvoir voter sur les problèmes de GitHub sans avoir à ajouter un nouveau commentaire au fil de discussion ... Mon vote est pour mutable et immutable , c'est assez net et propre. struct est surutilisé et ne met pas l'accent sur la mutabilité.

PS: Est-ce que quelqu'un sait ou peut contribuer à GitHub et ajouter une fonction de vote? Je leur ai posé la question dans la page "contactez-nous", mais mon email a probablement été perdu.

Ayant récemment basculé vers Julia avec une expérience dans de nombreux autres langages, je préfère ne pas voir Julia adopter la dénomination de style C et intégrer tous les problèmes de constance déroutants de C / C ++. Au lieu de cela, donner à une déclaration de type de données une notion qui reflète en quelque sorte l'intention d'être un type valeur ou un type de référence partagé m'aurait beaucoup aidé, au lieu de simplement faire référence à la mutabilité.

Mon attente initiale en Julia aurait été un simple type pour se comporter de manière similaire à un objet de style C immuable struct ou Python, puisque Julia semble être beaucoup plus un style de programmation fonctionnel et de vitesse.
Je suis toujours confus par l'asymétrie dans la formulation de type ... et immutable... , mais en obtenant un DataType partir de typeof(SomeType) , ou la signification réelle de 'bitstype ', et la nécessité d'un mot-clé typealias au lieu d'une simple instruction Alias = DataType .

Ainsi, je voterais pour datatype , ce qui serait cohérent avec typeof(SomeType) == DataType , et briserait la similitude irritante avec ::Type{} . Décorer le type mutable avec composite [datatype] pourrait mettre en évidence sa nature spéciale et peut-être plus chère par rapport aux 'bitstypes' fondamentaux.

tirer tous les problèmes confus de const-ness de C / C ++

Aucun changement de nom de ce mot-clé ne ferait cela. Ces problèmes sont liés à la vérification statique et aux moulages, qui ne sont pas du tout impliqués ici.

l'intention d'être un type valeur ou un type de référence partagé m'aurait beaucoup aidé, au lieu de simplement faire référence à la mutabilité

Je ne comprends pas tout à fait cela. Si un objet est immuable, il n'y a aucun moyen de dire s'il est passé par valeur ou référence, alors comment la distinction valeur / référence peut-elle être fondamentale?

datatype n'est pas un mauvais choix. Mais je ne pense pas que datatype vs composite datatype soit un bon moyen de faire la distinction entre la mutabilité.

@JeffBezanson , avec une const-ness de type C, je voulais dire l'attente éventuellement implicite du type Julia d'avoir le même comportement qu'en C / C ++: immuable seulement après construction, modifiable de toute façon par le casting, étant parfois sans effet du tout pour les arguments de fonction types de retour. Ainsi, lorsque vous choisissez des mots-clés ne faisant probablement pas référence à C / C ++, c'est un bon choix, donc veuillez ne pas const struct .

Concernant «valeur vs référence»: il m'a fallu un certain temps pour comprendre pourquoi un type immuable incorpore directement les membres et produit un code assembleur rapide agréable et compact, mais «type» ne l'a pas fait et contient toujours tous les appels aux objets. Ou en d'autres termes, pourquoi je voudrais généralement utiliser un NTuple pour viser la vitesse. Ainsi, en lisant «immuable» et «mutable», je m'attendais à ce que le sens soit un «paramètre» dans Fortran, mais pas aussi au changement de disposition ou de type d'implémentation du type de données réel.
Probablement, la plupart du temps, on voudra peut-être avoir une sémantique à `` valeur immuable '' pour les petits types composites comme un complexe, mais `` mutable et référençant / non copiant '' pour les grands ensembles de données comme les tableaux, etc.
Ensuite, l'intention sous-jacente n'est probablement pas la mutabilité, mais d'éviter de copier des données.

Cependant, c'était mon expérience lors de l'apprentissage de la machinerie de bas niveau Julia pour obtenir du code assembleur rapide, mais je ne sais pas comment mieux refléter cela en nommant des mots-clés et comment combiner ou exprimer cela simplement avec la mutabilité.

J'arrive d'où vous venez @mjw, j'y suis allé, mais je pense que vous feriez mieux de désapprendre tout ce que vous savez sur C / C ++. Ici, c'est la const -ness qui est immuable et que quelque chose soit empilé ou alloué dynamiquement, et qu'il soit passé par référence ou valeur, est libre de varier et sera des choix d'optimisation pour le compilateur. Vous pouvez créer un langage où tout est alloué dynamiquement et passé par référence, et c'est la méthode par défaut de Julia (pour les valeurs encadrées - il implémente le «passage par partage» même si le type est inconnu). Vous (et le reste d'entre nous) remarquez que les petits immuables sont tellement plus rapides parce que c'est là que les optimisations sont actuellement implémentées. C'est le résultat de la sémantique de immutable facilitant les optimisations.

Mais, vraiment, je préférerais que les grands immuables soient passés par référence (peut-être par des pointeurs de pile, où cela a du sens, mais il est probablement préférable d'allouer en tas un NTuple{1_000_000} ) et que les petits mutables de taille connue soient alloués à la pile (encore une fois, si possible). Même le garbage collection pourrait être déterminé statiquement dans certains cas, permettant par exemple de réutiliser l'espace du tas à l'intérieur de boucles. Je les vois comme de futures opportunités d'optimisation qui nécessitent une analyse d'échappement (et aucune de celles-ci n'affecte la sémantique du langage, juste les performances).

Je pense que ce que je dis, c'est que les mots-clés doivent refléter une sémantique qui restera constante pendant une décennie ou deux, pas des détails d'implémentation qui changeront dans quelques années (c'est-à-dire des petits mutables efficaces et de grands immuables efficaces).

Je voulais dire l'attente éventuellement implicite du type Julia d'avoir le même comportement qu'en C / C ++

Cela pourrait être une raison suffisante en soi pour considérer const -> constant , pour être honnête. Je pense que const pourrait être notre seul mot-clé abrégé pour le moment, ce qui en fait un mot étrange de toute façon.

un simple relevé Alias = DataType .

Je suis presque sûr que c'est tout à fait correct là où cela a du sens, mais cela ne permettra pas de modifications plus complexes du type, par exemple typealias RealMatrix{T<:Real} Matrix{T} , ni ne le devrait (c'est une simple liaison, ne créant pas un nouveau Type avec de nouveaux TypeVar s). À moins que vous ne vouliez le définir dans l'autre sens: RealMatrix = Matrix{T <: Real} et généraliser ce que apply fait pour un TypeVar (c'est-à-dire fait un TypeConstructor ) ... en fait c'est une idée intéressante (mais elle a des problèmes de syntaxe, c'est pourquoi typealias est sympa ...).

@andyferris , j'ai déjà «désappris», mais pour les autres nouveaux utilisateurs, il peut être plus facile de surmonter la phase «pourquoi Julia est-elle si lente malgré la compilation». Choisir des mots-clés qui soutiennent le développement rapide d'un modèle mental de ces détails peut être un énorme argument de vente pour les nouveaux utilisateurs n'ayant pas trop d'expérience en informatique. N'oubliez pas non plus les mots-clés «simples» pour éviter d'autres barrières linguistiques.

@mjw Super, et je suis d'accord avec tout cela. :)

Dites-vous quoi, essayons la chose la plus proche d'un sondage utilisant la meilleure fonctionnalité de GitHub: les émojis de réaction.

Ici, j'ai tabulé, _ sans ordre particulier_, les suggestions qui semblent avoir le plus de soutien. Réagissez en utilisant l'emoji spécifié pour voter pour cette suggestion. Je pense que cela nécessite d'accéder à GitHub via un navigateur de bureau; Les émoticônes de réaction AFAIK n'ont pas été implémentées dans l'interface mobile. Cliquez sur le visage dans le coin supérieur droit de ce post pour accéder au menu des emojis.

| type | immutable | réagir avec |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (Rires) |
| composite | const composite | : tada: (Hourra) |
| datatype | const datatype | 😕 (confus) |
| type | const type | ❤️ (Coeur) |

Le défaut de vote correspond à un vote implicite pour nuple , bien sûr. :visage de troll:

Je dois dire que je ne suis pas un grand fan de prendre des décisions litigieuses comme celle-ci «démocratiquement». Si la discussion s'est déroulée sans consensus, je m'en remettrais simplement à la décision des BDFL.

Bon point, @TotalVerb. Comme je l'ai déjà dit, je serais très bien d'avoir les pouvoirs qui nous donnent tout ce qu'ils pensent être le meilleur. Il me semble que le fil tourne un peu et @juliohm sur le vote semble raisonnable, alors j'ai pensé que

Personnellement, je ne pense pas que j'aime avoir deux mots esthétiquement ( const type ). Il se sent également un peu sémantiquement dissonant. Quand on dit const x = 1 . Nous voulons dire que x est constant. Quand nous disons const type; x; end nous voudrions dire que les instances de ce type ne changent pas après la construction. De l'interpolation directe, on a l'impression que dire que quelque chose est un type constant signifie que le type lui-même ne change pas (ce qui est déjà le cas maintenant). Voir également:

type foo
end
const bar = foo

Donc bar est const et c'est toujours foo, mais pourtant ce n'est pas un const type . Cela ressemble à la sémantique existante de const (s'appliquant aux liaisons), les noms des types sont déjà const.

Je soupçonne qu'il n'y a pas de mots-clés concis, véhiculant la sémantique voulue et peu susceptibles d'être souhaitables en tant que noms de variables. La terminologie qui me semble la plus proche de ces objectifs est mutable datatype , immutable datatype et abstract datatype pour les trois types de types déclarés.

Je souhaite qu'en plus de type et immutable il y ait un type de valeur mutable supplémentaire.
J'ai vu quelques discussions quelque part dans les problèmes, mais pour le moment, il est impossible de gérer efficacement des scénarios comme celui-ci (corrigez-moi si j'ai raté quelque chose):

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  

Le code crée un tableau soigné de types de valeur sizeof(T) * 10 , mais pour changer un champ, il faut réaffecter la totalité de T(...) , qui comprend généralement 3 à 5 champs.
Donc en gros mes 5 cents:
type - Référence collectée par GC
immutable - type de valeur (pile allouée) impossible à modifier
mutable - type de valeur qu'il est possible de changer, en particulier dans les tableaux

type de valeur qu'il est possible de modifier

Je pense que c'est un objectif impossible à atteindre car permettre des changements est précisément ce qui donne à quelque chose une identité d'objet.

Peut-être aimeriez-vous plutôt cette approche: # 11902

sauf pour séparer les mutables et les immuables , il devrait être préférable de séparer les valeurs et les références .

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

Il n'est pas nécessaire de trop compliquer le langage avec une distinction artificielle entre valeurs et références. Les types mutables et immuables sont sémantiquement beaucoup plus simples; le fait qu'un type est un type valeur n'est qu'une optimisation.

@Keno fait un bon point

Personnellement, je ne pense pas que j'aime avoir deux mots esthétiquement (type const). Il se sent également un peu sémantiquement dissonant. Quand nous disons const x = 1. Nous voulons dire que x est constant. Quand nous disons const type; X; fin, nous voudrions dire que les instances de ce type ne changent pas après la construction. De l'interpolation directe, on a l'impression que dire que quelque chose est un type constant signifie que le type lui-même ne change pas (ce qui est déjà le cas maintenant)

Comme je l'ai mentionné précédemment, je pense que la sémantique «correcte» est donnée par

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

Ici z.re se comporte exactement comme lorsque nous tapons quelque chose qui ressemble à const z.re = 1 , il n'y a donc pas de confusion sémantique sur la liaison exacte de const .

Comme l'indique @JeffBezanson , ce n'est pas vraiment pratique pour un grand nombre de champs et n'est pas compatible avec l'implémentation actuelle des types. Des structures partiellement mutables et partiellement constantes peuvent ou non être implémentées à l'avenir. Cependant, il existe une syntaxe qui a du sens à la fois actuellement et dans le futur:

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

De la manière actuelle, une macro peut changer le de type à immutable dans l'AST. À l'avenir, si des structures partiellement constantes sont implémentées, la macro peut toujours effectuer les manipulations de l'AST en ajoutant const à chaque champ, et il sera clair pour tout le monde que ce sont les liaisons de champ qui sont constants. Esthétiquement, c'est mieux que deux mots-clés d'affilée - nous faisons des choses similaires pour les fonctions ( @generated , @inline , @proagate_inbounds , etc.).

@const pourrait facilement être @immutable ou quelque chose de similaire ( <strong i="31">@immutable</strong> type Val{T}; end lit OK, OMI) et l'idée de macro est compatible avec struct , composite , etc.

@ be5invis oui, c'est une manière habituelle dans de nombreux langages, par exemple en C # il y a struct , qui se comporte de plusieurs manières comme immutable : il est passé par copie aux fonctions, est explicitement alloué dans tableaux (pas de références à des objets gérés par GC comme dans le cas de class | type ). Cependant, il est _mutable_, et dans les tableaux peut être modifié par un seul champ.
Ce que je pense, c'est que dans le cas de immutable il y a un mélange de 2 propriétés:

1. Immuabilité (pour faire une programmation fonctionnelle appropriée)
2. Se comportant comme un type de valeur au niveau inférieur

Donc, fondamentalement, j'aimerais voir l'introduction d'un type avec juste la propriété 2. Cela ne perturbera pas la base de code existante ( immutable reste), mais pour ceux qui écrivent quelque chose rapidement avec une implication minimale du GC, ce serait précieux .

@johnmyleswhite merci pour # 11902, je crois toujours que ça ne devrait pas être si moche

@wgreenr Comme mentionné précédemment, et cela a été discuté à plusieurs reprises, ce n'est pas possible. Ce n'est pas non plus vraiment lié à la discussion dans ce numéro.

Tout est possible, mais l'introduction de types de valeurs mutables serait extrêmement perturbatrice et une très mauvaise idée. Je peux comprendre pourquoi c'est une idée apparemment simple et attrayante, mais ajouter un nouveau type de sémantique d'objet entièrement différent et bifurquer le graphe de type en sémantique de référence et de valeur ne va pas améliorer le langage. Cela rendrait impossible d'écrire du code générique en toute sécurité car le même code ferait des choses très différentes en fonction d'une sémantique inconnue. Il y a une discussion approfondie avec des exemples ici . Le but de # 11902 est de récupérer les avantages des types de valeurs mutables sans détruire les choses.

Je ne sais pas si cela vaut même la peine d'être mentionné; mais en C / C ++, 'struct' implique également quelque chose sur la disposition des données. D'un autre côté, il est souvent utile de réorganiser les membres de structure pour obtenir une meilleure disposition de la mémoire. Si vous envisagez un changement radical de la syntaxe, cela pourrait valoir la peine d'avoir un mécanisme pour différencier d'une manière ou d'une autre entre les «structs» (ordonné -> C interop) et «immuable» (pourrait potentiellement être ordonné de quelque manière que ce soit).

Je suis assez nouveau avec Julia, donc je suis désolé si j'ai raté quelque chose d'évident.

Personnellement, je n'ai aucune préférence réelle pour les noms; cependant, je suis surpris que personne ne semble avoir suggéré «concret», étant donné qu'il existe déjà un «abstrait».

Pour ajouter encore une autre suggestion, ce qui me semble le mieux:

• Utilisez struct au lieu de immutable .

• Utilisez struct! au lieu de type . Lorsque vous parlez anglais, cela doit être appelé "structure mutable".

  • (Peut-être) autoriser que certains des champs à l'intérieur d'un struct! soient marqués comme const .

Quelques justifications et réflexions:

1) Sauf si j'ai manqué quelque chose d'évident, vous ne voulez jamais utiliser une fonction avec un ! pour manipuler une valeur d'un type immuable. Si c'est faux (par exemple s'il y a un cas important où le type immuable fait référence à un type mutable, et la fonction avec un ! change), cette suggestion peut ne pas être bonne.

2) Je pense que les types immuables devraient généralement être préférés aux types mutables, car ils sont sujets à plus d'optimisations et ont un comportement plus prévisible pour le programmeur.

3) Pour que cela fonctionne, il est probablement nécessaire d'implémenter les optimisations pour rendre les types immuables au moins aussi efficaces que les types mutables dans presque tous les cas. En particulier, le compilateur doit être intelligent pour transmettre de grands types immuables par référence.

MISE À JOUR : J'avais l'habitude d'avoir record au lieu de struct , mais record! ressemble trop à un verbe. Quelques autres options qui me viennent à l'esprit: newtype , typedef (ce qui déroutera les programmeurs C pendant 10 secondes), composite , ou concrete comme quelqu'un l'a suggéré ci-dessus .

Est-il probable que quelque chose se produise dans cet espace avant le gel des fonctionnalités v0.6?

Probablement pas, étant donné qu'aucune décision n'a été prise (du moins publiquement) et que nous ne sommes qu'à environ 10 jours du gel.

Je n'ai pas suivi cela attentivement, mais un commentaire est que si / quand cela change, j'aimerais demander que nous ayons d'abord un très bon rapport du fichier / numéro de ligne incriminé. Ou du moins le module; en 0.5, il est encore parfois difficile de savoir quel paquet a un @deprecate d _binding .

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