Difference between revisions of "Talk:Open research problems"

From HaskellWiki
Jump to: navigation, search
(Acoiding the I/O problem using the FFI)
(I/O-related content relocated to "Talk:The I/O quandary")
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Denotative languages and the I/O problem ==
+
There is currently no text in this page.
 
+
You can <span style="color:brown;">search for this page title</span> in other pages,
<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
+
<span style="color:brown;">search the related logs</span>,
My view is that the next logical step for programming is to split into two non-overlapping programming domains:
+
or <span style="color:brown;">create this page</span>.
 
 
* runtime building for …
 
* … mathematical programming languages
 
 
 
<tt>[https://www.haskellforall.com/2021/04/the-end-of-history-for-programming.html Gabriella Gonzalez].</tt>
 
</div>
 
 
 
Let's assume:
 
* a denotative language exists - here, it's called <i>DL</i>.
 
* the implementation of <i>DL</i> is written in an imperative language - let's call that <i>IL</i>.
 
 
 
Let's also assume:
 
* <i>DL</i> is initially successfull.
 
* solid-state Turing machines remain in use, so <i>IL</i> is still needed.
 
 
 
As time goes on, technology advances which means an ever-expanding list of hardware to cater for. Unfortunately, the computing architecture remains mired in state and effects - supporting the new hardware usually means a visit to <i>IL</i> to add the extra subroutines/procedures (or modify existing ones) in the implementation.
 
 
 
<i>DL</i> will still attract some interest:
 
 
 
* Parts of the logic required to support hardware can be more usefully written as <i>DL</i> definitions, to be called by the implementation where needed - there's no problem with imperative code calling denotative code.
 
 
 
* periodic refactoring of the implementation reveals suitable candidates for replacement with calls to <i>DL</i> expressions.
 
 
 
* <i>DL</i> is occasionally extended to cater for new patterns of use - mostly in the form of new abstractions and their supporting libraries, or (more rarely) the language itself and therefore its implementation in <i>IL</i>.
 
 
 
...in any case, <i>DL</i> remains denotative - if you want a computer to do something new to its surroundings, that usually means using <i>IL</i> to modify the implementation of <i>DL</i>.
 
 
 
So the question is this: which language will programmers use more often, out of habit - <i>DL</i> or <i>IL</i>?
 
 
 
Here's a clue:
 
 
 
<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
 
 
 
They [monadic types] are especially useful for structuring large systems. In fact, there's a danger of programming in this style too much (I know I do), and almost forgetting about the 'pure' style of Haskell.
 
 
 
<tt>[[Monad tutorials timeline|Noel Winstanley]].</tt>
 
</div>
 
 
 
Instead of [http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm looking at the whole system in a consistently denotational style (with simple & precise semantics)] by using <i>DL</i> alone, most users would be working on the implementation using <i>IL</i> - being denotative makes for nice libraries, but getting the job done means being imperative. Is this an improvement over the current situation in Haskell? No - instead of having the denotative/imperative division in Haskell by way of types, users would be contending with that division <i>at the language level</i> in the forms of differing syntax and semantics, annoying foreign calls, and so forth.
 
 
 
The advent of Haskell's FFI is an additional aggravation - it allows countless more effect-centric operations to be accessed. Moving <b>all</b> of them into a <i>finite</i> implementation isn't just impractical - it's impossible.
 
 
 
But if you still think being denotative is worth all that bother (or you just want to prove me wrong :-) [https://www.ioccc.org/2019/lynn/hint.html this] could be a useful place to start:
 
 
 
<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
 
* <tt>OneHundredPercentPure</tt>: Gone is the catch-all lawless <code>IO</code> monad. And no trace of those scary <code>unsafeThisAndThat</code> functions. All functions must be pure.
 
</div>
 
 
 
&mdash; [[User:Atravers|Atravers]] Fri Oct 22 06:36:41 UTC 2021
 
 
 
 
 
== Outsourcing the I/O problem ==
 
 
 
...it's quite simple really:
 
 
 
* just extend the FFI enough to replace the ''usually''-abstract I/O definitions with calls to foreign definitions:
 
:{|
 
|
 
    instance Monad IO where
 
        return = primUnitIO
 
        (>>=)  = primBindIO
 
 
 
    foreign import ccall unsafe primUnitIO :: a -> IO a
 
    foreign import ccall unsafe primBindIO :: IO a -> (a -> IO b) -> IO b
 
                    ⋮
 
|}
 
 
 
* the <code>IO</code> type is then just a type-level tag, as specified in the Haskell 2010 report:
 
 
 
:{|
 
|
 
    data IO a  -- that's all folks!
 
|}
 
 
 
''Voilà!'' In this example, the I/O problem has been outsourced to C - if you're not happy with C's solution to the I/O problem, just use another programming language for the Haskell implementation: there's plenty of them to choose from (...but don't use Haskell, to avoid going <code>⊥</code>-up ;-).
 
 
 
&mdash; [[User:Atravers|Atravers]] Thu Dec  9 01:55:47 UTC 2021
 

Latest revision as of 07:30, 3 March 2022

There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page.