Hi, I am positive about the following situation, but I can't find any concrete answer on the Web. Can anyone confirm this ? In template-haskell-2.7.0, the following quote [t| () |] appears as a (ConT name), where "name" is the name for unit. However, in template-haskell-2.8.0, the same quote appears as (TupleT 0). Is this the expected behaviour ? Thanks, Jose -- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
I can't answer about "expected behavior", but I can say that those two constructions should be considered identical by the $(…) splice construct. For better or worse, Template Haskell often offers multiple ways of encoding the same source Haskell phrase, and any code that processes Template Haskell syntax should probably treat the two constructs equivalently. In a week or so, I'm hoping to release the first version of a new th-desugar package, which attempts to remove these redundancies by converting TH syntax into a smaller syntax tree. I'll announce here when it's ready for public consumption. I hope this helps, Richard On Aug 29, 2013, at 9:03 AM, Jose A. Lopes wrote:
Hi,
I am positive about the following situation, but I can't find any concrete answer on the Web. Can anyone confirm this ?
In template-haskell-2.7.0, the following quote
[t| () |]
appears as a (ConT name), where "name" is the name for unit. However, in template-haskell-2.8.0, the same quote appears as (TupleT 0).
Is this the expected behaviour ?
Thanks, Jose
-- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München
Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I can't answer about "expected behavior", but I can say that those two constructions should be considered identical by the $(…) splice construct. For better or worse, Template Haskell often offers multiple ways of encoding the same source Haskell phrase, and any code that processes Template Haskell syntax should probably treat the two constructs equivalently.
I am not sure I agree that those two constructions should be identical. The Unit type is just a normal type with a single inhabitant: the unit value. How is this related to tuples ? Jose -- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
I've always considered Unit to just be a nullary tuple. This intuition has never steered me wrong, and it seems that Template Haskell is making the same assumption. If there's some reason that this conflation of ideas is wrong, I would be eager to know -- th-desugar makes this assumption in several places.
Thanks,
Richard
On Aug 29, 2013, at 11:08 AM, "Jose A. Lopes"
I can't answer about "expected behavior", but I can say that those two constructions should be considered identical by the $(…) splice construct. For better or worse, Template Haskell often offers multiple ways of encoding the same source Haskell phrase, and any code that processes Template Haskell syntax should probably treat the two constructs equivalently.
I am not sure I agree that those two constructions should be identical. The Unit type is just a normal type with a single inhabitant: the unit value. How is this related to tuples ?
Jose
-- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München
Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
Hi Jose and Richard,
haskell-src-meta has Language.Haskell.Meta.Utils.normalizeT which can
help with making code "treat the two constructs equivalently", though
I imagine using th-desugar instead will make that process harder to
mess up.
Adam
On Thu, Aug 29, 2013 at 10:13 AM, Richard Eisenberg
I can't answer about "expected behavior", but I can say that those two constructions should be considered identical by the $(…) splice construct. For better or worse, Template Haskell often offers multiple ways of encoding the same source Haskell phrase, and any code that processes Template Haskell syntax should probably treat the two constructs equivalently.
In a week or so, I'm hoping to release the first version of a new th-desugar package, which attempts to remove these redundancies by converting TH syntax into a smaller syntax tree. I'll announce here when it's ready for public consumption.
I hope this helps, Richard
On Aug 29, 2013, at 9:03 AM, Jose A. Lopes wrote:
Hi,
I am positive about the following situation, but I can't find any concrete answer on the Web. Can anyone confirm this ?
In template-haskell-2.7.0, the following quote
[t| () |]
appears as a (ConT name), where "name" is the name for unit. However, in template-haskell-2.8.0, the same quote appears as (TupleT 0).
Is this the expected behaviour ?
Thanks, Jose
-- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München
Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
adam vogt -
Jose A. Lopes -
Richard Eisenberg