renoX wrote:
> 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..

Tango development started almost a year and a half ago, long before most of these features existed.  And I'd still consider them incomplete until we get full macro capability.


Sean

renoX wrote:
> 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.

I just happen to be working on a Ruby project lately, so it was fresh in mind.  ;)

>> 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}"..
> 

Actually I feel much the same way.  If I ever find a clean way to code my own formatter that can borrow the calling context.... I'll get shivers.  (Probably have to write a Ruby extension in C to do so.)

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> renoX wrote:
>> I'm surprised that Ruby doesn't allow puts "X is #08x{X}"..
> 
> Actually I feel much the same way.  If I ever find a clean way to code my own formatter that can borrow the calling context.... I'll get shivers.  (Probably have to write a Ruby extension in C to do so.)
> 
> -- Chris Nicholson-Sauls

Heh, my formatter supports "X is $(08x){X}" which is a bit longer, but
non-ambiguous.  ^^

	-- Daniel

Daniel Keep Wrote:
> Chris Nicholson-Sauls wrote:
> > renoX wrote:
> >> I'm surprised that Ruby doesn't allow puts "X is #08x{X}"..
> > 
> > Actually I feel much the same way.  If I ever find a clean way to code my own formatter that can borrow the calling context.... I'll get shivers.  (Probably have to write a Ruby extension in C to do so.)
> > 
> > -- Chris Nicholson-Sauls
> 
> Heh, my formatter supports "X is $(08x){X}" which is a bit longer, but
> non-ambiguous.  ^^

I don't think that %08x{X} is ambiguous (and it has the advantage that it looks very much like printf formatter which is a plus in a language which is the successor of C/C++): anything between % and { is the 'formatter', anything inside {..} is the expression to be formatted.

Could you explain why you think it's ambiguous?

Regards,
renoX

> 
> 	-- Daniel

renoX wrote:
> I don't think that %08x{X} is ambiguous (and it has the advantage that it looks very much like printf formatter which is a plus in a language which is the successor of C/C++): anything between % and { is the 'formatter', anything inside {..} is the expression to be formatted.
> 
> Could you explain why you think it's ambiguous?
> 
> Regards,
> renoX
> 

No, you're right; it's not ambiguous.  I suppose I just don't like that the format options aren't explicitly delimited by anything; the parser I wrote for mine is a bit stricter.

The other problem is that, as you said, it looks like a printf string. My personal stance is that unless printf syntax is actually valid, it shouldn't look like it is.

I suppose it all boils down to taste in the end; viva-la-dollar! :)

	-- Daniel

Daniel Keep Wrote:
> renoX wrote:
> > I don't think that %08x{X} is ambiguous (and it has the advantage that it looks very much like printf formatter which is a plus in a language which is the successor of C/C++): anything between % and { is the 'formatter', anything inside {..} is the expression to be formatted.
> > 
> > Could you explain why you think it's ambiguous?
[]
> No, you're right; it's not ambiguous.  I suppose I just don't like that the format options aren't explicitly delimited by anything; the parser I wrote for mine is a bit stricter.
> 
> The other problem is that, as you said, it looks like a printf string. My personal stance is that unless printf syntax is actually valid, it shouldn't look like it is.

I agree that if it looks like printf then it should behave like printf: that's why the printf syntax was also valid in the function I made and that the same formater had the same result.

> I suppose it all boils down to taste in the end; viva-la-dollar! :)

Well, using printf-like formatter in a language which reuse C/C++ syntax make more sense to me, but sure that's a matter of taste and in any case your $ notation is far better than what there is currently in the libraries..

renoX
> 
> 	-- Daniel

renoX wrote:
> Daniel Keep Wrote:
>> renoX wrote:
>>> I don't think that %08x{X} is ambiguous (and it has the advantage that it looks very much like printf formatter which is a plus in a language which is the successor of C/C++): anything between % and { is the 'formatter', anything inside {..} is the expression to be formatted.
>>>
>>> Could you explain why you think it's ambiguous?
> []
>> No, you're right; it's not ambiguous.  I suppose I just don't like that
>> the format options aren't explicitly delimited by anything; the parser I
>> wrote for mine is a bit stricter.
>>
>> The other problem is that, as you said, it looks like a printf string.
>> My personal stance is that unless printf syntax is actually valid, it
>> shouldn't look like it is.
> 
> I agree that if it looks like printf then it should behave like printf: that's why the printf syntax was also valid in the function I made and that the same formater had the same result.
> 
>> I suppose it all boils down to taste in the end; viva-la-dollar! :)
> 
> Well, using printf-like formatter in a language which reuse C/C++ syntax make more sense to me, but sure that's a matter of taste and in any case your $ notation is far better than what there is currently in the libraries..
> 
> renoX
>> 	-- Daniel
> 

Here's an odd thought: "%{08x:X}"
Wherein the {}'s mean, "this is looking at a variable outside", and the ':' means "everything after this point is the variable's name".

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> renoX wrote:
> Here's an odd thought: "%{08x:X}"
> Wherein the {}'s mean, "this is looking at a variable outside", and the
> ':' means "everything after this point is the variable's name".
> 
> -- Chris Nicholson-Sauls

I actually played with something similar for a while, but eventually discarded it.  The problem was that there are times when you don't care to format some expression, you just want to output the thing.  I didn't like that you'd have to carry around the leading ':' when you're not using it.

OTOH, this is pretty similar to what Tango uses in its formatter.  IIRC, it's something like {n:f} where ':f' is your optional format string and 'n' is the position of the thing you want to format.  Or it might be the other way around; I dunno :P

	-- Daniel

Chris Nicholson-Sauls wrote:
> Here's an odd thought: "%{08x:X}"
> Wherein the {}'s mean, "this is looking at a variable outside", and the ':' means "everything after this point is the variable's name".
> 
> -- Chris Nicholson-Sauls

I always rather liked Python's syntax for this.

http://docs.python.org/lib/typesseq-strings.html

>>> '%(X)08x' % {'X' : 12}
'0000000c'

That is, the identifier is placed inside of parentheses between the '%' and the rest of the format string. The primary difference, here, is that Python then expects a dictionary instead of positional format arguments. You can get a dictionary of the current scope's variables with the locals() function, thus you could easily say:

>>> a = 'hello'
>>> b = 'world'
>>> '%(a)s %(b)s' % locals()
'hello world'

This part is not as applicable to D (since its AAs must be statically typed), but I do like the format string syntax.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Kirk McDonald wrote:
> Chris Nicholson-Sauls wrote:
>> Here's an odd thought: "%{08x:X}"
>> Wherein the {}'s mean, "this is looking at a variable outside", and
>> the ':' means "everything after this point is the variable's name".
>>
>> -- Chris Nicholson-Sauls
> 
> I always rather liked Python's syntax for this.
> 
> http://docs.python.org/lib/typesseq-strings.html
> 
>>>> '%(X)08x' % {'X' : 12}
> '0000000c'
> 
> That is, the identifier is placed inside of parentheses between the '%' and the rest of the format string. The primary difference, here, is that Python then expects a dictionary instead of positional format arguments. You can get a dictionary of the current scope's variables with the locals() function, thus you could easily say:
> 
>>>> a = 'hello'
>>>> b = 'world'
>>>> '%(a)s %(b)s' % locals()
> 'hello world'
> 
> This part is not as applicable to D (since its AAs must be statically typed), but I do like the format string syntax.
> 

It would be cool if we got a __traits(locals) function that returned a pointer to a struct whose members were overlaid over the function's local stack...

...yeah, seems a bit overkill :P  I still think that macros wrapping string mixins are the way to do it.

	-- Daniel