Re: Xtract with hugs and Haskell implementation inconsistency
| -From ParseSTXml.hs
| #define PARSEARG(tok) P (\st inp - case inp of { \
| ((p,tok n):ts) - [(n,st,ts)]; \
| ts - [] } )
| name :: Parser SymTab Token Name
| name = PARSEARG(TokName)
|
| string, freetext :: Parser SymTab Token String
| string = PARSEARG(TokName)
| freetext = PARSEARG(TokFreeText)
| ---
|
| Think ABSTRACTIONS and MONADS. Hows about
|
| name :: Parser SymTabs Token Name
| name = do
| (_,TokName n) - item
| return n
| string :: Parser SymTabs Token String
| string = do
| (_,TokName n) - item
| return n
| freetext :: Parser SymTabs Token String
| freetext = do
| (_,TokFreeText n) - item
| return n
Looks good. Now why didn't I think of that? I suppose I'm not yet
used to the fact that a stmt in a do-block can fail cleanly (i.e.
pattern-binding failure leads to a call of `fail', which is this case
is conveniently []).
| Neat, clean and Haskell 98.
Indeed. Thanks.
Regards,
Malcolm
Re: Xtract with hugs and Haskell implementation inconsistency
3. Inadequacy of Haskell
There are a few places where MW relies on the preprocessor rather than
Haskell. Xtract has this code:
-From ParseSTXml.hs
#define PARSEARG(tok) P (\st inp - case inp of { \
((p,tok n):ts) - [(n,st,ts)]; \
ts - [] } )
name :: Parser SymTab Token Name
name = PARSEARG(TokName)
string, freetext :: Parser SymTab Token String
string = PARSEARG(TokName)
freetext = PARSEARG(TokFreeText)
---
Is there clean a way of achieving the same functionality
without relying on the preprocessor?
Think ABSTRACTIONS and MONADS. Hows about
name :: Parser SymTabs Token Name
name = do
(_,TokName n) - item
return n
string :: Parser SymTabs Token String
string = do
(_,TokName n) - item
return n
freetext :: Parser SymTabs Token String
freetext = do
(_,TokFreeText n) - item
return n
Neat, clean and Haskell 98.
Andy Gill
RE: Xtract with hugs and Haskell implementation inconsistency
S. Alexander Jacobson [EMAIL PROTECTED] writes:
I am trying to get Malcolm Wallace's Xtract code to run with
Hugs and have noticed a few inconsistencies between whatever
compiler he is using and hugs...
Great - I'd encourage others to share their experiences of trying to
work with multiple Haskell systems. Cross-system portability
Report compliance is not something that's at the very top of a
Haskell system implementor's checklist (i.e., give them a helping hand.)
2. Allowing use of qualified names without importing qualified
MW's compiler allows use of Prelude.elem without qualified import of
the prelude. Hugs does not like that. I think Hugs is
right, but I am not sure which is "correct".
NHC is right, but using left-of-centre features of the module system
is not something I would recommend if you want your code to work
with Hugs.
3. Inadequacy of Haskell
There are a few places where MW relies on the preprocessor rather than
Haskell. Xtract has this code:
-From ParseSTXml.hs
#define PARSEARG(tok) P (\st inp - case inp of { \
((p,tok n):ts) - [(n,st,ts)]; \
ts - [] } )
name :: Parser SymTab Token Name
name = PARSEARG(TokName)
string, freetext :: Parser SymTab Token String
string = PARSEARG(TokName)
freetext = PARSEARG(TokFreeText)
---
Is there clean a way of achieving the same functionality
without relying on the preprocessor?
Your mileage may vary, but I'd probably do something like
this here:
mbParse :: (tok - Maybe a) - Parser state tok a
mbParse matcher = P $ \ st inp -
case inp of
((_,tok):ts) | Maybe.isJust mb_v - [(v, st, ts)]
where
mb_v = matcher tok
(Just v) = mb_v
_ - []
name = mbParse deTok where deTok (TokName x) = Just x ; deTok _ =
Nothing
freetext = mbParse deTok where deTok (TokFreeText x) = Just x ; deTok _ =
Nothing
string = name
If H98 had pattern guards, mbParse could have been expressed
with less effort,
mbParse matcher = P $ \ st inp -
case inp of
((_,tok):ts) | (Just v) - matcher tok - [(v,st,ts)]
_ - []
--sigbjorn
Xtract with hugs and Haskell implementation inconsistency
I am trying to get Malcolm Wallace's Xtract code to run with Hugs and have
noticed a few inconsistencies between whatever compiler he is using and
hugs...
1. Where `maybe` is exported
His compiler does not export `maybe` from the Maybe library but Hugs
does. The report says that Maybe should be exported from both.
I think the report is wrong and that `maybe` should only be exported from
Maybe. In any case, Hugs correctly implements H98 and his compiler does
not.
(MW, you need to hide maybe in ParseSTXml.hs ParseSTHtml.hs and
PPSTXmlNew.hs)
2. Allowing use of qualified names without importing qualified
MW's compiler allows use of Prelude.elem without qualified import of
the prelude. Hugs does not like that. I think Hugs is right, but I am
not sure which is "correct".
(MW, the offending line is in Combinators.hs on line 169)
3. Inadequacy of Haskell
There are a few places where MW relies on the preprocessor rather than
Haskell. Xtract has this code:
-From ParseSTXml.hs
#define PARSEARG(tok) P (\st inp - case inp of { \
((p,tok n):ts) - [(n,st,ts)]; \
ts - [] } )
name :: Parser SymTab Token Name
name = PARSEARG(TokName)
string, freetext :: Parser SymTab Token String
string = PARSEARG(TokName)
freetext = PARSEARG(TokFreeText)
---
Is there clean a way of achieving the same functionality without relying
on the preprocessor?
-Alex-
PS If you want to use HUGS to test, you need to pass HUGS a preprocessor:
runhugs +98 -F"python hpp.py" XTract.hs
Here is a short preprocessor in Python:
---hpp.py-
import sys,string,os;
cpp = 'gcc -E -xc -traditional -D__HASKELL_98__ '+sys.argv[1];
for line in os.popen(cpp).readlines()[1:]:
if line: print line[:-1];
___
S. Alexander Jacobson Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop
