View mode: basic / threaded / horizontal-split · Log in · Help
January 29, 2012
Char & the Extended ascii set
It there any support for the extended ascii characters? (128-255). I understand unicode is important, however working with some data and programs that don't support those, I am getting a problem that the program causes an exception because it isn't valid utf-8. Do I have to handle it all as bytes/ubytes? If I do then I lose out on many char specific functions. Alternatively I can rely on the C functions, but I want to avoid using them if I can.

Example: note the raw data below, being 39 vs -110

this._ID = "SPEL_wulfharth's cups"
rhs._ID  = "SPEL_wulfharthâ–’s cups"

this._ID = [83, 80, 69, 76, 95, 119, 117, 108, 102, 104, 97, 114, 116, 104, 39, 115, 32, 99, 117, 112, 115, 0]
rhs._ID  = [83, 80, 69, 76, 95, 119, 117, 108, 102, 104, 97, 114, 116, 104, -110, 115, 32, 99, 117, 112, 115, 0]


I have compiled and made a table for the appropriate conversions to proper unicode, which you can then use in reverse to get it back to it's previous state. However I'm not sure.

//referenced from http://ascii-table.com/ascii-extended-pc-list.php
wchar[128] convertAsciiExtended = [
	0x00C7, 0x00FC, 0x00E9, 0x00E2, 0x00E4, 0x00E0, 0x00E5, 0x00E7,
	0x00EA, 0x00EB, 0x00E8, 0x00EF, 0x00EE, 0x00EC, 0x00C4, 0x00C5,
	0x00C9, 0x00E6, 0x00C6, 0x00F4, 0x00F6, 0x00F2, 0x00FB, 0x00F9,
	0x00FF, 0x00D6, 0x00DC, 0x00A2, 0x00A3, 0x00A5, 0x20A7, 0x0192,
	0x00E1, 0x00ED, 0x00F3, 0x00FA, 0x00F1, 0x00D1, 0x00AA, 0x00BA,
	0x00BF, 0x2310, 0x00AC, 0x00BD, 0x00BC, 0x00A1, 0x00AB, 0x00BB,
	0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x2561, 0x2562, 0x2556,
	0x2555, 0x2563, 0x2551, 0x2557, 0x255D, 0x255C, 0x255B, 0x2510,
	0x2514, 0x2534, 0x252C, 0x251C, 0x2500, 0x253C, 0x255E, 0x255F,
	0x255A, 0x2554, 0x2569, 0x2566, 0x2560, 0x2550, 0x256C, 0x2567,
	0x2568, 0x2564, 0x2565, 0x2559, 0x2558, 0x2552, 0x2553, 0x256B,
	0x256A, 0x2518, 0x250C, 0x2588, 0x2584, 0x258C, 0x2590, 0x2580,
	0x03B1, 0x00DF, 0x0393, 0x03C0, 0x03A3, 0x03C3, 0x00B5, 0x03C4,
	0x03A6, 0x0398, 0x03A9, 0x03B4, 0x221E, 0x03C6, 0x03B5, 0x2229,
	0x2261, 0x00B1, 0x2265, 0x2264, 0x2320, 0x2321, 0x00F7, 0x2248,
	0x00B0, 0x2219, 0x00B7, 0x221A, 0x207F, 0x00B2, 0x25A0, 0x00A0];
January 29, 2012
Pure Contract bug? (unnecessarily strict)
Maybe someone's brought this up, but i seem to have the compiler complaining to me that my function isn't 'pure' by calling a non-pure function, specifically to!string().

However the unpure functions are only accessed in the contracts, and only if it failed seriously. Is this already planned to be worked on? I thought i read the contracts shouldn't be considered as part of it since they are totally excluded during the release builds (and shouldn't have any side effects). 

Error: pure function 'offset' cannot call impure function 'to'


	@property const pure int offset(int field)
	in {
		assert(field < notes.length);
	}
	out (o) {
		assert(o >= 0, "Negative value! Check structure:" ~ name ~ "\nReq:" ~ requ ~ "\nsize:" ~ to!string(size) ~ "\n");
	}
	body { ... }
January 29, 2012
Re: Pure Contract bug? (unnecessarily strict)
The way to avoid purity checking is to put code in a debug {} statement. 
I'm not aware of any plans to disable purity checking for contracts.
January 30, 2012
Re: Pure Contract bug? (unnecessarily strict)
On Sunday, 29 January 2012 at 06:22:26 UTC, Era Scarecrow wrote:
> Maybe someone's brought this up, but i seem to have the 
> compiler complaining to me that my function isn't 'pure' by 
> calling a non-pure function, specifically to!string().

I don't see why this couldn't be done, not only does it get not 
exist in release, it shouldn't be changing variables in 
non-release. As mentioned there is a hole for debug code.

Report it:

http://d.puremagic.com/issues/

and we'll see what happens with that.
January 30, 2012
Re: Pure Contract bug? (unnecessarily strict)
> I don't see why this couldn't be done, not only does it get not 
> exist in release, it shouldn't be changing variables in 
> non-release. As mentioned there is a hole for debug code.
>
> Report it:
>
> http://d.puremagic.com/issues/
>
> and we'll see what happens with that.

Reported; Minor priority (Won't break code)

http://d.puremagic.com/issues/show_bug.cgi?id=7401
February 04, 2012
Re: Pure Contract bug?
If I'm reading how pure works, my original example was likely 
broken as it was part of a struct that returned a state value 
(although the contract constraints meaning was still valid).

So is pure fully usable or is it not yet ready? Makes me think 
that pure should have further constraints/limits, if it's part of 
a class/struct it should either require or automatically be 
static (no state access) and if it accesses any global variables, 
they must be immutable.

int x;
immutable int y = 10;

pure int test(int z) {
	int t = z + x;		//should error
	t += y;			//fine, globally immutable.
	return t;
}

struct X {
	int s_x;
	static int s_st_x;
	immutable int s_y;
	static immutable int s_st_y = 100;

	pure int test(int z) {
		int t = x + z;	//should error
		t += s_x;	//error, mutable external state
		t += s_st_x;	//error, mutable external state (static)
		t += s_y;	//error, not statically immutable, mathematically 
impure.


		t += y;		//fine, global immutable
		t += s_st_y; 	//fine, statically immutable.
		return t;
	}
}

Errors I get currently are these:

test(int):
Error: pure function 'test' cannot access mutable static data 'x'

X.test(int):
Error: pure function 'test' cannot access mutable static data 'x'
Error: pure function 'test' cannot access mutable static data 
's_st_x'


If I understand pure correctly, I should get two more, for s_x 
and s_y.
February 04, 2012
Re: Pure Contract bug?
On 02/04/2012 08:51 PM, Era Scarecrow wrote:
> If I'm reading how pure works, my original example was likely broken as
> it was part of a struct that returned a state value (although the
> contract constraints meaning was still valid).
>
> So is pure fully usable or is it not yet ready? Makes me think that pure
> should have further constraints/limits, if it's part of a class/struct
> it should either require or automatically be static (no state access)
> and if it accesses any global variables, they must be immutable.
>
> int x;
> immutable int y = 10;
>
> pure int test(int z) {
> int t = z + x; //should error
> t += y; //fine, globally immutable.
> return t;
> }
>
> struct X {
> int s_x;
> static int s_st_x;
> immutable int s_y;
> static immutable int s_st_y = 100;
>
> pure int test(int z) {
> int t = x + z; //should error
> t += s_x; //error, mutable external state
> t += s_st_x; //error, mutable external state (static)
> t += s_y; //error, not statically immutable, mathematically impure.
>
>
> t += y; //fine, global immutable
> t += s_st_y; //fine, statically immutable.
> return t;
> }
> }
>
> Errors I get currently are these:
>
> test(int):
> Error: pure function 'test' cannot access mutable static data 'x'
>
> X.test(int):
> Error: pure function 'test' cannot access mutable static data 'x'
> Error: pure function 'test' cannot access mutable static data 's_st_x'
>
>
> If I understand pure correctly, I should get two more, for s_x and s_y.

Pure does not imply const in D. If you want stronger guarantees, just 
turn 'test' into a const (or immutable) member function. In D, a 
function can change anything that is mutable and reachable through its 
parameters, this includes the implicit 'this' pointer. The reason for 
this design is simple: There is no need to be overly restrictive, 
because the additional restrictions are already trivially expressed in 
the type system. Furthermore, any mutation of a parameter can be turned 
into a less efficient protocol that only requires a const pure function, 
so there would be no gain if pure implied const, it would only make pure 
less useful.

void foo(int* x)pure{*x+=2;}
int bar(const(int)*x)pure{return *x+2;}

void main() pure{
    int x, y;
    foo(&x);     // those two lines have
    y = bar(&y); // equivalent functionality!
}
February 04, 2012
Re: Pure Contract bug?
> Pure does not imply const in D. If you want stronger 
> guarantees, just turn 'test' into a const (or immutable) member 
> function. In D, a function can change anything that is mutable 
> and reachable through its parameters, this includes the 
> implicit 'this' pointer. The reason for this design is simple: 
> There is no need to be overly restrictive, because the 
> additional restrictions are already trivially expressed in the 
> type system. Furthermore, any mutation of a parameter can be 
> turned into a less efficient protocol that only requires a 
> const pure function, so there would be no gain if pure implied 
> const, it would only make pure less useful.
>
> void foo(int* x)pure{*x+=2;}
> int bar(const(int)*x)pure{return *x+2;}
>
> void main() pure{
> int x, y;
> foo(&x);     // those two lines have
> y = bar(&y); // equivalent functionality!
> }

Only external data I was implying, that was not based off the 
input arguments. Examples in the book refer that calculating Pi, 
or the square root of 2 is a constant and will always result in 
the same output, regardless the situation.

Quote TDPL pg 165:
"In D, a function is considered pure if returning a result is 
it's only  effect and the result depends only on the function's 
arguments.

Also, pure functions can run literally in parallel because they 
don't interact with the rest of the program except through their 
result."

So... If we take a struct.

struct X {
   int i;
   pure int squaredPlus(int x) {
       return x*x + i
   }
   alias squaredPlus sqp;
}

   X st(15);

   writeln(st.sqp(0));  //15
   int i1 = st.sqp(10); st.i++;
   int i2 = st.sqp(10); st.i++;
   int i3 = st.sqp(10); st.i++;
   int i4 = st.sqp(10); st.i++;

   assert(i1 == 100); //pass/fail?
   assert(i2 == 101); //pass/fail?
   assert(i3 == 102); //pass/fail?
   assert(i4 == 103); //pass/fail?
   assert(s1.i == 104); //probably pass.

If the compiler can reorder or run these in parallel (for 
optimization) or caches the result the first time (since it's 
suppose to always return the same value), what's correct in this 
case? This afterall isn't synchronized, even if it was, what's 
correct behavior? Am I wrong in understanding this?
February 04, 2012
Re: Pure Contract bug?
On 02/04/2012 11:04 PM, Era Scarecrow wrote:
>> Pure does not imply const in D. If you want stronger guarantees, just
>> turn 'test' into a const (or immutable) member function. In D, a
>> function can change anything that is mutable and reachable through its
>> parameters, this includes the implicit 'this' pointer. The reason for
>> this design is simple: There is no need to be overly restrictive,
>> because the additional restrictions are already trivially expressed in
>> the type system. Furthermore, any mutation of a parameter can be
>> turned into a less efficient protocol that only requires a const pure
>> function, so there would be no gain if pure implied const, it would
>> only make pure less useful.
>>
>> void foo(int* x)pure{*x+=2;}
>> int bar(const(int)*x)pure{return *x+2;}
>>
>> void main() pure{
>> int x, y;
>> foo(&x); // those two lines have
>> y = bar(&y); // equivalent functionality!
>> }
>
> Only external data I was implying, that was not based off the input
> arguments. Examples in the book refer that calculating Pi, or the square
> root of 2 is a constant and will always result in the same output,
> regardless the situation.
>
> Quote TDPL pg 165:
> "In D, a function is considered pure if returning a result is it's only
> effect and the result depends only on the function's arguments.
>
> Also, pure functions can run literally in parallel because they don't
> interact with the rest of the program except through their result."

Probably the restriction was lifted after TDPL was out.
>
> So... If we take a struct.
>
> struct X {
> int i;
> pure int squaredPlus(int x) {
> return x*x + i
> }
> alias squaredPlus sqp;
> }
>
> X st(15);
>
> writeln(st.sqp(0)); //15
> int i1 = st.sqp(10); st.i++;
> int i2 = st.sqp(10); st.i++;
> int i3 = st.sqp(10); st.i++;
> int i4 = st.sqp(10); st.i++;
>
> assert(i1 == 100); //pass/fail?
> assert(i2 == 101); //pass/fail?
> assert(i3 == 102); //pass/fail?
> assert(i4 == 103); //pass/fail?
> assert(s1.i == 104); //probably pass.
>
> If the compiler can reorder or run these in parallel (for optimization)
> or caches the result the first time (since it's suppose to always return
> the same value), what's correct in this case? This afterall isn't
> synchronized, even if it was, what's correct behavior? Am I wrong in
> understanding this?

Yes. The compiler will only reorder/run in parallel/optimize if it is 
safe (not changing execution semantics). Pure can be used to prove that 
certain optimizations are safe. If a pure function only takes const or 
immutable arguments, the compiler has more guarantees and can do more 
things. If a pure function takes mutable arguments, it can be used as a 
component of other pure functions (important!), but the kind of 
optimizations that can be performed directly on them are a lot more limited.

'Pure' means that the behavior of the function does not change between 
invocations with the same/equivalent arguments. This can include 
mutating actions on the arguments, if those are typed mutable.
February 04, 2012
Re: Pure Contract bug?
> Probably the restriction was lifted after TDPL was out.


> Yes. The compiler will only reorder/run in parallel/optimize if 
> it is safe (not changing execution semantics). Pure can be used 
> to prove that certain optimizations are safe. If a pure 
> function only takes const or immutable arguments, the compiler 
> has more guarantees and can do more things. If a pure function 
> takes mutable arguments, it can be used as a component of other 
> pure functions (important!), but the kind of optimizations that 
> can be performed directly on them are a lot more limited.
>
> 'Pure' means that the behavior of the function does not change 
> between invocations with the same/equivalent arguments. This 
> can include mutating actions on the arguments, if those are 
> typed mutable.


Even if you changed the signature of the pure function to 'pure 
int squaredPlus(immutable int);' you'd have the same problem; 
Because the int argument it receives is a copy so it won't matter 
if it was mutable or not. (If it were an object, then it would be 
more enforced).

I'll refer to the language specs to see if I can find an answer 
on this, but it feels wrong allowing access to 'this' on mutable 
data; I thought it could only mutate it's own data in regards to 
local variables and arguments it owned.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home