Code Monkey home page Code Monkey logo

forsyde-deep's People

Contributors

hwoidt avatar ingo-sander avatar shaniaki avatar ugeorge avatar

Stargazers

avatar

Watchers

avatar avatar avatar avatar avatar avatar

Forkers

ugeorge harika140901

forsyde-deep's Issues

Redesign: Netlist Node data structure (NlNode)

Issue by HWoidt
Saturday Jul 11, 2015 at 13:06 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/19

Reported by [email protected], Aug 9, 2008

Now, the output signals of a node are modeled by tagging the graph edges
connected to that node. However, that's quite inconvenient (and
inefficient) in practice.

Even if a better model cannot be found (which I doubt) at least we should
create a variant of NlNode which takes outputs in account.

data  NlNodeIO inputi outputi = 
             -- Ports
             InPort  PortId               | -- ^ Input Ports of the system 
             -- Processes
             Proc ProcId (NlProc inputi)

data NlProc inputi outputi = 
 ...
  ZipWithNSY (TypedProcFun Dynamic) -- Process function in dynamic form
            [inputi] outputi
 ...

GHC 8.0 Compatibility

GHC 8.0.1 is out. A cursory glance at the migration guide did not raise any alarms with me but we still need to check, whether everything works. There are also some new features that might be interesting (although we should not introduce any changes that break backwards compatibility for GHC 7.10):

  • A more refined interface for implicit call-stacks, allowing libraries to
    provide more helpful runtime error messages to users
  • Significant improvements in error message readability and content, including
    facilities for libraries to provide custom error messages, more aggressive
    warnings for fragile rewrite rules, and more helpful errors for missing
    imports
  • Introduction of type application syntax, reducing the need for proxies

https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.html
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0

Tri-State data type

Issue by HWoidt
Saturday Jul 11, 2015 at 13:01 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/12

Reported by [email protected], Apr 23, 2008

In order to model for instance buses a tri-state data type is needed.

std_logic in VHDL provides 9 different values, the most important are '1',
'0', 'Z' (high resistance) and 'X' (unknown).

How difficult would it be to implement it?

Apr 24, 2008
Project Member [email protected]

OK, sounds reasonable. On the other hand ... wouldn't it be better to just have one
type (e.g. StdLogic) instead of two (Bit + StdLogic)? Actually, Bit is currently
translated to std_logic.

I never really understood why VHDL makes use of both.

Apr 24, 2008
Project Member [email protected]

Let's think a little bit more about it. The full std_logic data type is not needed
for synthesis. One should have 'Z' and maybe 'X' is also used (for don't care, but we
have to check this further).

Print version information

Issue by ingo-sander
Friday Jan 15, 2016 at 09:23 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/26

I would like to have a simple command forsydeVersion, which gives me a version number and maybe additional information. Ideally the version number should include also the version number of the git-repository.

Something like

> forsydeVersion
forsyde-deep 0.2.1 - revision 288

This would simplify the discussion and avoid confusion.

Simulation with Modelsim

Issue by ingo-sander
Thursday Jan 14, 2016 at 14:42 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/24

There seems to be a bug in the simulation with Modelsim.

When I simulate the counter example then Modelsim produces an error. I have not analyzed it further, but it might have to do with reset or the clock input. So, please ensure that a Modelsim simulation generates the trace for the clock signal and resets all flip-flops at the beginning of the simulation.

Here comes the code for the counter:

{-# LANGUAGE TemplateHaskell #-}

module CounterHW (Direction, counterSys) where

import ForSyDe.Deep
import Data.Int

type Direction = Bit

nextStateFun :: ProcFun (Int8 -> Direction -> Int8)
nextStateFun = $(newProcFun
   [d| nextState state dir
          = if dir == H then
              if state < 9 then state + 1
              else 0
            else
              if state == 0 then 9
              else state - 1
     |])

counterProc :: Signal Direction -> Signal Int8 
counterProc = scanldSY "counterProc" nextStateFun 0


counterSys :: SysDef (Signal Direction -> Signal Int8)
counterSys = newSysDef counterProc "Counter" ["direction"] ["number"]

And here is the simulation output:

ingo@s2135:counter7Seg> ghci CounterHW.hs 
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling CounterHW        ( CounterHW.hs, interpreted )

CounterHW.hs:26:70: Warning: Tab character
Ok, modules loaded: CounterHW.
*CounterHW> simulate counterSys [L,H,H,H,H,L,L,L,L]
[0,9,0,1,2,3,2,1,0]
*CounterHW> let vhdlSim = writeAndModelsimVHDL Nothing counterSys
*CounterHW> vhdlSim [L,H,H,H,H,L,L,L,L]
Running: vmap forsyde /home/ingo/.cabal/share/x86_64-linux-ghc-7.10.3/ForSyDe-Deep-0.2.0/lib/modelsim
Modifying modelsim.ini
Running: vlib Counter_lib/modelsim
Running: vcom -93 -quiet -nologo -work Counter_lib/modelsim Counter_lib/Counter_lib.vhd
Running: vmap Counter_lib Counter_lib/modelsim
Modifying modelsim.ini
Running: vlib work/modelsim
Running: vcom -93 -quiet -nologo -work work/modelsim -just e work/Counter.vhd
Running: vcom -93 -quiet -nologo -work work/modelsim -just a work/Counter.vhd
Running: vmap work work/modelsim
Modifying modelsim.ini
Running: vcom -93 -quiet -nologo -work work test/Counter_tb.vhd
Running: vsim -c -std_output /tmp/tb_out1804289383846930886.txt -quiet -do run 90 ns; exit work.Counter_tb
Reading /opt/altera/13.0/modelsim_ae/tcl/vsim/pref.tcl 

#10.1d

# vsim -do {run 90 ns; exit} -c -quiet -std_output /tmp/tb_out1804289383846930886.txt work.Counter_tb 
# //  ModelSim ALTERA 10.1d Nov  2 2012 Linux 3.13.0-74-generic
# //
# //  Copyright 1991-2012 Mentor Graphics Corporation
# //  All Rights Reserved.
# //
# //  THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION
# //  WHICH IS THE PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS
# //  LICENSORS AND IS SUBJECT TO LICENSE TERMS.
# //
# run 90 ns 
# ** Fatal: (vsim-3421) Value -129 for return value is out of range -128 to 127.
#    Time: 0 ps  Iteration: 0  Process: /counter_tb/totest/\counterProc_NxtSt\/line__49 File: work/Counter.vhd
# Fatal error in Subprogram \nextState_0\ at work/Counter.vhd line 44
# 
# HDL call sequence:
# Stopped at work/Counter.vhd 44 Subprogram \nextState_0\
# called from  work/Counter.vhd 50 Block \counterProc_NxtSt\
# 
#  exit 
[]

[CLOSED] VHDL functions for the AbstExt type are not generated correctly

Issue by HWoidt
Saturday Jul 11, 2015 at 13:09 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/22

Reported by joaopizani, Nov 24, 2010

I've written a VERY simple RLE encoder using ForSyDe's deep-embedded API, intending to synthesize it. Simulation with "simulate" went well, and ForSyDe generated VHDL. But in the library generated by ForSyDe (rle_lib.vhd) the VHDL functions for verifying if an AbstExt value is present, and the Prst constructor are missing.

They are replaced by duplicate instances of "absent" functions. If I just replace the word "absent" by "present" in two places in the VHDL code, the project synthesizes and works beautifully...

What steps will reproduce the problem?

  1. runhaskell RLE.hs over the following code: http://hpaste.org/41770/forsyde_rle_encoder
  2. The generated VHDL library in (rle/vhdl/rle_lib/rle_lib.vhd) is this one:
    http://hpaste.org/41771/forsyde_generated_vhdl_library
  3. Try to compile the design under Quartus.

What is the expected output? What do you see instead?
Expected the VHDL design and libraries to compiles and synthesize successfully. Instead, when running the compilation in Quartus, it complains with the following error message:
"Error (10289): VHDL Subprogram Specification error at rle_lib.vhd(43): subprogram "absent" is a homograph of another object in the same declarative region"

It turns out that this declaration, and the corresponding definition are really duplicate. But if I replace both occurrences of "absent" by "present" it all works.

What version of the product are you using? On what operating system?
ForSyDe 3.1.1 (from Hackage)
Haskell Platform 2010.2.0.0
GHC 6.12.3
Quartus 10.0
Ubuntu 10.10

Please provide any additional information below.
I have made a small diff file from the comparison between what is generated by ForSyDe and what works. Here it is:

30c30
<      function absent (extabst : tup_2_int8_int16)

---
>      function present (extabst : tup_2_int8_int16)
40c40
<      function absent (extabst : abs_ext_tup_2_int8_int16)

---
>      function present (extabst : abs_ext_tup_2_int8_int16)
75c75
<      function absent (extabst : tup_2_int8_int16)

---
>      function present (extabst : tup_2_int8_int16)
98c98
<      function absent (extabst : abs_ext_tup_2_int8_int16)

---
>      function present (extabst : abs_ext_tup_2_int8_int16)

VHDL Backend: Range mismatch between Haskell's Int32 and Minimum VHDL'93 Integer range

Issue by HWoidt
Saturday Jul 11, 2015 at 13:04 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/17

Reported by [email protected], Aug 4, 2008

According to the VHDL'93 standard, the minimum guaranteed range for any
implementation if INTEGER is -2147483647 to 2147483647 (which matches the
range implemented by Modelsim 6.1g (Included with Quartus 7.2)).

However, the range of a 32-bit Two complement's representation (Int32) is
-2147483648 to 2147483647, making it overflow.

What should be done here?

[CLOSED] Name lookup of algebraic data types fails.

Issue by HWoidt
Thursday Jul 09, 2015 at 12:39 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/5

The test cases ALU and ButtonEncoder fail with an "Unsupported Type" error:

### Error in:   0:VHDL Backend Test:0:aluTest
VHDL Compilation Error: Unsupported type Bit
in process function `fullAddFun_0' (created in ALU)  used by  process `fulladd' belonging to system definition `fullAddSys' (created in <unkown>)

### Error in:   0:VHDL Backend Test:6:buttonEncoderTest
VHDL Compilation Error: Unsupported type Direction
in process function `transFun_0' (created in ButtonEncoder)  used by  process `encoder' belonging to system definition `buttonEncoder' (created in <unkown>)

This is due to wrong strings being compared in the enumType registry during translation:
enumTypes = fromList [EnumAlgTy "Bit" ["H","L"]]
lookupKey = "ForSyDe.Deep.Bit.Bit"
This should be resolved by either

  • use the fully qualified name for both inserting and querying
  • use only the base name for both cases

[CLOSED] Synthesis of FSVec

Issue by ingo-sander
Friday Dec 25, 2015 at 14:50 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/23

There seems to be a problem with the synthesis of FSVec, which becomes visible in the SimpleDES_HW.hs example. The normal 'compileQuartus', which synthesizes the fSys-subsystem works, but there is a problem with the full example, where FSVec D5 Bit cannot be synthesized.

Check the code below:

ingo@hsv:examples> ghci SimpleDES_HW.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling SimpleDES_HW ( SimpleDES_HW.hs, interpreted )
Ok, modules loaded: SimpleDES_HW.
SimpleDES_HW> compileQuartus_subkeysSys
** Exception: VHDL Compilation Error: Unsupported type FSVec D5 Bit
in process function subkeys_0' (created in SimpleDES_HW) used by processsubKeys' belonging to system definition `genSubkeys' (created in )
*SimpleDES_HW> :q
Leaving GHCi.

Compile forsyde.vhd on demand instead of during compilation

Issue by HWoidt
Thursday Jul 09, 2015 at 12:51 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/9

For the new test suite configuration to be usable, the library should to be compiled
alongside the generated vhdl files.
This would have several positive effects:

  • forsyde.vhdl available in project directory for redistribution
    of generated vhdl files
  • modelsim need not be available during installation of forsyde.
  • testsuite can run in the source directory without the package
    being installed in the system

The only downside would be additional effort when recompiling the
package. Since forsyde.vhd only contains a couple of functions this is
not of great concern.

[CLOSED] Introduce new FSDTypeRep type

Issue by HWoidt
Monday Feb 08, 2016 at 10:25 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/29

Data.Typeable.FSDTypeRepLib implements a wrapper around haskells own
Data.Typeable TypeRep/TyCon. This wrapper eliminates the package field
of the type, thus making it possible to construct it from template
haskell type objects.

This commit introduces the new type and changes all uses of the original
TypeRep with the new FSDTypeRep. Among others this fixes #23

[23] https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/23

HWoidt included the following code: https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/29/commits

take in FSVec

Hi, I found that the generated VHDL code for 'take' function in Data.Param.FSVec cannot be simulated by writeAndModelsimVHDL. Here is a small example.

{-# LANGUAGE TemplateHaskell #-}
module Take where
import ForSyDe.Deep
import Data.Int
import Data.TypeLevel
import Data.Param.FSVec

takeProcFun :: ProcFun(FSVec D3 Int32 -> FSVec D1 Int32)
takeProcFun = $(newProcFun
    [d| takeProcFun :: FSVec D3 Int32 -> FSVec D1 Int32
        takeProcFun x = Data.Param.FSVec.take d1 x
    |])

takeProc :: Signal (FSVec D3 Int32) -> Signal (FSVec D1 Int32)
takeProc = mapSY "proc1" takeProcFun

takeSysDef :: SysDef(Signal (FSVec D3 Int32) -> Signal (FSVec D1 Int32))
takeSysDef = newSysDef takeProc "mingzi" ["in"] ["out"]

x1 = (1 :: Int32) +> (2 :: Int32) +> (3 :: Int32) +> empty
x2 = (4 :: Int32) +> (5 :: Int32) +> (6 :: Int32) +> empty

The simulation in ForSyDe.Deep is fine.

simulate takeSysDef [x1, x2]
[<1>,<4>]

But the simulation in Modelsim failed.

writeAndModelsimVHDL Nothing takeSysDef [x1, x2]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim 
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
** Warning: (vlib-34) Library already exists at "mingzi_lib/modelsim".
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Warning: mingzi_lib/mingzi_lib.vhd(127): (vcom-1246) Range 0 to -1 is null.
Running: vmap mingzi_lib mingzi_lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap mingzi_lib mingzi_lib/modelsim 
Modifying modelsim.ini
Running: vlib work/modelsim
** Warning: (vlib-34) Library already exists at "work/modelsim".
Running: vcom -93 -quiet -nologo -work work/modelsim -just e work/mingzi.vhd
Running: vcom -93 -quiet -nologo -work work/modelsim -just a work/mingzi.vhd
Running: vmap work work/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap work work/modelsim 
Modifying modelsim.ini
Running: vcom -93 -quiet -nologo -work work test/mingzi_tb.vhd
Running: vsim -c -std_output /tmp/tb_out7198853861649760492.txt -quiet -do run 20 ns; exit work.mingzi_tb
Reading pref.tcl

# 2020.1

# vsim -c -std_output /tmp/tb_out7198853861649760492.txt -quiet -do "run 20 ns; exit" work.mingzi_tb 
# Start time: 00:51:37 on Oct 23,2022
# run 20 ns
# ** Fatal: (vsim-3420) Array lengths do not match. Left is 1 (0 to 0). Right is 0 (1 to 0 (null array)).
#    Time: 0 ps  Iteration: 0  Process: /mingzi_tb/totest/\proc1\/line__31 File: mingzi_lib/mingzi_lib.vhd
# Fatal error in Subprogram take at mingzi_lib/mingzi_lib.vhd line 187
# 
# HDL call sequence:
# Stopped at mingzi_lib/mingzi_lib.vhd 187 Subprogram take
# called from  work/mingzi.vhd 28 Subprogram \takeProcFun_0\
# called from  work/mingzi.vhd 31 Block \proc1\
# 
#  exit
# End time: 00:51:37 on Oct 23,2022, Elapsed time: 0:00:00
# Errors: 1, Warnings: 0
[]

For the simulation in Quartus, I am still struggling.

[CLOSED] Import issues from old google-code tracker

Issue by HWoidt
Thursday Jul 09, 2015 at 12:27 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/2

There exist unsolved issues in the old google-code tracker. They should be incorporated here.

http://code.google.com/p/forsyde-comp/issues/list

Note that google code will be closed at the end of 2016:
January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.

VHDL backend support for arbitrary function orders in where clauses

Issue by HWoidt
Saturday Jul 11, 2015 at 13:07 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/20

Reported by [email protected], Jan 19, 2010

To reproduce the problem:

  1. Define a process function which has included functions inside a where
    clause.
  2. Generate the VHDL code and try to simulate/synthesize the output.

The VHDL backend generates the output sub-functions in the VHDL code in the
same order as were defined in the design. This may result to using a
function in the VHDL code before defining it.
As a workaround, the designer could define the functions in the
define-then-use order which is not a common practice in functional programming.

multidimentional fixed size vector error in modelsim simulation on generated vhdl code

Hi. I find there is also something wrong with multi-dimensional fixed size vector. The simulation in forsyde deep is fine, but the generated VHDL code cannot be simulated.

My code is:

{-# LANGUAGE TemplateHaskell #-}
module Take where
import ForSyDe.Deep 
import Data.Int
import Data.TypeLevel
import Data.Param.FSVec

takeProcFun :: ProcFun(FSVec D2 (FSVec D2 Int32) -> FSVec D2 (FSVec D2 Int32))
takeProcFun = $(newProcFun
    [d| takeProcFun :: FSVec D2 (FSVec D2 Int32) -> FSVec D2 (FSVec D2 Int32) 
        takeProcFun x = x
    |])

takeProc :: Signal (FSVec D2 (FSVec D2 Int32)) -> Signal (FSVec D2 (FSVec D2 Int32)) 
takeProc = mapSY "proc1" takeProcFun

takeSysDef :: SysDef(Signal (FSVec D2 (FSVec D2 Int32)) -> Signal (FSVec D2 (FSVec D2 Int32)))
takeSysDef = newSysDef takeProc "mingzi" ["in"] ["out"]

x1 = (1 :: Int32) +> (2 :: Int32) +> empty
x2 = (4 :: Int32) +> (5 :: Int32) +> empty

y1 = x1 +> x2 +> empty

The simulation result in forsyde deep is:

simulate takeSysDef [y1]
[<<1,2>,<4,5>>]

But error happens in modelsim simulation:

writeAndModelsimVHDL Nothing takeSysDef [y1]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim 
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
** Warning: (vlib-34) Library already exists at "mingzi_lib/modelsim".
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Error: mingzi_lib/mingzi_lib.vhd(13): (vcom-1136) Unknown identifier "fsvec_2_int32".
** Note: mingzi_lib/mingzi_lib.vhd(187): VHDL Compiler exiting
*** Exception: VHDL Compilation Error: Modelsim failed
in system definition `mingzi' (created in <unkown>)
CallStack (from HasCallStack):
  error, called at src/ForSyDe/Deep/ForSyDeErr.hs:461:18 in forsyde-deep-0.2.0-7deUbX6BizeCKOZ9sbSqT7:ForSyDe.Deep.ForSyDeErr
*Take> writeVHDL takeSysDef
*Take> writeAndModelsimVHDL Nothing takeSysDef [y1]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim 
Copying /home/embedded/intelFPGA/20.1/modelsim_ase/linuxaloem/../modelsim.ini to modelsim.ini
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Error: mingzi_lib/mingzi_lib.vhd(13): (vcom-1136) Unknown identifier "fsvec_2_int32".
** Note: mingzi_lib/mingzi_lib.vhd(187): VHDL Compiler exiting
*** Exception: VHDL Compilation Error: Modelsim failed
in system definition `mingzi' (created in <unkown>)
CallStack (from HasCallStack):
  error, called at src/ForSyDe/Deep/ForSyDeErr.hs:461:18 in forsyde-deep-0.2.0-7deUbX6BizeCKOZ9sbSqT7:ForSyDe.Deep.ForSyDeErr

Include "instance Data a => Lift a" in ForSyDe

Issue by HWoidt
Saturday Jul 11, 2015 at 13:04 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/16

Reported by [email protected], Jun 23, 2008

As we know, all the types handled by ForSyDe are required to be instances
of Data.

Creating a "Data a => Lift a" (undecidable) instance would make all
instances of Data (and implicilty all ForSyDe-supported types) also
instances of Lift, sparing us from needing to use $(deriveLift
WhateverDataType).

I created ticket [1] in GHC's track asking for this feature a while ago,
and they accepted to include it in GHC 6.10, but that won't happen in a while.

[1] http://hackage.haskell.org/trac/ghc/ticket/1830

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.