小编hvr*_*hvr的帖子

我试图弄清楚如何在并发上下文中正确使用OpenSSL.Session API

例如假设我想实现一个stunnel-style ssl-wrapper,我希望有以下基本的骨架结构,它实现了一个天真的full-duplex tcp-port-forwarder:

runProxy :: PortID -> AddrInfo -> IO ()
runProxy localPort@(PortNumber lpn) serverAddrInfo = do
  listener <- listenOn localPort

  forever $ do
    (sClient, clientAddr) <- accept listener

    let finalize sServer = do
            sClose sServer
            sClose sClient

    forkIO $ do
        tidToServer <- myThreadId
        bracket (connectToServer serverAddrInfo) finalize $ \sServer -> do
            -- execute one 'copySocket' thread for each data direction
            -- and make sure that if one direction dies, the other gets
            -- …

(我希望这个问题是关于主题的 - 我试图寻找答案,但没有找到明确的答案.如果这恰好是偏离主题或已经回答,请缓和/删除它.)

我记得听过/读过关于Haskell 几次是最好的命令式语言的半开玩笑的评论,这当然听起来很奇怪,因为Haskell通常以其功能特性而闻名.

所以我的问题是,Haskell的哪些特性/特性(如果有的话)有理由证明Haskell被认为是最好的命令式语言 - 或者它实际上更像是一个笑话？

我在hackage上看过几个包含模块名称的包,.Internal作为它们的姓氏组件(例如Data.ByteString.Internal)

这些模块在Haddock中通常不能正常浏览(但它们可能会显示),不应该被客户端代码使用,而是包含从暴露的模块重新导出或仅在内部使用的定义.

现在我对这个图书馆组织模式的问题是:

• 这些.Internal模块解决了哪些问题？
• 是否有其他更好的方法来解决这些问题？
• 应该将哪些定义移到这些.Internal模块中？
• 在这些.Internal模块的帮助下组织图书馆的当前推荐做法是什么？

目前,有两种流行的选择实现了iteratee模式:

• 该枚举包和
• 该iteratee包.

他们的相对好处是什么？是一个比另一个好,还是取决于用例(如果是的话,决定使用哪个标准的标准是什么)？

我一直在阅读RFC-4627规范,我来解释一下:

将有效负载通告为application/jsonmime-type时,

1. 有必须是没有BOM在正确编码JSON流(基于部分"3.编码")的开始s和
2. 没有媒体参数也被支持,从而一个的mime类型报头application/json; charset=utf-8并不符合RFC-4627(基于部分"6. IANA考虑").

这些是正确的扣除吗？在实施遵循这种解释的Web服务或Web客户端时,我会遇到问题吗？我是否应该针对违反上述两个属性的Web浏览器提交错误？

最近,诸如计算Hashmap的大小之类的博客条目解释了如何推断常用容器类型的空间复杂性.现在我面临的问题是如何实际"看到"我的GHC版本选择的内存布局(取决于编译标志和目标体系结构),用于奇怪的数据类型(构造函数),例如

data BitVec257 = BitVec257 {-# UNPACK #-} !Word64
                           {-# UNPACK #-} !Word64
                           {-# UNPACK #-} !Bool
                           {-# UNPACK #-} !Word64
                           {-# UNPACK #-} !Word64

data BitVec514 = BitVec514 {-# UNPACK #-} !BitVec257
                           {-# UNPACK #-} !BitVec257

在C中有sizeof和offsetof运算符,它允许我"看到"为C字段选择的大小和对齐方式struct.

我试着看看GHC Core希望在那里找到一些提示,但我不知道该找什么.有人能指出我正确的方向吗？

我试图使用aeson解析以下形式的JSON

{"field":{"name":"..."}}

or

{"tag":{"name":"..."}}

or

{"line":{"number":"..."}}

构造以下数据类型

data Rule = Line Integer
          | Field L.ByteString
          | Tag L.ByteString

不幸的是,我面临两个我没有找到解决方案的问题,即:

1. 如何解析嵌套的JSON？查看(.:)的实现,它使用lookup来提取特定键的值.我对做这样的事情犹豫不决,因为它似乎过分依赖于aeson如何实现事物的具体细节.我认为这是一个问题我错了吗？

2. 如何根据JSON中存在的键使用正确的数据构造函数？我用<|>做的所有努力都让我无处可去.

我会发布到目前为止我写的代码,但我还没有达到我有什么值得发布的地步.

是否存在GHC特定的"不安全"扩展,以询问两个Haskell引用是否指向同一位置？

我知道如果使用不当,这会破坏引用透明度.但是应该没有什么害处(除非我遗漏了一些东西),如果它被非常小心地使用,作为通过短切递归(或昂贵)数据遍历进行优化的手段,例如用于实现优化Eq实例,例如:

instance Eq ComplexTree where
   a == b  = (a `unsafeSameRef` b) || (a `deepCompare` b)

deepCompare如果unsafeSameRef判定为真(但不一定相反),则保证提供.

编辑/ PS:由于答案指向System.Mem.StableName,我能够找到拉伸存储管理器的文章:Haskell中的弱指针和稳定名称,恰好已经解决了这个问题已经超过10年了......

我只是在注意学习阅读GHC Core时注意到,这是Eq枚举式数据类型的自动派生实例,如

data EType = ETypeA | ETypeB | ETypeC | ETypeD
           | ETypeE | ETypeF | ETypeG | ETypeH
           deriving (Eq)

在查看GHC的核心表示时,似乎会转换为类似O(N)的查找:

$fEqEType_$c== =
  \ (a_ahZ :: EType) (b_ai0 :: EType) ->
    case a_ahZ of _ {
      ETypeA ->
        case b_ai0 of _ {
          ETypeA -> True;
          ETypeB -> False;
          ETypeC -> False;
          ETypeD -> False;
          ETypeE -> False;
          ETypeF -> False;
          ETypeG -> False;
          ETypeH -> False
        };
      ETypeB -> case b_ai0 of _ …

从C++来了,我曾经是能够建立编译时断言,在那里我可以在编译时发出警告或错误的简单形式,如果一些简单的条件(例如在简单的代数表达式)未通过使用模板元的满足 - 编程和/或 cpp(1)

举例来说,如果我想确保我的程序时,只编译Int至少有一定的minBound/ maxBound范围或替代,如果从(如可逆)无损耗转换Int64到Int可能与当前编译目标.这可能是GHC Haskell扩展的一部分吗？我的第一个猜测是使用TH.是否有其他GHC设施可以被利用？