The only argument for making it a macro instead of a language construct is so that people can do this sort of thing as user libraries.

If it's possible in a user library, it gets pushed out of the standard library into the hands of the users because there's no "need" for it to be standard;  if people want that syntax they can make their own, and not everybody needs that feature so why standardize it?

It adds a lot of complexity to the language to allow robust macros.  That's one of the reasons D doesn't have them.

I'm asking for a better 'with' statement.  You're saying that macros can do that so what should instead be added are preprocessor macros.  That doesn't exactly solve my issue, and it entails lots of complications on its own. But thanks for trying!

Sean

"Dan Liebgold" <Dan_member@pathlink.com> wrote in message news:b40a57$213p$1@digitaldaemon.com...
> In article <b3v6q3$1bmn$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >Aside from all the subtle gotchas you have to watch out for when doing textual macro preprocessing, I really don't relish the idea of doing:
> >
> >import my_convenient_macro_library;
> >
> >my_convenient_macro_library.with (foo)
> >{
> >    // do something with foo
> >}
> >
>
> As Mark T quoted a few posts back: "Library design is language design". Something basic like the "with" macro would be part of the *standard*
library,
> and would not need importation or any special specification. Thus, unlike
in
> most languages, the implementation of many basic constructs would be
available
> to expert D practitioners, and that is a good thing.
>
> Syntax transforming macros are one of the basic Lisp ideas that Eric
Raymond was
> implicating when he said "LISP is worth learning for a different reason -
the
> profound enlightenment experience you will have when you finally get it.
That
> experience will make you a better programmer for the rest of your days,
even if
> you never actually use LISP itself a lot."
>
> Dan

Hi,

thanks for giving me another explanation "languages expressiveness".

Well, "intuitively" is not a generally useful concept, the problem is e.g.:
What's intuitive to people who know how computers work, is often counter-
intuitive to people that don't know and the other way round.
So, practically I cannot discuss inclusion/exclusion of features to D
claiming that this change would make things more intuitive.

The other definition "problems can be expressed directly" was very enlighting for me. If you take the idea of expressiveness to the extreme (problems are expressed directly, the language is the solution), isn't it very likely that the language is bound to some (or even many) specific application domains. I think that having some level of indirection for expressing problems is natural for a general purpose language.

> I also work with projects where performance is important, but else safety is. Do you prefer a fast elevator or a safe one? Presumably both. But if it can't be both, it'd rather be safe else you're risking your life.
Performance can be part of the solution. For your customers it does not matter whether your programm crashes or is too slow. Both can be simply inacceptable. Of course, I favour stability/maintainability whenever it is possible.

> 
> And i beg you for more respect towards the researchers. They usually research problems which are of importance. However, since they don't strive to make a product, but insight, they may choose ways of implementation and tools which are not appropriate for commercial software development, because they might just be better suited for that particular purpose. Or doesn't really matter why, may be a personal preference as well. They give you knowledge, which is to your advantage only, and can be profitably used in an industrial product. Just usually not the tools they have used to prove their thesis. Having a "research focus" rather than a "pragmatic purpose" is a good goal, since insight is always helpful in pragmatic sense.
> 
> -i.
> 
I think, you misunderstood me.


Maybe you refer to my statement:
"But I also have the impression that researchers don't read any source code
material to speak of. So researchers tend to come up with great solutions
for problems that are of minor importance for mainstream applications."
[Quote myself here to please my ego]

I said:
"So researchers tend to come up with great solutions
for problems that are of minor importance for mainstream applications."

I did not meant to say:
"So researchers tend to come up with great solutions
for problems that are of minor importance."

Also, I did not meant to say
"So researchers tend to come up with great solutions
for problems that are useless for mainstream applications."


Maybe you refer to my question:
"Is there any academic definition for it (That is easily understood) ?"

I guess, that my statement has ambigous meaning depending on your native language. So I refactor it a bit: "Is there any precise definition for it (That is easily understood) ?"



Farmer

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns9335CE7A4BC9itsFarmer@63.105.9.61...
> Well, "intuitively" is not a generally useful concept, the problem is
e.g.:
> What's intuitive to people who know how computers work, is often counter-
> intuitive to people that don't know and the other way round.
> So, practically I cannot discuss inclusion/exclusion of features to D
> claiming that this change would make things more intuitive.

You're right. But in the context of D, I would give more weight to "what is intuitive to a programmer comfortable with C or C++" than what might be intuitive to a programmer coming from a very different language, such as Lisp or Prolog. I want the C/C++ programmer feel like someone who has spent an hour driving down a dirt road and has now turned onto the main, freshly paved, macadam highway.

Walter wrote:
>in the context of D, I would give more weight to "what is
>intuitive to a programmer comfortable with C or C++" than what might be
>intuitive to a programmer coming from a very different language, such as
>Lisp or Prolog. I want the C/C++ programmer feel like someone who has spent
>an hour driving down a dirt road and has now turned onto the main, freshly
>paved, macadam highway.

Then you want high-level capability.  Compare

C-ish
----------------------------
int myfunction();
List mylist();
for(int i=0; i<mylist.len(); i++)
{ mylist[i] = myfunction(mylist[i]); }
----------------------------
Lisp-ish
----------------------------
int myfunction();
List mylist;
mylist = map(myfunction,mylist);
----------------------------

It's all about choices.  If a programmer wants to write C for-loops instead of using map, he can do that.  I see no conflict here.  In fact D has the opportunity to introduce to C folks choices that they never had before.  They might thank you for that.

Mark

> It's all about choices.  If a programmer wants to write C for-loops instead of
> using map, he can do that.  I see no conflict here.  In fact D has the
> opportunity to introduce to C folks choices that they never had before.  They
> might thank you for that.

Or they might run screaming and naked for the woods.

Bill

>Or they might run screaming and naked for the woods.
>
>Bill

Talk about paranoia!
M.

In article <3E6648D5.3030002@viasic.com>, Bill Cox says...
>
>> It's all about choices.  If a programmer wants to write C for-loops instead of using map, he can do that.  I see no conflict here.  In fact D has the opportunity to introduce to C folks choices that they never had before.  They might thank you for that.
>
>Or they might run screaming and naked for the woods.
>
>Bill
>
>

Why naked, exactly? ;)

But back to Mark's point, if D did implement builtin support for constructs like "map" over lists, it would really only be a win.  The old for-loop way of doing things is not going to be eliminated, and as new programmers catch on to the map (for example) idea, whey will migrate over and become more productive.

Built in garbage collection throws open the doors to all sorts of more expressive ways of doing things, and meanwhile the C-ish constructs will always be available.  D can really do everything right that the STL is attempting to do, without the negative impact to understandability and implementational complexity.

Dan

"Dan Liebgold" <Dan_member@pathlink.com> wrote in message news:b45oa0$2858$1@digitaldaemon.com...
> But back to Mark's point, if D did implement builtin support for
constructs like
> "map" over lists, it would really only be a win.  The old for-loop way of
doing
> things is not going to be eliminated, and as new programmers catch on to
the map
> (for example) idea, whey will migrate over and become more productive.

Yes, you're right.

> Built in garbage collection throws open the doors to all sorts of more expressive ways of doing things, and meanwhile the C-ish constructs will
always
> be available.  D can really do everything right that the STL is attempting
to
> do, without the negative impact to understandability and implementational complexity.

It would be great to do STL better than STL.

Dan Liebgold wrote:
> In article <3E6648D5.3030002@viasic.com>, Bill Cox says...
> 
>>>It's all about choices.  If a programmer wants to write C for-loops instead of
>>>using map, he can do that.  I see no conflict here.  In fact D has the
>>>opportunity to introduce to C folks choices that they never had before.  They
>>>might thank you for that.
>>
>>Or they might run screaming and naked for the woods.
>>
>>Bill
>>
>>
> 
> 
> Why naked, exactly? ;)

It was just too fun not to say.

> But back to Mark's point, if D did implement builtin support for constructs like
> "map" over lists, it would really only be a win.  The old for-loop way of doing
> things is not going to be eliminated, and as new programmers catch on to the map
> (for example) idea, whey will migrate over and become more productive.
> 
> Built in garbage collection throws open the doors to all sorts of more
> expressive ways of doing things, and meanwhile the C-ish constructs will always
> be available.  D can really do everything right that the STL is attempting to
> do, without the negative impact to understandability and implementational
> complexity.

You and Mark are probably right.  Don't tell anybody around here that I said that.

Bill

Farmer <itsFarmer.@freenet.de> writes:

> Mark Evans <Mark_member@pathlink.com> wrote in news:b3pg8m$19te$1@digitaldaemon.com:
>
> Hi,
>
> in your last post you often mentioned the term "languages expressiveness".
>
> What is this exactly?
> Is there any academic definition for it (That is easily understood) ?
> How can you measure this? [ the kernel language? :-) ]

Not an academic definition but definition all the same:

IMHO, language's expressiveness (and power) extends as far as a language's ability to define and use abstractions.

As languages have evolved, their designers have sought for possibilities for abstraction in different places:

- There is procedural abstraction, which enables the programmer to define a code unit that has inputs, outputs and side effects, give it a name and use that to perform the same task repeatedly.

- Data abstraction (structs) allows one to take several blocks of data, give them a name and use the same set of data in several places, denoting structured values.

- Object abstraction is yet another abstraction that combines a set of data, more or less hidden, that has an identity and operations that can be performed on it.

- "Concurrent process" abstraction is an object or a process that has an identity, a thread of control that can proceed conceptually simultaneously with others, and can communicate with them with different mechanisms.

- "Template" (or generic, or whatever you like to call it) abstraction defines common structure for data and/or code and lets you parameterize them with types or data.

- And much more. Anything which lets you define and name something and define things in terms of that something is an abstraction that gives rise to expressiveness.

- Metalinguistic abstraction is the most powerful form of abstraction which lets one define and extend the language in its own terms - this allows the programmer to tailor the ready-made abstraction facilities or make customized abstractions if needed.  Fear the LISP macro hackers, because having mastered this art they have incredible power at their fingertips.

http://mitpress.mit.edu/sicp/full-text/book/book.html http://www.paulgraham.com/onlisp.html

It is the combination of different abstraction mechanisms that give
rise to the programming paradigms that are available to a programmer
using a given language.

There have been attempts to unify the different paradigms and
abstraction mechanisms, and they are a lively research topic.

http://www.ifs.uni-linz.ac.at/~ecoop/cd/papers/1850/18500001.pdf (Was this paper mentioned earlier? At least it's about Beta and what it's all about)

http://www.info.ucl.ac.be/~pvr/
(Concepts, Techniques, and Models of Computer Programming, which was
already mentioned but is worth repeating over and over.  The kernel
language approach is something that would be healthy to be interested
in for most people that would like to call themselves computer
scientists.)

Having said that, I'd like to also express my opinion that *having* the abstractions is not enough.  You also have to be able to *use* them and using them should be easy and look nice.

For example, C++ has plenty of abstraction facilities.  It's a shame that you are punished for using them: to make a class (so that representation is separated from the interface) you have to maintain two different copies of the function signatures, and wrap the class inside a memory-managing smart pointer or use pointers and risk memory leakage.  To make a function object, you have to declare either a local object, global function, or use clumsy STL/boost combinators to combine them, which isn't always possible, either. You can't easily make local functions that can operate on local data, and so on.

D is mostly much better in this regard (function literals, nested functions, garbage collection, etc.), but there's one area where it lags behind C++: templates.  For example, to simply declare a set of integers, you'll have to instantiate the template manually:

(assume template List(T) which contains the class List)

--D snippet--
instance List(int) intList;

void foo()
{
    intList.List list;
    // use list
}
--D snippet--

compare this with

--C++ snippet--
void foo()
{
    List<int> list;
    // use list
}
--C++ snippet--

This is similar to the situation in which I'm tempted not to use std::for_each for performing an action over a container. Using a for loop is easier. There must be reasons for this, I guess, but...

So, let's return to the concept of expressiveness.  Basically you could determine expressiveness as an (intuitive) measure of the abstraction facilities offered by the language and the ease of use of those abstraction facilities.  You cannot be very deterministic in determining the expressiveness absolutely, but you could always ask a thousand programmers about how easy to use they find abstraction mechanism X in language Y, and then add them all, or something like that.  If you fancy things like that.

Expressiveness isn't everything, either.

If I have a language that allows me to build the most beautiful abstractions in a small amount of code, but the language simply looks stramge. difficult to read, or ugly in my opinion, I probably won't use it.

If the syntax and abstractions are elegant, but the implementation is slow as hell and the standard library lacks critical features, I probably won't use it.

If nobody else uses it (because of some of the features above), it's unlikely that it has decent standard library and support for the systems I use, and so I probably won't use it.

And so on.

Let's conclude with a nice little paper by MacLennan (1997) about the effect of aesthetics in the context of language design:

"The general principle is that designs that look good will also be good, and therefore the design process can be guided by aesthetics without extensive (but incomplete) mathematical analysis." -- -- "The same applies to programming language design. By restricting our attention to designs in which the interaction of features is manifest - in which good interactions look good, and bad interactions look bad - we can let our aesthetic sense guide our design and we can be much more confident that we have a good design, without having to check all the possible interactions. "

"We accomplish little by covering an unbalanced structure in a beautiful facade. When the bridge is unable to sustain the load for which it was designed, and collapses, it won't much matter that it was beautiful on the outside. So also in programming languages. If the elegance is only superficial, that is, if it is not the manifestation of a deep coherence in the design, then programmers will quickly see through the illusion and loose their (unwarranted) confidence."

It's available at: http://www.cs.utk.edu/~mclennan/anon-ftp/Elegance.html

-Antti