I stand corrected.

Chris Nicholson-Sauls Wrote:

> Julio César Carrascal Urquijo wrote:
> > Kirk McDonald wrote:
> >> Robert Fraser wrote:
> >>> Well, not even scripting languages keep names of local variables in memory at runtime...
> >>
> >> Hmm?
> >>
> >>  >>> a = 12
> >>  >>> b = 'waffles'
> >>  >>> locals()
> >> {'__builtins__': <module '__builtin__' (built-in)>, '__name__':
> >> '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
> >>  >>> "%(a)s %(b)s" % locals()
> >> '12 waffles'
> >>
> > 
> > And if I may add:
> > 
> > <?php
> > 
> > $a = 5;
> > $b = 'a';
> > $$b = 'Hello, world!';
> > echo $a;
> > 
> > ?>
> 
> And also Ruby.
> 
> # names.rb
> puts Symbol.all_symbols.inspect
> 
> 
> This will print for you an array of a few thousand symbols from the
> runtime, among them the names of many variables.  Changing the source to:
> myVar = 42
> puts Symbol.all_symbols.index(:myVar)
> 
> Gave me '1117'.  At least in Ruby each such symbol is retained exactly once, no matter how many things have that name.  (Otherwise... could you imagine the memory consumption...)
> 
> -- Chris Nicholson-Sauls

Robert Fraser wrote:
> I stand corrected.

Ok people come on.  Doesn't he have something of a point?  Doesn't byte compilation at least remove the names of local variables that clearly are not and therefor cannot ever be referred to by name?

--bb

Bill Baxter wrote:
> Robert Fraser wrote:
>> I stand corrected.
> 
> Ok people come on.  Doesn't he have something of a point?  Doesn't byte compilation at least remove the names of local variables that clearly are not and therefor cannot ever be referred to by name?
> 
> --bb

It depends upon the language.  To return to Ruby as an example, this is a language that only supports full reflection, but even full mutation at run-time, to the extent that much of a Ruby application could easily be generated on the fly.  Therefore, in this case at least, absolute all such state information and meta-information MUST be retained.  In the case of PHP, for example, it might be able to toss quite a lot of them, yes, based on the presence or absence of those few constructs that make use of them.  Then again that could actually make it compile slower, and PHP apps aren't usually designed to be long-lived.  Increased PHP compile times means losing much of its usefulness.

I'd be interested in seeing what Java does.

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls Wrote:

> [...]
> 
> I'd be interested in seeing what Java does.
> 
> -- Chris Nicholson-Sauls

Java bytecode doesn't have names for local variables, just stack indexes... though it's more than possible that such information could be included for debug reasons. I've only worked with the actual assembly, so dunno about the later really.

Steve Teale a écrit :
> Sean Kelly Wrote:
> 
>> Steve Teale wrote:
>>> It seemes to me that given Walter's definition of the language - a system programming language - that Phobos is closer to the mark.  If users want a more object oriented standard library, that's all well and good, but it should be a shoe-in, then if you want to use the OO stuff you can, but code that's been written to work with Phobos should work unmodified with other libraries.  (Note the recent discussion on C++ security).
>> While one might argue that it is easier to wrap a strictly procedural library with an OO layer than vice-versa, I think the ease with which any library may be encapsulated in a wrapper is more dependent on its design (the assumptions it makes, how features are exposed, etc) than on whether the interface uses functions or objects.  That said, I don't personally consider Tango to be an object-oriented library because it does not require the user to define his own objects in order to use it.
>>
>>
>> Sean
> 
> Sean, I take your point, and maybe should not have used the term "OO", but my idea of progress is:
> 
> printf("X is: %s\n", toStringz(x))
> cout << "X is: " << x << endl;
> Stdout("X is: ")(x).newline;
> writefln("X is: %s", x);

I agree with you that cout or Stdout strike me as particularly ugly and that writefln is a (small) progress over printf.

But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling that even writefln is not enough..

renoX

> 
> rather than:
> 
> printf("X is: %s\n", toStringz(&x))
> cout << "X is: " << x << endl;
> writefln("X is: %s", x);
> Stdout("X is: ")(x).newline;
> 

renoX wrote:
> ...
> I agree with you that cout or Stdout strike me as particularly ugly and
> that writefln is a (small) progress over printf.
> 
> But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling that even writefln is not enough..
> 
> renoX

http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell-style-variable.html

Just you wait until I get me grubby little mittens on AST macros... >:)

	-- Daniel

Bill Baxter a écrit :
> Robert Fraser wrote:
>> I stand corrected.
> 
> Ok people come on.  Doesn't he have something of a point?  Doesn't byte compilation at least remove the names of local variables that clearly are not and therefor cannot ever be referred to by name?

Well, ideally if there is a function which needs to the variable name at runtime, then the compiler *should* keep the name.. Otherwise, yes the compiler can drop the name to save memory.

Using index to refer to variable in a list strikes me as a very bad idea leading to a lot of potential mistake (think about the maintenance!), so a way to use variables name (at least for constant string at compilation time) should be provided.

I have made a 'format string' templated function which worked this way, I posted it some time ago..

renoX

> 
> --bb

renoX wrote:
> Steve Teale a écrit :
>> Sean Kelly Wrote:
>>
>>> Steve Teale wrote:
>>>> It seemes to me that given Walter's definition of the language - a system programming language - that Phobos is closer to the mark.  If users want a more object oriented standard library, that's all well and good, but it should be a shoe-in, then if you want to use the OO stuff you can, but code that's been written to work with Phobos should work unmodified with other libraries.  (Note the recent discussion on C++ security).
>>> While one might argue that it is easier to wrap a strictly procedural library with an OO layer than vice-versa, I think the ease with which any library may be encapsulated in a wrapper is more dependent on its design (the assumptions it makes, how features are exposed, etc) than on whether the interface uses functions or objects.  That said, I don't personally consider Tango to be an object-oriented library because it does not require the user to define his own objects in order to use it.
>>>
>>>
>>> Sean
>>
>> Sean, I take your point, and maybe should not have used the term "OO", but my idea of progress is:
>>
>> printf("X is: %s\n", toStringz(x))
>> cout << "X is: " << x << endl;
>> Stdout("X is: ")(x).newline;
>> writefln("X is: %s", x);
> 
> I agree with you that cout or Stdout strike me as particularly ugly and that writefln is a (small) progress over printf.
> 
> But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling that even writefln is not enough..
> 
> renoX
> 

Technically the Ruby sample would usually just be:
puts "X is #{X}"

Which is essentially shorthand for:
$stdout.method(:puts).call('X is ' + X.method(:to_s).call());

And if you need to format X any at all, you'd use something like this:
puts 'X is %08x' % [X]

Which is shorthand for:
$stdout.method(:puts).call('X is %08x'.method(:"%").call(X));

Which is a wrapper around:
puts sprintf('X is %08x', X)

Aka:
$stdout.method(:puts).call(Kernel::sprintf('X  is %08x', X));

Uhm.... sorry, got a little carried away there.  ;)  But the main point was, in cases like this Ruby and D don't really compare -- what with the former being in a virtual environment and the latter a systems language meant to expose metal.  For something like "X is #{X}" to work in D, wouldn't really require very much (symbol table, and runtime function to do the insertions) but the cost of such a thing becoming "mandatory" would be great.

I'd happily settle for a template or CTF that takes that string as parameter, and spits out an appropriate use of Stdout/writef.

On a side note, call me when we can duplicate this Ruby in D:

+-----[ Ruby ]-----------------------------------+
|
|    def verb_arg_str (flags, which)
|        ['none', 'any', 'this'][(flags >> case which
|            when :dobj then VFSHIFT_DOBJ
|            when :iobj then VFSHIFT_IOBJ
|        end) & VFMASK_ARGS]
|    end
|_________________________________________________

Er... actually we can, sans the symbol type in favor of a bool:

+-----[ D ]--------------------------------------+
|
|    char[] verbArgStr (uint flags, bool dobj) {
|      return ["none"[], "any", "this"][
|        (flags >> (dobj ? VFSHIFT_DOBJ : VFSHIFT_IOBJ))
|        & VFMASK_ARGS
|      ];
|    }
|_________________________________________________

Huh, how about that.

-- Chris Nicholson-Sauls

Daniel Keep a écrit :
> 
> renoX wrote:
>> ...
>> I agree with you that cout or Stdout strike me as particularly ugly and
>> that writefln is a (small) progress over printf.
>>
>> But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling
>> that even writefln is not enough..
>>
>> renoX
> 
> http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell-style-variable.html

Yes, I've did something similar (I've posted it in the newsgroup some time ago), but what I wonder is why does Tango devs didn't use such solution instead of their current not-very pretty one..

> Just you wait until I get me grubby little mittens on AST macros... >:)

Yup, I've put my solution on freeze until macros..

renoX


> 
> 	-- Daniel

Chris Nicholson-Sauls a écrit :
> renoX wrote:
>> Steve Teale a écrit :
>>> Sean Kelly Wrote:
>>>
>>>> Steve Teale wrote:
>>>>> It seemes to me that given Walter's definition of the language - a system programming language - that Phobos is closer to the mark.  If users want a more object oriented standard library, that's all well and good, but it should be a shoe-in, then if you want to use the OO stuff you can, but code that's been written to work with Phobos should work unmodified with other libraries.  (Note the recent discussion on C++ security).
>>>> While one might argue that it is easier to wrap a strictly procedural library with an OO layer than vice-versa, I think the ease with which any library may be encapsulated in a wrapper is more dependent on its design (the assumptions it makes, how features are exposed, etc) than on whether the interface uses functions or objects.  That said, I don't personally consider Tango to be an object-oriented library because it does not require the user to define his own objects in order to use it.
>>>>
>>>>
>>>> Sean
>>>
>>> Sean, I take your point, and maybe should not have used the term "OO", but my idea of progress is:
>>>
>>> printf("X is: %s\n", toStringz(x))
>>> cout << "X is: " << x << endl;
>>> Stdout("X is: ")(x).newline;
>>> writefln("X is: %s", x);
>>
>> I agree with you that cout or Stdout strike me as particularly ugly and that writefln is a (small) progress over printf.
>>
>> But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling that even writefln is not enough..
>>
>> renoX
>>
> 
> Technically the Ruby sample would usually just be:
> puts "X is #{X}"

Oops, a long time since I've made Ruby thanks for the various explanation of how it works in Ruby.

> Which is essentially shorthand for:
> $stdout.method(:puts).call('X is ' + X.method(:to_s).call());
>
> And if you need to format X any at all, you'd use something like this:
> puts 'X is %08x' % [X]

I don't like this syntax: the interesting part of #{X} is that the variable name is located at the same point as its string representation which reduce greatly the risk of mistake, when I've made my 'puts' like function for D (which used template,posted a while ago) , I used %{X} for normal embedding and allowed also %08x{X}.

I'm surprised that Ruby doesn't allow puts "X is #08x{X}"..

> 
> Which is shorthand for:
> $stdout.method(:puts).call('X is %08x'.method(:"%").call(X));
> 
> Which is a wrapper around:
> puts sprintf('X is %08x', X)
> 
> Aka:
> $stdout.method(:puts).call(Kernel::sprintf('X  is %08x', X));
> 
> Uhm.... sorry, got a little carried away there.  ;)  But the main point was, in cases like this Ruby and D don't really compare -- what with the former being in a virtual environment and the latter a systems language meant to expose metal.  For something like "X is #{X}" to work in D, wouldn't really require very much (symbol table, and runtime function to do the insertions) but the cost of such a thing becoming "mandatory" would be great.

It depends: when the string is known at compile-time (which happens quite often), then there is absolutely no overhead over printf.
For runtime string, yes this syntax would have a significant overhead.

> I'd happily settle for a template or CTF that takes that string as parameter, and spits out an appropriate use of Stdout/writef.

Well I've posted one some time ago (improved format string), there didn't seem to be a huge interest so I've stopped working on it (beside with macros it should be better), but I can't help cringing with index counting "{1} {2}" format string, barf..

renoX

> 
> On a side note, call me when we can duplicate this Ruby in D:
> 
> +-----[ Ruby ]-----------------------------------+
> |
> |    def verb_arg_str (flags, which)
> |        ['none', 'any', 'this'][(flags >> case which
> |            when :dobj then VFSHIFT_DOBJ
> |            when :iobj then VFSHIFT_IOBJ
> |        end) & VFMASK_ARGS]
> |    end
> |_________________________________________________
> 
> Er... actually we can, sans the symbol type in favor of a bool:
> 
> +-----[ D ]--------------------------------------+
> |
> |    char[] verbArgStr (uint flags, bool dobj) {
> |      return ["none"[], "any", "this"][
> |        (flags >> (dobj ? VFSHIFT_DOBJ : VFSHIFT_IOBJ))
> |        & VFMASK_ARGS
> |      ];
> |    }
> |_________________________________________________
> 
> Huh, how about that.
> 
> -- Chris Nicholson-Sauls