लघु संस्करण:
जावा में एकल-कार्य शैली को मज़बूती से बनाने के लिए, आपको (1) टेल-कॉल एलिमिनेशन के लिए किसी तरह के अपरिवर्तनीय-अनुकूल बुनियादी ढाँचे, और (2) संकलक- या रनटाइम स्तर के समर्थन की आवश्यकता होगी।
हम बहुत से बुनियादी ढांचे को लिख सकते हैं, और हम स्टैक को भरने से बचने की कोशिश करने के लिए चीजों को व्यवस्थित कर सकते हैं। लेकिन जब तक प्रत्येक कॉल एक स्टैक फ्रेम लेता है, तब तक एक सीमा होगी कि आप कितना पुनरावृत्ति कर सकते हैं। अपने iterables को छोटा और / या आलसी रखें, और आपके पास प्रमुख मुद्दे नहीं होने चाहिए। कम से कम आप जिन समस्याओं में भाग लेंगे उनमें से एक बार में एक लाख परिणाम वापस करने की आवश्यकता नहीं है। :)
यह भी ध्यान दें, क्योंकि प्रोग्राम को वास्तव में दिखाई देने वाले परिवर्तनों को प्रभावित करने के लिए चलना पड़ता है, आप सब कुछ अपरिवर्तनीय नहीं कर सकते । हालाँकि, आप अपने स्वयं के सामान के विशाल बहुमत को अपरिवर्तनीय रख सकते हैं, केवल कुछ महत्वपूर्ण बिंदुओं पर आवश्यक उत्परिवर्तनों (उदाहरणों के लिए) के एक छोटे उपसमुच्चय का उपयोग करते हुए, जहाँ विकल्प बहुत अधिक महत्वपूर्ण होंगे।
दीर्घ संस्करण:
सीधे शब्दों में कहें, एक जावा प्रोग्राम पूरी तरह से वैरिएबल से नहीं बच सकता है अगर वह कुछ भी करने लायक है। आप उन्हें शामिल कर सकते हैं , और इस प्रकार उत्परिवर्तन को एक बड़ी डिग्री तक सीमित कर सकते हैं , लेकिन भाषा और एपीआई का बहुत ही डिजाइन - साथ ही अंतर्निहित प्रणाली को बदलने की आवश्यकता के साथ - कुल अपरिवर्तनीयता को अस्वीकार्य बनाते हैं।
जावा को शुरू से ही एक अनिवार्य , वस्तु-उन्मुख भाषा के रूप में डिजाइन किया गया था ।
- शाही भाषाएँ लगभग हमेशा किसी न किसी प्रकार के परिवर्तनशील चर पर निर्भर करती हैं। वे पुनरावृत्ति पर पुनरावृत्ति का पक्ष लेते हैं, उदाहरण के लिए, और लगभग सभी पुनरावृत्त निर्माण - यहां तक कि
while (true)और for (;;)! - पूरी तरह से परिवर्तन से पुनरावृत्ति के लिए कहीं चर पर निर्भर हैं।
- ऑब्जेक्ट-ओरिएंटेड भाषाएं प्रत्येक प्रोग्राम को एक-दूसरे को संदेश भेजने वाली वस्तुओं के एक ग्राफ के रूप में और लगभग सभी मामलों में, कुछ संदेशों को म्यूट करके उन संदेशों का जवाब देते हुए बहुत अधिक कल्पना करती हैं।
उन डिज़ाइन निर्णयों का अंतिम परिणाम यह है कि बिना परिवर्तनशील चर के, जावा के पास किसी भी चीज़ की स्थिति को बदलने का कोई तरीका नहीं है - यहां तक कि "हैलो वर्ल्ड!" स्क्रीन में एक आउटपुट स्ट्रीम शामिल है, जिसमें एक म्यूटेबल बफर में बाइट्स चिपके हुए हैं ।
इसलिए, सभी व्यावहारिक उद्देश्यों के लिए, हम अपने स्वयं के कोड से वैरिएबल को सीमित करने के लिए सीमित हैं । ठीक है, हम थोड़े कर सकते हैं। लगभग। मूल रूप से हमें जो चाहिए वह लगभग सभी पुनरावृत्ति को पुनर्संरचना के साथ बदलना होगा, और पुनरावर्ती कॉल के साथ सभी उत्परिवर्तन बदले हुए मूल्य को वापस करना होगा। इस तरह...
class Ints {
final int value;
final Ints tail;
public Ints(int value, Ints rest) {
this.value = value;
this.tail = rest;
}
public Ints next() { return this.tail; }
public int value() { return this.value; }
}
public Ints take(int count, Ints input) {
if (count == 0 || input == null) return null;
return new Ints(input.value(), take(count - 1, input.next()));
}
public Ints squares_of(Ints input) {
if (input == null) return null;
int i = input.value();
return new Ints(i * i, squares_of(input.next()));
}
मूल रूप से, हम एक लिंक की गई सूची बनाते हैं, जहां प्रत्येक नोड अपने आप में एक सूची है। प्रत्येक सूची में एक "सिर" (वर्तमान मूल्य) और एक "पूंछ" (शेष सबलिस्ट) है। अधिकांश कार्यात्मक भाषाएँ इसके लिए कुछ महत्वपूर्ण हैं, क्योंकि यह कुशल अपरिवर्तनीयता के लिए बहुत ही अनुकूलनीय है। एक "अगला" ऑपरेशन केवल पूंछ लौटाता है, जो आमतौर पर पुनरावर्ती कॉल के ढेर में अगले स्तर तक पहुंच जाता है।
अब, यह इस सामान का एक अत्यंत उपयोगी संस्करण है। लेकिन जावा में इस दृष्टिकोण के साथ एक गंभीर समस्या का प्रदर्शन करना काफी अच्छा है। इस कोड पर विचार करें:
public function doStuff() {
final Ints integers = ...somehow assemble list of 20 million ints...;
final Ints result = take(25, squares_of(integers));
...
}
हालाँकि हमें परिणाम के लिए केवल 25 इंच की आवश्यकता है, लेकिन squares_ofयह नहीं पता है। यह हर संख्या के वर्ग को वापस करने जा रहा है integers। रिकर्सियन 20 मिलियन का स्तर जावा में बहुत बड़ी समस्याओं का कारण बनता है।
देखें, जिन कार्यात्मक भाषाओं में आप आमतौर पर इस तरह से व्यर्थता करते हैं, उनमें "टेल कॉल एलिमिनेशन" नामक एक सुविधा होती है। इसका मतलब क्या है, जब कंपाइलर कोड के अंतिम कार्य को खुद को कॉल करने के लिए देखता है (और फ़ंक्शन के गैर-शून्य होने पर परिणाम लौटाता है), यह एक नया सेट करने के बजाय वर्तमान कॉल के स्टैक फ्रेम का उपयोग करता है और इसके बजाय एक "कूद" करता है। एक "कॉल" (ताकि स्टैक स्पेस का उपयोग स्थिर रहता है)। संक्षेप में, यह पूंछ-पुनरावृत्ति को पुनरावृत्ति में बदलने की ओर लगभग 90% जाता है। यह स्टैक को ओवरफ्लो किए बिना उन बिलियन इन्ट्स से निपट सकता है। (यह अभी भी अंततः मेमोरी से बाहर चलेगा, लेकिन एक बिलियन इनट्स की एक सूची को इकट्ठा करना आपको 32-बिट सिस्टम पर वैसे भी मेमोरीवाइज़ को गड़बड़ाने वाला है।)
ज्यादातर मामलों में जावा ऐसा नहीं करता है। (यह कंपाइलर और रनटाइम पर निर्भर करता है, लेकिन ओरेकल का कार्यान्वयन ऐसा नहीं करता है।) एक पुनरावर्ती फ़ंक्शन के लिए प्रत्येक कॉल स्टैक फ़्रेम के मेमोरी के मूल्य को खाती है। बहुत अधिक उपयोग करें, और आपको एक ढेर अतिप्रवाह मिलता है। स्टैक को ओवरफ्लो करना लेकिन कार्यक्रम की मृत्यु की गारंटी देता है। इसलिए हमें यह सुनिश्चित करना होगा कि ऐसा न करें।
एक अर्ध-कसरत ... आलसी मूल्यांकन। हमारे पास अभी भी स्टैक सीमाएं हैं, लेकिन वे उन कारकों से बंधे हो सकते हैं जिन पर हमारा अधिक नियंत्रण है। हमें 25 लाख रिटर्न की गणना करने की जरूरत नहीं है। :)
तो आइए हम कुछ आलसी-मूल्यांकन बुनियादी ढांचे का निर्माण करें। (इस कोड का परीक्षण कुछ समय पहले किया गया था, लेकिन मैंने तब से इसे थोड़ा संशोधित किया है; इस विचार को पढ़ें, वाक्यविन्यास त्रुटियों को नहीं। ...)
// Represents something that can give us instances of OutType.
// We can basically treat this class like a list.
interface Source<OutType> {
public Source<OutType> next();
public OutType value();
}
// Represents an operation that turns an InType into an OutType.
// Note, these can be the same type. We're just flexible like that.
interface Transform<InType, OutType> {
public OutType appliedTo(InType input);
}
// Represents an action (as opposed to a function) that can run on
// every element of a sequence.
abstract class Action<InType> {
abstract void doWith(final InType input);
public void doWithEach(final Source<InType> input) {
if (input == null) return;
doWith(input.value());
doWithEach(input.next());
}
}
// A list of Integers.
class Ints implements Source<Integer> {
final Integer value;
final Ints tail;
public Ints(Integer value, Ints rest) {
this.value = value;
this.tail = rest;
}
public Ints(Source<Integer> input) {
this.value = input.value();
this.tail = new Ints(input.next());
}
public Source<Integer> next() { return this.tail; }
public Integer value() { return this.value; }
public static Ints fromArray(Integer[] input) {
return fromArray(input, 0, input.length);
}
public static Ints fromArray(Integer[] input, int start, int end) {
if (end == start || input == null) return null;
return new Ints(input[start], fromArray(input, start + 1, end));
}
}
// An example of the spiff we get by splitting the "iterator" interface
// off. These ints are effectively generated on the fly, as opposed to
// us having to build a huge list. This saves huge amounts of memory
// and CPU time, for the rather common case where the whole sequence
// isn't needed.
class Range implements Source<Integer> {
final int start, end;
public Range(int start, int end) {
this.start = start;
this.end = end;
}
public Integer value() { return start; }
public Source<Integer> next() {
if (start >= end) return null;
return new Range(start + 1, end);
}
}
// This takes each InType of a sequence and turns it into an OutType.
// This *takes* a Transform, rather than just *implementing* Transform,
// because the transforms applied are likely to be specified inline.
// If we just let people override `value()`, we wouldn't easily know what type
// to return, and returning our own type would lose the transform method.
static class Mapper<InType, OutType> implements Source<OutType> {
private final Source<InType> input;
private final Transform<InType, OutType> transform;
public Mapper(Transform<InType, OutType> transform, Source<InType> input) {
this.transform = transform;
this.input = input;
}
public Source<OutType> next() {
return new Mapper<InType, OutType>(transform, input.next());
}
public OutType value() {
return transform.appliedTo(input.value());
}
}
// ...
public <T> Source<T> take(int count, Source<T> input) {
if (count <= 0 || input == null) return null;
return new Source<T>() {
public T value() { return input.value(); }
public Source<T> next() { return take(count - 1, input.next()); }
};
}
(ध्यान रखें कि यदि यह वास्तव में जावा में व्यवहार्य था, तो कम से कम कुछ हद तक कोड जैसा कि पहले से ही एपीआई का हिस्सा होगा।)
अब, एक बुनियादी ढांचे के साथ, यह कोड लिखने के लिए तुच्छ है जो कि परिवर्तनशील चर की आवश्यकता नहीं है और कम से कम इनपुट के लिए स्थिर है।
public Source<Integer> squares_of(Source<Integer> input) {
final Transform<Integer, Integer> square = new Transform<Integer, Integer>() {
public Integer appliedTo(final Integer i) { return i * i; }
};
return new Mapper<>(square, input);
}
public void example() {
final Source<Integer> integers = new Range(0, 1000000000);
// and, as for the author's "bet you can't do this"...
final Source<Integer> squares = take(25, squares_of(integers));
// Just to make sure we got it right :P
final Action<Integer> printAction = new Action<Integer>() {
public void doWith(Integer input) { System.out.println(input); }
};
printAction.doWithEach(squares);
}
यह ज्यादातर काम करता है, लेकिन यह अभी भी कुछ हद तक ओवरफ्लो होने का खतरा है। प्रयास करें take2 अरब ints ing और उन पर कुछ कार्रवाई कर रही है। : P यह अंततः एक अपवाद फेंक देगा, कम से कम जब तक 64+ GB RAM मानक नहीं बन जाता। समस्या यह है कि एक प्रोग्राम की मेमोरी की मात्रा जो उसके स्टैक के लिए आरक्षित है, वह इतनी बड़ी नहीं है। यह आम तौर पर 1 और 8 MiB के बीच होता है। (आप बड़ी लिए पूछ सकते हैं, लेकिन यह सब इतना आप कितना के लिए पूछना कोई फर्क नहीं पड़ता - आप कॉल take(1000000000, someInfiniteSequence), आप होगा । एक अपवाद मिल) सौभाग्य से, आलसी मूल्यांकन के साथ, कमजोर है एक क्षेत्र में हम बेहतर कर सकते हैं नियंत्रण । हमें बस इस बात से सावधान रहना है कि हम कितना take()।
यह अभी भी बहुत सारी समस्याओं को बढ़ाएगा, क्योंकि हमारे ढेर का उपयोग रैखिक रूप से बढ़ जाता है। प्रत्येक कॉल एक तत्व को संभालती है और शेष को किसी अन्य कॉल में पास करती है। अब जब मैं इसके बारे में सोचता हूं, हालांकि, एक चाल है जिसे हम खींच सकते हैं जो हमें काफी अधिक हेडरूम दे सकता है: कॉल की श्रृंखला को कॉल के पेड़ में बदल दें। कुछ इस तरह से विचार करें:
public <T> void doSomethingWith(T input) { /* magic happens here */ }
public <T> Source<T> workWith(Source<T> input, int count) {
if (count < 0 || input == null) return null;
if (count == 0) return input;
if (count == 1) {
doSomethingWith(input.value());
return input.next();
}
return (workWith(workWith(input, count/2), count - count/2);
}
workWithमूल रूप से दो हिस्सों में काम टूट जाता है, और प्रत्येक आधे को खुद को एक और कॉल करने के लिए असाइन करता है। चूंकि प्रत्येक कॉल कार्य सूची के आकार को एक के बजाय आधे से कम कर देता है, इसलिए इसे रैखिक रूप से बजाय लघुगणक पैमाने पर होना चाहिए।
समस्या यह है, यह फ़ंक्शन एक इनपुट चाहता है - और एक लिंक की गई सूची के साथ, लंबाई प्राप्त करने के लिए पूरी सूची का पता लगाने की आवश्यकता होती है। यह आसानी से हल है, यद्यपि; बस परवाह नहीं है कि कितनी प्रविष्टियाँ हैं। :) उपरोक्त कोड Integer.MAX_VALUEगिनती की तरह कुछ के साथ काम करेगा , क्योंकि एक नल वैसे भी प्रसंस्करण बंद कर देता है। गिनती ज्यादातर वहाँ है इसलिए हमारे पास एक ठोस आधार मामला है। यदि आप Integer.MAX_VALUEकिसी सूची में प्रविष्टियों से अधिक होने का अनुमान लगाते हैं , तो आप workWithवापसी मूल्य की जांच कर सकते हैं - यह अंत में शून्य होना चाहिए। अन्यथा, पुनरावृत्ति।
ध्यान रखें, यह आपको बताए गए तत्वों को छूता है। यह आलसी नहीं है; यह अपनी बात तुरंत करता है। आप इसे केवल क्रियाओं के लिए करना चाहते हैं - अर्थात, ऐसी वस्तुएं जिनका एकमात्र उद्देश्य किसी सूची में प्रत्येक तत्व के लिए स्वयं को लागू करना है। जैसा कि मैं इसे अभी सोच रहा हूँ, यह मुझे लगता है कि अगर रेखीय रखा जाता है तो अनुक्रम बहुत कम जटिल होगा; कोई समस्या नहीं होनी चाहिए, क्योंकि अनुक्रम खुद को वैसे भी नहीं बुलाते हैं - वे केवल उन वस्तुओं को बनाते हैं जो उन्हें फिर से कॉल करते हैं।