RE: THSyntax

I'm ccing Tim Sheard, who has a direct interest,
and Seth Kurtzberg and Ian Lynagh who are also trying out TH.


Here are some points about TH from Manuel:

| I have a couple of questions regarding THSyntax (if any of
| this is in the paper, just say so and I'll go and look for
| it):
| 
| * In `Lit' what is the purpose of `CrossStage String'?

I think it's now redundant.  Let's remove it until we find out it is
needed.
 
| * NB: `counter' uses `unsafePerformIO' in an unsafe way :-)
|   I'll fix that.

Ok, good.
 
| * The type of `lift' is different from the paper.  I guess
|   that's a feature.

I guess...

| * What's the point of giving three type arguments to `Match'
|   and `Clause' that are always used with the same type?
|   (IMHO just makes the types harder to read.)  Ditto for
|   `Statement'.

This is a Tim Sheard-ism.  I'll let him answer!

| * Nitpick: Wouldn't `Clause' better be called `Equation'?
| * Nitpick: In `Dec', wouldn't call `Proto' better be called
|   `Signature'?  (Or `Sig' if you want to keep it short.)
|   It's Haskell and not C after all ;-)

I think so, in both cases.  Let's see if Tim minds the change.

| * In Exp, what is `Br' and `Esc' for?

Bracket and escape (= splice).  I'm not sure they should be in THSyntax
at all.  Tim?

| * I wonder whether it is a good idea to define
| 
|     type Type = Typ           -- No need for Q here
| 
|   Doesn't the lack of Q not imply that we can't extend this
|   to explicit foralls without changing the type and breaking
|   every program using this?

That's true. The existence of Type as a distinct name is intended to let
us change to Q Typ in due course... but that will entail a bit more
monadic threading too.  I'm inclined to leave the change till we need
it.

| * I am far from convinced of the naming scheme of the
|   combinator-based types.  Stuff like Rhs/Rihs and DDt/DDot
|   may be easy to remember for the person who invented the
|   naming scheme, but be a nuisance to others.  Usually a
|   regular naming scheme (even if ugly) is easier to
|   memorise (eg, prefixing each combinator-based type with a
|   "C").

I have no objection to adopting something different.  Our idea was to
have a three/four char uniformity, but maybe it'd be better to have a
standard prefix instead.  If you'd like to propose something, do by all
means.

Simon