Julia: 미친 아이디어 :`type` 키워드 변경

type 라는 단어를 다른 컨텍스트에서 사용할 수있게 만드는 것이 좋습니다.

일관성을 위해 mutable 을 좋아합니다.

이 작업이 완료되면 0.6 포함될 수 있도록 최대한 빨리 수행해야합니다.

이것이 일어날 경우, 생각하기 전에 모두가 인식하는 것을 사용하는 것보다 : struct

type 도 조금 어색하다고 생각합니다. 다른 사람들에게 설명 할 때 보통 "구조체처럼"이라고 말하므로 +1합니다.

이것이 일어날 경우, 생각하기 전에 모두가 인식하는 것을 사용하는 것보다 : struct

immutable 이 구조체와 같다고 생각 했나요?

mutable +1

immutable 에는 C 구조체의 메모리 레이아웃이 있습니다.
type 에는 C 구조체의 변경 가능성이 있습니다.

따라서 구조체는 둘 다에 관련됩니다. mutable 대신 struct 가 이것을 명확히하는 것이 더 낫다고 생각합니다.

모든 변수는 변경 가능합니다. 이 레이블을 보편적으로 인식되는 이름 ( struct )에 할당하면 이음새가 명확 해집니다.

Fortran에서 온 누군가에게 type 키워드는 이미 자연스러운 것입니다.
C에서 온 사람에게는 struct 키워드가 자연 스럽습니다.
immutable 를 많이 사용하는 사람에게는 반대 키워드 인 mutable 가 당연합니다.

따라서 우리는 그대로 두어야합니다.

struct{mutable}
struct{immutable}

또는

record{mutable}
record{immutable}

더 설명적인 양식이 필요한 경우.

struct 를 사용하면 불변의 구문은 immutable struct 가 될 수 있습니다 ( struct 부분은 최소한 초기에는 선택 사항 임).

Fortran 프로그래머는 "struct"라는 용어에 익숙하다고 생각합니다.

일관성 때문에 mutable +1. struct 를 선택한 경우 일관성이 const struct 와 같은 변경 불가능한 변경을 지시하지 않습니까? ;)

struct 와 immutable struct 가 실제로 꽤 좋을 것 같습니다. struct 은 매우 익숙한 용어이며 새 키워드를 하나만 추가하면됩니다. 반드시 필요한 것은 아니지만 mutable struct 허용하는 것도 의미가있을 수 있습니다.

struct 명사가 장점이라고 생각합니다. 형용사 만 사용하지 않는 것이 좋습니다.

struct 를 immutable struct 추가하면 불필요한 라인 노이즈가 추가되므로 입력 할 필요가 없었습니다.

Otoh, Fortran이 우리와 매우 유사한 일을하는 type 키워드를 가지고 있다고 생각합니다. 그러나 나는 이것을 변경하는 것을 싫어하지 않습니다.

위의 @KristofferC 가 옳습니다. 또한 이것이 무엇인지 설명 할 때 "struct"라고 말하고 있습니다. 내부 토론에서도 type 문제가있었습니다. 누군가는 " x 가 유형이라고 가정하자"고 말할 것이고, " type 키워드로 선언 된 것"을 의미하는지 다른 의미에서 "유형"을 의미하는지 명확하지 않습니다.

이러한 이름이 실제로 테이블에있는 경우 ( s/type/new name/ 는 약간 독해 보임),이 기회를 최대한 활용하여 기본 선언을 변경 불가능하게 만드는 것이 좋습니다.
따라서 struct 는 immutable 대체하고 mutable [struct] 는 type. 대체합니다.

생각대로 mutable에 대한 또 다른 가능한 용어는 Ref 일 수도 있습니다.

다른 가능한 이름은 composite . 이에 대한 일반적인 CS 용어는 복합 유형 이기 때문입니다. 하지만 여전히 mutable Foo 및 immutable Foo 를 mutable struct Foo 및 immutable struct Foo 보다 선호합니다 — struct (또는 composite 또는 class 등) 불필요 해 보입니다.

: +1 : 명사로

Julia의 데이터 유형은 전체적으로 더 강력하고 미묘하고 "struct"가 약간 단순 할 수 있기 때문에 Julia에서 struct 보다 항상 type 보다 더 좋아했습니다 (내 배경은 _C_ 임에도 불구하고). 아이디어. 나는 또한 이것이 새로운 언어이기 때문에 노련한 프로그래머들이 익숙한 관습에 얽매여서는 안된다고 느낍니다. "제일 언어가 줄리아 인 사람에게 이것을 설명하는 가장 좋은 단어는 무엇일까요"라고 생각해야합니다.

나는 또한 이것이 무엇인지 설명 할 때 "struct"라고 말하는 것을 발견한다.

struct T 새로 온 사람을 소개 한 다음 T::DataType 말하면 ::Type{T} 사용하여 디스패치 할 수 있으며 줄리아의 "강력한 유형 시스템"을 설명한다고 상상해보십시오. 나는 이것이 단지 도로 아래로 양동이를 더 걷어차는 것이라고 생각합니다.

명사는 장점이다

: +1 : 명사로

"mutable"과 같은 라틴어 계열 형용사는 문법적으로도 자체 언어의 명사가 될 수 있다는 점에 주목할 가치가 있습니다. 그렇기 때문에 "변이 형의 명사형은 무엇인가"라고 물을 때 우리는 어깨를 으쓱하는 것입니다. 그러나 우리는 항상 "변수"라고 말하고 Julia-speak에서는 "이것을 위해 불변을 도입합시다"라고 말할 것입니다. 불행히도 처음에는 영문법의 게르만 어근 때문에 어색함을 느낍니다. 그러나 이것은 영어에서 자주 발생하지만 (우리는 또한 프랑스어와 라틴어를 기반으로하기 때문에) 시간이 지남에 따라 익숙해집니다.

마지막으로, 주제가 "미친 아이디어"이기 때문에 이러한 키워드는 대체로 새로운 DataType 하므로 키워드를 완전히 제거하고 생성자를 사용할 수 있습니까?

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

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

나는 이것들이 ccall 처럼 특별히 (정적으로) 파싱되어야한다고 생각하며 지금은 최상위에서만 호출 할 수 있습니다. (또한-모든 가능성을 다루기 위해 Mutable <: DataType 및 Immutable <: DataType 및 BitsType <: DataType 가 필요한지 확실하지 않으며 바인딩의 경우 const 수도 있습니다).

불변이 구조체와 같다고 생각 했나요?

불변에는 C 구조체의 메모리 레이아웃이 있습니다.
유형은 C 구조체의 가변성을가집니다.

맞습니다 ... 저는 Swift를 생각하고 있었던 것 같습니다.

이것이 구조체와 클래스의 가장 큰 차이점입니다. 구조체가 복사되고 클래스가 참조됩니다. ... 따라서 큰 개체의 경우 참조가 아닌 값으로 전달됩니다.

immutable vs type 처럼 들리며 Julia 바인딩의 의미론에서 가변성을 허용하는 참조 일뿐입니다.

DataType 에는 abstract , bitstypes, 변경 불가능 및 변경 가능한 구조체와 같은 모든 명목 유형이 포함됩니다. 따라서 type 를 DataType 로 대체하는 것은 명확하지 않습니다. 또한 "신규"시나리오와는 다른 결론을 내립니다. ::Type 및 ::DataType type T 정의 된 항목의 상위 집합을 선택하므로 이름이 다른 것은 미친 일이 아닙니다. . " struct 는 Type 의 한 종류입니다." type 는 Type "의 한 종류입니다.

나는 형용사가 실제로 명사 역할을 할 수 있다는 데 동의합니다. 예를 들어 "이것은 불변입니다"라고 말할 수 있습니다. 설명이 충분하지 않다고 생각합니다. _is_가 무엇인지 말하지 않고, 그것이 무엇이든, 당신은 그것을 돌연변이시킬 수 있거나 할 수 없다는 것을 알려줍니다.

나는 유형에 대해 structure 및 mutable structure 를 좋아합니다. 변수 할당의 경우 a = 1 및 mutable a = 1 수 있습니다. 기본적으로 일관성, 약어 없음 및 불변성을 원한다는 생각에서 벗어나십시오.

편집 : 기본적으로 변경 가능성에서 const 대신 constant

또는 키워드 수가 적은 버전은 struct 대 const struct 입니다. 기본적으로 모든 변수를 const로 만드는 것은이 시점에서 너무 혼란 스러울 것이라고 생각합니다.

설명이 충분하지 않다고 생각합니다. 그것이 무엇인지 말하지 않고 그것이 무엇이든, 당신은 그것을 돌연변이시킬 수 있거나 할 수 없다는 것을 알려줍니다.

그게 좋은 점입니다.하지만 참조 동작 대 "값"동작을 "구조체 또는 비트 유형입니까?"보다 설명하는 것이 더 중요하고 흥미 롭다고 생각합니다. (대부분 bitstype 가 자주 나오지 않기 때문에-내가 만든 모든 Julia 유형은 구조체입니다). 불변성은 바인딩 의미와 값에 의한 전달의 결과 일뿐입니다.

struct 대 bitstype 의 필요성을 완전히 없애기 위해 @quinnj 의이 아이디어 를 포함 할 수도 있습니다.

immutable 32 Int32 <: Integer

또는 비트 수로 장식되지 않은 필드를 가질 수 있습니다.

immutable Int32 <: Integer
   32
end

(일반적으로 명명 된 필드와 혼합 된 경우) 필요한 경우 패딩을 삽입하는 데 유용 할 수도 있습니다.

그 다음은 값 형식 사이의 단지 선택 (현재 불변 무엇) 현재 가변 무엇인지 (참조 형 대 -하지만 잠재적으로 const 를 호출 할 또 다른 이유는 미래의 필드 mutable ) 및 적절한 이름이 필요합니다. 마지막으로 값 참조 유형에 struct 를 사용하면 Swift 프로그래머가 혼란스러워집니다.

bitstype 가 immutable 가 도입 된 이후로 모두 사라진 것은 사실입니다. 그러나 구조 대 비트보다 구별 할 것이 더 많습니다. 추상 유형, 튜플 (불변) 및 향후 불변 레코드가 있습니다.

원래 immutable 이것이 가장 눈에 잘 띄는 특징이라고 생각했기 때문입니다. 다른 개체와 달리 수정할 수 없습니다. 사실, 항상 값으로 전달되는 것은 아닙니다. 불변성은 차이를 구분할 수 없음을 의미합니다. 일부 immutable 는 배열 및 기타 개체에 인라인되고 일부는 그렇지 않습니다. 불변성은 차이가 일반 줄리아 코드에 문제를 일으키지 않음을 의미합니다. 메모리 레이아웃이 C interop과 같이 정말로 중요한 경우에만 문제가됩니다.

사실, 항상 값으로 전달되는 것은 아닙니다.

좋은 지적! 그러나 그것을 바꿀 계획이 있습니다.

1.0에 가까워지고 있기 때문에 미래 보장 개념을 반영하는 미래 보장 키워드 세트가 필요하다고 생각합니다. 불변 항목이 인라인되면 결과 의미 체계와 관련하여 도움이되는 이름으로 이름을 바꿀 수있는 합리적인 시간이 될 수 있습니다 (이러한 의미 체계가 FFI에 도움이되는 경우 더 좋습니다).

나는 사람들이 abstract , Tuple s 및 "records"와 혼동되는 새로운 구체적인 유형 정의 키워드를 얻지 못할 것이라고 생각합니다 (즉, 필드 이름이있는 제안 된 튜플과 같은 것을 의미한다면, 제 생각에는 나는 또한 이전에 "구조체"라고 불리는 것을 들었습니다 ...).

"값에 의한 전달"개념의 실제 목적은 f(x) (어떤 의미에서) 수정하면 어떻게되는지에 대한 질문에 답하는 것입니다. x : 동일한 x 수정합니까?

어쨌든 immutable 및 mutable 는 키워드에 대한 실행 가능한 옵션이라고 생각합니다.

불변이 도입 된 이후로 bitstype이 거의 사라진 것은 사실입니다.

개인은 일반적으로 새로운 비트 유형을 만들 필요가 없지만 기존 비트 유형과 일반 불변의 차이는 이들에 대한 ABI가 매우 다르기 때문에 원시 수준에서 매우 중요합니다. 대부분의 경우 사용자는 새로운 구체적인 데이터 유형을 정의 할 때 bitstype이 아닌 변경 불가능한 구조체를 원합니다.

FWIW, 변경 하지 않는 것에 대한 지원이 많지 않았기 때문에 type 및 immutable 가 괜찮다고 생각합니다.

( do 구문은 나를 괴롭히지 만 ... ;-)

모든 것은 "공유를 통한 전달"입니다.

나는 그것을 존중할 수 있으며 토론에 감사드립니다.

모든 것은 "공유를 통한 전달"입니다.

참고로, 유형 선언에 const 키워드가 있으면 immutable 가 완전히 불필요 해집니다.

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

(컴파일러는이 유형이 자동으로 변경 불가능하다고 판단 할 수 있으며 사용자는 const 유형을 사용하면 더 빠른 코드로 컴파일 할 수 있음을 이해할 수 있습니다.) 그러면 type 또는 struct 이 의미가 있습니다. setfield! 는 대소 문자가 혼합 된 const 필드에서 비활성화 될 수 있습니다.

type 및 const type 어떻습니까? -type 키워드는 struct보다 나에게 더 우아하게 들리며 struct와 나는 내부 생성자를 갖는 ~ object가 아닌 기술 메모리 레이아웃을 일종의 연관시킵니다. 복합 유형은 '... 줄리아에서 가장 일반적으로 사용되는 사용자 정의 유형'이므로 '유형이 유형의 한 종류'라면 그렇게 나쁘지 않을까요? '복합 형'을 사용하는 의사 소통에서는 내가 '추상 형'이라고 말한 것과 동일하게 명확히해야한다. 라인 노이즈와 관련하여 'const type'은 'immutable'보다 나쁘지 않습니다.

변수와 유형이있는 const 의 의미에 (약간) 차이가 있는지 잘 모르겠습니다. -어떤 경우에도 유형과 불변은 항상 나에게 작은 정신적 딸꾹질을 주었다. 여기서이 문제를 만나서 반갑습니다!

struct 사용의 주된 문제는 사람들이 Julia에서 반드시 사실이 아닌 C / C ++에서 익숙한 가정을 자연스럽게 만들 수 있다는 것입니다. 불변입니다.

immutable 가 type 보다 더 우아하게 표현하는 패러다임은 무엇입니까? 예를 들어, 원하는 필드가 업데이트 된 원본에서 변경 불가능한 새 항목을 인스턴스화하여 동기화 기본 요소없이 동시에 여러 필드의 상태를 원자 적으로 "전환"합니다.

유형이 디스패치 / 사용 지점이 아닌 정의 지점에서 두 개의 개별 범주로 분리되어야하는 이유는 무엇입니까 (C ++의 const 와 유사)? type / struct / composite 하여 복합 유형을 정의하고 Immutable{T} 구조를 도입하여 변경 가능을 불변으로 승격하면 다음과 같은 결과를 얻을 수 있습니다.

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

또한 여기에서 abstract 및 bitstype 대한 변경을 고려할 수 있습니까? AFAICT "abstract"의 용법은 명사가 아닌 형용사입니다. 유형 키워드 (모든 명사, 모든 형용사 등)에 최소한 언어 적 일관성이 있어야합니다. bitstype 는 bits 또는 primitive 로 더 잘 표현 될 수 있습니다.

Julia 키워드의 철자 (또는 의미 체계!)에 대한 변경 사항을 논의하기 위해 이것을 공개 스레드로 바꾸지 마십시오. 이 시점에서 배는 type 및 immutable 의 기본 _ 동작 _으로 항해했습니다. 여기서 제기되는 유일한 질문은 유사성을 더 잘 반영하는 type 및 immutable 철자를 사용할 수 있는지 여부입니다.

나는 계속해서 mutable vs immutable 를 지원하거나이 시점에서 가장 합리적인 두 가지 옵션으로 그대로 둡니다. 다른 것은 무의미하게 파괴적입니다.

@andyferris 저는 그 아이디어를 정말 좋아합니다. struct 및 const 이 좋습니다. 그렇게한다면 모든 필드에 const 를 쓸 필요가 없도록 const struct 또는 const type 라고 말할 수도 있습니다. (1) ) 따라서 필드 별 불변성의 새로운 기능을 즉시 추가 할 필요가 없습니다. 그 기능을 추가하고 싶다면 일관된 어휘를 사용하는 것이 좋습니다.

'복합 유형'을 사용하는 통신에서 명확히해야합니다.

우리가 가장 좋아하는 이름 지정 기법 중 하나는 한 문장으로 누군가에게 어떤 일을 설명하고 가장 많은 일을하는 것으로 보이는 단어를 골라내는 것입니다. 그래서 나에게 이것은 composite 대한 투표가 될 것입니다.

유형이 디스패치 / 사용 지점이 아닌 정의 지점에서 두 개의 개별 범주로 분리되어야하는 이유는 무엇입니까 (C ++의 const와 더 비슷 함)?

간단합니다. 글로벌 보증을 제공하는 것입니다. C ++에서 "const"객체는 누군가에 대한 non-const 참조가있는 경우 여전히 변경 될 수 있습니다.

또한 abstract 및 bitstype에 대한 변경을 여기서 고려할 수 있습니까?

제안을하십시오. bitstype 의 경우 키워드가 거의 사용되지 않으므로 bits 와 같은 작은 유용한 단어를 훔치고 싶지 않습니다.

immutable -> const type 도 괜찮아 보입니다. type -> composite 또는 struct 와 함께 사용하면 type 있습니다.

특히 @compat 에서 지원할 수 없기 때문에 이로 인해 발생할 수있는 모든 코드 변동에 대해 매우 만족스럽지 않습니다. 이 작업을 수행해야한다면 업그레이드 경로는 (1) 0.6에서 새 키워드 동의어를 도입하지만 이전 키워드 동의어는 _don't_ ( @compat 부족으로 인해), (2) deprecate와 같아야한다고 생각합니다. 0.7의 오래된 것.

bitstype 경우 이것을 primitive 유형이라고 부르는 것은 어떻습니까? 현재 이름은 an isbits composite type 와 유사하기 때문에 약간 짜증이납니다.

Julia가 다른 언어의 "def / func / elif"스타일 약어를 자주 사용하지 않는 방식이 마음에 듭니다. (Dn w abbrevs, kthx.) 그래서 mutable 가 struct 보다 승리합니다.

FWIW, OCaml은 레코드 및 변형 (구조체 및 공용체) 및 별칭에 type 를 사용합니다. 표준 ML은 datatype 을 사용한다고 생각합니다.

대칭은 좋지만 mutable 설명이 충분하지 않습니다. immutable 도 마찬가지입니다 ( const type 아이디어가 마음에 듭니다).

Steve가 지적했듯이 이로 인해 커뮤니티 전체에 심각한 코드 변동이 발생할 수 있습니다. 그리고 그 혜택은 모호합니다.

나는 확실히 const type 사건을 본다; 그것은 net -1 키워드가 될 것이고 type과 immutable 사이의 관계를 명확히합니다. 하지만 type 를 다른 방법으로 사용할 수 있다면 정말 좋을 것입니다. 그 혜택이 없으면 변화를 정당화하기가 훨씬 더 어렵습니다. 그러나이를위한 코드 업데이트는 매우 쉽습니다. type 의 구문은 기본적으로 다른 컨텍스트에서 사용할 수 없습니다.

composite / const composite 대한 +1.

primitive 대 composite 은 (는) 필요에 따라 const 키워드가 추가 된 훌륭한 차별화 요소라고 생각합니다.

변경 될 수있는 일부 비트와 구별하기 위해 (및 일관성을 위해) const primitive 가 필요합니까? 그래서 대칭 적으로 우리는

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

변경 가능한 기본 유형이라는 문제는 구현되어야합니다 ... (물론 이것은 나중에 발생할 수 있지만 bitstype -> const primitive _now_ 더 간단하게 말하면, 가변성을 스택에 가져 오기위한 좋은 "연습"대상이 될 수 있지만, 저는 그것에 대한 전문가가 아닙니다).

마찬가지로 복합의 개별 필드에 const 을 추가하는 아이디어는 나중에 쉽게 구현할 수 있으며 더 좋은 점은 깨지지 않는 변경입니다.

그렇게한다면, (1) 모든 필드에 const를 쓸 필요가 없도록하기 위해 const struct 또는 const type을 말할 수 있기를 원할 것입니다. (2) 새로운 기능을 추가 할 필요가 없습니다. 필드 별 불변성. 그 기능을 추가하고 싶다면 일관된 어휘를 사용하는 것이 좋습니다.

나에게 완벽하게 이해됩니다.

composite 데이터 형식을 검색 한 결과 적어도 Ada와 Visual Basic도 그 아래에 배열 형식을 포함한다는 것을 알았습니다. (그렇지 않으면 약간 무작위로 발견되었습니다 : Haskell : 목록과 튜플 (정의가 요청 되었더라도); Python : 목록, 튜플, dicts; Lisp : 목록, 벡터, 해시 테이블, 사용자 정의 클래스, 구조).

따라서 나는 이제 type 와 같은 구조에 대해 얼마나 정확한 합성이 있는지 궁금합니다. (그러나 나는 컴퓨터 과학자가 아니며 어휘 / 광범위한 시각이 부족합니다).

흠, 맞을 수 있습니다.이 특정 유형의 유형은 항상 구조체, 구조 또는 레코드 (또는 클래스 또는 객체)라고하며 "복합"은 더 넓은 용어입니다. http://rosettacode.org/wiki/Compound_data_type에 많은 예제가

type 를 식별자로 복구하고 더 구체적인 이름을 사용하는 것이 좋습니다. ~ 0.6 이전에 작성된 거의 모든 사소한 패키지의 파손은 매우 불행 할 것입니다.

const 키워드를 재사용한다는 아이디어는 전역 범위에서 const 변수 바인딩과 불변 항목 내의 필드 바인딩 const 의 동등성을 강조하므로 상당히 매력적입니다. 이것은 immutable 보다 좋은 통합과 더 나은 이름으로 보입니다.

type 를 대체 할 이름의 경우, struct 는 모호함을 상당히 잘 피하는 것 같습니다 ( "a mutable type"및 "immutable type"문구가 너무 비슷하게 들리는 경우가 많습니다).

다음은 상당히 멋져 보입니다.

struct A
    a::Float64
end

const struct B
    b::Float64
end

유형을 식별자로 복구하고 더 구체적인 이름을 사용하는 것이 좋습니다.

나는이 정서를 반향한다.

이름을 변경하려는 경우 지원 중단은 어떻게 처리됩니까? type 및 immutable 은 (는) 0.6에서 여전히 유효하며 아마도 1.0에서는 경고와 함께 유효합니까? Compat.jl 는 이것을 투명하게 처리 할 수 ​​있습니다. 인터넷에있는 많은 문헌 (블로그 포스트, 튜토리얼 등)은 경고를 보여줄 것입니다-초보자에게는 사소한 성가심입니다.

전환을 쉽게하기 위해 평소보다 더 오래 type 및 immutable 를 예약 할 수 있습니다.

우리는 1.0 이전입니다. 이것을 바꿀 때가 지금이 아니면 안됩니다. 이전 키워드를 더 오래 사용할 수 있으면 원활한 전환을 보장하는 데 확실히 좋습니다. 나는 실제 명명에 대한 논의와 전환이 의미하는 고통을 혼동하지 않을 것입니다.

개인적으로 나는 그것을 struct 라고 부르는 것입니다. 라고 한

나는 실제 명명에 대한 논의와 전환이 의미하는 고통을 혼동하지 않을 것입니다.

변화가 너무 고통 스럽다면 나는 그 변화에 반대 할 것입니다. 1.0 이전의 변경은 정당하지만 발생하는 모든 중단과 비교하여 IMO가 올바른 조치입니다.

@stevengj 는 지원 중단을 수행하는 방법에 대한 좋은 제안을 받았으며 @amitmurthy 가 동일한 결론에 도달 한 것처럼 보입니다 (평상시보다 키워드를 더 길게 유지). 우리 모두이 언어를 한동안 사용해 왔지만 아직 초기 단계이므로 변경하는 것을 두려워해서는 안됩니다. 이것도 쉽게 검색하고 교체 할 수 있습니다.

계속해서 struct 투표하겠습니다. 나는 이것이 많은 소문과 불만을 야기 할 그러한 변화 중 하나라고 생각하지만 실제로 패키지 / 사용자 코드를 수정하는 것은 그리 어렵지 않습니다.

immutable -> const type 은 (는) 저항이 가장 적은 경로 인 것 같으며 IMO는 확실히 수행되어야합니다. 나는 이것이 훨씬 더 좋은 것을 설명한다고 생각합니다.

type -> composite 보다 정확 type 그러나보다 정확한 struct 보다 적게하면서 용어-Y struct (행 새로운 프로그래머). Jeff의 '초보자에게 설명하는 문장 쓰기'테스트를 통과하고 type 키워드를 복구합니다. 단점은 composite 가 다른 언어로 표시되지 않는다고 생각합니다. 혼자 가세요.

type -> struct 가 가장 정확하지만 structure 가 약어보다 더 예뻐질 수 있습니다 (약어를 struct 처럼 추악하게 생각하려고합니다 eye() 은 영어 관점에서 꽤 역겨운 전통이라고 생각합니다).

bitstype -> primitive 는 type 가 변경되면 의미가 있습니다.

@tbreloff 가 맞습니다. 핵심 개발자들은 과거에 좋은 취향을 보였고 결국 사람들은 그들의 리드를 따를 것입니다. 곧하세요!

명시 적으로 변경할 필요가없는 한 immutable 이 표준이어야하므로 이름 변경이 다음과 같아야하는지 궁금합니다.

• immutable -> struct
• type -> mutable

그런 다음 공통 / 예상 이름이 모범 사례이며 변경 가능성을 요청하기위한 명시적이고 명확한 이름이 있습니다.

bitstype -> primitive 도 좋아합니다 ...

const 이 기본값이어야한다고 생각하지 않습니다. 기능을 줄이는 최적화가 기본값이되어서는 안됩니다.

struct 및 const struct 대한 +1.

composite 라는 용어는 약간 더 설명 적이지만 struct 는 짧고 일반적으로 복합 유형으로 알려져 있습니다.

bitstype 처럼 거의 사용되지 않는 것에 대해 실제 단어를 훔치지 않는 편입니다. primtype 또는 primitivetype ?

bitstype 를 primitive 와 같은 분명하게 더 나은 이름으로 변경하지 않으려면 그대로 두는 것이 더 낫다고 생각합니다.

-1 ~ struct . C 프로그래머와 이야기하지 않는 한 유형 정의가 무엇인지 설명하는 데이 용어를 사용하지 않고 레이아웃이 호환 가능하고 속성을 비교 / 대조한다는 점만 언급합니다.

-1 ~ const . C는 절대적으로 최소한의 키워드를 갖는 방향으로 갔고, 이제 우리는 문맥에 민감한 의미를 가진 많은 키워드에 갇혀 있습니다. 나는 실제로 const 가 이러한 유형의 핵심 속성이 아니라 값 유형 (참조 유형과 반대)이라고 생각합니다.

하지만 다른 방향으로 가면 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`

"값 유형"의 문제는 언어에 매우 깊은 사람 만 이해할 수 있다는 것입니다. 신규 사용자의 경우 필드가 변경 불가능하다는 사실은 즉시 직면하게되는 _semantic_ 사실입니다. 그 밖의 모든 것은 구현 세부 사항입니다. 그래서 저는 const 선호합니다.

나는 당신이 record 로 어디로 가는지 알지만, 솔직히 나는이 용어가 struct 보다 덜 일반적이라고 생각한다. (구글 "record type ruby"vs "struct type ruby"를 사용하거나 python, perl 또는 일부를 대체하더라도 다른 비 C 언어). record 는 키워드로 예약하는 것이 부끄러운 반면 struct 는 프로그램에서 다른 어떤 것도 필요하지 않을 것 같은 꽤 유용한 영어 단어라는 문제도 있습니다.

struct 는 매우 일반적으로 사용됩니다. rosettacode를 살펴보면 다음에서 사용됩니다.

algol, C, C #, C ++, lisp, D, elixir, forward, go, maxima, racket, rust, seed7, swift, visual basic ( structure )

record 사용처 :

ada, clojure, delphi, pascal, erlang, icon, modula-2, 일부 계획

record 은 (는) 이전 언어에서 선호되는 것 같습니다. 요즘 함수형 프로그래밍이 대중화됨에 따라 구조적으로 형식화 된 레코드를 참조하는 경향이 있습니다.

흥미롭게도 seed7은 new struct 합니다.

A는 볼 수 슬픈 비트 struct 까지했다 언어로 그것을 만들기 (정말 단어를 완료 나쁜? 할 수있는 별도의 세 글자이다) function 대신 func , 등등. 누군가가 언어를 거부하는 것은 아니지만 여전히 ...

structure 은 실제로 PL / I 및 Visual Basic에서 사용됩니다. VB에는 structure immutable 있습니다. 그러나 struct 은 너무 흔해서 거의 새로운 단어가 된 것 같습니다.

여기에도 원어민 말하기 문제가 있는지 궁금합니다. 이 문맥에서 struct 라는 단어에 매우 익숙한 저에게는 structure 가 더 이상하게 느껴집니다. 같은 이유로 func 끔찍하고 function 자연 스럽습니다.

struct 은 다양한 프로그래밍 언어에서 사용되기 때문에 독립적 인 용어가되지 않았습니까? structure 라는 단어는 (적어도 독일 출신 인 저에게는) 훨씬 더 추상적입니다. 예를 들어 그 유형 계층에는 특정 "구조"가 있습니다.

func 은 (는) 독립적 인 용어가 아니라 약어입니다.

func는 나에게 독립적 인 용어가 아니라 단지 약어입니다.

struct는 어떻게 약어가 아닌가? 말 그대로 구조의 약자 아닙니까, 아니면 제가 그 용어를 오해 했습니까? 당신은 func 보다 그것에 더 익숙합니다. 많은 것들이 "독립적 인 용어"이고 많은 언어에서 공통적이지만, 그것이 줄리아가 더 낫지 않은 경우 전통을 따라야한다는 것을 반드시 의미하지는 않습니다. 그렇다면 그것은 더 좋거나 더 나쁜 것에 대한 싸움이고, 그것은 거의 맛의 문제입니다.

어쨌든, 나는 mutable 선호하기 때문에 구조체 나 구조체 든 _ 너무 _ 신경 쓰지 않습니다. mutable은 현재 immutable 대해 항상 const 작성하는 것을 피할 수 있습니다.

하지만 결국 struct 또는 strct 또는 stct 또는 strctr 가 되어도 다른 언어로 Julia를 변경할 가능성은 거의 없습니다. 내 작품, 그래서 ... :)

이것이 영어로 이해되지 않는 경우 죄송합니다.하지만 struct 가 construct 의 약어가 아닙니다. 적어도 독일어에서는 Konstrukt 라는 단어가 복합 유형이 무엇인지 설명하는 데 훨씬 더 의미가 있습니다.

영어에서 construct 가 명사인지 또는 동사가 영어 기반 프로그래밍 언어에서 사용을 배제했는지 알 수없는 경우 :) 독일어 대문자 사용이 도움이됩니다.

struct 는 TV, ASAP 및 LOL이 단어 인 것과 같은 방식으로 자체 단어입니다. 나는 사람들이 "구조"라고 말하는 것을 거의 듣지 못합니다. 내 경험상 그 단어는 말하고 쓰여진 "구조체"입니다.

BTW : Matlab은 struct 라는 단어를 사용합니다.

위에서 언급 한대로 OTOH는 C # 및 Swift에서 struct 값 유형에 해당합니다 ( class 와 반대). 따라서 변경 가능한 유형과 변경 불가능한 유형 모두에 대해 유사한 용어를 사용하는 것은 이러한 언어에 익숙한 사람들에게 실제로 도움이되지 않습니다. 그것이 결정적인 지점인지 확실하지 않습니다 ....

mutable / immutable 은 (는) 가장 명백한 선택 인 것처럼 들리며, 신규 이민자에게는 매우 분명합니다.

struct 를 사용하는 많은 다른 언어를 감안할 때 해당 이름을 사용하는 데 동일한 의미가 필요하다고 생각하지 않습니다.

나는 type 및 const type 를 가장 좋아하지만 type 키워드를 확보하지는 못합니다. type 대해 계획된 것이 무엇인지 모르기 때문에 비용이 얼마나 큰지 모르겠습니다.

그러나 type 부분은 이미 abstract 암시되어 있으므로 mutable 및 immutable 자체를 사용하는 것이 가장 적합합니다. 그리고 immutable struct 보다 적은 타이핑과 약간의 변화 (type-> mutable).

단어 구조는 (적어도 독일 출신 인 나에게는) 훨씬 더 추상적입니다.

우리가 언어에 대해 논쟁하는 동안 모든 사람들은 struct 인 약어의 양을 과소 평가하고 있습니다. "데이터 구조"의 줄임말입니다. 마찬가지로 type 는 "데이터 유형"의 약자입니다. 나는 배열이나 버퍼도 링크 된리스트처럼 데이터 구조라고 말할 수 있지만, struct 는 첫 번째 공통 데이터 구조 중 하나로서 초기 루트를 가지고 있으며 컴퓨팅 내에서 그 자체의 더 구체적인 의미 (따라서 영어 또는 기타 네이티브 프로그래머에게는 structure 만큼 추상적으로 들리지 않습니다).

-1 ~ struct . C 프로그래머와 이야기하지 않는 한 유형 정의가 무엇인지 설명하는 데이 용어를 사용하지 않고 레이아웃이 호환 가능하고 속성을 비교 / 대조한다는 점만 언급합니다.

나는 struct 대해 정확히 이런 식으로 느낍니다. 특별한 이유없이 줄리아에게 새로운 용어를 도입 할 것이라고 생각합니다.

-1 ~ const . C는 절대적으로 최소한의 키워드를 갖는 방향으로 갔고, 이제 우리는 문맥에 민감한 의미를 가진 많은 키워드에 갇혀 있습니다. 나는 const가 이러한 유형의 핵심 속성이라고 생각하지 않지만 참조 유형과 반대되는 값 유형이라고 생각합니다.

Jeff는 나에게 (매우 친절하게) 의미 론적으로 사물이 값인지 참조인지 상관하지 않는다고 설명했습니다. 이것은 의미론이 아닌 구현 세부 사항이며 미래의 황금 시대에 _ 우리는 신경 쓰지 않을 것입니다 _. 컴파일러가 원하는 방식 (필요에 따라 일부 FFI 보장 포함)으로 모든 것이 "공유로 전달"됩니다. 지난 며칠 동안 저는 이미 "마법에 의한 공유"라고 부르기 위해 왔으며 이것이 제게 (이상적으로는) 생각할 필요가없는 정신적 압박을 덜어주는 계시라고 생각합니다. @vtjnash 당신은 내가 값과 참조로 어떻게 고생했는지, 그리고 이것이 컴파일러와 GC 등에 의해 다른 패키지와 스레드에서 어떻게 구현되는지 보았습니다).

바인딩은 변경되거나 일정 할 수 있습니다 ( const 하지만 constant 도 꽤 귀엽습니다). 마찬가지로 복합 데이터 유형 내의 필드 바인딩은 변경되거나 일정합니다. 이것이 내가 이전에 각 필드에 명시 적으로 const 첨부하도록 제안한 이유입니다. 이는 의미론을 명확하게 만들었습니다 (적어도 나에게는).

IMO 우리는 이것에 대해 이야기하기 위해 "mutability"및 "immutable"과 같은 멋진 단어를 사용할 필요가 없습니다. 무언가가 새로운 물체에 리 바인드 될 수도 있고 그렇지 않으면 일정합니다. struct 및 immutable struct 와 같은 복잡한 영어 단어의 필요성을 줄리아 (코드뿐만 아니라)에 대한 담론에서 완전히 제거하는 것은 좋은 일 (목표, 심지어)로 간주되어야합니다.

또한 "struct"는 자체 단어 (C에서 의미) 인 반면 "structure"는 아마도 "데이터 구조"일 것입니다. 레코드 유형을 의미하는 경우 "struct"라고 말할 수 있기 때문입니다. 하지만 여기에 내 C 뿌리를 보여주고 있습니다.

그것은 또한 공통적 인 부분에 있습니다. defstruct

아마도 여기에있는 대부분의 다른 요점보다 사소한 것 같지만 우리가 자전거를 타는 한 : 큰 소리로 말하면 immutable object 와 a mutable object 구절이 짜증나게 비슷하게 들립니다. 줄리아의 유형 시스템에 대한 대화를 필요 이상으로 어렵게 만들 것입니다. 편집 : 이것은 이미이 스레드에서 가져온 것 같습니다.

type -> struct 및 immutable -> const struct +1합니다. 나는 이것에 대해 혼란 스러울 사람을 만난 적이 없다고 생각합니다. 특히 간단한 설명 후에.

type 를 바꾸는 것은 v0.6에서는 현실적이고 v0.8에서는 비현실적입니다. 우리는 이것을해야합니다. 명확한 의사 소통과 표현의 신속성을 위해 Julia의 타고난 재능을보다 원활하게 만들고 향상시킬 수있는 기회입니다. 유형은 잘 작동하는 소프트웨어를 만드는 데 너무나 많이 사용됩니다. 전형적인 것들에 대한 더 나은 이름 지정은 강력하게 울려 퍼지며 Julia에게 더 이야기 된 미래를 가져다 줄 것입니다.

struct 사용하지 않은 상태로 두는 것이 좋습니다. C에서 구조체는 유형 고정 필드의 고정 시퀀스에 대한 구문 컨테이너입니다. Julia는 C가 아니며 C-ism을 Julian 담론으로 끌어 들이면 Julia의 측면을 개념화하는 최상의 사용과 더 나은 방법에 대한 진지한 토론에서 Julia의 일시적인 성격을 밀어 낼 수 있습니다.

또한 "불변"과 "변이 가능"은 시각적으로 너무 일치합니다. 우리는 더 잘할 수 있습니다.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff 옆으로 커뮤니티 표준 에 따라 Julia를 "그것"이라고 부르는 것이 좋습니다. 내가 언급 할 것이라고 생각했습니다. 🙂

@ararslan Julia에 대한 커뮤니티 표준 지침이 변경된 것으로 보이며 이제 문학 대명사 적용을 피합니다. 관심을 가져 주셔서 감사합니다. :크리켓:

여성 대명사를 사용하는 것은 그 자체로 나쁘지는 않지만 (그리고 많은 언어에서 피할 수없는) 많은 사람들이 "그녀"라는 용어를 사용하는 것에서 뜨거운 데이트로 줄리아에 대해 이야기하는 것으로 점프하는 것을 거부 할 수없는 것으로 보입니다. 가능한 한 많이 유혹을 피하십시오.

고마워

2016 년 11 월 3 일 목요일 오후 4:29, Stefan Karpinski [email protected]
썼다 :

여성 대명사를 사용하는 것은 그 자체로 나쁘지 않습니다.
언어), 그러나 많은 사람들이 사용에서 뛰어 내리는 것을 거부 할 수 없다고 생각하는 것 같습니다.
"그녀"라는 용어는 줄리아를 뜨거운 데이트로 말하는 것이므로
가능한 한 많이 유혹을 피하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

당면한 문제와 관련하여 저는 개인적으로 무엇이 최선의 변화라고 생각할지 결정하지 못했습니다. 그러나 줄리아의 놀라운 _type_ 시스템에 대한 이야기를 나에게 이상하게 보일 다음 유형의 구축에 사용 된 키워드가 실제로 지정 않습니다 struct 보다는 type . 나는 사람들이 대신 구조체로 타입에 대해 이야기하도록 장려하고 결국 Julia를 설명하는 데 사용되는 언어의 변화로 이어질 수 있다고 생각합니다. 예를 들어 Julia의 놀라운 _struct_ 시스템에 대해 논의합니다.

유형을 구성하는 데 사용되는 키워드는 실제로 유형이 아닌 구조체입니다.

그러나 키워드는 실제로 유형을 구성하는 것이 아닙니다. 예를 들어 Tuple{Int} 표현식도 유형을 구성합니다. type 로 현재 정의 된 것을 항상 struct s라고한다면 좋을 것입니다. Real 가 유형이고 Union{Int8,Int16} 는 유형 등입니다.

예, 이전 메모를 편집 중이며 방금 작성했습니다. 그것은
줄리아의 "돌봄과 먹이"에 만연해
표현력과 간결함의 미래 개발. 문은
Julia의 유형 시스템을 합법적으로 고려하기 위해 열었습니다.
C 구조체에 비계를 설치하면 전쟁이 사라집니다.

2016 년 11 월 3 일 목요일 오후 4:38, Alex Arslan [email protected]
썼다 :

당면한 문제와 관련하여 저는 개인적으로 제가 무엇을
최선의 변화를 고려할 것입니다. 하지만 이야기하는 것이 이상해 보입니다.
Julia의 놀라운 _type_ 시스템을 사용한 다음 키워드가
유형 생성은 실제로 유형이 아닌 구조체입니다. 아마도
사람들이 유형에 대해 구조체로 이야기하도록 장려하여 결국
줄리아를 설명하는 데 사용되는 언어의 변화, 예를 들어 줄리아의
놀라운 _struct_ 시스템.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

type 로 현재 정의 된 것을 항상 struct s라고한다면 Real 가 유형이고 Union{Int8,Int16} 은 유형 등입니다.

현재 그것에 대해 혼란이 있습니까? 나는 그것에 대한 토론을 놓친 것 같지만 나에게 많은 것이 분명해 보였다고 생각한다.

@ararslan : type 라는 용어는 현재 구성되어있는 것에 대한 일반적인 용어입니다. 현재 type 키워드로 구성하는 것은 복합 유형으로 구성된 구조입니다. 그러나 Julia 내에는 type 키워드를 사용하여 구성되지 않은 다른 유형이 많이 있습니다.

아니요, 저는 현재 그것에 대해 너무 많은 혼란이 있다고 생각하지 않지만 키워드 struct 사용하면 모든 줄리아 유형이 구조체라고 생각하지 않습니다.

좋아요, 좋은 지적입니다.

Union {Int8, Int16}은 유형입니다.

아. Union 도 존재한다는 사실을 잊었습니다. struct ( Struct ?)에 대한 주장이 더 매력적입니다. IMO. 그래도 mutable 및 immutable 는 마음에 들지 않습니다.

나는 _struct_ 불명예스럽고 정말로 줄리아를 가지고 다니면 시간이 지남에 따라 진화하는 시대 가이스트를 아래로 끌어 당길 것이라고 정말로 믿습니다. 원리는 움직이는 비트의 설명과 더 높은 수준의 멜드와 더 깊은 게 스탈 트로서의 계산적 어쩌면 표현 사이의 적대감입니다. struct 를 사용한다고해서 모든 사람들이 구조체가 요점을 벗어난 유형을 생각하게되는 것은 아닙니다. ... 과장되게하자 ...

특허 사무원으로서 아인슈타인에 대해 글을 쓰는 것이 그의 공헌에 대한 감사를 줄이는 것이라고 주장 할 수 없습니다. 알버트 아인슈타인에 대한 언급이 특허 사무원으로서의 시간의 중요성을 일시적으로 평가하는 과정에서 몇 명 이상의 학생들이 향후 대화에서 그러한 감각을 접하게 될 것입니다. so 것은 새 학교로 이사 한 후 so 만 작동하는 것을 보장하지 않습니다.

_struct_ 사용에 대한 설득력있는 사례가 있다면 다음 중 하나에 대한 더 나은 사례가 있어야합니다.

structure 는 정보에 입각 한 구성 인 부품의 의미있는 상호 관계입니다.
construct 는 가치를 높이는 디자인 인 관계의 유용한 구조입니다.

불변 structure 는 영구 합성물입니다.
mutuable structure 는 고정되지 않은 선향입니다.
변경 불가능한 construct 는 확립 된 결과입니다.
변경 가능한 construct 는 컨텍스트에 대한 의도적 인 제약입니다.

우리는 "비트 in place and through gates"말하는 방식과 "데이터 구조화가 존재 론적 정보를 드러낸다"는 두 가지가 모두 필요하며, 이는 변형 수정 자 방식으로 사용할 수 있습니다. CS 재능이있는 커뮤니티 참가자와 대규모로 프로그램하는 대부분의 다른 도메인 전문가는 바이트, 메모리, 논리, 지시 된 작업 등을 철저히 처리합니다. 욕망, 창의성, 가능성 및 상상력을 만드는 다른 방법은 잘 작동하는 소프트웨어가됩니다. 작업할만한 가치가 있습니다. 용어 명명에 대한 모든 결정은 그 연설을 장려하기 위해 도달해야합니다.

class 및 immutable 어떻습니까?

델파이의 클래스를 알고 있고 여기서는 불가능하다고 생각했지만 멀티 메소드가있는 Nice 언어에서는 키워드 ( link )로 사용됩니다. 그리고-내가 매뉴얼을 올바르게 읽으면-Haskell과 Dylan에서도 마찬가지입니다. 그것은 "class is one kind of Type"테스트를 통과했지만 여전히 꽤 모호합니다 (오늘날의 'type'처럼). 15:00-15:20 분의 '배열 및 반복 개요'비디오에서 Tim Holy (실수로)는 중요하지 않은 세부 사항 인 '클래스'라고 말했지만 그럼에도 불구하고 Julia 컨텍스트에서 클래스가 완전히 이질적이지 않다는 것을 보여줄 수 있습니다.

그렇지 않으면 reftype 및 immutable ? reftype 용어는 초기 주석에서 언급되었으며 그 이후로 무시되었습니다. 왜? 나에게 그것은 꽤 좋게 들리고 유형을 해제하고 참조 의미를 전달합니다.

( 'new'키워드의 목적을 이해하지 못했습니다. 변경없이 모든 줄에서 'new'를 생략 할 수 없었습니까? 'value'와 'record'용어는 키워드가되고 현재 사용되는 'immutable'을 대체합니다. 그리고 '타입'맞죠?)

@swissr 이 두 유형의 유일한 차이점 (대부분의 사용자가 알고 있어야 함)은 한 필드의 필드가 변경 될 수 있고 다른 필드는 변경할 수 없다는 것입니다. 그들의 이름이 유일한 의미 구별을 나타내면 논리적입니다. (언급했듯이 값과 참조를 사용하는 구현은 유동적입니다. 예를 들어 개선 된 컴파일러는 최적화로 참조에 의해 큰 isbits 유형을 자동으로 전달할 수 있으며 반대로 작은 가변은 특정 상황에서 스택으로 이동할 수 있습니다.)

type 대 struct 와 관련하여 abstract , Union{} , typealias 등으로 추상 데이터 유형을 만들 수 있음을 알 수 있습니다. Tuple{} 의 경우 새로운 유형인지 아니면 매개 변수화 된 유형인지 논쟁의 여지가 있지만 실제로는 _ 사용자 정의 구체적인 유형 _은 bitstype , type 및 immutable 이것들의 구문은 그들이 어떻게 든 포함하는 데이터를 정의하고 추상적 인 것은 정의하지 않는다는 점에서 추상적 인 정의와는 틀림 없다. immutable 를 const type 로 변경하면 상황이 명확 해집니다.

나는 언어에 대해 걱정하고 전문적인 단어 struct 를 전파하는 것에 대해 걱정합니다. 유일한 이유는 전통이기 때문입니다. 우리가 평신도의 용어로 논의되는 프로그래밍 언어를 만들 기회가있을 때입니다. 이것이 도움이되지 않는다고 생각하는 예는 Symmetric{Matrix{T}} 와 같은 래퍼 유형을 만들 때입니다.-토론에서 "이 struct 를 하나의 필드로 만들었습니다. "내가 말할 수있는 때"어떤 ... 내가 만든 Symmetric 래퍼 type 에 대해 Matrix "(그 문장의 절반은 실제 구문이라고 메모를 할). "래퍼 구조체"? 일종의 어리석은 소리-누가 하나의 필드로 구조체를 만들까요? 그 문제에 대해 필드가없는 싱글 톤은 어떻습니까? types 및 immutables 의 상당 부분은 (사소하지 않은) 데이터 구조 를 생성하도록 정의되지 않고 래퍼 및 싱글 톤과 함께 강력한 유형 및 디스패치 시스템을 사용하는 명시적인 목적으로 정의됩니다. IMO 이것은 Julia의 가장 흥미롭고 강력하며 표현력이 풍부한 측면입니다 (_fast_라는 사실과 결합 됨).

struct 의 모든 기능은 구조를 사용하여 특성 등을 구현할 수 있다는 것을 알고있는 숙련 된 템플릿 C ++ 메타 프로그래머에게만 즉시 명백 할 것이라고 생각합니다. 이는 약간 부끄러운 일입니다.

"종류"는 유형 이론에서 상당히 특정한 기술적 의미 를 가지고 있습니다.

목표 / 장점이 type 를 무료로하는 것이라면 어떻게하나요?

const datatype  # immutable
datatype        # type

그것들은 구체적인 유형이므로 아마도 데이터를 포함하고 DataType 를 구성하는 (많은) 방법 중 하나입니다.

"종류"는 유형 이론에서 상당히 특정한 기술적 의미를 가지고 있습니다.

위키에 대한 소개는 Type{} ( DataType 및 TypeConstructor , Union 등을 허용 함)과 정확히 똑같이 들립니다. 중단 할 가치가 있습니다)

kind 은 여기에서 올바른 단어가 아닙니다.

대부분의 경우 가장 좋은 방법은 분야의
표준 어휘로 바꾸려고하는 대신
추측이 더 쉬울 것입니다.

이 결정은 비공식 연설에는 영향을 미치지 않습니다. 당신은 여전히 ​​"나는
좀 더 구체적인 키워드를 사용하면
정확해야합니다.

제프. const struct 및 struct 이 (가) immutable 대비 type 보다 개선 될 것이라고 _do_ 생각합니다 (하지만 그렇다고해서 더 나은 것).

struct가 구조 또는 구조로 더 많이 인식한다고 생각할 때 둘 다 또는 둘 다?

@andyferris 내 'class'및 ' const struct 및 struct 가 개선 될 것이라는 것을 지원하지 않는다는 의미는 아닙니다. 'const'를 피하고, 'immutable'을 보존하고 'struct'를 제외하고 싶을 때 가능한 용어를 찾는 또 다른 시도였습니다 (언급 된 구현을 알고 있었지만 80 + %의 사례에서 맞다면 괜찮다고 생각했습니다) .

fieldtype (또는 fieldstype )는 어떻습니까? 그것은 평행 bitstype 와 일치 fieldnames() .

글렌,
나는 진실을 좋아한다. fieldstype이 더 나은 선택입니다. 어떤 것이 단수 또는 복수가 될 수있는 복수형을 사용하는 것이 적절하기 때문입니다.
-제프리

class 는 괜찮을 수 있습니다. 우리는 원래 객체 내부의 메소드와 클래스 기반 OO와의 연관 때문에 거부했습니다. struct 이 더 정확하다고 말할 수 있습니다.

나는 struct 를 어떤 것에 대한 줄임말로 보지 않는다; 이 시점에서 이러한 종류의 데이터 구조가 호출됩니다. 다소 재미있게도 lisp에는 cons 이 있는데, 원래는 construct 의 약자 ​​였을 수 있지만 사람들은이 사실을 금방 잊어 버리고 "단점 셀"에 대해 이야기하기 시작했습니다.

계속해서 class 를 거부해야한다고 생각합니다. 이 용어를 사용하면 Julia 스타일과 상반되는 수많은 OOP 기대치를 불러 일으킬 수 있습니다.

나는 struct 가 무엇이든 짧게 보지 않지만 C의 구조체에 대한 암시 적 참조가 Julia가 값 유형이 될 것이라는 것을 암시한다고 걱정합니다. 물론 그렇지 않습니다. 이를 위해 현재는 즉각적인 의미가 훨씬 적기 때문에 record 쪽으로 약간 기울고 있습니다.

명확하지 않을 수있는 점을 명확히하기 위해 const record 또는 const struct 것은 모든 필드에 const 매핑을위한 짧은 의미로 해석되는 경우에만 실행 가능하다고 생각합니다. , 이는 개별 필드를 const 로 표시하는 것을 지원한다는 것을 의미합니다. 그래서 제가 말하는 것은 우리가 이것을 가질 수 있다는 것입니다.

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

여기서 T3 및 T4는 실제로 동등한 유형을 설명합니다. 즉, const record 쓰는 것은 모든 필드가 const 약어입니다. 이것이 해석이 아니라면 불변성과 불변성의 융합은 이미 개념적 혼란의 공통된 근원이기 때문에 위험하다고 생각합니다. 그리고 우리가 그 용어 혼란을 더하면 문제를 돕지 않을 것입니다.

여기서 T3과 T4는 실제로 동등한 유형을 설명합니다. 즉, const 레코드를 작성하는 것은 const가되는 모든 필드에 대한 속기 일뿐입니다.

const record immutable 지금 의미하는 바를 의미한다고한다면 이것은 사실이 아닐 수도 있습니다. const record 는 필드를 변경할 수없는 참조 유형을 설명합니다. 현재 immutable 는 값 유형입니다.

record 대한 토론은 https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 및 다음 주석을 참조

@vtjnash 좋은 지적이지만, immutable 가 참조를 포함하는 경우 "참조"유형이되는 지금 발생하는 상황과 유사합니다.

record 가 덜 흔하다는 사실은 괜찮다고 생각합니다. 명사와 동사 모두 유용한 단어라는 사실이 더 문제가됩니다.

nuple 어때요? 물론 "named tuple"의 줄임말입니다.

위의 제안이 마음에 듭니다.

const datatype  # immutable
datatype        # type

지금까지 최고입니다. 그것은 역사적인 짐과 함께 오래된 단어를 가져 오는 것을 피하고 나에게 완전히 분명해 보인다. 물론 julia의 유일한 데이터 유형은 아니지만 일반 사용자가 정의한 가장 일반적인 데이터 유형입니다.

문서에서 이것을 설명하기 위해 용어도 변경하고 이와 같은 장의 제목을 더 많이 변경할 계획 이 있습니까? 그렇지 않다면 composite 및 immutable composite 또는 const composite 가장 좋습니다. const 는 전역 상수에도 사용되기 때문에 두 가지 모두에 대해 const 또는 immutable 를 선택하고 const 약간 선호합니다. 더 짧습니다. 적어도 합성이라는 단어는 대부분의 신규 사용자에게 익숙하지 않아서 문서를 강제로 살펴보고 C 이름과의 유사성으로 인한 잘못된 가정을 피할 수 있습니다. const 에 대한 잘못된 가정은 C ++에서 익숙한 사람은 아무것도 가정하지 않는 것을 알기 때문에 가능성이 낮아 보입니다.

또한 불변성을 나타 내기 위해 두 단어를 사용하는 이점은 필요할 때 가능한 미래 const abstract 및 const bitstype 합니다.

const 레코드를 만들면 현재 불변의 의미를 의미하는 것은 사실이 아닐 수도 있습니다. const 레코드는 필드를 변경할 수없는 참조 유형을 설명합니다. 현재 불변은 값 유형입니다.

어 오. immutable 의 가치 또는 비가 치가 구현 수준에서 정의되었다고 생각했고 모든 사용자는 필드를 리 바인드 할 수 없다는 점을 고려해야합니다. 값에 의한 전달 (또는 그렇지 않음)은 순수한 ABI 문제이며, 컴파일러는 원칙적으로 더 효율적인 것을 자유롭게 선택할 수 있어야합니다. 나에게 불변의 사용자가 볼 수있는 의미는 const 의 현재 의미를 유형의 모든 필드에 적용하는 것과 정확히 동일하게 보입니다.

불변의 의도 된 사용자 수준 의미론에 대해 여전히 혼란 스럽습니까, 아니면 여기서 구현 세부 사항을 이야기하고 있습니까?

누플은 어때? 물론 "named tuple"의 줄임말입니다.

record ) 사용할 수도 있습니다. 예를 들어, 명명 된 튜플은 Erlang에있는 record 입니다. 그리고 데이터베이스 세계에서도 생각합니다.

그러나 Julia가 C 아는 사람들과 더 많이 겹친다면 struct 가 더 적절한 변경입니다.

개인적으로 record 종류가 이상하고 명확하지 않다는 것을 발견했습니다. 데이터베이스 세계에서 레코드는 테이블의 행입니다. 그것은 Julia 유형 (불변 또는 기타)과 같은 일반적인 것과 혼란스러운 충돌처럼 보입니다.

이 스레드를 다시 읽은 후 composite 대해 type composite 쪽으로 기울고 있습니다. 그것은 Jeffs의 "한 문장 규칙"을 보유하고 있으며 이에 대한 부정적인 투표는 많지 않았습니다. 이 용어가 다른 언어에서 그렇게 많이 사용되지 않는다는 것은 제 생각에는 문제가 아닙니다. 그리고 composite 는 실제로 찾을 수있는 가장 설명적인 단어입니다. 이것이 문서에서 이러한 것들을 composite types 라고 부르는 이유입니다.

Fortran에서 왔지만 type 키워드가 괜찮다고 생각합니다.
최소 현명한 변경은 immutable -> const type 입니다.

하지만 type 정말 가야한다면
composite 및 const composite 가 차선책 인 것 같습니다.

immutable -> const type 은 확실히 실행 가능해 보입니다. 동시에 중단을 피하고 키워드를 제거하며 언어에 명확성을 추가합니다.

type 를 사용할 수 없다는 것이 슬프지만 솔직히 말해서 제가 사용하고 싶은 것은 Type 입니다. 내 유형 변수 10 개 중 9 개는 동적 유형 분석을위한 DataType 변수가 아닌 정적 디스패치를위한 매개 변수입니다 (예외가 생성되는 함수). inference.jl을 작성하는 사람들에게는 사실이 아니지만, 당신이 원한다면 그들은 실제로 언어의 "대상 청중"이 아닙니다.

관련 질문 : 최상위 수준에서 type 를 사용할 수 있지만 함수 내부 (현재는 항상 유효하지 않음)에서 변수 이름이 될 수 있도록 허용합니까? 또는 더 나아가 유형 정의의 구조는 매우 구체적입니다 ... 전역 변수 (또는 함수)도 type 바인딩되도록 허용하면서 유형 정의를 특정 구문으로 감지 할 수 있습니까?

즉, 유형을 정의하는 구문을 유지하면서 키워드 동작을 제거 할 수 있습니까?

(아마도 imo) 강력한 위험이 붙어 있습니다. 특이한 사전 법이주의를 산만하게하기가 너무 쉬워집니다. 그리고 누락 된 마이크로 연속성은 협업과 명확한 커뮤니케이션을 쉽게하기에 파괴적입니다.

@ c42f :

불변의 의도 된 사용자 수준 의미론에 대해 여전히 혼란 스럽습니까? 아니면 여기서 구현 세부 사항을 이야기하고 있습니까?

아니, 넌 아니야. 난 엉망 이었어. 불 변형은 실제로 값 유형이 아니지만 변이 형은 확실히 그렇지 않으며 C와 동일한 용어를 사용하는 것이 그렇다는 것을 암시 할 수 있다고 느꼈습니다.

나는 C의 맥락에서 구조체 "값 유형"을 호출하는 것이 합리적 일지 명확하지 않다는 것을 깨달았습니다. 실제 상황은 C가 값에 의한 전달 언어이기 때문입니다. 따라서 데이터 유형 자체가 아니라 전달 및 할당 규칙이 다릅니다.

이 문제가 열리는 변경 사항을 적용하는 데 전적으로 찬성합니다. 유용성은 후보 용어 중 하나가 사용되는 것보다 하나가 사용되는 본능적 선호보다 중요합니다.

_이기는 하지만_

실제 상황이 C이기 때문에

후보 용어 중 struct 이 가장 선호되지 않는 이유를 잘 포착합니다.

제가 판매하는 이야기는 다음과 같습니다. "C와 julia에서 struct 는 고정 된 필드 이름 집합을 다양한 유형의 값에 매핑하는 데이터 구조입니다. 가치에 따라 줄리아는 공유를 통해 전달됩니다. "

그 계정은 번거롭지 않고 완전히 정확합니다. 그 안에있는 모든 것이 성공적으로 검색 될 수 있습니다. PL 이론가는 그것에 대해 불평하지 않을 것이며, 비 PL 이론가는 그것을 듣고 무언가를 배울 것입니다.

나는 그 이야기를 산다. 궁금하지만 여기에 PL 이론가가 불평 할만한 용어가 있습니까? 나는 줄리아가 PL 이론가와 비 이론가 모두를 만족시키는 틈새 시장에 적합하다고 생각하기 때문에 여기에서 정확성과 일반 명확성의 균형을 맞추는 것이 중요해 보입니다.

글쎄요, 저는 다른 사람의 입에 말을하고 싶지 않습니다. 구조체가 "값 유형"이기 때문에 struct 이 혼란 스러울 수 있다는 생각을 다루고 싶었습니다.

immutable 은 (는) 단일 단어 키워드로 유지되어야한다고 생각합니다. const type 또는 const struct 또는 immutable struct 싫어합니다. 저는 immutable 를 많이 사용하는데 다른 모든 것이 하나의 단어 일 때 이러한 선언이 두 단어로되어있는 것이 정말 어색하다고 생각합니다. 그것은 진정한 관심사가 아니기 때문에 타이핑의 의미가 아닙니다. 그러나 "태그"처럼 변경 불가능하다는 점에서 2 등급 느낌이 듭니다.

@TotalVerb 나는 그것이 사실과 매우 호환

type MyType
    const field::Int
end

똑같이 행동해야

immutable MyType
    field::Int
end

지금합니다.

따라서 const type (또는 const struct , const composite 등)은 const 를 각 필드에 바로 가기로 브로드 캐스트하는 것이 유용 해 보입니다 (하지만 꼭 필요하지는 않음) 기능. 나는 미래에 컴파일러가 당신이 어떤 것을 입력했는지조차 알지 못하기를 바랍니다 ( const type 또는 const -전자는 파서에 의해 후자로 변환 될 수 있습니다). 이 시점에서 왜 immutable 합니까?

"태그"처럼 불변성을 갖는 것은 2 등급 느낌을줍니다.

Jeff와 Stefan을 올바르게 이해하면 immutable 는 유형의 필드가 상수 바인딩임을 나타내는 태그 일뿐입니다. 상수 (_really_ constant, C와 같지 않음)는 컴파일러가 최적화하는 데 도움이되며 필드 자체가 반복적으로 상수 또는 기본 요소 (예 : isbits )이면 더 많은 최적화를 수행하는 데 도움이됩니다. 이것은 알아두면 좋지만 의미 상 중요하지는 않습니다. 의미론을 현재 동작에 연결하면 향후 해당 동작을 개선하기가 더 어려울 수 있습니다.

그러나 중요한 의미 차이가 있습니다. 변경 불가능한 유형은 값이므로 객체의 ID가 필드에 의해 지정된다고 안전하게 가정 할 수 있습니다. 불변 유형의 객체는 사용자의 관점에서 필드에서 액세스 할 수없는 특별한 "식별 기능"이 없습니다. 반면에 단일화되지 않은 가변 유형의 객체는 분명히이 보이지 않는 "ID"를 가지고 있습니다. 많은 불변 유형이 박스형 객체로 저장되므로 실제로 내부적으로이 추가 ID가 있다는 사실은 의미론과 무관합니다.

제 생각에, 그것은 단지 _ 최적화 _가 아닙니다.

immutable Complex{T} ... end

대신에

type Complex{T} ... end

사용자가 볼 수있는 행동의 많은 측면이 변경되기 때문에 : === , 기본값 == , objectid , hash 등. 변경 불가능한 유형은 변경 가능한 유형의 기능의 하위 집합을 제공합니다. 반대로, 그것들이 불변이라는 사실은 불변 유형이 더 강력해질 수 있도록 중요한 보장을 제공합니다.

커뮤니티가 const 및 struct 에 정착하기 전에 constant 및 structure 대한 플러그를 하나 더 만들고 싶었습니다.

1) 실제 단어를위한 3 개의 추가 문자!
2) struct 가 관용적이라는 주장에도 불구하고
2a) R에서 마이그레이션하는 사람 (나와 같은)이 혼란 스러울 수 있습니다.
2b) 프로그래밍을 처음 접하는 사람 (가장 도움이 필요한 사람)은 혼란 스러울 수 있습니다.

재미를 위해 struct가 혼동 될 수있는 어리석은 단어 :
파괴 불가
방해
포스트 구조주의
상부 구조 (oh hi Marx)

및 const :
콘스탄티노플
별자리
보아 수축 근
위헌

불변의 불변과 이런 종류의 const에 의해 얻어지는 PL 아름다움 / 권력이 있는가?

즉, 같은 질문입니다.

현재는 전역 범위에서 변수를 사용하는 것이 문제가되고 해결해야 할 trick 은 (는) 단일 항목으로 const 벡터의 가변 값을 래핑하는 것입니다. 이 경우 const 은 방송되지 않습니다. const 의 방송 버전은 벡터뿐만 아니라 벡터의 항목 값에도 상수 성을 적용합니다. 마찬가지로 다른 종류의 값을 감싸거나 묶는 값을 보유 할 수있는 필드가있는 유형 선언입니다. 불변 유형은 이제 필드 값에 불변성을 부여하지 않습니다 (필드를 통해 간접적으로 도달 할 수있는 값이 아님). "이 항목 [또는이 유형의 항목]에 부여 된 값이 변경되지 않음 [변경이 허용되지 않음]을 의미하는 키워드의 방송 버전과 함께 제공되는 우아함과 유용한 기능이 있습니다. .

즉각적인 (비 방송) 정렬이 널리 사용되며, Julia의 사전 컴파일이 Julia의 사전 컴파일이 방송 가능한 constness 도입을 더 잘 / 빠르고 / 간단하게 만들거나 의존하도록 줄리아로 수행하는 작업 중 일부가 훨씬 쉬워 진다고 가정하면 재생이 필요합니다. 즉각적인 정렬과 잘 어울립니다. 이것이 추가적인 _ 이론적 프로그래밍 언어의 장점 _ (표현의 용이성, 표현력, ...)을 가져 오는 방법인지 궁금합니다. 방송 상수는 참조 유형이 포함되어 있거나?가있는 유형의 값을 통해 방송됩니다. (a) 내부 임베딩 또는 컨테이너가없는 값에 도달하거나 (b) 값에 도달하는 것은 자체적으로 (독립적으로 또는 달리) 방송되지 않는 상수를 갖는 유형의 것입니다.

이것에 대해 더 생각해 보면, 내가 정말로 파손 할 가치가 있다고 생각하는 유일한 변화는 bitstype -> primitive isbits 입니다.

이 토론의 진짜 요점 인 type 및 immutable ,이 시점에서 제가 가장 좋아하는 옵션은 전혀 변경되지 않습니다. 유형을 구성하는 type 는 명확하고 불변 유형을 구성하는 immutable 는 명확합니다. 그러나 나는 앞으로의 언어에 가장 적합한 것에 대한 그들의 판단을 암묵적으로 신뢰하기 때문에 우리의 최고 군주가 우리에게주는 것을 기꺼이 받아 들일 것입니다.

const 또는 constant 대신 fixed를 사용하지 않는 이유가 있습니까? 적어도 나에게는 훨씬 더 명확한 설명 인 것 같습니다.

@JeffreySarnoff 참조 (예 : 포인터)를 얻을 수있는 것에 const ness를 암시하는 것은 어렵습니다. Julia의 "공유"의미론은 컴파일러가 진정으로 불변성임을 증명할 수없는 모든 것이 참조 유형이어야 함을 의미합니다. 이러한 참조를 const type ( immutable )의 필드에 바인딩하면이 참조가 다른 곳에 존재하지 않는다는 증거가 없으므로 참조 된 데이터가 일정하다는 증거가 없습니다.

이 동작을 변경하는 것이 Julia 언어의 근본적인 변경이라고 생각합니다.

@andyferris 명확한 답변에 감사드립니다.

const 또는 constant 대신 fixed 를 사용하지 않는 이유가 있습니까? 적어도 나에게는 훨씬 더 명확한 설명 인 것 같습니다.

나는 그것이 영구적 인 바인딩이고 바인딩 된 개체 내부의 데이터가 변경 될 수 없다는 것을 (필연적으로) 반영한다는 것을 반영하는 const 또는 constant 보다 더 나은 것이 있는지 궁금했습니다. fixed 은 (는) 어떤 방식 으로든 갈 수 있지만 다른 언어에서는 보지 못했습니다 (다시 말하지만 다른 언어에서 Julia의 바인딩 / 공유 의미를 알아 차리지 못함).

아마도 bind (예 : bind x = 2 ) ... 시소러스가 glue 제안합니다 ... 이것은 꽤 추측이되고 있습니다 ...

const 를 더 정확한 것으로 바꾸는 아이디어는 매력적입니다. 그러나 우리는 유형 선언과 개별 변수 할당 모두에 현명하게 적용하기를 원합니다. fixed struct 은 의미가 있지만 유형 선언이 아닌 고정 된 구조체의 필드입니다. 불행히도 bound struct ( tied struct ?)는 다소 불분명 해 보입니다. 어떤 이유로 const 가 유형에 적용될 때 더 명확 해 보입니다.

a 타입 선언과 개별 변수 할당 모두에 현명하게 적용하기를 원합니다.

나는 그것을 목표로하는 것이 생산적이라고 생각합니다.

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

말이된다. type , struct 앞에 바로 가기가 있으면 위를 의미하는 바로 가기가됩니다.

@generated 와 같이 사물의 특성을 변경하는 다른 중요한 장식처럼이 매크로를 매크로로 만드는 것이 합리적 일 수 있습니다. 그러면 또 다른 키워드가 제거됩니다 ...

type -> composite 대한 +1,하지만 type 에서 실제로 변경된 사항은 훌륭하게 들립니다.

스레드에 새 댓글을 추가하지 않고도 GitHub 문제에 투표 할 수 있기를 바랍니다. 내 투표는 mutable 및 immutable 입니다. 매우 깔끔하고 깨끗합니다. struct 은 (는) 남용되며 변경 가능성 부분을 강조하지 않습니다.

추신 : 누구든지 GitHub에 기여하고 투표 기능을 추가 할 수 있습니까? "문의하기"페이지에서 질문했지만 이메일이 분실되었을 수 있습니다.

최근 다른 많은 언어에 대한 배경 지식이있는 Julia로 전환 한 후 Julia가 C / C ++의 모든 혼란스러운 const-ness 문제를 C 스타일 이름 지정 및 끌어 오기를 채택하는 것을보고 싶지 않습니다. 대신 데이터 유형 선언에 값 유형 또는 공유 참조 유형의 의도를 반영하는 개념을 제공하면 단순히 변경 가능성을 참조하는 대신 크게 도움이되었을 것입니다.

Julia에 대한 나의 초기 기대치는 변경 불가능한 C 스타일 struct 또는 Python 객체와 유사하게 동작하는 단순한 type 였을 것입니다. Julia는 함수형 프로그래밍 스타일과 속도에 관한 것 같기 때문입니다.
type ... 및 immutable... 의 비대칭 성으로 인해 여전히 혼란 스럽지만 DataType 에서 typeof(SomeType) 또는 'bitstype의 실제 의미 '및 간단한 Alias = DataType 문 대신 typealias 키워드가 필요합니다.

따라서, 나는 투표 것 datatype 과 일치 될 것이라고, typeof(SomeType) == DataType 와 함께 자극 유사성 휴식 것이 ::Type{} . composite [datatype] 변경 가능한 유형을 장식하면 기본 'bitstypes'에 비해 특별하고 아마도 더 비싼 특성을 강조 할 수 있습니다.

C / C ++의 모든 혼란스러운 const-ness 문제 가져 오기

이 키워드의 이름을 바꾸면 그렇게되지 않습니다. 이러한 문제는 여기에 전혀 관련되지 않은 정적 검사 및 캐스트와 관련이 있습니다.

값 유형 또는 공유 참조 유형이 되려는 의도는 단순히 변경 가능성을 참조하는 대신 크게 도움이되었을 것입니다.

나는 이것을 완전히 이해하지 못합니다. 객체가 불변 인 경우 값 또는 참조로 전달되는지 여부를 알 수있는 방법이 없습니다. 그렇다면 값 / 참조 구별이 어떻게 기본이 될 수 있습니까?

datatype 은 나쁜 선택이 아닙니다. 하지만 datatype 대 composite datatype 는 가변성 구분을 전달하는 좋은 방법이라고 생각하지 않습니다.

@JeffBezanson , C와 유사한 const-ness를 사용하여 Julia 유형이 C / C ++에서와 동일한 동작을 가질 수 있다는 암시 적 기대를 의미했습니다. 반환 유형. 따라서 C / C ++를 참조하지 않는 키워드를 선택할 때 좋은 선택이므로 const struct 하지 마십시오.

'값 대 참조'관련 : 불변 유형이 멤버를 직접 포함하고 멋지고 간결한 빠른 어셈블러 코드를 생성하는 이유를 이해하는 데 꽤 오랜 시간이 걸렸지 만 '유형'에는 객체에 대한 모든 호출이 포함되지 않았고 여전히 포함되어 있습니다. 즉, 속도를 겨냥 할 때 일반적으로 NTuple을 사용하는 이유입니다. 따라서 '불변'과 '변이 가능'을 읽을 때 나는 Fortran에서 '매개 변수'로 의미를 예상했지만 실제 데이터 유형의 레이아웃이나 구현의 종류가 변경되지 않았습니다.
아마도 대부분의 경우 Complex와 같은 작은 복합 유형에 대해서는 '불변 값'의미 체계를 원할 수 있지만 배열 등과 같은 큰 데이터 세트에 대해서는 '변경 가능 및 참조 / 비 복사'를 원할 수 있습니다.
그런 다음 기본 의도는 아마도 변경 가능성이 아니라 데이터 복사를 피하는 것입니다.

그러나 그것은 빠른 어셈블러 코드를 얻기 위해 Julia 저수준 기계를 배울 때의 경험 이었지만 키워드 이름 지정에 그것을 더 잘 반영하는 방법과 그것을 가변성으로 결합하거나 표현하는 방법을 모릅니다.

나는 당신이 @mjw에서 오는 곳을 얻었습니다. 나는 거기에 있었지만 C / C ++에 대해 아는 모든 것을 배우지 않는 것이 낫다고 생각합니다. 여기에서 불변하는 것은 const -ness이며 무언가가 스택인지 또는 동적으로 할당되는지, 참조 또는 값으로 전달되는지 여부는 자유롭게 변경할 수 있으며 컴파일러에 대한 최적화 선택이 될 것입니다. 모든 것이 동적으로 할당되고 참조로 전달되는 언어를 만들 수 있습니다. 이것은 Julia의 기본 방식입니다 (박스형 값의 경우 유형을 알 수없는 경우에도 "공유로 전달"을 구현합니다). 여러분 (그리고 나머지 우리)은 현재 최적화가 구현 된 곳이기 때문에 작은 불변성이 훨씬 더 빠르다는 것을 알았습니다. 이것은 최적화를 더 쉽게 만드는 immutable 의 의미 체계의 결과입니다.

그러나 실제로는 큰 불변 항목이 참조 (아마도 스택 포인터에 의해 전달되는 경우)를 선호하지만 NTuple{1_000_000} 를 힙 할당하는 것이 가장 좋으며 알려진 크기의 작은 변경 가능 항목은 스택 할당됩니다. (가능한 경우 다시). 가비지 수집조차도 경우에 따라 정적으로 결정될 수 있으며, 예를 들어 루프 내에서 힙 공간을 재사용 할 수 있습니다. 나는 이것을 이스케이프 분석이 필요한 미래의 최적화 기회라고 생각합니다 (그리고 이것들 중 어느 것도 언어의 의미론에 영향을주지 않고 성능에만 영향을 미칩니다).

제가 말하고자하는 것은 키워드가 몇 년 안에 변경 될 구현 세부 사항 (즉, 효율적인 소형 가변 및 효율적인 대형 불변)이 아니라 10 ~ 2 년 동안 일정하게 유지 될 의미를 반영해야한다는 것입니다.

나는 Julia 유형이 C / C ++에서와 동일한 동작을 가질 것이라는 암시 적 기대를 의미했습니다.

이것은 솔직히 const -> constant 을 고려할 충분한 이유가 될 수 있습니다. 현재로서는 const 가 유일한 축약 형 키워드 일 수 있으므로 어쨌든 이상하게 만들 수 있습니다.

간단한 Alias = DataType 문.

나는 이것이 의미있는 곳에서 절대적으로 괜찮다고 확신하지만 typealias RealMatrix{T<:Real} Matrix{T} 와 같이 더 복잡한 유형의 수정을 허용하지 않을 것이며, 새로운 Type 생성하지 않는 단순한 바인딩입니다 TypeVar ). RealMatrix = Matrix{T <: Real} 로 정의하고 싶지 않다면 apply 가 TypeVar 대해하는 apply 일반화하십시오 (즉, TypeConstructor 만듭니다) ... 실제로 흥미로운 아이디어입니다 (하지만 구문 문제가 있으므로 typealias 가 좋은 이유입니다 ...).

@andyferris , 나는 이미 '

@mjw 훌륭합니다. 저는 그 모든 것에 동의합니다. :)

가장 좋은 GitHub 기능인 반응 이모티콘을 사용하여 설문 조사에 가장 가까운 방법을 시도해 보겠습니다.

여기에서는 _ 특정 순서없이 _ 가장 많은지지를받는 ​​제안을 표로 정리했습니다. 지정된 이모티콘을 사용하여 반응하여 해당 제안에 투표하세요. 데스크톱 브라우저를 통해 GitHub에 액세스해야한다고 생각합니다. AFAIK 반응 이모지는 모바일 인터페이스에서 구현되지 않았습니다. 이 게시물의 오른쪽 상단 모서리에있는 얼굴을 클릭하여 그림 이모티콘 메뉴에 액세스합니다.

| type | immutable | 반응 |
| :-: | :-: | :-: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (웃음) |
| composite | const composite | : tada : (만세) |
| datatype | const datatype | 😕 (혼란) |
| type | const type | ❤️ (하트) |

투표에 실패하는 것은 물론 nuple 에 대한 암시 적 투표에 해당합니다. : trollface :

저는 "민주적으로"이와 같은 논쟁적인 결정을 내리는 것을 좋아하지 않습니다. 합의없이 논의가 진행 되었다면 BDFL의 결정을 연기 할 것입니다.

공정한 포인트, @TotalVerb. 내가 전에 말했듯이, 나는 그들이 최고라고 생각하는 것을 우리에게 줄 수있는 힘을 가지면 완전히 괜찮을 것입니다. 스레드가 약간 구불 구불하고 투표에 대한 @juliohm 의 요점이 합리적 인 것처럼

개인적으로 저는 미학적으로 두 단어를 갖는 것을 좋아하지 않는다고 생각합니다 ( const type ). 그것은 또한 약간 의미 상 불협화음을 느낍니다. const x = 1 라고하면. 우리는 x 가 일정하다는 것을 의미합니다. const type; x; end 라고하면이 유형의 인스턴스가 생성 후에도 변경되지 않는다는 의미입니다. 직선 보간에서 무언가가 상수 유형이라고 말하는 것은 유형 자체가 변경되지 않는다는 것을 의미합니다 (이미 이미 그렇습니다). 또한보십시오:

type foo
end
const bar = foo

따라서 bar 는 const이고 항상 foo이지만 const type 는 아닙니다. const (바인딩에 적용)의 기존 의미 체계에 대한 wrt처럼 느껴지며 유형의 이름은 이미 const입니다.

간결하고 의도 된 의미를 전달하며 변수 이름으로 바람직하지 않은 키워드가 없다고 생각합니다. 이러한 목표에 가장 가깝다고 생각하는 용어는 선언 된 세 가지 유형에 대한 mutable datatype , immutable datatype 및 abstract datatype 입니다.

type 및 immutable 외에도 추가 변경 가능한 값 유형이 있기를 바랍니다.
문제 어딘가에서 몇 가지 논의를 보았지만 기본적으로 현재 다음과 같은 시나리오를 효율적으로 처리하는 것은 불가능합니다.

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  

이 코드는 sizeof(T) * 10 값 유형의 깔끔한 배열을 생성하지만 일부 필드를 변경하려면 일반적으로 3-5 개의 필드 길이 인 전체 T(...) 를 다시 할당해야합니다.
그래서 기본적으로 내 5 센트 :
type -GC 수집 참조
immutable -변경할 수없는 값 (스택 할당) 유형
mutable -특히 배열에서 변경할 수있는 값 유형

변경할 수있는 값 유형

변경을 허용하는 것이 사물의 정체성을 부여하는 것이므로 달성하기 불가능한 목표라고 생각합니다.

대신이 접근 방식을 원할 수도 있습니다. # 11902

가변 과 불변 을 분리하는 것을 제외하고는 값 과 참조를 분할하는 것이 더 좋습니다.

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

값과 참조를 인위적으로 구분하여 언어를 지나치게 복잡하게 만들 필요가 없습니다. 변경 가능 및 불변 유형은 의미 상 훨씬 더 간단합니다. 유형이 값 유형이라는 사실은 단지 최적화 일뿐입니다.

@Keno 는 좋은 지적을합니다

개인적으로 저는 미학적으로 두 단어를 갖는 것을 좋아하지 않는다고 생각합니다 (const type). 그것은 또한 약간 의미 상 불협화음을 느낍니다. const x = 1이라고하면 x가 일정하다는 것을 의미합니다. 우리가 const type이라고 말할 때; 엑스; end 우리는이 유형의 인스턴스가 생성 후에 변경되지 않는다는 것을 의미합니다. 직선 보간에서 무언가가 상수 유형이라고 말하는 것처럼 느껴진다는 것은 유형 자체가 변경되지 않는다는 것을 의미합니다 (지금은 이미 그렇습니다)

앞서 언급했듯이 "올바른"의미는

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

여기서 z.re 는 const z.re = 1 와 유사한 것을 입력 할 때와 똑같이 동작하므로 정확히 어떤 바인딩이 const 인지에 대한 의미 상 혼동이 없습니다.

@JeffBezanson이 말했듯이 이것은 많은 수의 필드에 실제로 편리하지 않으며 현재 유형의 구현과 호환되지 않습니다. 부분적으로 변경 가능하고 부분적으로 일정한 구조체는 미래에 구현되거나 구현되지 않을 수 있습니다. 그러나 현재와 미래에 모두 의미 가 있는 구문이 있습니다.

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

이것이 구현 된 현재 방식으로 매크로는 AST에서 type 에서 immutable 로 변경할 수 있습니다. 앞으로 부분적으로 상수 인 구조체가 구현되면 매크로는 각 필드에 const 를 추가하여 AST에 대한 조작을 계속 수행 할 수 있으며 필드 바인딩이라는 것이 모두에게 분명 할 것입니다. 일정합니다. 미학적으로는 연속 된 두 개의 키워드보다 낫습니다. 함수 ( @generated , @inline , @proagate_inbounds 등)에 대해 유사한 작업을 수행합니다.

@const 는 쉽게 @immutable 또는 유사한 것 ( <strong i="31">@immutable</strong> type Val{T}; end 읽기 OK, IMO)이 될 수 있으며 매크로 아이디어는 struct , composite 와 호환됩니다. , 등등.

@ be5invis 예,이 C #에서 예를 들어, 많은 언어에서 일반적인 방법이된다 struct , 등 여러 가지면에서 어떤 동작합니다 immutable : 그것은 명시 적으로 할당되고, 기능에 사본 전달 배열 ( class | type 의 경우처럼 GC 관리 객체에 대한 참조가 아님). 그러나 _mutable_이며 배열에서 단일 필드로 수정할 수 있습니다.
immutable 경우 두 가지 속성이 혼합되어 있다고 생각합니다.

1. 불변성 (적절한 함수 프로그래밍 수행을위한)
2. 하위 수준에서 값 유형으로 작동

따라서 기본적으로 속성 2 만있는 유형의 도입을보고 싶습니다. 이것은 기존 코드베이스를 방해하지 않습니다 ( immutable 남아 있음).하지만 최소한의 GC 개입으로 빠르게 무언가를 작성하는 사람들에게는 가치가있을 것입니다. .

@johnmyleswhite # 11902에 감사드립니다.

@wgreenr 앞서 언급했듯이 여러 번 논의되었으므로 불가능합니다. 이 문제의 논의와도 실제로 관련이 없습니다.

모든 것이 가능하지만 가변 값 유형을 도입하는 것은 매우 파괴적이고 매우 나쁜 생각입니다. 나는 그것이 겉보기에 간단하고 매력적인 아이디어 인 이유를 이해할 수 있지만, 완전히 다른 종류의 새 객체 의미를 추가하고 유형 그래프를 참조 및 값 의미로 분기하는 것이 언어를 더 좋게 만들지는 않습니다 . 알 수없는 의미론에 따라 동일한 코드가 매우 다른 작업을 수행하므로 일반 코드를 안전하게 작성하는 것이 불가능합니다. 여기 에 예제에 대한 광범위한 논의가

이것이 언급 할 가치가 있는지 확실하지 않습니다. 그러나 C / C ++에서 'struct'는 데이터의 레이아웃에 대해서도 암시합니다. 반면에 더 나은 메모리 레이아웃을 얻기 위해 구조체 멤버를 다시 정렬하는 것이 좋습니다. 구문의 주요 변경을 고려하고 있다면 '구조체'(순서-> C interop)와 '불변'(어떤 식 으로든 순서를 지정할 수 있음)을 어떻게 든 구분할 수있는 메커니즘을 갖는 것이 좋습니다.

나는 줄리아를 처음 접했기 때문에 분명한 것을 놓쳤다면 죄송합니다.

나는 개인적으로 진정한 선호 wrt 이름이 없습니다. 그러나 "추상적"이 이미 존재한다는 점을 감안할 때 아무도 "구체적"을 제안하지 않은 것 같아 놀랐습니다.

또 다른 제안을 추가하려면 다음이 가장 좋습니다.

• 사용 struct 대신 immutable .

• 사용 struct! 대신 type . 영어로 말할 때 이것을 "변이 가능한 구조체"라고합니다.

  • (아마도) struct! 안에있는 일부 필드를 const 로 표시하도록 허용합니다.

몇 가지 정당화 및 생각 :

1) 내가 명백한 것을 놓친 경우가 아니라면, 불변 유형의 값을 조작하기 위해 ! 와 함께 함수를 사용하고 싶지 않습니다. 그것이 틀렸다면 (예를 들어, 변경 불가능한 유형이 변경 가능한 유형을 참조하고 ! 가있는 함수가이를 변경하는 중요한 경우가있는 경우),이 제안은 좋은 제안이 아닐 수 있습니다.

2) 변경 불가능한 유형은 일반적으로 변경 가능한 유형보다 선호되어야한다고 생각합니다. 더 많은 최적화가 적용되고 프로그래머에게 더 예측 가능한 동작이 있기 때문입니다.

3) 이것이 작동하려면, 아마도 거의 모든 경우에서 불변 유형을 최소한 가변 유형만큼 효율적으로 만들기 위해 최적화를 구현하는 것이 전제 조건 일 것입니다. 특히 컴파일러는 큰 불변 유형을 참조로 전달하는 것에 대해 현명해야합니다.

업데이트 : 내가 가진 데 사용 record 대신 struct 있지만 record! 너무 많은 동사 같다. 떠오르는 몇 가지 다른 옵션 : newtype , typedef (10 초 동안 C 프로그래머를 혼란스럽게 함), composite 또는 concrete .

v0.6 기능이 동결되기 전에이 공간에서 어떤 일이 발생할 가능성이 있습니까?

(적어도 공개적으로) 결정이 내려지지 않았고 동결에서 10 일 정도 남았다는 점을 감안할 때 아마도 아닐 것입니다.

나는 이것을주의 깊게 따르지 않았지만 한 가지 의견은 이것이 변경 될 경우, 먼저 문제가되는 파일 / 줄 번호에 대한 좋은보고를 우리에게 요청하고 싶다는 것입니다. 또는 적어도 모듈; 0.5에서는 어떤 패키지에 @deprecate d _binding 가 있는지 알아 내기조차 어렵습니다.

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