Talk:Strict programming language: Difference between revisions

Revision as of 06:55, 18 November 2018

Latest revision as of 08:57, 14 January 2025

(3 intermediate revisions by 3 users not shown)

Line 1:

{{WikiProject Computing}}banner shell|class=Start|

{{WikiProject Computing|importance=Low}}

{{WikiProject Computer science|importance=Mid}}

{{WikiProject Software|importance=Low}}

}}

{{Wikipedia Unreferenced articles improved|date=21 November 2014}}

== Disadvantages ==

One of the disadvantages listed is "language must be pure". Ilisted is dcts, semannon-strict ticdisadvantage advantages keeps you "honest" reason why there evenI ondon't see this as a disadvantage, but just a consequence. In fact, I see it as a mdisadvsmajor anyadvantage! All strict purely functional languages todaygave (and why things like monadic IO was invented - they hadin to becausethe thecircumspacesiren usagecall reasoningy couldn't haveof side edeffects, non-strict intosemantics akeeps lessyou "evangelicastrict purely lhonest" form stances those coantage is the one uld be seen as disadvantages).and isThe onlof side effeexithat is probably the inreason whatwhy .there Ieven thinkexists theany wholepurely sectionfunctional shouldlanguages betoday refactoredfunctional(and thewhy silanguagesthings gavelike effectsymonadic !IO Allwas invented laziness- ensuredthey abouthad (i.e.to ratherbecause thanthey talkingcouldn't abouthave "disadvantages", talk about "consequences", and perhapsside effects without them, andtrulyand anlaziness undisputajorensured stthatthat!).in to ren call

The only disadvantage that is truly an undisputed disadvantage is the one about space usage reasoning. I think the whole section should be refactored into a less "evangelical" form (i.e. rather than talking about "disadvantages", talk about "consequences", and perhaps in what circumstances those could be seen as disadvantages).

== Common Lisp ==

Line 34 ⟶ 39:

::Consider the following example in typed lambda calculus, which takes a boolean and two functional thunks and returns another thunk:

<syntaxhighlight lang="text">

<code>

&lambda; b : (unit -> a) -> (unit -> a) -> a. &lambda; tr : unit -> a. &lambda; fa : unit -> a. &lambda; u : unit. b tr fa

</syntaxhighlight>

</code>

::In this case, b could be a suspended [[Church encoding]] of "true" or "false":

<syntaxhighlight lang="text">

<code>

true := &lambda; tr : unit -> a. &lambda; fa : unit -> a. tr ()

false := &lambda; tr : unit -> a. &lambda; fa : unit -> a. fa ()

</syntaxhighlight>

</code>

::So all you really need are functions and unit; non-strictness is just a matter of convenience if you don't want to deal with explicitly invoking your thunks. I won't claim it's not convenient, because it is; but it's not really a matter of expressiveness. --[[User:Donhalcon|bmills]] 19:26, 19 February 2006 (UTC)