ਪਿਛਲੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ ਮੈਂ ਹਿੱਸਾ ਲਿਆ ਸੀ ਗੂਗਲ ਸਮਰ ਕੋਡ - ਗੂਗਲ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਇੱਕ ਪ੍ਰੋਗਰਾਮ। ਹਰ ਸਾਲ, ਆਯੋਜਕ ਕਈ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਚੋਣ ਕਰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਅਜਿਹੀਆਂ ਮਸ਼ਹੂਰ ਸੰਸਥਾਵਾਂ ਸ਼ਾਮਲ ਹਨ Boost.org и ਲੀਨਕਸ ਫਾਉਂਡੇਸ਼ਨ. ਗੂਗਲ ਦੁਨੀਆ ਭਰ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਇਹਨਾਂ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਸੱਦਾ ਦਿੰਦਾ ਹੈ। 

Google ਸਮਰ ਆਫ਼ ਕੋਡ 2019 ਵਿੱਚ ਇੱਕ ਭਾਗੀਦਾਰ ਵਜੋਂ, ਮੈਂ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਕੀਤਾ ਐਲਗਾ ਸੰਗਠਨ ਦੇ ਨਾਲ Haskell.org, ਜੋ ਹਾਸਕੇਲ ਭਾਸ਼ਾ ਦਾ ਵਿਕਾਸ ਕਰ ਰਹੀ ਹੈ - ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਕਾਰਜਸ਼ੀਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ। ਐਲਗਾ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਦਰਸਾਉਂਦੀ ਹੈ ਸੁਰੱਖਿਅਤ ਟਾਈਪ ਕਰੋ ਹਾਸਕੇਲ ਵਿੱਚ ਗ੍ਰਾਫ ਲਈ ਨੁਮਾਇੰਦਗੀ। ਇਹ ਵਰਤਿਆ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਵਿੱਚ ਸਿਮਰਤੀ - ਇੱਕ ਗਿਥਬ ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਕੋਡ ਦੇ ਅਧਾਰ 'ਤੇ ਸਿਮੈਂਟਿਕ ਟ੍ਰੀ, ਕਾਲ ਅਤੇ ਨਿਰਭਰਤਾ ਗ੍ਰਾਫ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਦੀ ਹੈ। ਮੇਰਾ ਪ੍ਰੋਜੈਕਟ ਉਸ ਪ੍ਰਤੀਨਿਧਤਾ ਲਈ ਦੋ-ਪੱਖੀ ਗ੍ਰਾਫਾਂ ਅਤੇ ਐਲਗੋਰਿਦਮ ਲਈ ਇੱਕ ਕਿਸਮ-ਸੁਰੱਖਿਅਤ ਪ੍ਰਤੀਨਿਧਤਾ ਜੋੜਨਾ ਸੀ। 

ਇਸ ਪੋਸਟ ਵਿੱਚ ਮੈਂ ਹਾਸਕੇਲ ਵਿੱਚ ਦੋ-ਪੱਖੀਤਾ ਲਈ ਇੱਕ ਗ੍ਰਾਫ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਐਲਗੋਰਿਦਮ ਦੇ ਆਪਣੇ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ। ਭਾਵੇਂ ਕਿ ਐਲਗੋਰਿਦਮ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸ ਨੂੰ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਸ਼ੈਲੀ ਵਿੱਚ ਸੁੰਦਰਤਾ ਨਾਲ ਲਾਗੂ ਕਰਨ ਲਈ ਮੈਨੂੰ ਕਈ ਦੁਹਰਾਓ ਅਤੇ ਕਾਫ਼ੀ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਮੋਨਾਡ ਟ੍ਰਾਂਸਫਾਰਮਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਲਾਗੂ ਕਰਨ 'ਤੇ ਸੈਟਲ ਹੋ ਗਿਆ. 

ਮੇਰੇ ਬਾਰੇ

ਮੇਰਾ ਨਾਮ ਵੈਸੀਲੀ ਅਲਫੇਰੋਵ ਹੈ, ਮੈਂ ਸੇਂਟ ਪੀਟਰਸਬਰਗ HSE ਵਿੱਚ ਚੌਥੇ ਸਾਲ ਦਾ ਵਿਦਿਆਰਥੀ ਹਾਂ। ਪਹਿਲਾਂ ਬਲੌਗ ਵਿੱਚ ਮੈਂ ਲਿਖਿਆ ਸੀ ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਐਲਗੋਰਿਦਮ ਬਾਰੇ ਮੇਰੇ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ и ਜ਼ੂਰੀਹੈਕ ਦੀ ਯਾਤਰਾ ਬਾਰੇ. ਇਸ ਸਮੇਂ ਮੈਂ ਇੰਟਰਨਸ਼ਿਪ 'ਤੇ ਹਾਂ ਬਰਗਨ ਯੂਨੀਵਰਸਿਟੀ ਨਾਰਵੇ ਵਿੱਚ, ਜਿੱਥੇ ਮੈਂ ਸਮੱਸਿਆ ਲਈ ਪਹੁੰਚ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਸੂਚੀ ਰੰਗ. ਮੇਰੀਆਂ ਦਿਲਚਸਪੀਆਂ ਵਿੱਚ ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਐਲਗੋਰਿਦਮ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸ਼ਾਮਲ ਹਨ।

ਐਲਗੋਰਿਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਬਾਰੇ

ਮੁਖਬੰਧ

ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਭਾਗ ਲੈਣ ਵਾਲੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਬਲੌਗ ਕਰਨ ਲਈ ਜ਼ੋਰਦਾਰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਨੇ ਮੈਨੂੰ ਬਲੌਗ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹਾਸਕੇਲ ਦੀ ਗਰਮੀ. ਇਹ ਲੇਖ ਇੱਕ ਅਨੁਵਾਦ ਹੈ ਲੇਖ, ਮੇਰੇ ਦੁਆਰਾ ਜੁਲਾਈ ਵਿੱਚ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਇੱਕ ਛੋਟੇ ਪ੍ਰਸਤਾਵਨਾ ਦੇ ਨਾਲ। 

ਸਵਾਲ ਵਿੱਚ ਕੋਡ ਦੇ ਨਾਲ ਪੁੱਲ ਬੇਨਤੀ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ ਇੱਥੇ.

ਤੁਸੀਂ ਮੇਰੇ ਕੰਮ ਦੇ ਨਤੀਜਿਆਂ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ (ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ) ਇੱਥੇ.

ਇਸ ਪੋਸਟ ਦਾ ਉਦੇਸ਼ ਪਾਠਕ ਨੂੰ ਫੰਕਸ਼ਨਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਿੱਚ ਬੁਨਿਆਦੀ ਸੰਕਲਪਾਂ ਨਾਲ ਜਾਣੂ ਕਰਵਾਉਣਾ ਹੈ, ਹਾਲਾਂਕਿ ਮੈਂ ਸਮਾਂ ਆਉਣ 'ਤੇ ਵਰਤੇ ਗਏ ਸਾਰੇ ਸ਼ਬਦਾਂ ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ।

ਦੋ-ਪੱਖੀਤਾ ਲਈ ਗ੍ਰਾਫਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ 

ਦੋ-ਪੱਖੀਤਾ ਲਈ ਇੱਕ ਗ੍ਰਾਫ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਐਲਗੋਰਿਦਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਰਲ ਗ੍ਰਾਫ ਐਲਗੋਰਿਦਮ ਦੇ ਰੂਪ ਵਿੱਚ ਐਲਗੋਰਿਦਮ ਦੇ ਇੱਕ ਕੋਰਸ ਵਿੱਚ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਸਦਾ ਵਿਚਾਰ ਸਿੱਧਾ ਹੈ: ਪਹਿਲਾਂ ਅਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਨਾਲ ਖੱਬੇ ਜਾਂ ਸੱਜੇ ਹਿੱਸੇ ਵਿੱਚ ਸਿਰਲੇਖ ਪਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਜਦੋਂ ਇੱਕ ਵਿਰੋਧੀ ਕਿਨਾਰਾ ਮਿਲਦਾ ਹੈ, ਅਸੀਂ ਦਾਅਵਾ ਕਰਦੇ ਹਾਂ ਕਿ ਗ੍ਰਾਫ ਦੋ-ਪੱਖੀ ਨਹੀਂ ਹੈ।

ਥੋੜਾ ਹੋਰ ਵਿਸਤਾਰ: ਪਹਿਲਾਂ ਅਸੀਂ ਖੱਬੇ ਸ਼ੇਅਰ ਵਿੱਚ ਕੁਝ ਸਿਰਲੇਖ ਪਾਉਂਦੇ ਹਾਂ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਸ ਸਿਰਲੇਖ ਦੇ ਸਾਰੇ ਗੁਆਂਢੀ ਸਹੀ ਲੋਬ ਵਿੱਚ ਪਏ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਸਿਰਲੇਖ ਦੇ ਗੁਆਂਢੀਆਂ ਦੇ ਸਾਰੇ ਗੁਆਂਢੀਆਂ ਨੂੰ ਖੱਬੇ ਲੋਬ ਵਿੱਚ ਲੇਟਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ. ਅਸੀਂ ਸਿਰਲੇਖਾਂ ਨੂੰ ਸ਼ੇਅਰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਕਿ ਅਸੀਂ ਸ਼ੁਰੂ ਕੀਤੇ ਸਿਰਲੇਖ ਦੇ ਕਨੈਕਟ ਕੀਤੇ ਭਾਗ ਵਿੱਚ ਅਜੇ ਵੀ ਸਿਰਲੇਖ ਮੌਜੂਦ ਹਨ ਜਿਸ ਨੂੰ ਅਸੀਂ ਗੁਆਂਢੀਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਫਿਰ ਇਸ ਕਿਰਿਆ ਨੂੰ ਸਾਰੇ ਜੁੜੇ ਹੋਏ ਹਿੱਸਿਆਂ ਲਈ ਦੁਹਰਾਉਂਦੇ ਹਾਂ।

ਜੇਕਰ ਇੱਕੋ ਭਾਗ ਵਿੱਚ ਡਿੱਗਣ ਵਾਲੇ ਸਿਰਿਆਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਕਿਨਾਰਾ ਹੈ, ਤਾਂ ਗ੍ਰਾਫ ਵਿੱਚ ਇੱਕ ਅਜੀਬ ਚੱਕਰ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਦੋ-ਪੱਖੀ ਗ੍ਰਾਫ ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ (ਅਤੇ ਸਪੱਸ਼ਟ ਤੌਰ' ਤੇ) ਅਸੰਭਵ ਹੈ। ਨਹੀਂ ਤਾਂ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਹੀ ਭਾਗ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗ੍ਰਾਫ ਦੋ-ਪੱਖੀ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਇਸ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਚੌੜਾਈ ਪਹਿਲੀ ਖੋਜ ਜ ਡੂੰਘਾਈ ਪਹਿਲੀ ਖੋਜ. ਲਾਜ਼ਮੀ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ, ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਦੀ ਵਰਤੋਂ ਆਮ ਤੌਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਥੋੜੀ ਸਰਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਵਾਧੂ ਡਾਟਾ ਢਾਂਚੇ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਮੈਂ ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਨੂੰ ਵੀ ਚੁਣਿਆ ਕਿਉਂਕਿ ਇਹ ਵਧੇਰੇ ਰਵਾਇਤੀ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਸਕੀਮ 'ਤੇ ਆਏ ਹਾਂ. ਅਸੀਂ ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਗ੍ਰਾਫ ਦੇ ਸਿਰਿਆਂ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸ਼ੇਅਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਕਿਨਾਰੇ ਦੇ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਾਂ ਸ਼ੇਅਰ ਦੀ ਸੰਖਿਆ ਨੂੰ ਬਦਲਦੇ ਹਾਂ। ਜੇਕਰ ਅਸੀਂ ਕਿਸੇ ਸਿਰਲੇਖ ਨੂੰ ਇੱਕ ਸ਼ੇਅਰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸ਼ੇਅਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਗ੍ਰਾਫ ਦੋ-ਪੱਖੀ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਸਾਰੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਇੱਕ ਸ਼ੇਅਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਸਾਰੇ ਕਿਨਾਰਿਆਂ ਨੂੰ ਦੇਖਿਆ ਹੈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਧੀਆ ਭਾਗ ਹੈ।

ਗਣਨਾ ਦੀ ਸ਼ੁੱਧਤਾ

ਹਾਸਕੇਲ ਵਿੱਚ ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਹਨ ਸਾਫ਼ ਹਾਲਾਂਕਿ, ਜੇਕਰ ਇਹ ਸੱਚਮੁੱਚ ਅਜਿਹਾ ਹੁੰਦਾ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਸਕ੍ਰੀਨ ਤੇ ਕੁਝ ਵੀ ਪ੍ਰਿੰਟ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ। ਤੇ ਸਾਰੇ, ਸਾਫ਼ ਗਣਨਾ ਇੰਨੇ ਆਲਸੀ ਹਨ ਕਿ ਇੱਕ ਵੀ ਨਹੀਂ ਹੈ ਸਾਫ਼ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਗਣਨਾ ਕਰਨ ਦੇ ਕਾਰਨ. ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ "ਅਸ਼ੁੱਧ" ਮੋਨਾਡ ਆਈ.ਓ.

ਮੋਨਾਡਸ ਗਣਨਾਵਾਂ ਨੂੰ ਦਰਸਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਪ੍ਰਭਾਵ ਹਾਸਕੇਲ ਵਿੱਚ. ਇਹ ਦੱਸਣਾ ਕਿ ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਇਸ ਪੋਸਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ। ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਇੱਕ ਚੰਗਾ ਅਤੇ ਸਪਸ਼ਟ ਵਰਣਨ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇੱਥੇ.

ਇੱਥੇ ਮੈਂ ਇਹ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਜਦੋਂ ਕਿ ਕੁਝ ਮੋਨਾਡ, ਜਿਵੇਂ ਕਿ IO, ਕੰਪਾਈਲਰ ਮੈਜਿਕ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਲਗਭਗ ਸਾਰੇ ਬਾਕੀ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਸ਼ੁੱਧ ਹੁੰਦੀਆਂ ਹਨ।

ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਭਾਵ ਹਨ ਅਤੇ ਹਰੇਕ ਦਾ ਆਪਣਾ ਮੋਨਾਡ ਹੈ। ਇਹ ਇੱਕ ਬਹੁਤ ਮਜ਼ਬੂਤ ​​ਅਤੇ ਸੁੰਦਰ ਸਿਧਾਂਤ ਹੈ: ਸਾਰੇ ਮੋਨਾਡ ਇੱਕੋ ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਤਿੰਨ ਮੋਨਾਡਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ:

• ਜਾਂ ਤਾਂ ea ਇੱਕ ਗਣਨਾ ਹੈ ਜੋ ਕਿਸਮ a ਦਾ ਮੁੱਲ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜਾਂ ਕਿਸਮ e ਦੇ ਅਪਵਾਦ ਨੂੰ ਸੁੱਟਦੀ ਹੈ। ਇਸ ਮੋਨਾਡ ਦਾ ਵਿਵਹਾਰ ਲਾਜ਼ਮੀ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਅਪਵਾਦ ਹੈਂਡਲਿੰਗ ਵਰਗਾ ਹੈ: ਗਲਤੀਆਂ ਫੜੀਆਂ ਜਾਂ ਦਿੱਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਮੋਨਾਡ ਨੂੰ ਹਾਸਕੇਲ ਵਿੱਚ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਰਕ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਦੋਂ ਕਿ ਲਾਜ਼ਮੀ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।
• ਸਟੇਟ sa ਇੱਕ ਗਣਨਾ ਹੈ ਜੋ ਕਿਸਮ a ਦਾ ਮੁੱਲ ਵਾਪਸ ਕਰਦੀ ਹੈ ਅਤੇ ਕਿਸਮ s ਦੀ ਪਰਿਵਰਤਨਯੋਗ ਸਥਿਤੀ ਤੱਕ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ।
• ਸ਼ਾਇਦ ਏ. ਹੋ ਸਕਦਾ ਹੈ ਮੋਨਾਡ ਇੱਕ ਗਣਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਿਸੇ ਵੀ ਸਮੇਂ ਕੁਝ ਨਹੀਂ ਵਾਪਸ ਕਰਕੇ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਸੀਂ ਸ਼ਾਇਦ ਕਿਸਮ ਲਈ ਮੋਨਾਡਪਲੱਸ ਕਲਾਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਜੋ ਕਿ ਉਲਟ ਪ੍ਰਭਾਵ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: ਇਹ ਇੱਕ ਗਣਨਾ ਹੈ ਜੋ ਕਿਸੇ ਖਾਸ ਮੁੱਲ ਨੂੰ ਵਾਪਸ ਕਰਕੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਐਲਗੋਰਿਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਸਾਡੇ ਕੋਲ ਦੋ ਡਾਟਾ ਕਿਸਮਾਂ ਹਨ, ਗ੍ਰਾਫ a ਅਤੇ Bigraph ab, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਪਹਿਲਾ ਕਿਸਮ a ਦੇ ਮੁੱਲਾਂ ਨਾਲ ਲੇਬਲ ਕੀਤੇ ਸਿਰਲੇਖਾਂ ਵਾਲੇ ਗ੍ਰਾਫਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਕਿਸਮ a ਅਤੇ ਸੱਜੇ ਕਿਸਮ ਦੇ ਮੁੱਲਾਂ ਨਾਲ ਲੇਬਲ ਕੀਤੇ ਖੱਬੇ-ਪਾਸੇ ਦੇ ਕੋਣਾਂ ਵਾਲੇ ਦੋ-ਪੱਖੀ ਗ੍ਰਾਫਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। -ਕਿਸਮ b ਦੇ ਮੁੱਲਾਂ ਨਾਲ ਲੇਬਲ ਕੀਤੇ ਪਾਸੇ ਦੇ ਸਿਰਲੇਖ।

ਇਹ ਐਲਗਾ ਲਾਇਬ੍ਰੇਰੀ ਦੀਆਂ ਕਿਸਮਾਂ ਨਹੀਂ ਹਨ। ਐਲਗਾ ਵਿੱਚ ਨਿਰਦੇਸਿਤ ਦੋ-ਪੱਖੀ ਗ੍ਰਾਫ਼ਾਂ ਲਈ ਕੋਈ ਪ੍ਰਤੀਨਿਧਤਾ ਨਹੀਂ ਹੈ। ਮੈਂ ਸਪਸ਼ਟਤਾ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਬਣਾਈਆਂ।

ਸਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਦਸਤਖਤਾਂ ਦੇ ਨਾਲ ਸਹਾਇਕ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵੀ ਲੋੜ ਪਵੇਗੀ:

-- Список соседей данной вершины.
neighbours :: Ord a => a -> Graph a -> [a]

-- Построить двудольный граф по графу и функции, для каждой вершины
-- выдающей её долю и пометку в новой доле, игнорируя конфликтные рёбра.
toBipartiteWith :: (Ord a, Ord b, Ord c) => (a -> Either b c)
                                         -> Graph a
                                         -> Bigraph b c

-- Список вершин в графе
vertexList :: Ord a => Graph a -> [a]
Сигнатура функции, которую мы будем писать, выглядит так:

type OddCycle a = [a]
detectParts :: Ord a => Graph a -> Either (OddCycle a) (Bigraph a a)

ਇਹ ਵੇਖਣਾ ਆਸਾਨ ਹੈ ਕਿ ਜੇਕਰ ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਦੌਰਾਨ ਸਾਨੂੰ ਇੱਕ ਵਿਰੋਧੀ ਕਿਨਾਰਾ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਅਜੀਬ ਚੱਕਰ ਆਵਰਤੀ ਸਟੈਕ ਦੇ ਸਿਖਰ 'ਤੇ ਹੁੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਰੀਕਰਸ਼ਨ ਸਟੈਕ ਤੋਂ ਲੈ ਕੇ ਆਖਰੀ ਸਿਰੇ ਦੀ ਪਹਿਲੀ ਮੌਜੂਦਗੀ ਤੱਕ ਸਭ ਕੁਝ ਕੱਟਣ ਦੀ ਲੋੜ ਹੈ।

ਅਸੀਂ ਹਰੇਕ ਸਿਰਲੇਖ ਲਈ ਸ਼ੇਅਰ ਨੰਬਰਾਂ ਦੀ ਇੱਕ ਸਹਿਯੋਗੀ ਐਰੇ ਨੂੰ ਕਾਇਮ ਰੱਖ ਕੇ ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਾਂ। ਆਵਰਤੀ ਸਟੈਕ ਨੂੰ ਸਾਡੇ ਦੁਆਰਾ ਚੁਣੇ ਗਏ ਮੋਨਾਡ ਦੇ ਫੰਕਟਰ ਕਲਾਸ ਦੇ ਲਾਗੂ ਕਰਨ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਹੀ ਬਣਾਈ ਰੱਖਿਆ ਜਾਵੇਗਾ: ਸਾਨੂੰ ਸਿਰਫ ਰਿਕਰਸਿਵ ਫੰਕਸ਼ਨ ਤੋਂ ਵਾਪਸ ਆਏ ਨਤੀਜੇ ਵਿੱਚ ਮਾਰਗ ਤੋਂ ਸਾਰੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਪਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

ਮੇਰਾ ਪਹਿਲਾ ਵਿਚਾਰ Either monad ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੀ, ਜੋ ਬਿਲਕੁਲ ਉਹਨਾਂ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਜਾਪਦਾ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ। ਪਹਿਲਾ ਲਾਗੂਕਰਨ ਜੋ ਮੈਂ ਲਿਖਿਆ ਸੀ ਉਹ ਇਸ ਵਿਕਲਪ ਦੇ ਬਹੁਤ ਨੇੜੇ ਸੀ। ਵਾਸਤਵ ਵਿੱਚ, ਮੇਰੇ ਕੋਲ ਇੱਕ ਬਿੰਦੂ 'ਤੇ ਪੰਜ ਵੱਖ-ਵੱਖ ਲਾਗੂਕਰਨ ਸਨ ਅਤੇ ਆਖਰਕਾਰ ਇੱਕ ਹੋਰ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ.

ਪਹਿਲਾਂ, ਸਾਨੂੰ ਸ਼ੇਅਰ ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਇੱਕ ਸਹਿਯੋਗੀ ਲੜੀ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ - ਇਹ ਰਾਜ ਬਾਰੇ ਕੁਝ ਹੈ। ਦੂਜਾ, ਜਦੋਂ ਕਿਸੇ ਟਕਰਾਅ ਦਾ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਤਾਂ ਸਾਨੂੰ ਰੋਕਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਜਾਂ ਤਾਂ ਮੋਨਾਡ ਲਈ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਲਈ ਮੋਨਾਡਪਲੱਸ। ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਜਾਂ ਤਾਂ ਕੋਈ ਮੁੱਲ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਗਣਨਾ ਨੂੰ ਰੋਕਿਆ ਨਹੀਂ ਗਿਆ ਹੈ, ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਇਸ ਬਾਰੇ ਸਿਰਫ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕਰੇ। ਕਿਉਂਕਿ ਸਾਨੂੰ ਸਫਲਤਾ ਲਈ ਵੱਖਰੇ ਮੁੱਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ (ਇਹ ਪਹਿਲਾਂ ਹੀ ਰਾਜ ਵਿੱਚ ਸਟੋਰ ਹੈ), ਅਸੀਂ ਸ਼ਾਇਦ ਚੁਣਦੇ ਹਾਂ। ਅਤੇ ਇਸ ਸਮੇਂ ਜਦੋਂ ਸਾਨੂੰ ਦੋ ਮੋਨਾਡਾਂ ਦੇ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਉਹ ਬਾਹਰ ਆਉਂਦੇ ਹਨ ਮੋਨਾਡ ਟ੍ਰਾਂਸਫਾਰਮਰ, ਜੋ ਇਹਨਾਂ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ।

ਮੈਂ ਅਜਿਹੀ ਗੁੰਝਲਦਾਰ ਕਿਸਮ ਦੀ ਚੋਣ ਕਿਉਂ ਕੀਤੀ? ਦੋ ਕਾਰਨ. ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਲਾਗੂ ਕਰਨਾ ਲਾਜ਼ਮੀ ਦੇ ਸਮਾਨ ਹੁੰਦਾ ਹੈ. ਦੂਜਾ, ਅਜੀਬ ਲੂਪ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਦੁਹਰਾਓ ਤੋਂ ਵਾਪਸ ਪਰਤਣ ਵੇਲੇ ਸਾਨੂੰ ਵਿਰੋਧ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸੀ ਮੁੱਲ ਨੂੰ ਹੇਰਾਫੇਰੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਜੋ ਸ਼ਾਇਦ ਮੋਨਾਡ ਵਿੱਚ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ ਸਾਨੂੰ ਇਹ ਅਮਲ ਮਿਲਦਾ ਹੈ।

{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE ScopedTypeVariables #-}

data Part = LeftPart | RightPart

otherPart :: Part -> Part
otherPart LeftPart  = RightPart
otherPart RightPart = LeftPart

type PartMap a = Map.Map a Part
type OddCycle a = [a]

toEither :: Ord a => PartMap a -> a -> Either a a
toEither m v = case fromJust (v `Map.lookup` m) of
                    LeftPart  -> Left  v
                    RightPart -> Right v

type PartMonad a = MaybeT (State (PartMap a)) [a]

detectParts :: forall a. Ord a => Graph a -> Either (OddCycle a) (Bigraph a a)
detectParts g = case runState (runMaybeT dfs) Map.empty of
                     (Just c, _)  -> Left  $ oddCycle c
                     (Nothing, m) -> Right $ toBipartiteWith (toEither m) g
    where
        inVertex :: Part -> a -> PartMonad a
        inVertex p v = ((:) v) <$> do modify $ Map.insert v p
                                      let q = otherPart p
                                      msum [ onEdge q u | u <- neigbours v g ]

        {-# INLINE onEdge #-}
        onEdge :: Part -> a -> PartMonad a
        onEdge p v = do m <- get
                        case v `Map.lookup` m of
                             Nothing -> inVertex p v
                             Just q  -> do guard (q /= p)
                                           return [v]

        processVertex :: a -> PartMonad a
        processVertex v = do m <- get
                             guard (v `Map.notMember` m)
                             inVertex LeftPart v

        dfs :: PartMonad a
        dfs = msum [ processVertex v | v <- vertexList g ]

        oddCycle :: [a] -> [a]
        oddCycle c = tail (dropWhile ((/=) last c) c)

ਜਿੱਥੇ ਬਲਾਕ ਐਲਗੋਰਿਦਮ ਦਾ ਕੋਰ ਹੈ। ਮੈਂ ਇਹ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਕਿ ਇਸ ਦੇ ਅੰਦਰ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।

• inVertex ਡੂੰਘਾਈ-ਪਹਿਲੀ ਖੋਜ ਦਾ ਹਿੱਸਾ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਵਰਟੇਕਸ 'ਤੇ ਜਾਂਦੇ ਹਾਂ। ਇੱਥੇ ਅਸੀਂ ਸਿਰਲੇਖ ਨੂੰ ਇੱਕ ਸ਼ੇਅਰ ਨੰਬਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਾਰੇ ਗੁਆਂਢੀਆਂ 'ਤੇ onEdge ਚਲਾਉਂਦੇ ਹਾਂ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਕਾਲ ਸਟੈਕ ਨੂੰ ਰੀਸਟੋਰ ਕਰਦੇ ਹਾਂ: ਜੇਕਰ msum ਇੱਕ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ vertex v ਨੂੰ ਉੱਥੇ ਧੱਕਦੇ ਹਾਂ।
• onEdge ਉਹ ਹਿੱਸਾ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਕਿਨਾਰੇ 'ਤੇ ਜਾਂਦੇ ਹਾਂ। ਇਸ ਨੂੰ ਹਰੇਕ ਕਿਨਾਰੇ ਲਈ ਦੋ ਵਾਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ. ਇੱਥੇ ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਦੂਜੇ ਪਾਸੇ ਦੇ ਸਿਰੇ ਦਾ ਦੌਰਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਜੇਕਰ ਨਹੀਂ ਤਾਂ ਇਸ 'ਤੇ ਜਾਓ। ਜੇਕਰ ਵਿਜ਼ਿਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕਿਨਾਰਾ ਵਿਰੋਧੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਇਹ ਹੈ, ਤਾਂ ਅਸੀਂ ਮੁੱਲ ਵਾਪਸ ਕਰਦੇ ਹਾਂ - ਰੀਕਰਸ਼ਨ ਸਟੈਕ ਦਾ ਬਿਲਕੁਲ ਸਿਖਰ, ਜਿੱਥੇ ਵਾਪਸ ਆਉਣ 'ਤੇ ਬਾਕੀ ਸਾਰੇ ਸਿਰਲੇਖ ਰੱਖੇ ਜਾਣਗੇ।
• processVertex ਹਰੇਕ ਸਿਰਲੇਖ ਲਈ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਵਿਜ਼ਿਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜੇਕਰ ਨਹੀਂ ਤਾਂ ਇਸ 'ਤੇ ਇਨਵਰਟੈਕਸ ਚਲਾਉਂਦਾ ਹੈ।
• dfs ਸਾਰੇ ਸਿਰਿਆਂ 'ਤੇ processVertex ਚਲਾਉਂਦਾ ਹੈ।

ਇਹ ਸਭ ਹੈ.

INLINE ਸ਼ਬਦ ਦਾ ਇਤਿਹਾਸ

INLINE ਸ਼ਬਦ ਐਲਗੋਰਿਦਮ ਦੇ ਪਹਿਲੇ ਅਮਲ ਵਿੱਚ ਨਹੀਂ ਸੀ; ਇਹ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ। ਜਦੋਂ ਮੈਂ ਇੱਕ ਬਿਹਤਰ ਲਾਗੂਕਰਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਮੈਂ ਪਾਇਆ ਕਿ ਗੈਰ-ਇਨਲਾਈਨ ਸੰਸਕਰਣ ਕੁਝ ਗ੍ਰਾਫਾਂ 'ਤੇ ਧਿਆਨ ਨਾਲ ਹੌਲੀ ਸੀ। ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਅਰਥ ਪੱਖੋਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਸਨੇ ਮੈਨੂੰ ਬਹੁਤ ਹੈਰਾਨ ਕੀਤਾ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਅਜਨਬੀ, GHC ਦੇ ਇੱਕ ਵੱਖਰੇ ਸੰਸਕਰਣ ਵਾਲੀ ਇੱਕ ਹੋਰ ਮਸ਼ੀਨ 'ਤੇ ਕੋਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਅੰਤਰ ਨਹੀਂ ਸੀ।

GHC ਕੋਰ ਆਉਟਪੁੱਟ ਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਇੱਕ ਹਫ਼ਤਾ ਬਿਤਾਉਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਸਪਸ਼ਟ ਇਨਲਾਈਨ ਦੀ ਇੱਕ ਲਾਈਨ ਨਾਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਿਆ। GHC 8.4.4 ਅਤੇ GHC 8.6.5 ਦੇ ਵਿਚਕਾਰ ਕਿਸੇ ਸਮੇਂ ਆਪਟੀਮਾਈਜ਼ਰ ਨੇ ਇਹ ਆਪਣੇ ਆਪ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ।

ਮੈਨੂੰ ਹਾਸਕੇਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਅਜਿਹੀ ਗੰਦਗੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਦੀ ਉਮੀਦ ਨਹੀਂ ਸੀ. ਹਾਲਾਂਕਿ, ਅੱਜ ਵੀ, ਆਪਟੀਮਾਈਜ਼ਰ ਕਈ ਵਾਰ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੰਕੇਤ ਦੇਣਾ ਸਾਡਾ ਕੰਮ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਫੰਕਸ਼ਨ ਇਨਲਾਈਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲਾਜ਼ਮੀ ਸੰਸਕਰਣ ਵਿੱਚ ਇਨਲਾਈਨ ਹੈ, ਅਤੇ ਇਹ ਕੰਪਾਈਲਰ ਨੂੰ ਇੱਕ ਸੰਕੇਤ ਦੇਣ ਦਾ ਇੱਕ ਕਾਰਨ ਹੈ।

ਅੱਗੇ ਕੀ ਹੋਇਆ?

ਫਿਰ ਮੈਂ ਹੋਪਕ੍ਰਾਫਟ-ਕਾਰਪ ਐਲਗੋਰਿਦਮ ਨੂੰ ਹੋਰ ਮੋਨਾਡਾਂ ਨਾਲ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ ਇਹ ਪ੍ਰੋਗਰਾਮ ਦਾ ਅੰਤ ਸੀ।

ਗੂਗਲ ਸਮਰ ਆਫ ਕੋਡ ਲਈ ਧੰਨਵਾਦ, ਮੈਂ ਫੰਕਸ਼ਨਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਵਿਹਾਰਕ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਜਿਸ ਨੇ ਨਾ ਸਿਰਫ ਅਗਲੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ ਜੇਨ ਸਟ੍ਰੀਟ ਵਿੱਚ ਇੱਕ ਇੰਟਰਨਸ਼ਿਪ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਮਦਦ ਕੀਤੀ (ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਸਥਾਨ ਹੈਬਰ ਦੇ ਜਾਣਕਾਰ ਦਰਸ਼ਕਾਂ ਵਿੱਚ ਵੀ ਕਿੰਨਾ ਮਸ਼ਹੂਰ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਹੈ। ਉਹਨਾਂ ਕੁਝ ਵਿੱਚੋਂ ਜਿੱਥੇ ਤੁਸੀਂ ਫੰਕਸ਼ਨਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ ਗਰਮੀਆਂ ਕਰ ਸਕਦੇ ਹੋ), ਪਰ ਇਸ ਨੇ ਮੈਨੂੰ ਅਭਿਆਸ ਵਿੱਚ ਇਸ ਪੈਰਾਡਾਈਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਸ਼ਾਨਦਾਰ ਦੁਨੀਆ ਨਾਲ ਜਾਣੂ ਕਰਵਾਇਆ, ਜੋ ਕਿ ਰਵਾਇਤੀ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਮੇਰੇ ਤਜ਼ਰਬੇ ਤੋਂ ਕਾਫ਼ੀ ਵੱਖਰਾ ਹੈ।

ਸਰੋਤ: www.habr.com