Batch compilation fails for csv.pure

[GoogleCodeExporter]

When compiling a module that imports csv:

asys$> pure -c asys_ledger_report.pure
csv.pure, line 165: non-const value in const definition: #<pointer 0xa671f80>
csv.pure, line 166: non-const value in const definition: #<pointer 0xa6fe9f0>
csv.pure, line 167: non-const value in const definition: #<pointer 0xb18f018>
** Your program contains one or more constants referring to run time
data such as pointers and closures. Changing the offending constants
to variables should fix this. *

This is from a fresh update/make/install version of pure-csv.

Original issue reported on code.google.com by p.summer...@gmail.com on 8 Jul 2010 at 11:37

[GoogleCodeExporter]

The dialect function in csv.pure returns a pointer value which currently isn't 
allowed in const definitions if they are batch-compiled. See 
http://pure-lang.googlecode.com/svn/docs/pure.html#batch-compilation for an 
explanation. Specifically: "Also, constant values in a batch-compiled script 
must be real constants, run time data such as pointers (other than the null 
pointer) and local functions are not permitted. (If necessary, you can bind 
such values to variables instead, then they will work fine even in a 
batch-compiled program.)"

The fix would be to turn those definitions into ordinary variable definitions 
so that they can be batch-compiled. Another option would be to make the 
'dialect' function return an ordinary Pure value instead; does it really have 
to be an opaque pointer?

(I could also change the batch compiler so that it emits ordinary variable 
initialization code for such definitions and merely warns about such situations 
instead of spitting out an error message. I'm not sure whether that is the 
right solution, though, so we should first discuss this on the mailing list.)

I'm assigning this to Eddie Rucker who maintains this module.

Original comment by aggraef@gmail.com on 9 Jul 2010 at 7:29

• Changed state: New

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Fixed r3488.

Original comment by ruckerrobert48@gmail.com on 9 Jul 2010 at 6:41

[GoogleCodeExporter]

See if the new module compiles

Original comment by ruckerrobert48@gmail.com on 9 Jul 2010 at 9:02

• Changed state: Fixed

[GoogleCodeExporter]

Works great. I learned a new "Let trick" in the bargain. Thanks.

Original comment by p.summer...@gmail.com on 10 Jul 2010 at 4:04

[GoogleCodeExporter]

I should maybe add some explanation why this happens. Suppose you have a 
definition which sets a variable to a pointer value, like:

let x = malloc 10;

If you batch-compile this program, it will work ok, because the variable 
binding is actually performed at runtime, i.e., the code for 'malloc 10' is 
executed again when the batch-compiled program is run.

In contrast, if you have the same as a constant definition:

const x = malloc 10;

A const definition like this gets substituted away at compile time. This works 
ok if the script is run in the interpreter, since the original malloced pointer 
is still available. However, if you batch-compile the script, the 'malloc' is 
only performed at compile time, giving you a literal pointer value that has no 
meaning when running the batch-compiled program later, since the original 
malloced pointer is long gone (it only has a meaning while the script is being 
compiled). So if you used the pointer value in the batch-compiled program, it 
would point nowhere and would most likely give a segfault. To prevent that, the 
batch compiler complains about any kind of const object which can only be 
created at runtime.

Maybe the compiler should warn about such bogus constant values even if the 
script is only run in the interpreter, so that you don't run into nasty 
surprises when you batch-compile a script later. I'll have to think about this.

Original comment by aggraef@gmail.com on 10 Jul 2010 at 6:13

• Changed state: Verified