Julia: verrückte Idee: ändere das Schlüsselwort `type`

Es wäre großartig, das Wort type in anderen Kontexten verwendbar zu machen.

Ich mag mutable für Konsistenz.

Wenn dies erledigt ist, sollte es so schnell wie möglich gemacht werden, damit es in 0.6

Wenn dies passieren wird, verwenden Sie das, was jeder erkennt, bevor Sie denken: struct

Ich denke auch, dass type etwas umständlich ist. Wenn ich es anderen Leuten erkläre, sage ich normalerweise "wie eine Struktur", also +1 dafür.

Wenn dies passieren wird, verwenden Sie das, was jeder erkennt, bevor Sie denken: struct

Ich dachte, immutable wie eine Struktur?

+1 für mutable

immutable hat das Speicherlayout einer C-Struktur
type hat die Veränderlichkeit einer C-Struktur

Somit ist struct mit beiden verwandt. Ich denke, mutable anstelle von struct ist besser, um dies zu klären.

Jede Variable ist veränderbar. Das Zuweisen dieses Etiketts zu einem allgemein anerkannten Namen ( struct ) ist für mich alles andere als klar.

Für jemanden aus Fortran ist das Schlüsselwort type bereits selbstverständlich.
Für jemanden, der aus C kommt, wäre das Schlüsselwort struct natürlich.
Für jemanden, der immutable , wäre das entgegengesetzte Schlüsselwort mutable natürlich.

Vielleicht sollten wir es so lassen, wie es ist.

struct{mutable}
struct{immutable}

oder

record{mutable}
record{immutable}

wenn eine aussagekräftigere Form gewünscht wird.

Wenn wir struct die Syntax für unveränderliche Werte immutable struct (wobei der Teil struct zumindest anfänglich optional ist).

Ich vermute, Fortran-Programmierer kennen den Begriff "Struktur".

+1 für mutable wegen Konsistenz. Wenn struct ausgewählt würde, würde die Konsistenz nicht vorschreiben, dass die Änderung unveränderlich in etwas wie const struct geändert wird? ;)

Ich denke, struct und immutable struct wären eigentlich ziemlich gut; struct ist ein sehr bekannter Begriff und wir müssten nur ein neues Schlüsselwort hinzufügen. Das Zulassen von mutable struct kann ebenfalls sinnvoll sein, auch wenn dies nicht unbedingt erforderlich ist.

Ich sollte klarstellen, dass ich denke, dass es ein Vorteil ist, wenn struct ein Substantiv ist. Es wäre besser, nicht nur Adjektive zu verwenden, um diese Dinge zu benennen.

Das Hinzufügen von struct zu immutable struct fügt unnötiges Zeilenrauschen hinzu, umso mehr, als man es gewohnt war, dies nicht eingeben zu müssen.

Otoh, ich glaube, Fortran hat ein type -Schlüsselwort, das etwas sehr Ähnliches wie das unsere tut. Ich bin jedoch nicht abgeneigt, dies zu ändern.

@KristofferC oben hat es richtig: Ich sage auch "struct", wenn ich erkläre, was das ist. Selbst in internen Diskussionen war type ein Problem. Jemand wird sagen "Angenommen, x ist ein Typ", und es ist nicht klar, ob es "Ding, das mit dem Schlüsselwort type deklariert wurde" oder "Typ" in einem anderen Sinne bedeutet.

Wenn diese Namen wirklich auf dem Tisch liegen ( s/type/new name/ scheint etwas widerlich zu sein), würde ich vorschlagen, dass wir diese Gelegenheit nutzen möchten, um die Standarddeklaration unveränderlich zu machen.
struct würde also immutable ersetzen, und mutable [struct] würde type. ersetzen

Genau wie ein Gedanke könnte ein anderer möglicher Begriff für veränderlich auch Ref .

Ein anderer möglicher Name wäre composite , da ein generischer CS-Begriff hierfür ein zusammengesetzter Typ ist . Aber ich bevorzuge immer noch mutable Foo und immutable Foo gegenüber mutable struct Foo und immutable struct Foo - die struct (oder composite oder class oder was auch immer) erscheint überflüssig.

: +1: zu Substantiv (en)

Ich mochte type in Julia immer mehr als struct (obwohl mein Hintergrund _C_ ist), weil Julias Datentypen eine ganze Reihe mächtiger und subtiler sind und ich denke, dass "struct" ein bisschen simpel sein könnte für die Idee. Ich denke auch, da dies eine neue Sprache ist, sollten wir nicht an Konventionen gebunden sein, an die erfahrene Programmierer gewöhnt sind - Sie sollten auch überlegen, "was das beste Wort wäre, um dies einer Person zu erklären, deren Muttersprache Julia ist".

Ich sage auch "struct", wenn ich erkläre, was das ist

Stellen Sie sich vor, Sie stellen einem Neuling struct T und sagen ihm dann T::DataType und Sie können mit ::Type{T} versenden, während Sie Julias "mächtiges Typensystem" erklären. Ich denke, das ist nur ein Tritt in den Eimer die Straße hinunter.

ein Substantiv zu sein ist ein Vorteil

: +1: zu Substantiv (en)

Wahrscheinlich erwähnenswert, dass lateinischsprachige Familienadjektive wie "veränderlich" grammatikalisch auch Substantive in ihrer eigenen Sprache sein dürfen. Deshalb zucken wir mit den Schultern, wenn wir fragen, was die Nomenform von veränderlich ist. Aber wir sagen immer "eine Variable" und in Julia-Sprache würde ich sagen "lasst uns eine unveränderliche dafür einführen". Leider fühlt es sich aufgrund der germanischen Wurzeln der englischen Grammatik zunächst unangenehm an - aber das passiert sehr oft auf Englisch (weil wir auch auf Französisch und Latein basieren), aber man gewöhnt sich mit der Zeit daran.

Da das Thema "verrückte Idee" ist, konstruieren diese Schlüsselwörter mehr oder weniger ein neues DataType Können wir also die Schlüsselwörter vollständig entfernen und nur einen Konstruktor verwenden?

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

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

Ich denke, diese müssten speziell (statisch) analysiert werden, wie es ccall ist, und sie können vorerst nur auf oberster Ebene aufgerufen werden. (Auch - nicht sicher, ob wir Mutable <: DataType und Immutable <: DataType und BitsType <: DataType benötigen würden, um alle Möglichkeiten abzudecken, und wahrscheinlich const für die Bindung).

Ich dachte, unveränderlich wäre wie eine Struktur?

unveränderlich hat das Speicherlayout einer C-Struktur
Typ hat die Veränderlichkeit einer C-Struktur

Richtig ... Ich glaube, ich habe an Swift gedacht, wo:

Dies ist der größte Unterschied zwischen Strukturen und Klassen. Strukturen werden kopiert und Klassen referenziert. ... Sie werden daher bei großen Objekten als Werte und nicht als Referenz übergeben.

Das klingt nach immutable vs type , und es ist nur die Referenz, die die Veränderbarkeit im Kontext der Semantik von Julia-Bindungen ermöglicht.

DataType enthält alle nominalen Typen: abstract , Bitstypen, unveränderliche und veränderbare Strukturen. Es bringt also nicht viel Klarheit, type durch DataType zu ersetzen. Ich ziehe auch eine andere Schlussfolgerung aus dem "Newcomer" -Szenario: ::Type und ::DataType wählen Supersätze der durch type T definierten Dinge aus, daher ist es nicht verrückt, wenn sie unterschiedliche Namen haben . " struct ist eine Art von Type " ist sinnvoller als " type ist eine Art von Type ".

Ich bin damit einverstanden, dass die Adjektive in der Praxis als Substantive dienen können. Man kann zB sagen "das ist unveränderlich". Ich denke nur, dass sie nicht ausreichend beschreibend sind. Anstatt dir zu sagen, was das Ding ist, sagt es dir nur, dass du es mutieren kannst / nicht mutieren kannst, was auch immer es ist.

Ich mag structure und mutable structure für Typen. vielleicht a = 1 und mutable a = 1 für die Variablenzuweisung. Von der Idee abkommen, standardmäßig Konsistenz, keine Abkürzungen und Unveränderlichkeit zu wollen.

Bearbeiten: Vielleicht constant anstelle von const in der Standardveränderbarkeit

Oder eine Version mit weniger Schlüsselwörtern wäre struct vs. const struct . Standardmäßig alle Variablen const zu machen, wäre an dieser Stelle meiner Meinung nach zu störend.

Ich denke nur, dass sie nicht ausreichend beschreibend sind. Anstatt dir zu sagen, was das Ding ist, sagt es dir nur, dass du es mutieren kannst / nicht mutieren kannst, was auch immer es ist.

Das ist ein guter Punkt - aber ich würde das Referenzierungsverhalten gegenüber dem "Wert" -Verhalten als viel wichtiger und interessanter zu beschreiben betrachten als "Ist es eine Struktur oder ein Bittyp?" (hauptsächlich, weil bitstype nicht sehr häufig vorkommt - jeder von mir erstellte Julia-Typ ist eine Struktur). Unveränderlichkeit ist nur eine Folge der verbindlichen Semantik und des Pass-by-Value.

Um die Notwendigkeit von struct vs bitstype vollständig zu vermeiden, könnten wir auch diese Idee von @quinnj einbeziehen, die es war

immutable 32 Int32 <: Integer

oder Sie könnten ungeschmückte Felder als Anzahl von Bits haben

immutable Int32 <: Integer
   32
end

Dies kann (im Allgemeinen beim Mischen mit benannten Feldern) auch zum Einfügen von Auffüllungen bei Bedarf hilfreich sein.

Dann ist es nur eine Wahl zwischen einem Werttyp (was derzeit unveränderlich ist) und einem Referenztyp (was derzeit veränderlich ist - aber möglicherweise mit const Feldern in der Zukunft, was ein weiterer Grund ist, ihn nicht mutable ) und entsprechende Namen werden benötigt, um diese zu unterscheiden. Und schließlich mit struct wird für den Referenzwert Typ Swift Programmierer verwechseln ...

Es ist wahr, dass bitstype fast verschwunden ist, seit immutable eingeführt wurde. Es gibt jedoch mehr Dinge zu unterscheiden als Struktur und Bits: Es gibt abstrakte Typen, Tupel (auch unveränderlich) und wahrscheinlich unveränderliche Datensätze in der Zukunft.

Wir haben ursprünglich immutable da wir der Meinung waren, dass dies das sichtbarste Unterscheidungsmerkmal ist: Im Gegensatz zu anderen Objekten können Sie sie nicht ändern. Tatsächlich werden sie nicht immer als Wert übergeben; Unveränderlichkeit bedeutet, dass Sie den Unterschied nicht erkennen können. Einige immutable s sind in Arrays und andere Objekte eingebunden, andere nicht. Unveränderlichkeit bedeutet, dass der Unterschied keine Probleme für den einfachen Julia-Code verursacht. Dies wird nur dann zu einem Problem, wenn das Speicherlayout wirklich wichtig ist, z. B. für C-Interop.

Tatsächlich werden sie nicht immer als Wert übergeben

Guter Punkt! Es gibt jedoch Pläne, das zu ändern, oder?

Ich denke, ich sage, Sie benötigen einen zukunftssicheren Satz von Schlüsselwörtern, die einige zukunftssichere Konzepte widerspiegeln, da wir uns 1.0 nähern. Wenn unveränderliche Elemente inline sind, scheint dies ein angemessener Zeitpunkt zu sein, um sie in etwas umzubenennen, das im Hinblick auf die resultierende Semantik hilfreich ist (und wenn diese Semantik bei FFI hilft, ist das sogar noch besser).

Ich glaube nicht, dass die Leute neue konkrete Schlüsselwörter für die Typdefinition bekommen werden, die mit abstract , Tuple s und "Datensätzen" verwechselt werden (was, wenn Sie das vorgeschlagene tupelartige Ding mit Feldnamen meinen, denke ich Ich habe auch gehört, dass ich früher als "Strukturen" bezeichnet wurde ...).

Der eigentliche Zweck des Begriffs "Wertübergabe" besteht darin, die Frage zu beantworten, was passiert, wenn f(x) (in gewissem Sinne) x ändert: Ändert er das gleiche x Der Anrufer hat übergeben, oder ist die Änderung nur lokal? Julia hatte und wird (ich hoffe) niemals Typen, Argumente oder Funktionen haben, die sich in Bezug auf dieses Verhalten unterscheiden. Alles ist "Pass by Sharing". Für uns gibt es Pass-by-Value nur auf ABI-Ebene, aber diese Diskussion gehört nur in den FFI-Abschnitt des Handbuchs. Ich bin mir nicht sicher, ob wir jemals eine Art Typ haben werden, der immer als Wert übergeben oder immer inline ist, da dies bei großen Objekten schlechter abschneiden kann.

Wie auch immer, ich denke, immutable und mutable sind praktikable Optionen für Keywords.

Es ist wahr, dass Bitstype seit Einführung von unveränderlich so gut wie verschwunden ist

Während Individuen normalerweise keine neuen Bitstypen erstellen müssen, ist der Unterschied zwischen den vorhandenen Bitstypen und den üblichen unveränderlichen Stoffen auf primitiver Ebene von großer Bedeutung, da die ABI für diese sehr unterschiedlich sind. Es kommt nur vor, dass Benutzer beim Definieren eines neuen konkreten Datentyps meistens die unveränderliche Struktur und nicht den Bittyp wünschen.

FWIW, da es nicht viel Unterstützung dafür gab, Dinge nicht zu ändern, denke ich, dass type und immutable in Ordnung sind, so wie sie sind.

(Die do -Syntax nervt mich allerdings ... ;-)

Alles ist "Pass by Sharing".

Ich kann das respektieren - und danke für die Diskussion.

Alles ist "Pass by Sharing".

In diesem Sinne nur eine Beobachtung - wenn wir const Schlüsselwörter in Typdeklarationen hatten, wird immutable völlig unnötig:

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

(Der Compiler könnte feststellen, dass dieser Typ automatisch unveränderlich ist, und Benutzer können verstehen, dass mit const -Typen schnellerer Code kompiliert werden kann.) Dann machen type oder struct Sinn. setfield! kann im gemischten Fall für const Felder deaktiviert werden.

Was ist mit type und const type ? - Das Schlüsselwort type klingt für mich eleganter als struct und mit struct verknüpfe ich ein technisches Speicherlayout und kein ~ Objekt mit zB inneren Konstruktoren. Da der zusammengesetzte Typ "... bei weitem der am häufigsten verwendete benutzerdefinierte Typ in Julia ..." ist, ist es vielleicht nicht so schlimm, wenn "Typ ist eine Art von Typ"? Bei der Kommunikation mit 'Composite Type' sollte klargestellt werden, wie ich sagen würde 'Abstract Type'. In Bezug auf Leitungsrauschen ist 'const type' nicht schlechter als 'unveränderlich'.

Ich bin mir nicht sicher über den (geringfügigen) Unterschied in der Bedeutung von const mit Variablen vs. Typen. - Auf jeden Fall gab mir Typ und unveränderlich immer einen kleinen geistigen Schluckauf. Schön, dieses Problem hier zu sehen!

Das Hauptproblem bei der Verwendung von struct darin, dass Benutzer natürlich Annahmen treffen, an die sie von C / C ++ gewöhnt sind, die in Julia nicht unbedingt zutreffen, z. B. wird ein veränderlicher zusammengesetzter Typ nicht nach Wert in einem Array gespeichert, während ein unveränderlich ist.

Welche Paradigmen repräsentieren immutable eleganter als type ? Beispiel: Atomarer "Übergang" des Zustands mehrerer Felder gleichzeitig, ohne dass Synchronisationsprimitive erforderlich sind, indem eine neue unveränderliche vom Original mit den gewünschten aktualisierten Feldern instanziiert wird.

Warum sollte der Typ am Punkt seiner Definition und nicht am Punkt seines Versands / seiner Verwendung in zwei verschiedene Kategorien unterteilt werden (eher wie const in C ++)? Indem wir nur type / struct / composite , um zusammengesetzte Typen zu definieren, und ein Immutable{T} -Konstrukt einführen, um veränderlich bis unveränderlich zu fördern, könnten wir:

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

Könnte hier auch eine Änderung von abstract und bitstype in Betracht gezogen werden? AFAICT die Verwendung von "abstrakt" ist als Adjektiv, nicht als Substantiv. Es sollte mindestens eine sprachliche Konsistenz zwischen den Schlüsselwörtern des Typs bestehen: alle Substantive, alle Adjektive usw. bitstype könnte besser als nur bits oder primitive .

Bitte lassen Sie uns dies nicht in einen offenen Thread verwandeln, um Änderungen an der Rechtschreibung (oder Semantik!) Von Julia-Schlüsselwörtern zu diskutieren. Zu diesem Zeitpunkt ist das Schiff auf dem Grundverhalten von type und immutable gesegelt. Die einzige Frage, die hier aufgeworfen wird, ist, ob wir eine Schreibweise von type und immutable , die ihre Ähnlichkeit besser widerspiegelt.

Ich unterstütze weiterhin mutable vs immutable oder lasse es einfach so wie es ist, als die beiden vernünftigsten Optionen an dieser Stelle. Alles andere wäre sinnlos störend.

@andyferris Ich mag diese Idee wirklich; Eine Kombination aus struct und const wäre gut. Wenn wir diesen Weg gehen, möchte ich auch const struct oder const type sagen können (1), um zu vermeiden, dass auf jedes Feld const werden muss (2) ), damit wir die neue Funktion der Unveränderlichkeit pro Feld nicht sofort hinzufügen müssen. Wenn wir diese Funktion jemals hinzufügen möchten, wäre es gut, ein konsistentes Vokabular dafür zur Verfügung zu haben.

Bei der Kommunikation mit 'Composite Type' sollte klargestellt werden

Eine unserer bevorzugten Techniken zum Benennen war es, jemandem in einem Satz etwas zu erklären und dann das eine oder andere Wort auszuwählen, das die meiste Arbeit zu leisten scheint. Für mich wäre dies eine Abstimmung für composite .

Warum sollte der Typ am Punkt seiner Definition und nicht am Punkt seines Versands / seiner Verwendung in zwei verschiedene Kategorien unterteilt werden (eher wie const in C ++)?

Das ist einfach: globale Garantien geben. In C ++ kann sich ein "const" -Objekt unter Ihnen immer noch ändern, wenn jemand einen nicht-const-Verweis darauf hat.

Könnte hier auch eine Änderung von abstrakt und bitstype in Betracht gezogen werden?

Mache einen Antrag. Was bitstype betrifft, wird das Schlüsselwort sehr selten verwendet, daher möchte ich kein kleines nützliches Wort wie bits dafür stehlen.

immutable -> const type scheint mir auch in Ordnung zu sein. Kombiniert mit type -> composite oder struct , wenn wir wirklich type freigeben wollen.

Ich bin nicht besonders glücklich über die gesamte Code-Abwanderung, die dies verursachen wird, zumal sie jedoch nicht von @compat kann. Wenn wir dies tun müssen, sollte der Upgrade-Pfad ungefähr so ​​lauten: (1) neue Keyword-Synonyme in 0.6 einführen, aber alte nicht verwerfen (wegen des Fehlens von @compat ), dann (2) veralten die alten in 0.7.

Wie wäre es für bitstype , wenn Sie dies einen primitive -Typ nennen? Der aktuelle Name ist aufgrund seiner Ähnlichkeit mit an isbits composite type etwas nervig

Ich mag die Art und Weise, wie Julia oft einige der Abkürzungen im "def / func / elif" -Stil einiger anderer Sprachen vermieden hat. (Dn w abbrevs, kthx.) Also mutable Gewinne über struct für mich.

FWIW, OCaml verwendet type für Datensätze und Varianten (Strukturen und Gewerkschaften) und Aliase. Standard ML verwendet datatype denke ich.

Symmetrie ist nett, aber ich finde mutable nicht ausreichend beschreibend; immutable auch (ich mag die Idee von const type ).

Wie Steve betont, wird dies in der gesamten Community zu einer ziemlich schlechten Code-Abwanderung führen. Und der Nutzen ist zweifelhaft.

Ich sehe definitiv den Fall für const type ; Es wäre das Schlüsselwort net -1 und würde die Beziehung zwischen Typ und unveränderlich verdeutlichen. Es wäre wirklich schön, type auf andere Weise verwenden zu können. Ohne diesen Vorteil ist es viel schwieriger, eine Änderung zu rechtfertigen. Das Aktualisieren des Codes hierfür sollte jedoch sehr einfach sein. Die Syntax von type ist so, dass sie grundsätzlich in keinem anderen Kontext verwendet werden kann.

+1 für composite / const composite .

Ich bin der Meinung, dass primitive vs composite ein großartiges Unterscheidungsmerkmal ist, wobei const Bedarf

Benötigen wir const primitive , um von einigen Bits zu unterscheiden, die sich ändern können (und um die Konsistenz zu gewährleisten)? So symmetrisch hätten wir

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

Das Problem, ein veränderlicher primitiver Typ zu sein, müsste implementiert werden ... (natürlich könnte dies möglicherweise zu einem späteren Zeitpunkt sein, aber wir würden bitstype -> const primitive _now_ wollen, wenn das gehen würde Einfacher zu sein, könnte ein gutes "Übungsziel" sein, um Mutables auf den Stapel zu bringen, aber ich bin kein Experte in diesem Bereich.

In ähnlicher Weise kann die Idee, einzelnen Feldern eines Verbundwerkstoffs const hinzuzufügen, zu einem späteren Zeitpunkt problemlos umgesetzt werden, und noch besser, es handelt sich um eine nicht brechende Änderung.

Wenn wir diesen Weg gehen, möchte ich auch const struct oder const type sagen können (1), um zu vermeiden, dass const in jedes Feld geschrieben werden muss, (2) damit wir nicht die neue Funktion von hinzufügen müssen Unveränderlichkeit pro Feld sofort. Wenn wir diese Funktion jemals hinzufügen möchten, wäre es gut, ein konsistentes Vokabular dafür zur Verfügung zu haben.

Macht für mich vollkommen Sinn.

Ich habe den Datentyp composite nachgeschlagen und festgestellt, dass zumindest Ada und Visual Basic auch Array-Typen darunter subsumieren. (Ansonsten etwas zufällig gefunden: Haskell: Listen und Tupel (es wurde jedoch nach einer Definition gefragt); Python: Listen, Tupel, Dikte; Lisp: Listen, Vektoren, Hash-Tabellen, benutzerdefinierte Klassen, Struktur).

Daher frage ich mich jetzt, wie genau Composite für das eher strukturähnliche type . (Aber ich bin kein Informatiker, mir fehlt der Wortschatz / die umfassende Sicht).

Hmm, das könnte richtig sein: Diese bestimmte Art von Typ scheint immer als Struktur, Struktur oder Datensatz (oder Klasse oder Objekt) bezeichnet zu werden, wobei "zusammengesetzt" ein weiter gefasster Begriff ist. Es gibt viele Beispiele unter http://rosettacode.org/wiki/Compound_data_type

Es wäre schön, type als Kennung wiederherzustellen und einen spezifischeren Namen zu verwenden. Der Bruch so ziemlich aller trivialen Pakete, die vor ~ 0.6 geschrieben wurden, wäre sehr unglücklich. Ich bin mir nicht sicher, wie ich das abwägen soll.

Die Idee, das Schlüsselwort const wiederzuverwenden, ist sehr überzeugend, da sie die Gleichwertigkeit von const Variablenbindungen im globalen Bereich mit den const Bindungen von Feldern in unveränderlichen Bereichen betont. Dies scheint eine gute Vereinheitlichung und bessere Benennung zu sein als immutable .

Was Namen betrifft, die type ersetzen sollen, scheint struct Mehrdeutigkeiten ziemlich gut zu vermeiden (ich finde die Ausdrücke "ein veränderlicher Typ" und "unveränderlicher Typ" häufig zu ähnlich).

Das Folgende sieht ziemlich gut aus, denke ich:

struct A
    a::Float64
end

const struct B
    b::Float64
end

Es wäre schön, den Typ als Bezeichner wiederherzustellen und einen spezifischeren Namen zu verwenden.

Ich stimme diesem Gefühl zu.

Wie würden wir mit der Abwertung umgehen, wenn wir den Namen ändern würden? Werden type und immutable in 0.6 und wahrscheinlich 1.0 mit Warnungen noch gültig sein? Kann Compat.jl dies transparent handhaben? Einiges an Literatur im Internet (Blog-Beiträge, Tutorials usw.) zeigt Warnungen - kleinere Belästigungen für einen Neuling.

Wir könnten type und immutable noch länger als gewöhnlich reservieren, um den Übergang zu erleichtern.

Wir sind vor 1.0: Die Zeit, dies zu ändern, ist jetzt oder nie. Das alte Schlüsselwort länger verfügbar zu haben, ist sicherlich gut, um einen reibungslosen Übergang zu gewährleisten. Ich würde die Diskussion über die tatsächliche Benennung nicht mit dem Schmerz verwechseln, den der Übergang bedeuten wird.

Persönlich bin ich alles dafür, es struct . Trotzdem

Ich würde die Diskussion über die tatsächliche Benennung nicht mit dem Schmerz verwechseln, den der Übergang bedeuten wird.

Wenn die Änderung zu schmerzhaft ist, würde ich gegen die Änderung stimmen. Während eine Änderung vor 1.0 gerechtfertigt ist, ist es IMO das Richtige, sie gegen jede verursachte Störung abzuwägen.

@stevengj hatte einen guten Vorschlag, wie die Abwertung durchgeführt werden soll, und es sieht so aus, als wäre @amitmurthy zu dem gleichen Schluss gekommen (behalten Sie die Keywords länger bei, als wir es normalerweise tun würden). Obwohl wir alle diese Sprache schon eine Weile verwenden, ist es noch früh und wir sollten keine Angst haben, die Änderung vorzunehmen. Dies ist auch nur ein einfaches Suchen und Ersetzen.

Ich werde weitermachen und für struct stimmen. Ich denke, dies ist eine dieser Änderungen, die viel Aufsehen und Beschwerden hervorrufen wird, aber es ist eigentlich nicht sehr schwer, Pakete / Benutzercode zu reparieren ... tun Sie es einfach und die Leute werden es herausfinden.

immutable -> const type scheint der Weg des geringsten Widerstands zu sein, und IMO sollte auf jeden Fall getan werden. Ich denke, das erklärt die Dinge viel schöner.

type -> composite ist genauer als type aber weniger genau als struct , während es weniger umgangssprachlich ist als struct (bis neue Programmierer). Es besteht Jeffs 'Schreiben eines Satzes, um ihn einem Neuling-Test zu erklären "und stellt das Schlüsselwort type . Andererseits glaube ich nicht, dass composite in anderen Sprachen erscheint, also würden wir sei es alleine.

type -> struct ist am genauesten, aber möglicherweise wäre structure hübscher als eine Abkürzung (ich versuche mir eine Abkürzung vorzustellen, die so hässlich ist wie struct anderer Stelle in der Sprache und leer - ich nehme an, eye() ist aus englischsprachiger Sicht eine ziemlich ekelhafte Tradition.

bitstype -> primitive ist sinnvoll, wenn type geändert wird.

@tbreloff ist richtig - die Kernentwickler haben in der Vergangenheit guten Geschmack gezeigt und am Ende werden die Leute ihrem Beispiel folgen. Mach es bald!

Ich frage mich, ob, da immutable der Standard sein sollte, es sei denn, Sie müssen explizit mutieren, ob die Umbenennung sein sollte:

• immutable -> struct
• type -> mutable

Dann ist der gebräuchliche / erwartete Name die beste Vorgehensweise, und es gibt einen expliziten und eindeutigen Namen für die Anforderung der Veränderlichkeit.

Ich mag auch bitstype -> primitive ...

Ich denke nicht, dass const die Standardeinstellung sein sollte. Optimierungen, die die Funktionalität reduzieren, sollten nicht die Standardeinstellung sein.

+1 für struct und const struct .

Der Begriff composite ist etwas aussagekräftiger, aber struct ist kurz und wird sehr häufig als zusammengesetzter Typ bezeichnet.

Ich würde lieber kein tatsächliches Wort für etwas stehlen, das so selten verwendet wird wie bitstype . Vielleicht primtype oder primitivetype ?

Wenn wir bitstype in einen deutlich besseren Namen wie primitive ändern, dann denke ich, dass es wahrscheinlich besser wäre, ihn so zu lassen, wie er ist.

-1 bis struct . Ich verwende diesen Begriff nicht, um zu erklären, was eine Typdefinition ist, es sei denn, ich spreche mit einem C-Programmierer, und um dann nur zu erwähnen, dass das Layout kompatibel ist, und um deren Eigenschaften zu vergleichen / gegenüberzustellen.

-1 bis const . C ging in diese Richtung, um absolut minimale Keywords zu haben, und jetzt stecken wir bei vielen Keywords fest, die kontextsensitive Bedeutungen haben. Ich denke nicht wirklich, dass const die Schlüsseleigenschaft dieser Typen ist, sondern dass es sich um Werttypen handelt (im Gegensatz zu Referenztypen).

Wenn Sie jedoch in eine andere Richtung gehen, wie wäre es mit dem Schlüsselwort 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`

Das Problem mit "Werttyp" ist, dass es etwas ist, das nur Leute verstehen können, die ziemlich tief in der Sprache sind. Für neue Benutzer ist die Tatsache, dass die Felder unveränderlich sind, die semantische Tatsache, mit der sie sofort konfrontiert werden; Alles andere ist ein Implementierungsdetail. Also bevorzuge ich const .

Ich sehe, wohin Sie mit der Aufzeichnung gehen , aber ehrlich gesagt denke ich, dass diese Terminologie noch weniger verbreitet ist als struct (selbst wenn Sie "Datensatztyp Ruby" gegen "Strukturtyp Ruby" googeln oder Python oder Perl oder einige ersetzen andere Nicht-C-Sprache). Es gibt auch das Problem, dass record ein ziemlich nützliches englisches Wort ist, das es schade wäre, als Schlüsselwort zu reservieren, während struct wahrscheinlich für nichts anderes in einem Programm benötigt wird.

struct wird sehr häufig verwendet. Mit Blick auf Rosettacode wird es verwendet von:

Algol, C, C #, C ++, Lisp, D, Elixier, her, gehen, Maxima, Schläger, Rost, Samen7, schnell, visuell grundlegend ( structure )

record wird verwendet von:

ada, clojure, delphi, pascal, erlang, icon, modula-2, einige schemata

record scheint in älteren Sprachen bevorzugt zu sein; Heutzutage, da die funktionale Programmierung immer beliebter wird, bezieht sie sich tendenziell auf strukturell typisierte Datensätze.

Interessanterweise verwendet seed7 new struct .

Ein bisschen traurig zu sehen, dass struct (sind die zusätzlichen drei Buchstaben, um das Wort wirklich so schlecht zu vervollständigen?) Es zu einer Sprache macht, die bisher function anstelle von func , und so weiter. Es ist nicht etwas, das irgendjemand ablehnen wird, aber trotzdem ...

structure wird tatsächlich in PL / I und Visual Basic verwendet. VB hat auch structure immutable . Allerdings ist struct so häufig, dass ich denke, dass es fast ein neues Wort für sich geworden ist.

Ich frage mich, ob es hier auch ein muttersprachliches Problem gibt. Für mich ist das, was ich in diesem Zusammenhang sehr gewohnt bin, struct zu sagen, structure , was sich seltsamer anfühlt. Aus dem gleichen Grund klingt func schrecklich und function natürlich.

Ist struct aufgrund seiner Verwendung in verschiedenen Programmiersprachen nicht zu einem eigenständigen Begriff geworden? Das Wort structure ist (zumindest für mich als Deutscher) viel abstrakter. Zum Beispiel hat diese Typhierarchie eine bestimmte "Struktur".

func ist für mich kein eigenständiger Begriff, sondern nur eine Abkürzung.

func ist für mich kein in sich geschlossener Begriff, sondern nur eine Abkürzung.

Wie ist struct nicht nur eine Abkürzung? Ist es nicht buchstäblich eine Abkürzung für Struktur oder habe ich den Begriff einfach falsch verstanden? Du bist nur mehr daran gewöhnt als func . Viele Dinge sind "in sich geschlossene Begriffe" und in vielen Sprachen gleich, aber das bedeutet nicht unbedingt, dass Julia einer Tradition folgen sollte, wenn es besser ist, dies nicht zu tun. Dann ist es nur ein Kampf um das, was besser oder schlechter ist, und das ist so ziemlich nur eine Frage des Geschmacks.

Wie auch immer, ich würde mutable bevorzugen, also ist es mir zu tief, ob es Struktur oder Struktur ist. veränderlich würde es vermeiden, ständig const für das zu schreiben, was jetzt immutable .

Aber selbst wenn es struct oder sogar strct oder stct oder strctr , ist es sehr unwahrscheinlich, dass ich Julia für eine andere Sprache ändern würde meine Arbeit, also ... :)

Entschuldigung, wenn dies auf Englisch keinen Sinn ergibt: Ist aber nicht struct eine Abkürzung von construct . Zumindest auf Deutsch ist das Wort Konstrukt viel sinnvoller, um zu beschreiben, was ein zusammengesetzter Typ ist.

In Englisch nicht in der Lage zu sein zu sagen, ob construct ein Substantiv oder ein Verb ist, hat wahrscheinlich seine Verwendung in Englisch-basierten Programmiersprachen ausgeschlossen :) Die deutsche Verwendung von Großbuchstaben ist dort hilfreich.

struct ist ein eigenes Wort, genauso wie TV, ASAP und LOL Wörter sind. Ich höre selten Leute "Struktur" sagen. Nach meiner Erfahrung ist das Wort sowohl gesprochen als auch geschrieben "Struktur".

Übrigens: Matlab verwendet das Wort struct , wenn das einen Unterschied macht.

OTOH entspricht, wie oben erwähnt, in C # und Swift struct einem Werttyp (im Gegensatz zu class ). Die Verwendung einer ähnlichen Terminologie für veränderbare und unveränderliche Typen würde den mit diesen Sprachen vertrauten Personen also nicht wirklich helfen. Ich bin mir nicht sicher, ob das ein entscheidender Punkt ist ...

mutable / immutable klingt nach der explizitesten Wahl, die für Neulinge offensichtlich sein sollte.

Angesichts der großen Anzahl verschiedener Sprachen, die struct , denke ich nicht, dass eine identische Semantik erforderlich ist, um diesen Namen zu verwenden.

Ich mag type und const type am besten, aber das gibt das Schlüsselwort type nicht frei. Da ich nicht weiß, was für type , weiß ich nicht, wie hoch die Kosten sind.

Da der Teil type bereits in abstract , ist es möglicherweise am sinnvollsten, mutable und immutable für sich allein zu verwenden. Und es ist weniger tippen als immutable struct und eine kleine Änderung (Typ -> veränderlich).

Die Wortstruktur ist (zumindest für mich als Deutscher) viel abstrakter.

Während wir über Sprache streiten, unterschätzen alle die Abkürzung struct . Es ist die Abkürzung für "Datenstruktur". Ebenso würde ich sagen, dass type für "Datentyp" steht. Ich wage zu sagen, dass ein Array oder Puffer auch eine Datenstruktur ist, ebenso wie eine verknüpfte Liste und so weiter, aber struct hat frühe Wurzeln als eine der ersten gemeinsamen Datenstrukturen und innerhalb des Rechnens hat es eine spezifischere eigene Bedeutung (und daher klingt es für Programmierer, die in Englisch oder auf andere Weise einheimisch sind, nicht so abstrakt wie structure ).

-1 bis struct . Ich verwende diesen Begriff nicht, um zu erklären, was eine Typdefinition ist, es sei denn, ich spreche mit einem C-Programmierer, und um dann nur zu erwähnen, dass das Layout kompatibel ist, und um deren Eigenschaften zu vergleichen / gegenüberzustellen.

Ich fühle genau so über struct . Ich denke, wir würden Julia ohne besonderen Grund einen neuen Begriff vorstellen.

-1 bis const . C ging in diese Richtung, um absolut minimale Keywords zu haben, und jetzt stecken wir bei vielen Keywords fest, die kontextsensitive Bedeutungen haben. Ich denke nicht wirklich, dass const die Schlüsseleigenschaft dieser Typen ist, sondern dass es sich um Werttypen handelt (im Gegensatz zu Referenztypen).

Jeff erklärte mir (sehr freundlich) oben, dass es uns semantisch egal ist, ob es sich um Werte oder Referenzen handelt oder was auch immer - dies sind Implementierungsdetails, keine Semantik, und in einem zukünftigen goldenen Zeitalter ist es uns einfach egal. Die Dinge werden auf jede vom Compiler gewünschte Weise "weitergegeben" (mit einigen FFI-Garantien nach Bedarf). In den letzten Tagen habe ich das bereits als "Teilen durch Magie" bezeichnet und ich denke, dass dies eine Offenbarung für mich war, die einen Haufen mentalen Drucks lindert, über den ich (idealerweise) einfach nicht nachdenken sollte ( @vtjnash Sie haben gesehen, wie ich mit Werten und Referenzen zu kämpfen habe und wie diese vom Compiler und GC usw. in anderen Paketen und Threads implementiert werden.

Bindungen können sich entweder ändern oder sind konstant (wir verwenden const aber constant ist auch ziemlich süß). In ähnlicher Weise können sich die Bindungen von Feldern innerhalb eines zusammengesetzten Datentyps entweder ändern oder sind konstant. Aus diesem Grund habe ich früher vorgeschlagen, const explizit an jedes Feld anzuhängen - dies hat die Semantik (zumindest für mich) kristallklar gemacht.

IMO sollten wir keine ausgefallenen Wörter wie "Veränderlichkeit" und "unveränderlich" verwenden müssen, um über dieses Zeug zu sprechen. Etwas kann auf ein neues Objekt zurückgebunden werden, oder es ist konstant. Die Notwendigkeit komplexer englischsprachiger Wörter wie struct und immutable vollständig aus unserem Diskurs über Julia (nicht nur den Code) zu streichen, sollte als eine gute Sache angesehen werden (sogar ein Ziel).

Ich habe auch das Gefühl, dass "struct" ein eigenes Wort ist (was bedeutet, was es in C bedeutet), während "struct" wahrscheinlich eine "Datenstruktur" ist - denn wenn Sie einen Datensatztyp meinen, würden Sie "struct" sagen. Aber ich zeige hier meine C-Wurzeln.

Es ist auch allgemein lisp; defstruct .

Wahrscheinlich trivialer als die meisten anderen Punkte hier, aber solange wir mit dem Fahrrad fahren: Wenn wir laut gesprochen werden, klingen die Sätze immutable object und a mutable object ärgerlich ähnlich. Es würde das Gespräch über Julias Typsystem schwieriger machen, als es sein muss. EDIT: Es scheint, dass dies bereits in diesem Thread angesprochen wurde .

+1 bis type -> struct und immutable -> const struct . Ich glaube nicht, dass ich jemals jemanden getroffen habe, der davon verwirrt wäre, besonders nach einer flüchtigen Erklärung.

Das Ersetzen von type ist für v0.6 realistisch und für v0.8 unrealistisch. Wir sollten das tun. Es ist eine Gelegenheit, Julias natürliches Talent für klare Kommunikation und Ausdrucksgeschwindigkeit zu verbessern und zu verbessern. Typen arbeiten so gut daran, Software zu erstellen, die funktioniert. Eine bessere Benennung typischer Dinge schwingt stark mit und wird Julia eine größere Zukunft bescheren.

Ich schlage vor, struct unbenutzt zu lassen. In C ist eine Struktur ein syntaktischer Container für eine feste Folge typfester Felder. Julia ist nicht C, und ein C-Ismus in den julianischen Diskurs zu ziehen, würde Julias epiphemere Natur aus der ernsthaften Diskussion über die besten Verwendungsmöglichkeiten und besseren Möglichkeiten zur Konzeptualisierung von Aspekten von Julia herausdrücken.

Außerdem sind "unveränderlich" und "veränderlich" zu visuell übereinstimmend. Wir können es besser machen.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@ JeffreySarnoff Abgesehen davon wird es gemäß den Community-Standards bevorzugt, Julia als "es" zu bezeichnen. Ich dachte nur, ich würde es erwähnen. 🙂

@ararslan Die Community-Standard-Anleitung zu Julia scheint sich geändert zu haben und verzichtet nun auf die Anwendung von Literaturpronomen. Vielen Dank, dass Sie mich darauf aufmerksam gemacht haben. :Kricket:

Die Verwendung des Femininpronomen ist an sich nicht schlecht (und in vielen Sprachen unvermeidlich), aber es scheint, dass viele es unwiderstehlich finden, von der Verwendung des Begriffs "sie" zur Rede von Julia als heißem Date zu springen, also scheint es am besten zu sein Vermeiden Sie die Versuchung so weit wie möglich.

Danke

Am Do, 3. November 2016 um 16:29 Uhr, Stefan Karpinski [email protected]
schrieb:

Die Verwendung des Femininpronomen ist an sich nicht schlecht (und bei vielen unvermeidlich
Sprachen), aber es scheint, dass viele es unwiderstehlich finden, von der Verwendung zu springen
der Begriff "sie", um über Julia als heißes Date zu sprechen, also scheint es am besten zu sein
Vermeiden Sie die Versuchung so weit wie möglich.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

In Bezug auf das vorliegende Problem bin ich persönlich unentschlossen, was ich als die beste Änderung betrachten würde. Aber es scheint mir seltsam, über Julias erstaunliches Typsystem zu sprechen und dann anzugeben, dass das Schlüsselwort, das zum Erstellen eines Typs verwendet wird, tatsächlich struct und nicht type . Ich denke, es könnte die Leute dazu ermutigen, stattdessen über Typen als Strukturen zu sprechen, was schließlich zu einer Verschiebung der Sprache führt, die zur Beschreibung von Julia verwendet wird, z. B. über Julias erstaunliches Konstruktionssystem.

Das Schlüsselwort, das zum Erstellen eines Typs verwendet wird, ist eher struct als type

Bei dem Schlüsselwort geht es jedoch nicht wirklich darum, Typen zu konstruieren. Beispielsweise erstellt der Ausdruck Tuple{Int} auch einen Typ. Es wäre großartig, wenn die derzeit mit type definierten Dinge immer als struct s bezeichnet würden, da es dann keine Verwirrung darüber geben würde, wie Real ein Typ ist und Union{Int8,Int16} ist ein Typ usw.

Ja, ich bearbeite meine vorherige Notiz und habe gerade darüber geschrieben. Es wäre
allgegenwärtig schädlich für die "Pflege und Ernährung" der Julia und der
zukünftige Entwicklung von Ausdruckskraft und Prägnanz. Sollte die Tür sein
geöffnet, um die Berücksichtigung von Julias Typensystem als legitim zu machen
Gerüst auf C-Strukturen, der Krieg ist verloren.

Am Do, 3. November 2016 um 16:38 Uhr, Alex Arslan [email protected]
schrieb:

In Bezug auf das vorliegende Problem bin ich persönlich unentschlossen, was ich tue
würde die beste Änderung in Betracht ziehen. Aber es scheint mir seltsam, darüber zu sprechen
Julias erstaunliches _type_-System und geben Sie dann an, dass das Schlüsselwort verwendet wurde
Ein Typ zu konstruieren ist eigentlich eher eine Struktur als ein Typ. Ich denke es könnte
Ermutigen Sie die Menschen, stattdessen über Typen als Strukturen zu sprechen und schließlich zu führen
zu einer Änderung der Sprache, die zur Beschreibung von Julia verwendet wird, z. B. zur Erörterung von Julia
erstaunliches _struct_ System.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

Es wäre großartig, wenn die derzeit mit type definierten Dinge immer als struct s bezeichnet würden, da es dann keine Verwirrung darüber geben würde, wie Real ein Typ ist und Union{Int8,Int16} ist ein Typ usw.

Gibt es derzeit Verwirrung darüber? Ich denke, so viel schien mir offensichtlich, obwohl ich vielleicht Diskussionen darüber verpasst habe.

@ararslan : Der Begriff type ist für das, was derzeit erstellt wird, viel zu allgemein. Was wir derzeit mit dem Schlüsselwort type konstruieren, ist eine Struktur, die aus zusammengesetzten Typen besteht. Es gibt jedoch viele andere Typen in Julia, die nicht mit dem Schlüsselwort type .

Nein, ich glaube nicht, dass es derzeit zu viel Verwirrung gibt, aber jeder würde auch nicht denken, dass alle Julia-Typen Strukturen sind, wenn wir das Schlüsselwort struct .

Okay, guter Punkt.

und Union {Int8, Int16} ist ein Typ

Ah. Ich hatte vergessen, dass es auch Union gibt. Was das Argument für struct ( Struct ?) Überzeugender macht, IMO. Ich mag mutable und immutable trotzdem nicht.

Ich finde _struct_ schmachvoll und glaube wirklich, dass das Tragen von Julia im Laufe der Zeit den sich entwickelnden Zeitgeist nach unten ziehen würde. Das Prinzip ist ein Antagonismus zwischen der Darstellung von bewegten Bits und dem Ausdruck von rechnerischen Maybes als Verschmelzungen höherer Ordnung und tieferen Gestalten. Dass die Verwendung von struct nicht dazu führen würde, dass jeder an Typen denkt, die eine Struktur enthält, ist nebensächlich. ... lass mich überdramatisieren ...

Ich kann nicht behaupten, dass das Schreiben über Einstein als Patentangestellter die Wertschätzung seiner Beiträge mindert. Daraus folgt nicht, dass in einem Kurs, in dem Verweise auf Albert Einstein die Bedeutung seiner Zeit als Patentangestellter betonen, mehr als einige Studenten in zukünftigen Gesprächen einen Sinn dafür entwickeln würden. Dass eine Sache so stellt nicht sicher, dass sie sich nach dem Umzug in eine neue Schule nur so verhält.

Wenn es einen überzeugenden Fall für die Verwendung von _struct_ gibt, sollte es einen besseren Fall für einen von geben

a structure ist eine sinnvolle Wechselbeziehung von Teilen, eine informierte Komposition
Ein construct ist eine nützliche Strukturierung von Relevanzen, ein wertsteigerndes Design

Ein unveränderliches structure ist ein dauerhaftes Komposit
Ein veränderliches structure ist eine nicht festgelegte Vorauswahl
Ein unveränderliches construct ist eine etablierte Eventualität
Ein veränderliches construct ist eine absichtliche Einschränkung des Kontexts

Wir brauchen sowohl die Sprechweise "Bits an Orten und durch Tore" als auch die "Datenstrukturierung enthüllt ontologische Informationen", die als Transformationsmodifikator-Sprechweise zur Verfügung gestellt werden können. Community-Teilnehmer, die CS-Talente sind, und die meisten anderen Domain-Experten, die im Großen und Ganzen programmieren, haben einen gründlichen Umgang mit Bytes, Speicher, Logik, angewiesenen Operationen usw. Die andere Art, Wünsche, Kreativität, Möglichkeiten und Vorstellungskraft zu erzeugen, wird zu Software, die gut funktioniert und funktioniert Die Arbeit lohnt sich - das wird weniger geteilt. Jede Entscheidung über die Benennung von Begriffen sollte getroffen werden, um dieses Gespräch zu fördern.

Was ist mit class und immutable ?

Ich kenne die Klasse von Delphi und dachte, dass es hier unmöglich wäre, aber in der Nizza-Sprache, die Multimethoden hat, wird sie als Schlüsselwort ( Link ) verwendet. Und - wenn ich die Handbücher richtig lese - auch in Haskell und Dylan. Es besteht den Test "Klasse ist eine Art von Typ" und ist immer noch ziemlich vage (als "Typ" heute), was mir gefällt. In dem Video "Ein Überblick über Arrays und Iteration" zwischen 15:00 und 15:20 Uhr sagt Tim Holy (aus Versehen) "Klasse", ein unwichtiges Detail, zeigt aber möglicherweise, dass die Klasse im Julia-Kontext nicht völlig fremd wäre.

Ansonsten reftype und immutable ? Der Reftype-Begriff wurde im ersten Kommentar erwähnt und seitdem ignoriert. Warum? Für mich klingt es ganz nett, macht Typ frei und transportiert die Referenzbedeutung.

(Ich habe den Zweck des Schlüsselworts "neu" nicht verstanden. Könnte "neu" nicht in allen Zeilen ohne Änderung weggelassen werden? Die Begriffe "Wert" und "Datensatz" wären Schlüsselwörter und ersetzen die derzeit verwendeten "unveränderlichen". und 'Typ', richtig?)

@swissr Der einzige Unterschied (den die meisten Benutzer beachten sollten) zwischen diesen beiden Typen besteht darin, dass sich die Felder in einem ändern können und in den anderen nicht. Es wäre logisch, wenn ihre Namen ihre einzige semantische Unterscheidung anzeigen würden. (Wie bereits erwähnt, sind die Implementierungen unter Verwendung von Werten und Referenzen fließend - z. B. kann ein verbesserter Compiler als Optimierung automatisch große isbits -Typen als Referenz übergeben, und umgekehrt können kleine Mutables in bestimmten Situationen auf den Stapel verschoben werden.)

In Bezug auf type vs struct sehe ich, dass ich abstrakte Datentypen mit abstract , Union{} , typealias und so weiter erstellen kann ( im Fall von Tuple{} es fraglich, ob es sich um einen neuen Typ oder nur um einen parametrisierten Typ handelt), aber tatsächlich werden die einzigen vom Benutzer definierten konkreten Typen durch bitstype , type und erstellt immutable . Die Syntax für diese ist für die abstrakten Definitionen insofern unverkennbar, als sie die Daten definieren, die sie irgendwie enthalten, und die abstrakten nicht. Das Ändern von immutable in const type scheint mir die Situation klar zu machen.

Ich mache mir Sorgen um die Sprache und die Verbreitung des technischen Wortes struct Der einzige Grund ist die Tradition, wenn wir die Möglichkeit haben, eine Programmiersprache zu erstellen, die in Laienbegriffen diskutiert wird. Ein Beispiel dafür, wo ich denke, dass dies nicht hilft, ist das Erstellen eines Wrapper-Typs wie Symmetric{Matrix{T}} - Ich möchte nicht, dass meine Diskussionen "Ich habe dieses struct mit nur einem Feld erstellt was ... "wenn ich sagen kann" Ich habe einen Symmetric Wrapper type für Matrix "(beachten Sie, dass die Hälfte dieses Satzes die tatsächliche Syntax ist). Eine "Wrapper-Struktur"? Klingt irgendwie albern - und wer macht eine Struktur mit einem Feld? Was ist mit Singletons ohne Felder? Ein beträchtlicher Anteil von types und immutables gibt keine (nicht-triviale) Datenstruktur zu schaffen , definiert , sondern vielmehr mit dem ausdrücklichen Ziel , die leistungsfähige Art und Versandsystem mit Umhüllungen und Singletons verwenden. IMO ist dies der interessanteste, kraftvollste und ausdrucksstärkste Aspekt von Julia (kombiniert mit der Tatsache, dass es schnell ist).

Ich bin der Meinung, dass die volle Leistung von struct nur erfahrenen Template-C ++ - Metaprogrammierern sofort klar ist, die wissen, dass sie Merkmale usw. mit Strukturen implementieren können, und das ist ein bisschen schade.

"Art" hat in der Typentheorie eine ziemlich spezifische technische Bedeutung .

Wenn das Ziel / der Vorteil darin besteht, type freizugeben, wie wäre es dann mit:

const datatype  # immutable
datatype        # type

Da es sich um konkrete Typen handelt, enthalten sie wahrscheinlich Daten, und dies ist eine (von vielen) Möglichkeiten, ein DataType erstellen.

"Art" hat in der Typentheorie eine ziemlich spezifische technische Bedeutung.

Die Einführung in das Wiki klingt genau wie Type{} (das DataType und TypeConstructor , Union usw. akzeptiert) (BEARBEITEN: nicht, dass ich eine solche Änderung denke ist die Störung wert)

kind ist hier nicht das richtige Wort.

Ich bin der Meinung, dass der beste Ansatz meistens darin besteht, nur ein Feld zu lernen
Standardvokabular, anstatt zu versuchen, es durch etwas zu ersetzen, das Sie
Vermutung wird einfacher sein.

Diese Entscheidung hat keinen Einfluss auf die informelle Sprache. Sie können immer noch vernünftig sagen "Ich
definierte einen Typ ". Die Verwendung eines spezifischeren Schlüsselworts macht es nur einfacher, wenn
Sie müssen präzise sein.

Guter Punkt, Jeff. Bitte beachten Sie, dass ich _do_ denke, dass const struct und struct eine Verbesserung gegenüber immutable gegenüber type (aber das bedeutet nicht, dass wir nicht danach suchen sollten etwas noch besseres).

Wenn Sie denken, Struktur ist diese Wahrnehmung eher eine Struktur oder ein Konstrukt, keine oder beide?

@andyferris Mein Kommentar zu 'class' und 'reftype' bedeutete nicht, dass ich 'const type' nicht mögen oder nicht unterstützen würde, dass const struct und struct eine Verbesserung wären. Es war ein weiterer Versuch, nach möglichen Begriffen zu suchen, um "const" zu vermeiden, "unveränderlich" zu erhalten und "struct" fernzuhalten (war sich der erwähnten Implementierung bewusst, dachte aber, wenn sie in etwa 80% der Fälle korrekt ist, ist sie in Ordnung). .

Wie wäre es mit fieldtype (oder fieldstype )? Es ist parallel zu bitstype und konsistent mit fieldnames() .

Tal,
Ich mag die Wahrhaftigkeit. Feldtyp ist die bessere Wahl, da die Verwendung einer Pluralform, bei der etwas Singular oder Plural sein kann, richtig ist.
- Jeffrey

class könnte in Ordnung sein; Wir haben es ursprünglich abgelehnt, weil es mit klassenbasiertem OO mit Methoden in Objekten verknüpft ist. Ich würde sagen, struct ist genauer.

Ich sehe struct für nichts als kurz an; Es ist genau das, was diese Art von Datenstrukturen an dieser Stelle genannt wird. Etwas amüsant ist, dass lisp cons , was ursprünglich eine Abkürzung für construct , aber die Leute vergaßen das ziemlich schnell und sprachen gerade über "Nachteile-Zellen".

Ich denke, wir sollten weiterhin class ablehnen. Die Verwendung dieses Begriffs würde eine ganze Reihe von OOP-Erwartungen einladen, die dem Julia-Stil zuwiderlaufen.

Ich sehe struct für nichts als kurz an, aber ich mache mir Sorgen, dass der implizite Verweis auf Cs Strukturen impliziert, dass Julias Werttypen wären, was sie natürlich nicht sind. Zu diesem Zweck neige ich derzeit ein wenig zu record da es weit weniger unmittelbare Konnotationen hat.

Um einen Punkt zu verdeutlichen, der möglicherweise nicht klar ist, denke ich, dass die Verwendung von const record oder const struct nur sinnvoll ist, wenn sie so interpretiert wird, dass sie für die Zuordnung von const über alle Felder kurz ist Dies bedeutet, dass wir das Markieren einzelner Felder als const unterstützen möchten. Ich sage also, dass wir diese haben könnten:

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

Hier beschreiben T3 und T4 tatsächlich äquivalente Typen - dh das Schreiben von const record ist nur eine Abkürzung für alle Felder, die const . Wenn dies nicht die Interpretation ist, denke ich, dass die Verschmelzung von Unveränderlichkeit mit Beständigkeit gefährlich ist, da dies bereits eine häufige Quelle konzeptioneller Verwirrung ist, und wenn wir diese terminologische Verwirrung ergänzen, werden wir den Dingen nicht helfen.

Hier beschreiben T3 und T4 tatsächlich äquivalente Typen - dh das Schreiben eines const-Datensatzes ist nur eine Abkürzung für alle Felder, die const sind.

Wenn wir const record bedeuten lassen, was immutable jetzt bedeutet, ist dies möglicherweise nicht der Fall. const record würde einen Referenztyp beschreiben, für den keines der Felder geändert werden kann. Während das aktuelle immutable ein Werttyp ist.

Unter https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 und dem folgenden Kommentar finden Sie einige Erläuterungen zu record .

@vtjnash Das ist ein guter Punkt, aber es ist ähnlich wie jetzt, wo ein immutable zu einem "Referenz" -Typ wird, wenn er Referenzen enthält.

Ich denke, die Tatsache, dass record weniger häufig ist, ist in Ordnung, die Tatsache, dass es ein nützliches Wort ist, da sowohl ein Substantiv als auch ein Verb problematischer sind.

Wie wäre es mit nuple ? Natürlich die Abkürzung für "Named Tuple".

Ich mag den oben gemachten Vorschlag von

const datatype  # immutable
datatype        # type

bisher am besten. Es vermeidet es, ein altes Wort mit historischem Gepäck einzubringen, und scheint mir völlig klar zu sein. Sicher, es ist nicht der einzige Datentyp in Julia, aber es ist der häufigste, der von normalen Benutzern definiert wird.

Gibt es Pläne zur Erläuterung dieses in der Dokumentation auch die Terminologie zu ändern, mehr auf den Punkt ändern wie die Titel der Kapitel dieses ? Wenn nicht, denke ich, ich mag composite und immutable composite oder const composite besten. Da const auch für globale Konstanten verwendet wird, würde ich für beide entweder const oder immutable wählen, wobei const leicht bevorzugt wird, weil dies der Fall ist kürzer. Zumindest wird das Wort Composite den meisten Neulingen nicht bekannt vorkommen, was einen Blick in die Dokumentation erzwingt und falsche Annahmen aufgrund der Ähnlichkeit mit einem C-Namen vermeidet. Falsche Annahmen bezüglich const scheinen weniger wahrscheinlich zu sein, da jeder, der dies in C ++ gewohnt ist, weiß, nichts anzunehmen.

Auch der Vorteil der Verwendung von zwei Wörtern als Hinweis auf Unveränderlichkeit macht eine mögliche Zukunft frei const abstract und const bitstype falls dies jemals erforderlich sein sollte.

Wenn wir const record bedeuten lassen, was unveränderlich jetzt bedeutet, ist dies möglicherweise nicht wahr. const record würde einen Referenztyp beschreiben, für den keines der Felder geändert werden kann. Während der Strom unveränderlich ein Werttyp ist.

Oh oh. Ich dachte, der Wert oder Nicht-Wert von immutable wurde auf Implementierungsebene definiert, und der Benutzer sollte nur berücksichtigen, dass Felder nicht neu gebunden werden können. Das Übergeben von Werten (oder nicht) ist dann ein reines ABI-Problem, bei dem der Compiler grundsätzlich frei wählen sollte, was effizienter ist. Für mich scheint die vom Benutzer sichtbare Semantik von unveränderlich genau gleichbedeutend mit der Anwendung der aktuellen Semantik von const auf alle Felder eines Typs zu sein.

Bin ich immer noch verwirrt über die beabsichtigte Semantik auf Benutzerebene von unveränderlich, oder sprechen Sie hier über Implementierungsdetails?

Wie wäre es mit Nupel? Natürlich die Abkürzung für "Named Tuple".

Kann auch mit record , oder? Ein benanntes Tupel ist beispielsweise das, was ein record in Erlang ist. Und ich denke auch in der Datenbankwelt.

Aber wenn Julia mehr Überschneidungen mit Leuten hat, die auch C , ist struct eine angemessenere Änderung.

Ich persönlich finde record irgendwie bizarr und unklar. In der Datenbankwelt ist ein Datensatz eine Zeile in einer Tabelle. das scheint ein verwirrender Konflikt mit etwas so Allgemeinem wie einem Julia-Typ (unveränderlich oder auf andere Weise) zu sein.

Nachdem ich diesen Thread noch einmal gelesen habe, neige ich zu composite für type . Es enthält Jeffs "Ein-Satz-Regel" und es gab nicht so viele negative Stimmen dafür. Dass der Begriff in anderen Sprachen nicht so häufig verwendet wird, ist meiner Meinung nach kein Problem. Und composite ist wirklich das aussagekräftigste Wort, das man dafür finden kann. Aus diesem Grund werden diese Dinge in der Dokumentation als composite types .

Ich komme aus Fortran und denke immer noch, dass das Schlüsselwort type in Ordnung ist.
und eine vernünftige Mindeständerung wäre immutable -> const type .

Aber wenn type wirklich gehen muss,
composite und const composite scheinen die nächstbeste Wahl zu sein.

immutable -> const type scheint durchaus realisierbar: Gleichzeitig werden Störungen vermieden, ein Schlüsselwort entfernt und die Sprache klarer.

Es mag traurig sein, type nicht verwenden zu können, aber um ehrlich zu sein, ist das, was ich verwenden möchte, trotzdem Type . Neun von zehn meiner Typvariablen sind Parameter für den statischen Versand, nicht DataType Variablen für die dynamische Typanalyse (die Ausnahme sind generierte Funktionen). Nicht wahr für Leute, die inference.jl schreiben, aber sie sind nicht wirklich die "Zielgruppe" der Sprache, wenn Sie so wollen.

Verwandte Frage: Ist es überhaupt möglich, type wie auf oberster Ebene zu verwenden, aber innerhalb einer Funktion (wo sie derzeit immer ungültig ist) zuzulassen, dass es sich um einen Variablennamen handelt? Oder noch weiter, die Struktur einer Typdefinition ist ziemlich spezifisch ... könnten wir Typdefinitionen als spezifische Syntax erkennen und gleichzeitig zulassen, dass sogar globale Variablen (oder Funktionen) an type gebunden werden?

Dh können wir das Keyword-Verhalten beseitigen, während wir die Syntax zum Definieren eines Typs beibehalten?

(unwahrscheinlich imo) Es besteht ein starkes Risiko: Es wird zu leicht, dass die eigenwillige Lexikographie ablenkt. Und diese fehlenden Mikrokontinuitäten sind zerstörerisch, um die Zusammenarbeit und die klare Kommunikation zu vereinfachen.

@ c42f :

Bin ich immer noch verwirrt über die beabsichtigte Semantik auf Benutzerebene von unveränderlich, oder sprechen Sie hier über Implementierungsdetails?

Nein, bist du nicht - ich war schlampig. Immutables sind keine wirklichen Werttypen, aber Mutables sicherlich nicht, und ich hatte das Gefühl, dass die Verwendung der gleichen Begriffe wie C darauf hindeuten könnte, dass sie es sind.

Ich habe gerade festgestellt, dass es im Kontext von C nicht klar ist, ob es sinnvoll ist, Strukturen als "Werttypen" zu bezeichnen, da die tatsächliche Situation darin besteht, dass C eine Pass-by-Value-Sprache ist. Es sind also wohl die Übergabe- und Zuweisungskonventionen, die unterschiedlich sind, nicht die Datentypen selbst.

Ich bin voll und ganz dafür, die Änderung in Kraft zu setzen, die dieses Problem eröffnet. Die Nützlichkeit überwiegt jede viszerale Präferenz, dass einer der Kandidatenbegriffe anstelle eines anderen verwendet wird.

_obwohl_

da die tatsächliche Situation ist, dass C.

fängt gut ein, warum von den Kandidatenbegriffen struct am wenigsten bevorzugt wird

Hier ist die Geschichte, die ich verkaufe: "Sowohl in C als auch in Julia ist ein struct eine Datenstruktur, die einen festen Satz von Feldnamen Werten verschiedener Typen zuordnet. Wenn Sie diese jedoch weitergeben, ist C pass -by-Value und Julia ist Pass-by-Sharing. "

Dieses Konto ist sowohl nicht belastend als auch vollständig korrekt. Alles darin kann erfolgreich gegoogelt werden. Kein PL-Theoretiker würde sich darüber beschweren, und Nicht-PL-Theoretiker würden etwas lernen, indem sie es hören.

Ich kaufe diese Geschichte. Obwohl ich mich frage, gibt es hier irgendwelche Begriffe, über die sich ein PL-Theoretiker beschweren würde? Ich denke gerne, dass Julia genau in diese Nische passt, die sowohl PL-Theoretiker als auch Nicht-Theoretiker zufriedenstellt. Daher scheint es entscheidend, hier ein Gleichgewicht zwischen Korrektheit und allgemeiner Klarheit zu finden.

Nun, ich möchte niemandem Worte in den Mund stecken. Ich wollte nur auf die Idee eingehen, dass struct verwirrend sein könnte, da Strukturen "Werttypen" sind.

Ich denke, immutable sollte ein Schlüsselwort mit einem Wort bleiben. Ich mag const type oder const struct oder immutable struct . Ich benutze immutable oft und ich denke, es wäre wirklich ziemlich umständlich, wenn diese Erklärungen zwei Wörter wären, wenn fast alles andere ein Wort ist. Nicht im Sinne des Tippens, da dies kein wirkliches Problem ist. aber in dem Sinne, dass unveränderlich wie ein "Tag" es sich zweitklassig anfühlt.

@TotalVerb Ich glaube nicht, dass das sehr gut mit der Tatsache vereinbar ist, dass

type MyType
    const field::Int
end

sollte sich genau so verhalten

immutable MyType
    field::Int
end

tut jetzt.

Angesichts dessen, dass ein const type (oder const struct , const composite oder was auch immer) die const als Verknüpfung an jedes Feld sendet, scheint dies eine nützliche Verknüpfung zu sein nicht unbedingt erforderlich). Ich würde hoffen, dass der Compiler in Zukunft nicht einmal weiß, welches Sie eingegeben haben ( const type oder const vor jedem Feld - das erstere könnte vom Parser in das letztere umgewandelt werden). Warum sollte man an diesem Punkt immutable behalten?

Unveränderlich wie ein "Tag" zu sein, macht es zweitklassig.

Wenn ich Jeff und Stefan richtig verstehe, dann ist immutable nur ein Tag, das besagt, dass die Felder eines Typs konstante Bindungen sind. Konstant zu sein (wirklich konstant, nicht wie C) hilft dem Compiler, Optimierungen vorzunehmen, und wenn die Felder selbst rekursiv Konstanten oder Grundelemente sind (dh isbits ), hilft es ihm, noch mehr Optimierungen vorzunehmen. Dies ist gut zu wissen, aber nicht semantisch wichtig. Die Verknüpfung der Semantik mit dem aktuellen Verhalten könnte es schwieriger machen, dieses Verhalten in Zukunft zu verbessern.

Aber es gibt einen wichtigen semantischen Unterschied: Unveränderliche Typen sind Werte, und daher kann man sicher annehmen, dass die Identität eines Objekts durch seine Felder angegeben wird. Ein Objekt eines unveränderlichen Typs hat aus Sicht des Benutzers kein spezielles "Identifizierungsmerkmal", auf das über seine Felder nicht zugegriffen werden kann. Andererseits hat jedes Objekt eines nicht singleton-veränderlichen Typs eindeutig diese unsichtbare "Identität". Die Tatsache, dass viele unveränderliche Typen als Boxobjekte gespeichert werden und daher diese zusätzliche Identität tatsächlich intern haben, ist für die Semantik irrelevant.

Meiner Meinung nach ist es nicht nur eine Optimierung

immutable Complex{T} ... end

Anstatt von

type Complex{T} ... end

weil sich viele Aspekte des vom Benutzer sichtbaren Verhaltens ändern: === , die Standardeinstellung == , objectid , hash usw. Es ist einfach nicht richtig, das zu sagen unveränderliche Typen bieten eine Teilmenge der Funktionalität veränderlicher Typen; im Gegenteil, die Tatsache, dass sie unveränderlich sind, bietet wichtige Garantien, die es unveränderlichen Typen ermöglichen, leistungsfähiger zu sein.

Bevor sich die Community für const und struct , wollte ich nur noch einen Plug für constant und structure .

1) Nur drei zusätzliche Buchstaben für tatsächliche Wörter!
2) Trotz Behauptungen, dass struct idiomatisch geworden ist
2a) Jemand, der von R migriert (wie ich), könnte verwirrt sein
2b) Jemand, der neu in der Programmierung ist (diejenigen, die die meiste Hilfe benötigen), könnte verwirrt sein

Nur zum Spaß, dumme Wörter, für die Struktur verwirrt sein könnte:
Unzerstörbarkeit
Obstruktionspolitik
Poststrukturalismus
der Überbau (oh hi Marx)

und const:
Konstantinopel
Konstellation
Boa-Constrictor
verfassungswidrig

Gibt es PL-Schönheit / Kraft, die durch multikontextuelle Unveränderlichkeit und Konstante dieser Art gewonnen wird: unveränderlich, die niemals durch / innerhalb ihres aufgelösten Referenten sendet (seine Natur projiziert) und Konstante, die durch eingebettete Referenten sendet, die nicht unveränderlich sind, als wäre es ein Adverb oder Gerundium?

Die gleiche Frage, mit anderen Worten:

Im Moment ist die Verwendung von Variablen im globalen Bereich problematisch, und das zu trick besteht darin, den variierenden Wert in einen konstanten Vektor mit einem einzelnen Eintrag zu verpacken. In diesem Fall wird const nicht gesendet. Eine Rundfunkversion von const würde eine Konstanz sowohl für den Wert des Eintrags im Vektor als auch für den Vektor bedeuten. Ebenso eine Typdeklaration mit Feldern, die Werte enthalten können, die andere Werttypen umschließen oder einschließen. Ein unveränderlicher Typ verleiht den Werten seiner Felder jetzt keine Unveränderlichkeit (und keinen Wert, der indirekt über seine Felder erreicht werden kann). Es gibt eine elegante und hilfreiche Fähigkeit, die mit einer Rundfunkversion eines Schlüsselworts einhergeht, das bedeutet, dass sich "der Wert, der diesem Element [oder Elementen dieses Typs] zugeschrieben wird, nicht ändert [darf nicht geändert werden]" .

Die unmittelbare (nicht sendbare) Sortierung ist weit verbreitet, und wenn Julias Vorkompilierung davon ausgeht, dass einige Dinge, die Menschen mit Julia tun, viel einfacher / schneller / einfacher zu verwenden sind oder sich auf die einführbare Konstanz der Einführung verlassen, muss dies abgespielt werden gut mit der sofortigen Sorte. Ich frage mich, ob dies ein Weg ist, der zusätzliche theoretische Programmiersprachengüte bringt (einfache Ausdrucksweise, Repräsentationskraft, ...): Die Sendekonstanz sendet durch Werte von Typen, die eingebettete Referenztypen haben und / oder? Sind indirekt enthaltene Typen bis (a) das Erreichen eines Wertes ohne interne Einbettungen oder Container oder (b) das Erreichen eines Wertes ist selbst (unabhängig oder auf andere Weise) von einem Typ, der keine Rundfunkkonstanz aufweist.

Wenn ich mehr darüber nachdenke, ist die einzige Änderung, die ich wirklich für den Bruch wert halte, bitstype -> primitive , hauptsächlich, weil es ärgerlich ist, etwas isbits .

Was den eigentlichen Punkt dieser Diskussion betrifft, type und immutable , an diesem Punkt ist die Option, die mir am besten gefällt, überhaupt keine Änderung. type zum Erstellen eines Typs ist klar, immutable zum Erstellen eines unveränderlichen Typs ist klar. Ich nehme jedoch gerne das, was uns unsere obersten Oberherren geben, da ich implizit auf ihr Urteil vertraue, was für die künftige Sprache am besten ist.

Gibt es einen Grund, nicht fest statt konstant oder konstant zu verwenden? Zumindest scheint mir eine viel klarere Beschreibung zu sein.

@JeffreySarnoff Es ist schwierig, const ness auf eine Sache zu implizieren, auf die Sie einen Verweis (dh einen Zeiger) erhalten können. Julias "Sharing" -Semantik bedeutet, dass alles, was der Compiler nicht als wirklich unveränderlich erweisen kann, ein Referenztyp sein muss. Wenn Sie einen solchen Verweis an das Feld eines const type ( immutable ) binden, gibt es keinen Beweis dafür, dass dieser Verweis an keiner anderen Stelle vorhanden ist, und daher keinen Beweis dafür, dass die Daten, auf die verwiesen wird, konstant sind.

Ich denke, dieses Verhalten zu ändern wäre eine wirklich grundlegende Änderung der Julia-Sprache.

@andyferris Vielen Dank für diese klare Antwort.

Gibt es einen Grund, nicht fixed anstelle von const oder constant ? Zumindest scheint mir eine viel klarere Beschreibung zu sein.

Ich hatte mich gefragt, ob es etwas Besseres als const oder constant das widerspiegelt, dass die Bindung dauerhaft ist und nicht (unbedingt), dass die Daten innerhalb des gebundenen Objekts unveränderlich sind. fixed geht in diese Richtung, aber ich habe das in anderen Sprachen nicht gesehen (andererseits habe ich auch Julias Bindungs- / Freigabesemantik in anderen Sprachen nicht bemerkt).

Vielleicht so etwas wie bind (zB bind x = 2 ) ... Thesaurus schlägt glue ... das wird ziemlich spekulativ ...

Die Idee, const durch etwas Präziseres zu ersetzen, ist verlockend. Wir möchten jedoch, dass es sowohl für die Typdeklaration als auch für die Zuweisung einzelner Variablen sinnvoll ist. fixed struct macht Sinn, aber es sind die Felder der Struktur, die fest sind, und nicht die Typdeklaration. Leider scheint bound struct ( tied struct ?) Ziemlich unklar. Aus irgendeinem Grund erscheint mir const klarer, wenn es auf einen Typ angewendet wird.

Wir möchten, dass es sowohl für die Typdeklaration als auch für die Zuweisung einzelner Variablen sinnvoll ist.

Ich denke, es wäre produktiv, das anzustreben

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

macht Sinn. Eine Verknüpfung vor type , struct oder was auch immer zu haben, wäre nur eine Verknüpfung, die das oben Genannte bedeutet.

Es könnte sinnvoll sein, dies zu einem Makro zu machen, wie andere wichtige Dekorationen, die den Charakter einer Sache verändern, wie z. B. @generated . Das würde noch ein weiteres Schlüsselwort entfernen ...

+1 für type -> composite , obwohl wirklich jede Änderung von type großartig klingt.

Ich wünschte, ich könnte über GitHub-Themen abstimmen, ohne dem Thread einen neuen Kommentar hinzufügen zu müssen ... Meine Stimme ist für mutable und immutable , es ist ziemlich ordentlich und sauber. struct wird überbeansprucht und betont den Mutability-Teil nicht.

PS: Kennt oder kann jemand zu GitHub beitragen und eine Abstimmungsfunktion hinzufügen? Ich habe sie auf der Seite "Kontakt" gefragt, aber meine E-Mail ging wahrscheinlich verloren.

Nachdem ich kürzlich zu Julia mit einem Hintergrund in vielen anderen Sprachen gewechselt bin, würde ich es vorziehen, wenn Julia nicht die Benennung im C-Stil übernimmt und alle verwirrenden Konstanzprobleme von C / C ++ berücksichtigt. Stattdessen hätte es mir erheblich geholfen, einer Datentypdeklaration einen Begriff zu geben, der irgendwie die Absicht widerspiegelt, ein Werttyp oder ein gemeinsamer Referenztyp zu sein, anstatt einfach auf Veränderlichkeit zu verweisen.

Meine anfängliche Erwartung an Julia wäre gewesen, dass sich ein einfaches type ähnlich wie ein unveränderliches C struct -Stil
Ich bin immer noch verwirrt über die Asymmetrie im Wortlaut von type ... und immutable... , aber ich bekomme ein DataType von typeof(SomeType) oder die tatsächliche Bedeutung von 'Bitstype' 'und die Notwendigkeit eines Schlüsselworts typealias anstelle einer einfachen Anweisung Alias = DataType .

Daher würde ich für datatype stimmen, was mit typeof(SomeType) == DataType übereinstimmen würde und die irritierende Ähnlichkeit mit ::Type{} brechen würde. Das Dekorieren des veränderlichen Typs mit composite [datatype] könnte seine besondere und möglicherweise teurere Natur im Vergleich zu den grundlegenden 'Bitstypen' hervorheben.

Alle verwirrenden Konstanzprobleme von C / C ++ werden berücksichtigt

Kein Umbenennen dieses Schlüsselworts würde dies tun. Diese Probleme haben mit statischen Überprüfungen und Abgüssen zu tun, die hier überhaupt nicht beteiligt sind.

Die Absicht, ein Wertetyp oder ein gemeinsamer Referenztyp zu sein, hätte mir erheblich geholfen, anstatt nur auf Veränderlichkeit zu verweisen

Ich verstehe das nicht ganz. Wenn ein Objekt unveränderlich ist, kann nicht festgestellt werden, ob es als Wert oder Referenz übergeben wurde. Wie kann die Unterscheidung zwischen Wert und Referenz also grundlegend sein?

datatype ist keine schlechte Wahl. Aber ich denke nicht, dass datatype vs. composite datatype ein guter Weg ist, um die Mutabilitätsunterscheidung zu vermitteln.

@ JeffBezanson , mit C-ähnlicher const struct .

In Bezug auf 'Wert vs. Referenz': Es hat eine ganze Weile gedauert, bis ich verstanden habe, warum ein unveränderlicher Typ die Mitglieder direkt einbettet und einen schönen und kompakten schnellen Assembler-Code erzeugt, aber 'Typ' hat und enthält nicht alle Aufrufe von Objekten. Oder mit anderen Worten, warum ich normalerweise ein NTuple verwenden möchte, wenn ich Geschwindigkeit anstrebe. Wenn ich also "unveränderlich" und "veränderlich" gelesen hätte, hätte ich die Bedeutung als "Parameter" in Fortran erwartet, aber nicht auch die Änderung des Layouts oder der Art der Implementierung des tatsächlichen Datentyps.
Wahrscheinlich möchte man die meiste Zeit eine Semantik mit unveränderlichem Wert für kleine zusammengesetzte Typen wie einen Komplex haben, aber für große Datenmengen wie Arrays usw. "veränderlich und referenzierend / nicht kopierend".
Dann ist die zugrunde liegende Absicht wahrscheinlich nicht die Veränderlichkeit, sondern das Vermeiden des Kopierens von Daten.

Dies war jedoch meine Erfahrung beim Erlernen der Low-Level-Maschinerie von Julia, um schnellen Assembler-Code zu erhalten, aber ich weiß nicht, wie ich dies bei der Benennung von Schlüsselwörtern besser widerspiegeln und wie ich dies nur mit Veränderlichkeit kombinieren oder ausdrücken kann.

Ich verstehe, woher Sie kommen @mjw, ich war dort, aber ich denke, Sie sollten besser alles verlernen, was Sie über C / C ++ wissen. Hier ist es die const -Eigenschaft, die unveränderlich ist und ob etwas gestapelt oder dynamisch zugewiesen wird und ob es als Referenz oder Wert übergeben wird, frei variieren kann und Optimierungsoptionen für den Compiler darstellt. Sie können eine Sprache erstellen, in der alles dynamisch zugewiesen und als Referenz übergeben wird. Dies ist Julias Standardmethode (bei Boxed-Werten wird "Pass by Sharing" implementiert, auch wenn der Typ unbekannt ist). Sie (und der Rest von uns) bemerken, dass kleine unveränderliche Dinge so viel schneller sind, weil dort derzeit Optimierungen implementiert werden. Dies ist das Ergebnis der Semantik von immutable , die Optimierungen erleichtert.

Aber wirklich, ich würde es vorziehen, wenn große unveränderliche Objekte als Referenz übergeben würden (vielleicht durch Stapelzeiger, wo dies sinnvoll ist, aber es ist wahrscheinlich am besten, ein NTuple{1_000_000} häufen) und dass kleine Mutables bekannter Größe stapelweise zugewiesen werden (wieder wo möglich). In einigen Fällen kann sogar die Speicherbereinigung statisch bestimmt werden, sodass der Heap-Speicher beispielsweise in Schleifen wiederverwendet werden kann. Ich stelle mir diese als zukünftige Optimierungsmöglichkeiten vor, die eine Escape-Analyse erfordern (und keine davon beeinflusst die Semantik der Sprache, nur die Leistung).

Ich denke, ich sage, dass die Schlüsselwörter die Semantik widerspiegeln müssen, die ein oder zwei Jahrzehnte lang konstant bleibt, und keine Implementierungsdetails, die sich in ein paar Jahren ändern werden (dh effiziente kleine veränderbare und effiziente große unveränderliche).

Ich meinte die möglicherweise implizite Erwartung, dass der Julia-Typ dasselbe Verhalten wie in C / C ++ hat

Dies könnte an sich schon ein guter Grund sein, const -> constant in Betracht zu ziehen, um ehrlich zu sein. Ich denke, const könnte im Moment unser einziges abgekürztes Schlüsselwort sein, was es sowieso zu einem merkwürdigen macht.

eine einfache Alias = DataType Anweisung.

Ich bin mir ziemlich sicher, dass dies absolut in Ordnung ist, wenn es sinnvoll ist, aber es erlaubt keine komplexeren Änderungen des Typs, z. B. typealias RealMatrix{T<:Real} Matrix{T} , und sollte es auch nicht (es ist eine einfache Bindung, die kein neues Type mit neuen TypeVar s). Es sei denn, Sie möchten es anders herum definieren: RealMatrix = Matrix{T <: Real} und verallgemeinern, was apply für ein TypeVar tut (dh ein TypeConstructor ) ... tatsächlich Das ist eine interessante Idee (aber es gibt Syntaxprobleme, weshalb typealias nett ist ...).

@andyferris , ich habe bereits "verlernt", aber für andere neue Benutzer ist es möglicherweise einfacher, die Phase "Warum ist Julia trotz Kompilierung so langsam

@mjw Großartig, und ich stimme dem alles zu. :) :)

Sagen Sie was, lassen Sie uns versuchen, mit einer der besten GitHub-Funktionen einer Umfrage so nahe wie möglich zu kommen: Reaktions-Emojis.

Hier habe ich _in keiner bestimmten Reihenfolge_ die Vorschläge aufgelistet, die die größte Unterstützung zu haben scheinen. Reagieren Sie mit dem angegebenen Emoji, um Ihre Stimme für diesen Vorschlag abzugeben. Ich glaube, dies erfordert den Zugriff auf GitHub über einen Desktop-Browser. AFAIK-Reaktionsemojis wurden nicht in die mobile Schnittstelle implementiert. Klicken Sie auf das Gesicht in der oberen rechten Ecke dieses Beitrags, um auf das Menü der Emojis zuzugreifen.

| type | immutable | reagieren mit |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (lacht) |
| composite | const composite | : tada: (Hurra) |
| datatype | const datatype | 😕 (verwirrt) |
| type | const type | ❤️ (Herz) |

Wenn Sie nicht abstimmen, entspricht dies natürlich einer impliziten Abstimmung für nuple . :Troll Gesicht:

Ich muss sagen, ich bin kein großer Fan von umstrittenen Entscheidungen wie diesen "demokratisch". Wenn die Diskussion ohne Konsens stattgefunden hat, würde ich mich nur der Entscheidung der BDFLs widersetzen.

Fairer Punkt, @TotalVerb. Wie ich bereits sagte, wäre es völlig in Ordnung, wenn ich die Kräfte hätte, die uns nur das geben, was sie für das Beste halten. Mir scheint, der Thread schlängelt sich ein wenig und @juliohms Argument zur Abstimmung scheint vernünftig, also dachte ich mir, ich würde es

Persönlich glaube ich nicht, dass ich es mag, zwei Wörter ästhetisch zu haben ( const type ). Es fühlt sich auch ein wenig semantisch dissonant an. Wenn wir const x = 1 sagen. Wir meinen, dass x konstant ist. Wenn wir const type; x; end sagen, bedeutet dies, dass sich Instanzen dieses Typs nach der Erstellung nicht ändern. Aus der direkten Interpolation geht hervor, dass etwas ein konstanter Typ ist, was bedeutet, dass sich der Typ selbst nicht ändert (was bereits jetzt der Fall ist). Siehe auch:

type foo
end
const bar = foo

bar ist also const und es ist immer foo, aber es ist noch kein const type . Es fühlt sich so an, als würde die vorhandene Semantik von const (gilt für Bindungen) verwendet. Die Namen der Typen sind bereits const.

Ich vermute, dass es keine Schlüsselwörter gibt, die präzise sind, die beabsichtigte Semantik vermitteln und als Variablennamen wahrscheinlich nicht wünschenswert sind. Die Terminologie, die meiner Meinung nach diesen Zielen am nächsten kommt, lautet mutable datatype , immutable datatype und abstract datatype für die drei Arten deklarierter Typen.

Ich wünschte, zusätzlich zu type und immutable gäbe es einen zusätzlichen veränderlichen Werttyp.
Ich habe irgendwo in einigen Fragen einige Diskussionen gesehen, aber im Moment ist es im Grunde unmöglich, solche Szenarien effizient zu handhaben (korrigieren Sie mich, wenn ich etwas verpasst habe):

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  

Der Code erstellt ein ordentliches Array von Werttypen sizeof(T) * 10 . Um jedoch ein Feld zu ändern, muss das gesamte T(...) neu zugewiesen werden, was normalerweise 3-5 Felder lang ist.
Also im Grunde meine 5 Cent:
type - GC hat Referenz gesammelt
immutable - Werttyp (Stapel zugewiesen), der nicht geändert werden kann
mutable - Werttyp, der geändert werden kann, insbesondere in Arrays

Werttyp, der geändert werden kann

Ich denke, dies ist ein unmöglich zu erreichendes Ziel, da das Zulassen von Änderungen genau das ist, was etwas Objektidentität verleiht.

Vielleicht möchten Sie stattdessen diesen Ansatz: # 11902

Mit Ausnahme der Trennung von veränderlichen und unveränderlichen Stoffen sollte es besser sein, Werte und Referenzen aufzuteilen.

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

Es besteht keine Notwendigkeit, die Sprache durch eine künstliche Unterscheidung zwischen Werten und Referenzen zu komplizieren. Veränderbare und unveränderliche Typen sind semantisch viel einfacher; Die Tatsache, dass ein Typ ein Werttyp ist, ist lediglich eine Optimierung.

@ Keno macht einen guten Punkt

Persönlich glaube ich nicht, dass ich zwei Wörter ästhetisch mag (const-Typ). Es fühlt sich auch ein wenig semantisch dissonant an. Wenn wir const x = 1 sagen, meinen wir, dass x konstant ist. Wenn wir const type sagen; x; Ende würden wir bedeuten, dass sich Instanzen dieses Typs nach der Erstellung nicht ändern. Bei der geraden Interpolation fühlt es sich so an, als ob etwas ein konstanter Typ ist, was bedeutet, dass sich der Typ selbst nicht ändert (was jetzt bereits der Fall ist).

Wie ich bereits erwähnt habe, denke ich, dass die "richtige" Semantik gegeben ist durch

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

Hier verhält sich z.re genau so, als würden wir etwas eingeben, das const z.re = 1 ähnelt. Es gibt also keine semantische Verwirrung darüber, welche Bindung genau const .

Wie @JeffBezanson feststellt , ist dies für eine große Anzahl von Feldern nicht wirklich praktisch und nicht mit der aktuellen Implementierung von Typen kompatibel. Teilweise veränderbare, teilweise konstante Strukturen können in Zukunft implementiert werden oder nicht. Es gibt jedoch eine Syntax, die sowohl aktuell als auch in Zukunft sinnvoll ist:

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

Bei der aktuellen Implementierung kann ein Makro im AST den type von immutable ändern. Wenn in Zukunft teilweise konstante Strukturen implementiert werden, kann das Makro die Manipulationen am AST weiterhin ausführen, indem es jedem Feld const hinzufügt, und es wird allen und jedem klar sein, dass es sich um die Feldbindungen handelt die konstant sind. Ästhetisch ist es besser als zwei Schlüsselwörter hintereinander - wir machen ähnliche Dinge für Funktionen ( @generated , @inline , @proagate_inbounds usw.).

@const könnte leicht @immutable oder ähnliches sein ( <strong i="31">@immutable</strong> type Val{T}; end lautet OK, IMO) und die Makroidee ist kompatibel mit struct , composite , und so weiter.

@ be5invis ja, dies ist in vielen Sprachen üblich, z. B. in C # gibt es struct , das sich in vielerlei Hinsicht wie immutable verhält: Es wird per Kopie an Funktionen übergeben und explizit in zugewiesen Arrays (keine Verweise auf GC-verwaltete Objekte wie im Fall von class | type ). Es ist jedoch _veränderlich_ und kann in Arrays durch ein einzelnes Feld geändert werden.
Was ich glaube, dass es im Fall von immutable eine Mischung aus 2 Eigenschaften gibt:

1. Unveränderlichkeit (für eine ordnungsgemäße funktionale Programmierung)
2. Verhalten als Werttyp auf der unteren Ebene

Grundsätzlich würde ich gerne die Einführung eines Typs mit nur Eigenschaft 2 sehen. Dies wird die vorhandene Codebasis nicht stören ( immutable bleibt), aber für diejenigen, die etwas schnelles mit minimaler GC-Beteiligung schreiben, wäre es wertvoll .

@ Johnmyleswhite Danke für # 11902, glaube immer noch, dass es nicht so hässlich sein sollte

@wgreenr Wie bereits erwähnt und schon oft diskutiert, ist dies nicht möglich. Es hat auch nicht wirklich mit der Diskussion in dieser Ausgabe zu tun.

Alles ist möglich, aber die Einführung veränderlicher Werttypen wäre äußerst störend und eine sehr schlechte Idee. Ich kann verstehen , warum es eine scheinbar einfache und ansprechende Idee, aber das Hinzufügen eine neue, ganz andere Art von Objekt Semantik und gabele den Typen Graph in Referenz- und Wert Semantik ist nicht die Sprache besser gehen zu machen. Dies würde es unmöglich machen, generischen Code sicher zu schreiben, da derselbe Code je nach unbekannter Semantik sehr unterschiedliche Aufgaben ausführen würde. Es gibt eine ausführliche Diskussion mit Beispielen hier . Der Punkt von # 11902 besteht darin, die Vorteile veränderlicher Werttypen wiederherzustellen, ohne Dinge zu zerstören.

Ich bin mir nicht sicher, ob dies überhaupt erwähnenswert ist. In C / C ++ impliziert 'struct' aber auch etwas über das Layout der Daten. Andererseits lohnt es sich häufig, Strukturelemente neu anzuordnen, um ein besseres Speicherlayout zu erhalten. Wenn Sie eine bahnbrechende Änderung der Syntax in Betracht ziehen, könnte es sich lohnen, einen Mechanismus zu haben, um irgendwie zwischen 'Strukturen' (geordnet -> C-Interop) und 'unveränderlichen' (möglicherweise in irgendeiner Weise geordnet) zu unterscheiden.

Ich bin ziemlich neu bei Julia, also tut es mir leid, wenn ich etwas Offensichtliches verpasst habe.

Ich persönlich habe keine wirkliche Präferenz für Namen; Ich bin jedoch überrascht, dass niemand "konkret" vorgeschlagen zu haben schien, da es bereits "abstrakt" gibt.

Um noch einen weiteren Vorschlag hinzuzufügen, scheint mir Folgendes am besten zu sein:

• Verwenden Sie struct anstelle von immutable .

• Verwenden Sie struct! anstelle von type . Wenn Sie Englisch sprechen, sollte dies als "veränderbare Struktur" bezeichnet werden.

  • (Vielleicht) erlauben Sie, dass einige der Felder in einem struct! als const markiert werden.

Einige Rechtfertigungen und Gedanken:

1) Wenn ich nichts Offensichtliches verpasst habe, möchten Sie niemals eine Funktion mit einem ! , um einen Wert eines unveränderlichen Typs zu manipulieren. Wenn dies falsch ist (z. B. wenn es einen wichtigen Fall gibt, in dem sich der unveränderliche Typ auf einen veränderlichen bezieht und die Funktion mit einem ! ändert), ist dieser Vorschlag möglicherweise nicht gut.

2) Ich denke, dass unveränderliche Typen im Allgemeinen veränderlichen vorgezogen werden sollten, da sie mehr Optimierungen unterliegen und für den Programmierer ein vorhersehbareres Verhalten aufweisen.

3) Damit dies funktioniert, ist es wahrscheinlich eine Voraussetzung, die Optimierungen zu implementieren, um unveränderliche Typen in fast allen Fällen mindestens so effizient wie veränderbare Typen zu machen. Insbesondere sollte der Compiler klug sein, große unveränderliche Typen als Referenz zu übergeben.

UPDATE : Früher hatte ich record anstelle von struct , aber record! ist zu sehr wie ein Verb. Einige andere Optionen, die mir in den Sinn kommen: newtype , typedef (was C-Programmierer 10 Sekunden lang verwirrt), composite oder concrete wie oben vorgeschlagen .

Ist es wahrscheinlich, dass in diesem Bereich vor dem Einfrieren der v0.6-Funktion etwas passiert?

Wahrscheinlich nicht, da (zumindest öffentlich) keine Entscheidung getroffen wurde und wir nur noch ca. 10 Tage vom Einfrieren entfernt sind.

Ich habe dies nicht sorgfältig verfolgt, aber ein Kommentar ist, dass ich, wenn sich dies ändert, darum bitten möchte, dass wir zuerst eine wirklich gute Berichterstattung über die betreffende Datei- / Zeilennummer haben. Oder zumindest das Modul; In 0,5 ist es manchmal immer noch schwierig herauszufinden, welches Paket ein @deprecate d _binding .

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