after a few more changes, the build goes through, and i can load
my simple curry program into pakcs. there are still some bugs in
the process, and some things don't work (that is one reason for
some of the debug output still being enabled). but it is a start.
btw, i'd still be curious to know whether pakcs' behaviour in the
last examples below is expected (see comments), and why?
hth,
claus
ps diff is attached, software versions used are:
$ uname -a
CYGWIN_NT-5.1 cr3-lt 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.4.1
$ plcon
Welcome to SWI-Prolog (Multi-threaded, Version 5.6.6)
..
$ ./patched_pakcs/bin/pakcs --version
c:/cygwin/bin/bash -xc "rm -f c:/docume~1/cr3/locals~1/temp/pakcs_main5
>>script.log 2>&1"
+ rm -f c:/docume~1/cr3/locals~1/temp/pakcs_main5
c:/cygwin/bin/bash -xc "c:/curry/patched_pakcs/update-pakcsrc >>script.log
2>&1"
+ c:/curry/patched_pakcs/update-pakcsrc
Run-time parameters passed to application: [--version]
______ __ _ _ ______ _______
| __ | / \ | | / / | ____| | _____| Portland Aachen Kiel
| | | | / /\ \ | |_/ / | | | |_____ Curry System
| |__| | / /__\ \ | _ | | | |_____ |
| ____| / ______ \ | | \ \ | |____ _____| | Version 1.8.0 (1)
|_| /_/ \_\ |_| \_\ |______| |_______| March 2007
Curry2Prolog(swi) Compiler Environment (Version of 27/03/07)
(RWTH Aachen, CAU Kiel, Portland State University)
Bug reports: mh_at_informatik.uni-kiel.de
Type ":h" for help
Prelude> :l Encap
c:/cygwin/bin/bash -xc "c:/curry/patched_pakcs/bin/parsecurry -fcy Encap
>>script.log 2>&1"
+ c:/curry/patched_pakcs/bin/parsecurry -fcy Encap
.
[., c:/curry/patched_pakcs/lib, c:/curry/patched_pakcs/lib/meta]
c:/cygwin/bin/bash -xc "rm -f c:/docume~1/cr3/locals~1/temp/pakcs_main5
>>script.log 2>&1"
+ rm -f c:/docume~1/cr3/locals~1/temp/pakcs_main5
Encap> g
Result: [0,1,0,0,1] ? ;
Result: [0,1,0,0,1] ? ;
Result: [0,1,1,0,1] ? ;
Result: [0,1,1,0,1] ? ;
Result: [0,1,0,0,1] ? ;
Result: [0,1,0,0,1] ? ;
Result: [0,1,1,0,1] ? ;
Result: [0,1,1,0,1] ? ;
No more solutions.
-- why is there a functional type expected here?
Encap> let x=1 in x
ERROR: Type error in application: 1 _G4792
*** term : 1
*** type : Int
*** is not of functional type
Encap> 1
Result: 1 ? ;
No more solutions.
-- why is the parameter of wrap evaluated here??
-- wrap g f = f g
Encap> let x free in (wrap (x=:=0?x=:=1),x)
Free variables in goal: x
Result: (wrap success,0)
Bindings:
x=0 ? ;
Result: (wrap success,1)
Bindings:
x=1 ? ;
No more solutions.
-- there should be no demand for wrap's parameter here?
Encap> let x free in wrap (x=:=0?x=:=1)
Free variables in goal: x
Result: wrap success
Bindings:
x=0 ? ;
Result: wrap success
Bindings:
x=1 ? ;
No more solutions.
-- this is more what i expected
Encap> let x free in length [wrap (x=:=0?x=:=1)]
Free variables in goal: x
Result: 1
Bindings:
x=x ? ;
No more solutions.
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Mai 09 2007 - 16:02:43 CEST