Talk:Strict programming language: Difference between revisions

Revision as of 22:10, 17 October 2017

Latest revision as of 08:57, 14 January 2025

(5 intermediate revisions by 4 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)

Line 71 ⟶ 76:

''A strict programming language is a programming language which employs a strict programming paradigm, allowing only strict functions''

What does that means? It's like a recursive definition <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/186.120.227.55|186.120.227.55]] ([[User talk:186.120.227.55#top|talk]]) 22:09, 17 October 2017 (UTC)</small> <!--Autosigned by SineBot-->

:If I'm not mistaken you mean it is a circular definition. Yes there doesn't seem to be a strict definition of what strict means here[[User:Ethanpet113|Ethanpet113]] ([[User talk:Ethanpet113|talk]]) 06:50, 18 November 2018 (UTC)

== No Context ==

There isn't enough context for this article to be useful, what is it that makes a programming paradigm strict. Is it only necessary that arguments to the function must be evaluated before call, or are there other requirements?[[User:Ethanpet113|Ethanpet113]] ([[User talk:Ethanpet113|talk]]) 06:55, 18 November 2018 (UTC)