(기능적?) 프로그래밍의 맥락에서 "수정"과 "수정"은 무엇을 의미합니까?

(기능적?) 프로그래밍의 맥락에서 "수정"과 "수정"은 무엇을 의미합니까?

---

이 용어는 haskell과 함수형 프로그래밍에 대한 블로그 (특히 sigfpe의 블로그 ) 에서 많이 읽었 지만 그 의미에 대해서는 전혀 모르겠습니다. 나는 대부분의 경우 그것을 모른 채 도망 치지 만, 내가 알았다면 아마도 본문을 훨씬 더 잘 이해했을 것입니다. Google은 나를 돕지 않았습니다. 나는 기술적 인 일에 빠져 있습니다.

또한 세계의 비 기술적 의미 ( "추상적 구체화")는 코드에서 무언가를 구체화하는 것이 실제로 의미하는 바를 이해하는 데 도움이되지 않습니다.

나는 컴퓨터 과학 개념에 다소 느리기 때문에 코드를 사용한 실용적인 예제가 좋을 것입니다. :피

---

그래서 저는 이것에 대해 읽어 봤습니다. 그것이 의미하는 바는 꽤 많습니다. 추상적 개념을 취하고 그것을 구체적으로 만듭니다. 또는 추상적 인 개념을 나타내는 프록시가 있습니다. 예를 들어 Lisp에서는 람다를 사용할 때 프로 시저 추상화 및 적용의 개념이 수정됩니다.

수정 자체는 광범위한 개념이며 함수형 프로그래밍 언어에만 적용 할 수 없습니다.

예를 들어 Java에는 런타임에 사용할 수있는 유형이 있습니다. 이들은 수정 가능한 유형입니다. 즉, 런타임 중에 유형의 추상 개념에 대한 구체적인 표현이 있습니다. 대조적으로, 수정 불가능한 유형이 있습니다. 이것은 Java에서 제네릭을 사용하는 동안 특히 분명합니다. Java에서 제네릭은 유형 삭제의 영향을 받기 때문에 런타임 중에 제네릭 유형 정보를 사용할 수 없습니다 (매개 변수화 된 유형이 제한되지 않은 와일드 카드를 사용하지 않는 한).

또 다른 예는 개념을 모델링하려고 할 때입니다. 예를 들어, Group클래스와 클래스 가 있다고 가정하십시오 User. 이제 둘 사이의 관계를 설명하는 특정 추상 개념이 있습니다. 예를 들어 a User의 구성원이되는 추상 개념은 Group. 이 관계를 구체적으로 만들기 위해 a가의 멤버 isMemberOf인지 여부를 나타내는 메서드를 작성 User합니다 Group. 그래서 여기에서 한 것은 그룹 구성원 의 추상적 인 개념 을 구체화 (실제 / 명시 적 / 구체화) 한 것 입니다.

또 다른 좋은 예는 개체간에 부모-자식 관계가있는 데이터베이스입니다. 이 관계를 나무 의 추상적 인 개념 으로 설명 할 수 있습니다 . 이제 데이터베이스에서이 데이터를 가져와 실제 Tree 객체를 생성하는 함수 / 메서드가 있다고 가정 합니다. 지금까지 한 것은 부모-자식 나무와 같은 관계의 추상적 인 개념을 실제 객체 로 구체화 한 것입니다 . Tree

일반적으로 기능적 언어로 돌아 가면 아마도 수정의 가장 좋은 예는 Lisp 프로그래밍 언어 자체의 생성 일 것입니다. Lisp는 완전히 추상적이고 이론적 인 구조였습니다 (기본적으로 컴퓨터 언어에 대한 수학적 표기법). Lisp의 eval기능이 실제로 IBM 704에서 Steve Russel에 의해 구현 될 때까지 그대로 유지 되었습니다.

Hackers & Painters에서 Paul Graham이보고 한 내용에 따르면, p. 185, McCarthy는 다음과 같이 말했습니다. "Steve Russell이 말했습니다.이 평가판을 프로그래밍하는 것이 어떻습니까? 그리고 저는 그에게 말했습니다. 호, 호, 이론과 연습을 혼동하고 있습니다.이 평가는 읽기를위한 것이 아니라 하지만 그는 내 논문의 eval을 IBM 704 기계 코드로 컴파일하고 버그를 수정 한 다음이를 Lisp 인터프리터로 광고했습니다. 본질적으로 오늘날의 형태 ... "

그래서 리스프가 된 구체화 실제 프로그래밍 언어, 추상적 인 개념에서.  

---

수정

수정은 인스턴스화의 한 형태입니다. 개념을 구체화 할 때 제공 한 사전 정의처럼 추상적 인 것을 취하고 구체적으로 만듭니다.

가능한 유형의 추상 구문 트리에 서식하는 용어로 유형을 수정하도록 선택할 수 있습니다.

일부 언어에 대한 범용 구현을 제시하여 디자인 패턴을 구체화 할 수 있습니다. 예를 들어,

template<typename T> class Singleton {
    public:
        static T& Instance() {
            static T me;
            return me;
        }

    protected:
       virtual ~Singleton() {};
       Singleton() {};
}

싱글 톤 디자인 패턴을 C ++의 템플릿으로 수정합니다.

Hoare의 Quicksort 아이디어를 원하는 프로그래밍 언어로 구현할 수 있습니다. 이런 맥락에서 저는 범주 이론의 개념을 하스켈 코드로 구체화하는 데 많은 시간을 할애합니다.

해당 언어에 대한 통역사로 언어를 수정할 수 있습니다. Perl 언어에 대한 Larry Wall의 아이디어는 Perl 인터프리터로 구체화됩니다.

데이터 구체화 하고 진공 패키지가 함께 공유 메모리에 어떻게 구성되어 있는지를 나타내는 그래프 등의 조건을 구체화.

반사

구체화의이면은 구체적으로 무언가를 취하고 일반적으로 세부 사항을 잊어 버림으로써 추상화를 생성하는 반사 입니다. 추상화가 더 간단하거나 어떤 식 으로든 당신이 말하는 내용의 본질을 포착하기 때문에 이것을하고 싶을 것입니다.

Java, C # 등의 유형 시스템 리플렉션은 프로그래밍 언어의 구체적인 클래스를 가져 와서 클래스가 제공하는 멤버 목록에 대한 액세스를 제공하는 클래스의 추상 구조를 제공합니다. 여기서 우리는 유형의 구체적인 개념을 취하고 그 구조를 설명하는 추상적 인 용어를 생성하고 특정 값을 버립니다.

프로그래밍 언어를 구현으로 구체화하는 방법과 마찬가지로 때때로 반대 방향으로 갈 수 있습니다. 이것은 일반적으로 나쁜 아이디어로 간주되지만 구현을 취하고 바람직한 동작 속성에서 언어 사양을 반영하려고 할 수 있습니다. TeX는 Knuth, sans 사양에 의해 처음 구현 되었습니다. TeX의 모든 사양은 Knuth의 구현에서 반영되었습니다.

(보다 공식적으로 당신이 구체적인 영역에서 추상적 인 영역으로 당신을 데려가는 건망증의 펑터로 반사를 본다면, 이상적으로는 반영이 반사와 인접하게 남게됩니다.)

The reflection package I maintain provides a reify method that takes a term and yields a type that represents it, then a reflect method that lets you generate a new term. Here the 'concrete' domain is the type system, and the abstract domain are terms.

---

From the Haskell Wiki:

To "reify" something is to take something that is abstract and regard it as material. A classic example is the way that the ancients took abstract concepts (e.g. "victory") and turned them into deities (e.g. Nike, the Greek goddess of victory).

A reified type is a value that represents a type. Using reified types instead of real types means that you can do any manipulations with them that you can do with values.

---

One use I can think of (I'm sure there are others!) is turning a class into a dictionary. Let's take the Eq class (forgetting about the /= operator for the moment):

class Eq a where
    (==) :: a -> a -> Bool

If we reify this class, it becomes:

data EqDict a = EqDict (a -> a -> Bool)

which can be constructed, inspected and so on. Also noteworthy is that you can have only one Eq instance per type, but multiple EqDict values. But the automatic construction of instances (e.g. getting equality for lists when you have it for elements) doesn't work; you'll have to construct the EqDict [a] value yourself.

The reifying process is as simple as this (for this case):

reify :: Eq a => EqDict a
reify = EqDict (==)

A function using the Eq class could transform something like this:

-- silly example, doesn't really do anything
findMatches :: Eq a => a -> [a] -> [a]
findMatches x ys = [ y | y <- ys, x == y ]

-- version using EqDict
findMatchesDict :: EqDict a -> a -> [a] -> [a]
findMatchesDict (EqDict f) x ys = [ y | y <- ys, f x y ]

If you unwrap the EqDict and just pass an a -> a -> Bool, you're getting the ..By functions, like Data.List.nubBy and friends - a similar trick for Ord leads to Data.List.sortBy.

---

Even just in the context of Haskell the term is used very broadly. Andy Gill's reify package allows you to take recursive structures and turn them into explicit graphs. Sigpfe's post on continuations describes reifying the notion of "the rest of the computation" into a value you can pass around. Template Haskell has a reify function (executed, along with TH code in general, at compile time) that when given the name of a Haskell value returns available information on it (where declared, type, etc.).

What do all these cases have in common? They're talking about taking something which we can reason about and know, but which we can't directly programmatically manipulate, and turning it into an actual first class value that we can name and pass around just like any other. And that's generally the intent that people want to convey when they use the word.

---

I know there's the concept of reification in RDF. As stated by Tim Bernes-Lee:

Reification in this context means the expression of something in a language using the language, so that it becomes treatable by the language.

I suppose it's kind of like reflection or introspection. I hope you get some good answers here!

참고URL : https://stackoverflow.com/questions/5314884/what-do-reify-and-reification-mean-in-the-context-of-functional-programmi