CTFE of yl2x() and other intrinsics
I thought that the compiler could evaluate all intrinsics at compile time, but this doesn't seem to be the case for std.math.yl2x(). Is my assumption wrong, or is this a bug that should be reported? -Lars
Re: CTFE of yl2x() and other intrinsics
On 15/11/2010 11:00, Lars T. Kyllingstad wrote: I thought that the compiler could evaluate all intrinsics at compile time, but this doesn't seem to be the case for std.math.yl2x(). Is my assumption wrong, or is this a bug that should be reported? -Lars Looks like it's not implemented because yl2x isn't in DMC. Dam and I thought it would be an easy one! Still I'll have a play with inline asm and see if it'll work. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
explore current scope, or other hack
Hello,
Is there a way to explore the current scope, meaning the set of currently
defined symbols?
(Equivalent of python's vars(), locals(), globals().)
I have 2 use cases for this:
1. name objects automatically
I need some objects to know their name (as field on themselves). the only
solution I can else imagine is for the user write:
x = ...;
x.name = "x";
I hope you agree this is more than stupid ;-) Exploring the scope would allow
providing a tool func that does this automatically, once all objects are known.
Is there an alternative I overlook?
2. some tool like format()
Say I wish like to define an alternative approach to variable strings, like
s = VarString("Hello, 'userName'!");
This requires getting variable values at runtime, I guess, meaning explore the
scope. How do format and writefln work (pointer welcome)? Is there an
alternative?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: CTFE of yl2x() and other intrinsics
On 15/11/2010 12:12, div0 wrote: On 15/11/2010 11:00, Lars T. Kyllingstad wrote: I thought that the compiler could evaluate all intrinsics at compile time, but this doesn't seem to be the case for std.math.yl2x(). Is my assumption wrong, or is this a bug that should be reported? -Lars Looks like it's not implemented because yl2x isn't in DMC. Dam and I thought it would be an easy one! Still I'll have a play with inline asm and see if it'll work. Sweet, I got it working! I'll submit a patch to bugzilla in a bit. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: CTFE of yl2x() and other intrinsics
On Mon, 15 Nov 2010 13:03:03 +, div0 wrote: > On 15/11/2010 12:12, div0 wrote: >> On 15/11/2010 11:00, Lars T. Kyllingstad wrote: >>> I thought that the compiler could evaluate all intrinsics at compile >>> time, but this doesn't seem to be the case for std.math.yl2x(). Is my >>> assumption wrong, or is this a bug that should be reported? >>> >>> -Lars >> >> Looks like it's not implemented because yl2x isn't in DMC. Dam and I >> thought it would be an easy one! >> >> Still I'll have a play with inline asm and see if it'll work. >> >> > Sweet, I got it working! I'll submit a patch to bugzilla in a bit. Cool! :) -Lars
effect of a label on following block
Hello.
Consider this code
void main()
{
l:
{
int v;
}
v = 5; // ok, v is defined
}
As I understand from D's grammar this behaviour is not a bug as
LabeledStatement:
Identifier : NoScopeStatement
and NoScopeStatement in turn takes BlockStatement without creating new
scope.
It looks very unnatural for me though. Especially when label goes before
ThenStatement
if(1)
l1:{
int v;
}
v = 5;
it works as above, yet label after 'while'
while(1)
l1:{
int v;
}
v = 5; // error, v is undefined
has no such effect, even if ThenStatement is just another ScopeStatement.
I don't understand this difference. Any rationale behind this?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: segfault
On Sat, 13 Nov 2010 15:57:50 -0500, spir wrote:
On Fri, 12 Nov 2010 08:03:26 -0500
"Steven Schveighoffer" wrote:
Essentially, if you change your line above to:
this.patterns = patterns.dup;
Works, but I don't understand why: isn't the duplicate also allocated on
the stack? I mean, dup is supposed to just duplicate, isn't it? what
does it give to the new structure that the original one hasn't? I
thought I would have to do for instance:
ints[] x;
void f(int[] ints...) {
x.length = ints.length; // allocate new area on the heap
x[] = ints[]; // copy elements in there
}
When doing this:
arr1 = arr2;
It copies the reference to the data, not the data itself. Since the data
is on the stack, you are still pointing at the stack
arr1 = arr2.dup;
copies the data itself, then returns a reference to the new data. The
reference is stored wherever the reference is stored. In your case, the
reference this.patterns is stored in the class, so it's also stored on the
heap.
I hope this is clearer.
-Steve
Re: Is there a way to forward-declare interfaces to avoid module interdependencies?
On Sun, 14 Nov 2010 05:28:29 -0500, Per Ångström wrote: On 2010-11-11 17:21, Steven Schveighoffer wrote: First, you can't forward-declare classes in one file that are defined in another file, instead of importing. The reason is because in D, the module is the namespace that the class is declared in. So for instance, when you define IStudent in IStudent.d, it's full name is IStudent.Istudent if you did something like: interface IStudent; in ITeacher.d, then it's full name would be ITeacher.IStudent, not IStudent.IStudent. So it's not the same. I get it now. So there is no way out for me: I have to import any module whose interfaces I use, even though I'm only referring to their names. Second, you are only having fits about forward declarations because you aren't used to it :) Actually, I would say it's the other way around: I am used to them (being able to refer to an unknown identifier as long as I don't use it) in C and C++ and find it lacking in D. I said that wrong, I meant forward *references* not forward *declrations*. That is, referring to things that aren't declared yet. > That being said, D has had many forward reference bugs (I believe there are still a few active ones), so it doesn't always *just work*. Plus there's the issue of circular imports causing code to fail at runtime due to module construction dependencies. But in any case, you shouldn't worry about it, just import away, and the compiler can take it. But I still think cutting down on intermodule dependencies is a good thing, for ease of comprehension and unit testing. Fortunately, by separating interface and implementation, one can at least keep the implementation modules free from interdependencies. It's not perfect but it's not a complete mess either. It is one way to keep dependencies down. And less dependencies means less coupling, meaning importing one module doesn't make you import (and include the code for) many other modules. The compiler isn't yet mature enough to trim out some code that is never used. -Steve
Re: effect of a label on following block
My gut feeling is that the if statement's behavior is wrong and the while statement's is correct, but it could go either way. No need for a rationale for what can be adequately explained as a compiler bug (this is a downside of dmd - it trains you to think like this) It is curious, though, as it looks like both bodies get parsed the same way. Not sure what's going on. Please to report to bugzilla
Re: effect of a label on following block
poking around a little more and I really don't know what's going on.
fun piece of trivia though: while loops get rewritten to for loops, so
for(;;) l1 {
int v;
}
v = 4;
exhibits the same behavior as the while loop.
do loops seem to do the same thing as the if statement
On 11/15/2010 10:34 AM, Ellery Newcomer wrote:
My gut feeling is that the if statement's behavior is wrong and the
while statement's is correct, but it could go either way.
No need for a rationale for what can be adequately explained as a
compiler bug (this is a downside of dmd - it trains you to think like
this) It is curious, though, as it looks like both bodies get parsed the
same way. Not sure what's going on.
Please to report to bugzilla
Re: effect of a label on following block
Ellery Newcomer: > No need for a rationale for what can be adequately explained as a > compiler bug (this is a downside of dmd - it trains you to think like > this) Or: Any sufficiently incomprehensible behaviour is indistinguishable from a DMD compiler bug :-) Bye, bearophile
Re: explore current scope, or other hack
spir: > 1. name objects automatically > I need some objects to know their name (as field on themselves). the only > solution I can else imagine is for the user write: > x = ...; > x.name = "x"; What if you have two or more references to the same object? Regarding your generic question, I'd like DMD to have more static introspection, for for now ... Bye, bearophile
==, is
quick question: are the following rewrites always valid: e1 != e2 -> !(e1 == e2) e1 !is e2-> !(e1 is e2) e1 !in e2-> !(e1 in e2) ?
Re: ==, is
On Mon, 15 Nov 2010 14:06:34 -0500, Ellery Newcomer wrote: quick question: are the following rewrites always valid: e1 != e2 -> !(e1 == e2) e1 !is e2-> !(e1 is e2) e1 !in e2-> !(e1 in e2) I believe this is in fact what the compiler does (rewriting). -Steve
Re: effect of a label on following block
On 15/11/2010 16:45, Ellery Newcomer wrote:
poking around a little more and I really don't know what's going on.
fun piece of trivia though: while loops get rewritten to for loops, so
for(;;) l1 {
int v;
}
v = 4;
exhibits the same behavior as the while loop.
do loops seem to do the same thing as the if statement
Eugh, that's fugly.
Labels shouldn't be allowed between keyword statements and their blocks,
it makes no sense in any circumstance.
--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Re: ==, is
parser definitely does it for !in, but it doesn't for the other ones, and I didn't want to go digging all over the place for it. Also, spec says yes for !in, but is silent for the other ones On 11/15/2010 01:08 PM, Steven Schveighoffer wrote: On Mon, 15 Nov 2010 14:06:34 -0500, Ellery Newcomer wrote: quick question: are the following rewrites always valid: e1 != e2 -> !(e1 == e2) e1 !is e2 -> !(e1 is e2) e1 !in e2 -> !(e1 in e2) I believe this is in fact what the compiler does (rewriting). -Steve
Re: ==, is
On Mon, 15 Nov 2010 14:36:33 -0500, Ellery Newcomer wrote: parser definitely does it for !in, but it doesn't for the other ones, and I didn't want to go digging all over the place for it. Also, spec says yes for !in, but is silent for the other ones http://www.digitalmars.com/d/2.0/operatoroverloading.html#equals As far as is, it doesn't explicitly say that rewriting is done, but, it does spell out that to do the opposite, use !is. Maybe the spec should be updated to explicitly say x !is y is the same as !(x is y). http://www.digitalmars.com/d/2.0/expression.html#IdentityExpression On 11/15/2010 01:08 PM, Steven Schveighoffer wrote: On Mon, 15 Nov 2010 14:06:34 -0500, Ellery Newcomer wrote: quick question: are the following rewrites always valid: e1 != e2 -> !(e1 == e2) e1 !is e2 -> !(e1 is e2) e1 !in e2 -> !(e1 in e2) I believe this is in fact what the compiler does (rewriting). -Steve
Re: explore current scope, or other hack
On Mon, 15 Nov 2010 12:44:24 -0500
bearophile wrote:
> spir:
>
> > 1. name objects automatically
> > I need some objects to know their name (as field on themselves). the only
> > solution I can else imagine is for the user write:
> > x = ...;
> > x.name = "x";
>
> What if you have two or more references to the same object?
I'm not sure what you mean. The said objects are patterns (instances of a
Pattern class hierachy). And indeed, they are multiply referenced (that's
precisely the point of writing a grammar ;-).
Their names are used everywhere:
* stand-alone pattern output
* super-pattern output (subpatterns are replaced by their name, else output
explodes) eg
operand: symbol|number
* inside nodes they generate (eg allow discrimination between choices)
* error output ("expected operand at position...")
* result output for testing
> Regarding your generic question, I'd like DMD to have more static
> introspection, for for now ...
Dynamic introspection would do the job for me, I guess. In python, would be
like (untested):
def namePatterns (scope = var()):
for (name,obj) in scope:
if isinstance(obj, Pattern):
obj.name = name
Don't know how static would help better.
Any idea how else to write somethink analog to format()?
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: ==, is
On Monday 15 November 2010 11:47:11 Steven Schveighoffer wrote: > On Mon, 15 Nov 2010 14:36:33 -0500, Ellery Newcomer > > wrote: > > parser definitely does it for !in, but it doesn't for the other ones, > > and I didn't want to go digging all over the place for it. > > > > Also, spec says yes for !in, but is silent for the other ones > > http://www.digitalmars.com/d/2.0/operatoroverloading.html#equals > > As far as is, it doesn't explicitly say that rewriting is done, but, it > does spell out that to do the opposite, use !is. Maybe the spec should be > updated to explicitly say x !is y is the same as !(x is y). Honestly, I don't see how it could be otherwise. I would have just assumed that they were identical. - Jonathan M Davis
Re: explore current scope, or other hack
spir wrote:
On Mon, 15 Nov 2010 12:44:24 -0500
bearophile wrote:
spir:
> 1. name objects automatically
> I need some objects to know their name (as field on themselves). the
only solution I can else imagine is for the user write:
>x = ...;
>x.name = "x";
What if you have two or more references to the same object?
I'm not sure what you mean. The said objects are patterns (instances of
a Pattern class hierachy). And indeed, they are multiply referenced
(that's precisely the point of writing a grammar ;-).
The two (or more) references could not be referred to by the same name.
Sure, they would point to the same object, but how could the object know
whether its functions were called from x or from y? While you may use the
same name everywhere for the same object, the x in function foo is a
different one from that in function bar, not to mention across modules.
If I may come with a solution, it would be something like this:
mixin template New!( T, string name ) {
mixin( "auto " ~ name ~ " = new T(\"" ~ name ~ "\")");
}
--
Simen
Re: ==, is
a while ago, I assumed that e1 += e2 gets rewritten as e1 = e1 + e2 Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed arguments On 11/15/2010 02:35 PM, Jonathan M Davis wrote: As far as is, it doesn't explicitly say that rewriting is done, but, it does spell out that to do the opposite, use !is. Maybe the spec should be updated to explicitly say x !is y is the same as !(x is y). Honestly, I don't see how it could be otherwise. I would have just assumed that they were identical. - Jonathan M Davis
Re: ==, is
On Monday 15 November 2010 12:40:43 Ellery Newcomer wrote: > a while ago, I assumed that > > e1 += e2 > > gets rewritten as > > e1 = e1 + e2 > > Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed > arguments Well, that would potentially be two different set of operator overloads (+= vs = and/or +), so they definitely can't act the same, though I can see why you'd think so at first glance. None of the operators that you specificy have that problem. Still, it pays to be careful. It can be easy to make erroneous assumptions. - Jonathan M Davis
Re: ==, is
On Mon, 15 Nov 2010 15:40:43 -0500, Ellery Newcomer wrote: a while ago, I assumed that e1 += e2 gets rewritten as e1 = e1 + e2 Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed arguments I understand the care taken, but the spec gives reasons to believe otherwise: There is opAdd and opAddAssign There are opEquals and opIn, but no opNotEquals and opNotIn. If you can override the operators independently, naturally you should not expect that one is rewritten, otherwise why have the independent operators? Likewise, if there is no overload for the opposite, then it must be a rewriting function. 'is' is sorta different because you can't override it either way. -Steve
