| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Language.Fortran.AST.Literal.Complex
Description
Supporting definitions for COMPLEX literals.
Synopsis
- data ComplexLit a = ComplexLit {}
- data ComplexPart a
- = ComplexPartReal a SrcSpan RealLit (Maybe (KindParam a))
- | ComplexPartInt a SrcSpan String (Maybe (KindParam a))
- | ComplexPartNamed a SrcSpan Name
Documentation
data ComplexLit a Source #
A COMPLEX literal, composed of a real part and an imaginary part.
Fortran has lots of rules on how COMPLEX literals are defined and used in
various contexts. To support all that, we define the syntactic structure
ComplexLit to wrap all the parsing rules. Then during a analysis pass, you
may (attempt to) convert these into a more regular type, like a Haskell
(Double, Double) tuple.
Constructors
| ComplexLit | |
Fields
| |
Instances
data ComplexPart a Source #
A part (either real or imaginary) of a complex literal.
Since Fortran 2003, complex literal parts support named constants, which must be resolved in context at compile time (R422, R423).
Some compilers also allow constant expressions for the parts, and must evaluate at compile time. That's not allowed in any standard. Apparently, gfortran and ifort don't allow it, while nvfortran does. See: https://fortran-lang.discourse.group/t/complex-constants-and-variables/2909/3
We specifically avoid supporting that by defining complex parts without being
mutually recursive with Expression.
Constructors
| ComplexPartReal a SrcSpan RealLit (Maybe (KindParam a)) | signed real lit |
| ComplexPartInt a SrcSpan String (Maybe (KindParam a)) | signed int lit |
| ComplexPartNamed a SrcSpan Name | named constant |