Hi There,
I've just found out about D (thanks to slashdot), and i see a lot of stuff
about it i really like -- several things that when i've thought to myself
"if i ever made a programming language, i'd do _______" are in there.  It
looks very promising to me.  anyway, if i may, i'd like to fire off a
couple questions:

1) where is D at in regards to specifing the features that it includes? is it still pretty much a work in progress, or has it moved onto the "okay, that's enough discussion, now lets get it working" point, which is my impression from skimming the specs?

2) if it was still in the forming stages (or if i was making a language) the following are some things i'd be tempted to include.  now, my assumption is that these have already been discussed to death, since they're mainly things already in other languages, and probably some of the long time readers here would rather chuck their computer throught the window instead of read another thread on it, so please accept my apologies in advance.  I did skim the headers looking for relevent discussions, but as there are nearly 10,000 legacy messages here, it's a hell of a lot easier for me to just write this and hope someone out there doesn't mind responding.  basically, what i'm wondering is: if it was already discussed, what was the consensus regarding it, or is it already in the language and i overlooked it, or is it so obviously a bad idea that it wasn't even worthy of discussion.  anyway, in no particular order, here they are:

unless/until syntatic sugarcoating, where "unless(false){}" ==
"if(!false){}"  and "until(true)" == "while(!true)".  okay, these add no
functionality, but i think that it would create easier to follow code,
seeing how i get confused easily by logical negations >;-)

functions as first class objects.  now, i really have no idea what this means in terms of implementation or performance, but lisp has had it since day one, so i'd suspect it can't be too bad.  (of course, i don't know of many other languages that have it, so maybe it ain't so easy after all). but personally, being able to store functions in data structures, pass them (easily) as arguments to functions or creating fuctions which are themselves capable of creating and returning a functions just sounds very tantalizing to me.  having this would go hand in hand with having something equivalent to lisp/python lamda statements - i.e. anonymous, unnammed functions.

multiple return values from a function.  personally, i've never been very keen on the C/C++ idea of having parameters that are actually return values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i think it's a lot easier to follow code that has all the inputs in one place and the outputs in another.  i guess this wouldn't be compatibly with the IDL like the current in/out/inout specifiers, but i'd say that it's a lot more often that you'd write a function w/ multiple return values than write something that needs to be compatible w/ IDL.  and no, i wouldn't suggest getting rid of the in/out/inout specifiers, i'd just rather not use them myself all that often.

java style online API/user libary documentation -- for my money, one of the best things about working with Java.  i'd hope that D would have a similar resource (and am puzzeled why c and c++ don't have something similar).

lisp like closures.  now, of all the things here which i've heard about
and like the sound of, but haven't actually used in practice, this one is
the one i probably understand the least. but what i think i understand,
appeals to me.  basically, my understanding is that this amounts to
functions with a shared state - or perhaps they're anonymous, unnammed
classes. e.g.  closure{ double total
			add(double x){total += x; return total}
			sub(double x){total += x; return total}
	}
so, add and sub both act on the same variable total, but total is
protected from having any other function modify it.  maybe not quite a
global variable, but a national variable.  i dunno, sounds good to me
though.  and if that isn't a lisp closure, well, then i like whatever it
is i just described.

a foreach or forall statement for iterating over elements of a collection: "foreach person in newsgroup{.....}" where newsgroup is a collection/array of persons, and whatever's between the {}'s is code that is executed on each person.  to me this just seems a lot more intuitive to work with than "for(x = 0; x < Y; x++)..."

the obvious name of the following unfortunately clashes with that of the previous, but having just wrapped up a course in program correctness i'm thinking i'd like to see boolean "forall" and "exists" expressions for use in contracts to verify the program correctness.  "forall x in X(cond)" would be true if all the x's in X satisfy the cond, and "exists x in X(cond)" would be true in any one x in X satisfied the cond.


well, i think that's more than enough for now.  thanks for reading to anybody who actually got this far.  take care & good night.

-scott

Scott Pigman wrote:
> Hi There,
> I've just found out about D (thanks to slashdot), and i see a lot of stuff
> about it i really like -- several things that when i've thought to myself
> "if i ever made a programming language, i'd do _______" are in there.  It
> looks very promising to me.  anyway, if i may, i'd like to fire off a
> couple questions:

welcome. But i'm fairly new here too.

> 1) where is D at in regards to specifing the features that it includes? is
> it still pretty much a work in progress, or has it moved onto the "okay,
> that's enough discussion, now lets get it working" point, which is my
> impression from skimming the specs?

It is already working. And the job is being done of creating further compilers. However, the language is not 100% solid yet - the string format questions as well as many other things are not solved yet. Some major features were introduced only a couple of months ago. And the changes are not too much hampered by any major legacy code to take care of.

Currently there is one front-end (well, and one minor deviation), and multiple backends being developed for it. The target compilers are kept in sync with the open-source front-end released by Walter. Besides Walters original compiler, the only working port is "dli", D for Linux/x86 by Burton Radons.

> 2) if it was still in the forming stages (or if i was making a language)
> the following are some things i'd be tempted to include.  now, my
> assumption is that these have already been discussed to death, since
> they're mainly things already in other languages, and probably some of the
> long time readers here would rather chuck their computer throught the
> window instead of read another thread on it, so please accept my apologies
> in advance.  I did skim the headers looking for relevent discussions, but
> as there are nearly 10,000 legacy messages here, it's a hell of a lot
> easier for me to just write this and hope someone out there doesn't mind
> responding.  basically, what i'm wondering is: if it was already
> discussed, what was the consensus regarding it, or is it already in the
> language and i overlooked it, or is it so obviously a bad idea that it
> wasn't even worthy of discussion.  anyway, in no particular order, here
> they are:
> 
> unless/until syntatic sugarcoating, where "unless(false){}" ==
> "if(!false){}"  and "until(true)" == "while(!true)".  okay, these add no
> functionality, but i think that it would create easier to follow code,
> seeing how i get confused easily by logical negations >;-)
> 
> functions as first class objects.  now, i really have no idea what this
> means in terms of implementation or performance, but lisp has had it since
> day one, so i'd suspect it can't be too bad.  (of course, i don't know of
> many other languages that have it, so maybe it ain't so easy after all).
> but personally, being able to store functions in data structures, pass
> them (easily) as arguments to functions or creating fuctions which are
> themselves capable of creating and returning a functions just sounds very
> tantalizing to me.  having this would go hand in hand with having
> something equivalent to lisp/python lamda statements - i.e. anonymous,
> unnammed functions.

Lisp is an interpreted language. What that means, is that you've always got a code generator at hand to generate some more code. In D this cannot be done. Maybe after a VM version of D is made (in years), something similar can be thought of. For now you can toss functions around as you like, but you can't create them at runtime. They need to be all defined to compile time. This possibility can be added as a library later, but it's probable that you'd only be able to use C or a small subset of D for runtime generation.

It is a very complicated topic within non-interpreted environments, but i'm glad to tell you that it's a subject of my particular interest so i'll keep investigating how such things can be done. I guess Burton is also interested in something similar.

Currently research is led to make code optimise itself at run-time. For example, there are values which become constant at run-time, but are not known at compile time. These would get optimised out then. But don't expect this to become real within your life span. :>

> multiple return values from a function.  personally, i've never been very
> keen on the C/C++ idea of having parameters that are actually return
> values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i
> think it's a lot easier to follow code that has all the inputs in one
> place and the outputs in another.  i guess this wouldn't be compatibly
> with the IDL like the current in/out/inout specifiers, but i'd say that
> it's a lot more often that you'd write a function w/ multiple return
> values than write something that needs to be compatible w/ IDL.  and no, i
> wouldn't suggest getting rid of the in/out/inout specifiers, i'd just
> rather not use them myself all that often.

Sweet. Hm. Not a real problem, just a decision question. It could make the result be placed on stack, not returned imlicitly by reference, which makes it impossible to call legacy functions this way, but might... be good for something. Opinions? And inout would simply mutate back to what they are - references?

But what if you use such a function in an expression - you get a real mess. Noone forces though.

> java style online API/user libary documentation -- for my money, one of
> the best things about working with Java.  i'd hope that D would have a
> similar resource (and am puzzeled why c and c++ don't have something
> similar).

Well, that's something you could make someday. ;)  In my personal opinion, D is quite unlike c++ suited as an educational language, so a lot of easy-to-read documentation would have to be written. But of course, Consider: C comes with a tiny library only. But of course there is a description of it. As of c++, there is no common style, little common libraries and tools, and a LOT of resources. C++ coders don't understand each other when they talk. It shouldn't happen to D. It gets a decent library, which in turn needs documentation.

> lisp like closures.  now, of all the things here which i've heard about
> and like the sound of, but haven't actually used in practice, this one is
> the one i probably understand the least. but what i think i understand,
> appeals to me.  basically, my understanding is that this amounts to
> functions with a shared state - or perhaps they're anonymous, unnammed
> classes. e.g.  closure{ double total
> 			add(double x){total += x; return total} 			sub(double x){total += x; return total}
> 	}
> so, add and sub both act on the same variable total, but total is
> protected from having any other function modify it.  maybe not quite a
> global variable, but a national variable.  i dunno, sounds good to me
> though.  and if that isn't a lisp closure, well, then i like whatever it
> is i just described.

Any real usage? Consider using templates, or just creating another module in such case. Such closures would only resolve unit-scope ambiguities, which you would have to stumble over later when making some minor change. It simply takes accurate naming to avoid it. It is better to correct a bug than to hide it, right? Consider also: keeping units (=modules) small enough would do legibility good.

> a foreach or forall statement for iterating over elements of a collection:
> "foreach person in newsgroup{.....}" where newsgroup is a collection/array
> of persons, and whatever's between the {}'s is code that is executed on
> each person.  to me this just seems a lot more intuitive to work with than
> "for(x = 0; x < Y; x++)..."

I'm pretty much sure Walter is considering this right now.

> the obvious name of the following unfortunately clashes with that of the
> previous, but having just wrapped up a course in program correctness i'm
> thinking i'd like to see boolean "forall" and "exists" expressions for use
> in contracts to verify the program correctness.  "forall x in X(cond)"
> would be true if all the x's in X satisfy the cond, and "exists x in
> X(cond)" would be true in any one x in X satisfied the cond.

Hm. {We} are afraid of too many keywords :> as well as of complex parsing. So that features like ^^ runtime-generated functions could become possible someday. Well, a keyword or two doesn't matter but... Hm. What I am considering is an alternative plugin-driven parsing possibility, which would make it possible to make some tests without messing around with the actual language, as well as add a few functional programming constructs. D better stay lighweight, so that it is as easy to learn as Delphi, and yet to combine the powers of Perl and C++ and everything needed really often. Whereas i don't consider pure english keywords a danger for learnability.

> well, i think that's more than enough for now.  thanks for reading to
> anybody who actually got this far.  take care & good night.
> 
> -scott

>
> Currently research is led to make code optimise itself at run-time. For example, there are values which become constant at run-time, but are not known at compile time. These would get optimised out then. But don't expect this to become real within your life span. :>
>
that is exactly what java dynamic compilers do, and is why some companies
claim that their Java VM's can run code faster than C/C++
because the code executed it the true mainline (all if rewritten to branch
out as the rare condition) calculated by interpeting the code a few times
first and only compiling the code that is actually executed, reorder,
inlined and generally mess about with so within any complete section all the
computed values are right, the flow or way they are calculated may not be
anything like a statically compiled version of the same code, and a section
of code may end up being compiled in several different ways depending on how
you get to it. something that it would be possible to do with a static
compiler linked to a profiler, assuming that your profile the correct data
:) before setting your code "in stone". but I doubt with the dynamic
adjustment to input that a true dynamic compiler offers.
there are also benifits to the GC too, you can determine short lived
objects,  the way the objects interconections and allocations are arranged
allowing ahead of time object allocations, pruning known dead objects and
optimise the way the GC walks the stack etc.

On Sat, 18 Jan 2003 03:05:36 +0100, Ilya Minkov wrote:

> Scott Pigman wrote:
>> Hi There,
>> I've just found out about D (thanks to slashdot), and i see a lot of stuff

> welcome. But i'm fairly new here too.

Thankyou.



>> 
>> functions as first class objects.  now, i really have no idea what this means in terms of implementation or performance, but lisp has had it since
<snip>
> Lisp is an interpreted language. What that means, is that you've always got a code generator at hand to generate some more code. In D this cannot be done. Maybe after a VM version of D is made (in years), something similar can be thought of. For now you can toss functions around as you like, but you can't create them at runtime. They need to be all defined to compile time. This possibility can be added as a library later, but it's probable that you'd only be able to use C or a small subset of D for runtime generation.

to what extent is "tossing around" functions supported now?  is it c style
function pointers (which i have to admit to not being at all comfortable
with), or is is it something cleaner?  I can't find anything
relevent on the web page.

> It is a very complicated topic within non-interpreted environments, but i'm glad to tell you that it's a subject of my particular interest so i'll keep investigating how such things can be done. I guess Burton is also interested in something similar.

i think it's a worthy goal, so put me down as interested too, although i'm not sure if i could contribute much to the mix myself.

> Currently research is led to make code optimise itself at run-time. For example, there are values which become constant at run-time, but are not known at compile time. These would get optimised out then. But don't expect this to become real within your life span. :>

that's another feature i would like.  just please don't go putting limits on my lifespan, okay ;-)

>> lisp like closures.  now, of all the things here which i've heard about
<snip>
> 
> Any real usage? Consider using templates, or just creating another module in such case. Such closures would only resolve unit-scope ambiguities, which you would have to stumble over later when making some minor change. It simply takes accurate naming to avoid it. It is better to correct a bug than to hide it, right? Consider also: keeping units (=modules) small enough would do legibility good.

good points.  i'll get back to you on that ;-)

>> a foreach or forall statement for iterating over elements of a collection: "foreach person in newsgroup{.....}" where newsgroup is a collection/array of persons, and whatever's between the {}'s is code that is executed on each person.  to me this just seems a lot more intuitive to work with than "for(x = 0; x < Y; x++)..."
> 
> I'm pretty much sure Walter is considering this right now.

Awesome.

>> multiple return values from a function.  personally, i've never been very keen on the C/C++ idea of having parameters that are actually return values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i think it's a lot easier to follow code that has all the inputs in one place and the outputs in another.  i guess this wouldn't be compatibly with the IDL like the current in/out/inout specifiers, but i'd say that it's a lot more often that you'd write a function w/ multiple return values than write something that needs to be compatible w/ IDL.  and no, i wouldn't suggest getting rid of the in/out/inout specifiers, i'd just rather not use them myself all that often.
> 
> Sweet. Hm. Not a real problem, just a decision question. It could make the result be placed on stack, not returned imlicitly by reference, which makes it impossible to call legacy functions this way, but

why does it make impossible to call legacy functions?  actually, what do you mean by legacy functions - embedded C functions i presume?  their can't be much of any D legacy functions yet.

> might... be good for something. Opinions? And inout would simply mutate back to what they are - references?
> 
> But what if you use such a function in an expression - you get a real mess. Noone forces though.

i don't think that's necessary - the expression would use only the first returned value.

i think it'd go something like this:

int,int,int foo()
{
	return 1,2,3;
}

a,b,c = foo() // a == 1, b == 2, c == 3
d = foo(); // d = 1, the second & third return values are lost

x = foo()*foo() // x = 1 (1 * 1), the other values are ignored.


hmmm, how about this construct?
foreach x in foo(){ print x} // prints "1 2 3"

scott

Hi,

    Comments embedded.

"Scott Pigman" <scottpig1@attbi.com> escreveu na mensagem news:b088tj$2dr9$1@digitaldaemon.com...
> Hi There,
> I've just found out about D (thanks to slashdot), and i see a lot of stuff
> about it i really like -- several things that when i've thought to myself
> "if i ever made a programming language, i'd do _______" are in there.  It
> looks very promising to me.  anyway, if i may, i'd like to fire off a
> couple questions:
>
> 1) where is D at in regards to specifing the features that it includes? is it still pretty much a work in progress, or has it moved onto the "okay, that's enough discussion, now lets get it working" point, which is my impression from skimming the specs?


    Dmd compiler is in alpha stage, version 0.50, so there are lots of thing
that may change. Others are already settled, and some are trying to survive
the trials of time. In particular:

- Templates, unified function types and anonymous functions are things that
may get in or change in the next releases. Also reflection is a no man's
land currently.
- Interfaces and operator overloading are being discussed, but are already
quite stable in the language. Something may change if intelligent critics
are posted.
- Structs vs. classes in stack, in/out/inout modifiers, array semantics are
pretty much stablished. Some people still argue about it, but I think Walter
want things the way they are.


> 2) if it was still in the forming stages (or if i was making a language) the following are some things i'd be tempted to include.  now, my assumption is that these have already been discussed to death, since they're mainly things already in other languages, and probably some of the long time readers here would rather chuck their computer throught the window instead of read another thread on it, so please accept my apologies in advance.  I did skim the headers looking for relevent discussions, but as there are nearly 10,000 legacy messages here, it's a hell of a lot easier for me to just write this and hope someone out there doesn't mind responding.  basically, what i'm wondering is: if it was already discussed, what was the consensus regarding it, or is it already in the language and i overlooked it, or is it so obviously a bad idea that it wasn't even worthy of discussion.  anyway, in no particular order, here they are:


    This is a newsgroup, we always get in recurrent discussions ;-)

>
> unless/until syntatic sugarcoating, where "unless(false){}" ==
> "if(!false){}"  and "until(true)" == "while(!true)".  okay, these add no
> functionality, but i think that it would create easier to follow code,
> seeing how i get confused easily by logical negations >;-)


    I agree they're nice, but proliferation of control structures is a bad
thing, IMO. Generalized control structures, OTOH, are a way to go, but I
think D is more conservative and go through the path of all other C
derivatives.

>
> functions as first class objects.  now, i really have no idea what this means in terms of implementation or performance, but lisp has had it since day one, so i'd suspect it can't be too bad.  (of course, i don't know of many other languages that have it, so maybe it ain't so easy after all). but personally, being able to store functions in data structures, pass them (easily) as arguments to functions or creating fuctions which are themselves capable of creating and returning a functions just sounds very tantalizing to me.  having this would go hand in hand with having something equivalent to lisp/python lamda statements - i.e. anonymous, unnammed functions.


    D has delegates (pointer to object methods) and plain function pointers,
but the syntax for each one is different. Also there are no anonymous
functions with closure semantics, so most forms of higher-order programming
are difficult and error-prone.


>
> multiple return values from a function.  personally, i've never been very keen on the C/C++ idea of having parameters that are actually return values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i think it's a lot easier to follow code that has all the inputs in one place and the outputs in another.  i guess this wouldn't be compatibly with the IDL like the current in/out/inout specifiers, but i'd say that it's a lot more often that you'd write a function w/ multiple return values than write something that needs to be compatible w/ IDL.  and no, i wouldn't suggest getting rid of the in/out/inout specifiers, i'd just rather not use them myself all that often.


    The problem with multiple assigments is that usually they're linked with
a tuple construction/deconstruction pair of operations. Python uses multiple
assignments as a particular form of tuple deconstruction. And when we got
tuples in the language we are almost a functional language and that is a bad
thing... Just kidding ;-)


>
> java style online API/user libary documentation -- for my money, one of the best things about working with Java.  i'd hope that D would have a similar resource (and am puzzeled why c and c++ don't have something similar).


    There's some talk about embedding D source code in HTML, a la literate
programming http://www.literateprogramming.com/ AFAIK would be easy to add
javadoc-like documentation to D, because D is easy to parse, but nobody
written a tool for it yet. Any volunteers?


>
> lisp like closures.  now, of all the things here which i've heard about
> and like the sound of, but haven't actually used in practice, this one is
> the one i probably understand the least. but what i think i understand,
> appeals to me.  basically, my understanding is that this amounts to
> functions with a shared state - or perhaps they're anonymous, unnammed
> classes. e.g.  closure{ double total
> add(double x){total += x; return total}
> sub(double x){total += x; return total}
> }
> so, add and sub both act on the same variable total, but total is
> protected from having any other function modify it.  maybe not quite a
> global variable, but a national variable.  i dunno, sounds good to me
> though.  and if that isn't a lisp closure, well, then i like whatever it
> is i just described.
>

    See above.

> a foreach or forall statement for iterating over elements of a collection: "foreach person in newsgroup{.....}" where newsgroup is a collection/array of persons, and whatever's between the {}'s is code that is executed on each person.  to me this just seems a lot more intuitive to work with than "for(x = 0; x < Y; x++)..."
>
> the obvious name of the following unfortunately clashes with that of the previous, but having just wrapped up a course in program correctness i'm thinking i'd like to see boolean "forall" and "exists" expressions for use in contracts to verify the program correctness.  "forall x in X(cond)" would be true if all the x's in X satisfy the cond, and "exists x in X(cond)" would be true in any one x in X satisfied the cond.
>


    A for-each like statement will be in the language anytime soon, IIRC.
forall and exists quantifications are available (currently just for arrays)
in the Deimos Template Library www.minddrome.com/d/deimos/deimos-0.0.1.zip
As there is no standard way to iterate over collections (neither an iterator
template nor iterator constructs) there's no way of adding a foreach
statemente to every possible collection type. If you have some ideas post
them, perhaps you'll solve this problem.


>
> well, i think that's more than enough for now.  thanks for reading to anybody who actually got this far.  take care & good night.
>
> -scott


    The best way to change something in D is proving that current solution
is inneficient, awkward or unsafe, but your solution isn't. If you do
something in D (libraries, tools, etc.) you'll get a feeling about the way
things are in D and perhaps change your opinions, or become convinced that
you are right indeed :-)

    Best regards,
    Daniel Yokomiso.

"God is real, unless declared integer."

Hi,

    Comments embedded.

"Ilya Minkov" <midiclub@8ung.at> escreveu na mensagem news:b0accn$l2u$1@digitaldaemon.com...

[snip]

> > functions as first class objects.  now, i really have no idea what this means in terms of implementation or performance, but lisp has had it
since
> > day one, so i'd suspect it can't be too bad.  (of course, i don't know
of
> > many other languages that have it, so maybe it ain't so easy after all). but personally, being able to store functions in data structures, pass them (easily) as arguments to functions or creating fuctions which are themselves capable of creating and returning a functions just sounds
very
> > tantalizing to me.  having this would go hand in hand with having something equivalent to lisp/python lamda statements - i.e. anonymous, unnammed functions.
>
> Lisp is an interpreted language. What that means, is that you've always got a code generator at hand to generate some more code. In D this cannot be done. Maybe after a VM version of D is made (in years), something similar can be thought of. For now you can toss functions around as you like, but you can't create them at runtime. They need to be all defined to compile time. This possibility can be added as a library later, but it's probable that you'd only be able to use C or a small subset of D for runtime generation.
>
> It is a very complicated topic within non-interpreted environments, but i'm glad to tell you that it's a subject of my particular interest so i'll keep investigating how such things can be done. I guess Burton is also interested in something similar.
>
> Currently research is led to make code optimise itself at run-time. For example, there are values which become constant at run-time, but are not known at compile time. These would get optimised out then. But don't expect this to become real within your life span. :>


    The remark about Lisp is incorrect. AFAIK almost all Lisp compilers
compile also to native code (maybe there are a few exceptions). Check out at
http://www.cons.org/cmucl where there is a free (as in freedom)
implementation of Common Lisp. Other languages that have closures and are
compiled are OCaml, Haskell, SML, Smalltalk (has blocks and can be
compiled), Java (using inner classes with final variables as closures). It's
pretty much easy topic on non-interpreted environments. You just have to
pack a data structure together with a function pointer. I saw one message
some months ago (don't remember where) about a trick in C, where you define
a function, access it through a function pointer, malloc something with the
size of the function in memory, copy the fp to the memory area, access it
via a pointer, and change the hardcoded values inside the function, latter
executing it through the function pointer. It's a hack but it's possible.
    Also closures can be inlined by smart compilers without much code bloat
(some bloat is always inevitable if you inline things).


>
> > multiple return values from a function.  personally, i've never been
very
> > keen on the C/C++ idea of having parameters that are actually return values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i think it's a lot easier to follow code that has all the inputs in one place and the outputs in another.  i guess this wouldn't be compatibly with the IDL like the current in/out/inout specifiers, but i'd say that it's a lot more often that you'd write a function w/ multiple return values than write something that needs to be compatible w/ IDL.  and no,
i
> > wouldn't suggest getting rid of the in/out/inout specifiers, i'd just rather not use them myself all that often.
>
> Sweet. Hm. Not a real problem, just a decision question. It could make the result be placed on stack, not returned imlicitly by reference, which makes it impossible to call legacy functions this way, but might... be good for something. Opinions? And inout would simply mutate back to what they are - references?
>
> But what if you use such a function in an expression - you get a real mess. Noone forces though.


    This kind of thing is very tricky. if you have:

(int, int, int) a(int a) {
    return a,a,a;
}
int b(int a, int b, int c) {
    return a + b + c;
}

    Can you do this or not?

int six = b(a(2));

    Using stack semantics we could do this, but it open some strange
possibilities. Other possibilitie is to use tuple semantics, but this has
its complications too (changes the type system in several ways). Note that a
template Pair or Triple can do a similar job here, simplifying our work.

Triple(int,int,int) a(int a) {
    return new triple(a,a,a);
}


>
> > java style online API/user libary documentation -- for my money, one of the best things about working with Java.  i'd hope that D would have a similar resource (and am puzzeled why c and c++ don't have something similar).
>
> Well, that's something you could make someday. ;)  In my personal opinion, D is quite unlike c++ suited as an educational language, so a lot of easy-to-read documentation would have to be written. But of course, Consider: C comes with a tiny library only. But of course there is a description of it. As of c++, there is no common style, little common libraries and tools, and a LOT of resources. C++ coders don't understand each other when they talk. It shouldn't happen to D. It gets a decent library, which in turn needs documentation.
>
> > lisp like closures.  now, of all the things here which i've heard about and like the sound of, but haven't actually used in practice, this one
is
> > the one i probably understand the least. but what i think i understand,
> > appeals to me.  basically, my understanding is that this amounts to
> > functions with a shared state - or perhaps they're anonymous, unnammed
> > classes. e.g.  closure{ double total
> > add(double x){total += x; return total}
> > sub(double x){total += x; return total}
> > }
> > so, add and sub both act on the same variable total, but total is
> > protected from having any other function modify it.  maybe not quite a
> > global variable, but a national variable.  i dunno, sounds good to me
> > though.  and if that isn't a lisp closure, well, then i like whatever it
> > is i just described.
>
> Any real usage? Consider using templates, or just creating another module in such case. Such closures would only resolve unit-scope ambiguities, which you would have to stumble over later when making some minor change. It simply takes accurate naming to avoid it. It is better to correct a bug than to hide it, right? Consider also: keeping units (=modules) small enough would do legibility good.
>


    If you do higher-order programming, closures are very useful, specially
when you want some partial application. A good starting point is
http://www.md.chalmers.se/~rjmh/Papers/whyfp.html or
http://www.cs.ukc.ac.uk/pubs/1997/224/index.html A simple example is a map
function:


int[] scale(int[] numbers, int scale) {
    return numbers.map(i anon(int i) {return i * scale});
}


    Map apply the function to each item of the array, creating a new array
with the results. There are other usages, if you're interested I can dig
some nice examples of Higher-Order Functions (HOF) expressiveness.


> > a foreach or forall statement for iterating over elements of a
collection:
> > "foreach person in newsgroup{.....}" where newsgroup is a
collection/array
> > of persons, and whatever's between the {}'s is code that is executed on each person.  to me this just seems a lot more intuitive to work with
than
> > "for(x = 0; x < Y; x++)..."
>
> I'm pretty much sure Walter is considering this right now.
>
> > the obvious name of the following unfortunately clashes with that of the previous, but having just wrapped up a course in program correctness i'm thinking i'd like to see boolean "forall" and "exists" expressions for
use
> > in contracts to verify the program correctness.  "forall x in X(cond)"
> > would be true if all the x's in X satisfy the cond, and "exists x in
> > X(cond)" would be true in any one x in X satisfied the cond.
>
> Hm. {We} are afraid of too many keywords :> as well as of complex parsing. So that features like ^^ runtime-generated functions could become possible someday. Well, a keyword or two doesn't matter but... Hm. What I am considering is an alternative plugin-driven parsing possibility, which would make it possible to make some tests without messing around with the actual language, as well as add a few functional programming constructs. D better stay lighweight, so that it is as easy to learn as Delphi, and yet to combine the powers of Perl and C++ and everything needed really often. Whereas i don't consider pure english keywords a danger for learnability.
>


    With HOFs we can do this. Deimos Template Library
http://www.minddrome.com/d/deimos/deimos-0.0.1.zip provides all, any and
none quantifiers (I think they're in this release) for arrays as template
functions, so you just write:

public boolean isOdd(int n) {
    return n % 2 != 0;
}
instance TArrays(int) arrays;
const int[] numbers = ...;
if (arrays.all(numbers, &isOdd)) { ...}
if (arrays.any(numbers, &isOdd)) { ...}


> > well, i think that's more than enough for now.  thanks for reading to anybody who actually got this far.  take care & good night.
> >
> > -scott
>


    Best regards,
    Daniel Yokomiso.

"Lord save me from your followers."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003

"Mike Wynn" <mike.wynn@l8night.co.uk> escreveu na mensagem news:b0af79$mo1$1@digitaldaemon.com...
> >
> > Currently research is led to make code optimise itself at run-time. For example, there are values which become constant at run-time, but are not known at compile time. These would get optimised out then. But don't expect this to become real within your life span. :>
> >
> that is exactly what java dynamic compilers do, and is why some companies
> claim that their Java VM's can run code faster than C/C++
> because the code executed it the true mainline (all if rewritten to branch
> out as the rare condition) calculated by interpeting the code a few times
> first and only compiling the code that is actually executed, reorder,
> inlined and generally mess about with so within any complete section all
the
> computed values are right, the flow or way they are calculated may not be anything like a statically compiled version of the same code, and a
section
> of code may end up being compiled in several different ways depending on
how
> you get to it. something that it would be possible to do with a static
> compiler linked to a profiler, assuming that your profile the correct data
> :) before setting your code "in stone". but I doubt with the dynamic
> adjustment to input that a true dynamic compiler offers.
> there are also benifits to the GC too, you can determine short lived
> objects,  the way the objects interconections and allocations are arranged
> allowing ahead of time object allocations, pruning known dead objects and
> optimise the way the GC walks the stack etc.
>

    One of the main advantages of a JIT compiler is that it can perform
whole-world optimizations, deciding which methods may be inlined, which
methods are truly dynamic, etc.. Every libray loaded goes through this
process. A static compiler that generates dlls must provide the worst case
binary. As a side note Portable Net interpreter (www.dotgnu.org for more
info) is sometimes faster than JIT compilers from Mono or DotNet, because it
doesn't try to analyze and JIT things first, it just interprets it as fast
as it can.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003

Daniel Yokomiso wrote:
> Hi,
> 
>     Comments embedded.
> 
> "Ilya Minkov" <midiclub@8ung.at> escreveu na mensagem
> news:b0accn$l2u$1@digitaldaemon.com...
> 
> [snip]
> 
> 
>>>functions as first class objects.  now, i really have no idea what this
>>>means in terms of implementation or performance, but lisp has had it
> 
> since
> 
>>>day one, so i'd suspect it can't be too bad.  (of course, i don't know
> 
> of
> 
>>>many other languages that have it, so maybe it ain't so easy after all).
>>>but personally, being able to store functions in data structures, pass
>>>them (easily) as arguments to functions or creating fuctions which are
>>>themselves capable of creating and returning a functions just sounds
> 
> very
> 
>>>tantalizing to me.  having this would go hand in hand with having
>>>something equivalent to lisp/python lamda statements - i.e. anonymous,
>>>unnammed functions.
>>
>>Lisp is an interpreted language. What that means, is that you've always
>>got a code generator at hand to generate some more code. In D this
>>cannot be done. Maybe after a VM version of D is made (in years),
>>something similar can be thought of. For now you can toss functions
>>around as you like, but you can't create them at runtime. They need to
>>be all defined to compile time. This possibility can be added as a
>>library later, but it's probable that you'd only be able to use C or a
>>small subset of D for runtime generation.
>>
>>It is a very complicated topic within non-interpreted environments, but
>>i'm glad to tell you that it's a subject of my particular interest so
>>i'll keep investigating how such things can be done. I guess Burton is
>>also interested in something similar.
>>
>>Currently research is led to make code optimise itself at run-time. For
>>example, there are values which become constant at run-time, but are not
>>known at compile time. These would get optimised out then. But don't
>>expect this to become real within your life span. :>
> 
> 
> 
>     The remark about Lisp is incorrect. AFAIK almost all Lisp compilers
> compile also to native code (maybe there are a few exceptions). Check out at
> http://www.cons.org/cmucl where there is a free (as in freedom)
> implementation of Common Lisp. Other languages that have closures and are
> compiled are OCaml, Haskell, SML, Smalltalk (has blocks and can be
> compiled), Java (using inner classes with final variables as closures). It's
> pretty much easy topic on non-interpreted environments. You just have to
> pack a data structure together with a function pointer. I saw one message
> some months ago (don't remember where) about a trick in C, where you define
> a function, access it through a function pointer, malloc something with the
> size of the function in memory, copy the fp to the memory area, access it
> via a pointer, and change the hardcoded values inside the function, latter
> executing it through the function pointer. It's a hack but it's possible.
>     Also closures can be inlined by smart compilers without much code bloat
> (some bloat is always inevitable if you inline things).

HM. But is the lisp compiler *always at hand*? I don't know lisp.

I'll have to look up how closures are done in OCaml.

OK, it basically means you need a piece of code which makes sense, then it can be compiled. But you can't eval() some run-time generated string like in perl. Such work is being done in "Tick C", where you always carry a compiler with you. It would also optimise out many operations depending on the run-time constants. The current Tick C compiler is made  out of the infamous LCC 3.6 and uses VCode as its back-back-end. I plan to finish the port of VCode to x86, and to adapt TickCC backend for D, adding the "tick" possibilities.

I wonder how you can keep track of so many languages - i chose D because it's almost nothing new to learn for me, not too many new problems to stumble over... Another language which I *have* to learn is OCaml, but i see a lot of sense in it and i'm doing it with plaesure. I have no more power to learn another different language, just for myself. But well, i also have hobbies like drawing, 3d gfx, music (hence my nickname).

>>>multiple return values from a function.  personally, i've never been
> 
> very
> 
>>>keen on the C/C++ idea of having parameters that are actually return
>>>values.  i like the python model here: "a,b,c = foo(x,y,z)".  again, i
>>>think it's a lot easier to follow code that has all the inputs in one
>>>place and the outputs in another.  i guess this wouldn't be compatibly
>>>with the IDL like the current in/out/inout specifiers, but i'd say that
>>>it's a lot more often that you'd write a function w/ multiple return
>>>values than write something that needs to be compatible w/ IDL.  and no,
> 
> i
> 
>>>wouldn't suggest getting rid of the in/out/inout specifiers, i'd just
>>>rather not use them myself all that often.
>>
>>Sweet. Hm. Not a real problem, just a decision question. It could make
>>the result be placed on stack, not returned imlicitly by reference,
>>which makes it impossible to call legacy functions this way, but
>>might... be good for something. Opinions? And inout would simply mutate
>>back to what they are - references?
>>
>>But what if you use such a function in an expression - you get a real
>>mess. Noone forces though.
> 
> 
> 
>     This kind of thing is very tricky. if you have:
> 
> (int, int, int) a(int a) {
>     return a,a,a;
> }
> int b(int a, int b, int c) {
>     return a + b + c;
> }
> 
>     Can you do this or not?
> 
> int six = b(a(2));

My brain overheats. I'd say yes... but then it is the same as returning a structure. And taking a structure. Someone in the hread suggested ignoring extra parameters, but it's *very evil*. It would inevitably lead to a new class of bugs.

Maybe it's the solution - anonymous structure defined by the types. It would also allow writing functions recieving structures, and feed them with any data of the corresponding types.

> 
>     Using stack semantics we could do this, but it open some strange
> possibilities. Other possibilitie is to use tuple semantics, but this has
> its complications too (changes the type system in several ways). Note that a
> template Pair or Triple can do a similar job here, simplifying our work.
> 
> Triple(int,int,int) a(int a) {
>     return new triple(a,a,a);
> }
> 

Good job, Daniel. I just have to take a look at the library when I have time. It's like you foresee everything :)

> 
> 
>>>java style online API/user libary documentation -- for my money, one of
>>>the best things about working with Java.  i'd hope that D would have a
>>>similar resource (and am puzzeled why c and c++ don't have something
>>>similar).
>>
>>Well, that's something you could make someday. ;)  In my personal
>>opinion, D is quite unlike c++ suited as an educational language, so a
>>lot of easy-to-read documentation would have to be written. But of
>>course, Consider: C comes with a tiny library only. But of course there
>>is a description of it. As of c++, there is no common style, little
>>common libraries and tools, and a LOT of resources. C++ coders don't
>>understand each other when they talk. It shouldn't happen to D. It gets
>>a decent library, which in turn needs documentation.
>>
>>
>>>lisp like closures.  now, of all the things here which i've heard about
>>>and like the sound of, but haven't actually used in practice, this one
> 
> is
> 
>>>the one i probably understand the least. but what i think i understand,
>>>appeals to me.  basically, my understanding is that this amounts to
>>>functions with a shared state - or perhaps they're anonymous, unnammed
>>>classes. e.g.  closure{ double total
>>>add(double x){total += x; return total}
>>>sub(double x){total += x; return total}
>>>}
>>>so, add and sub both act on the same variable total, but total is
>>>protected from having any other function modify it.  maybe not quite a
>>>global variable, but a national variable.  i dunno, sounds good to me
>>>though.  and if that isn't a lisp closure, well, then i like whatever it
>>>is i just described.
>>
>>Any real usage? Consider using templates, or just creating another
>>module in such case. Such closures would only resolve unit-scope
>>ambiguities, which you would have to stumble over later when making some
>>minor change. It simply takes accurate naming to avoid it. It is better
>>to correct a bug than to hide it, right? Consider also: keeping units
>>(=modules) small enough would do legibility good.
>>
> 
> 
> 
>     If you do higher-order programming, closures are very useful, specially
> when you want some partial application. A good starting point is
> http://www.md.chalmers.se/~rjmh/Papers/whyfp.html or
> http://www.cs.ukc.ac.uk/pubs/1997/224/index.html A simple example is a map
> function:
> 
> 
> int[] scale(int[] numbers, int scale) {
>     return numbers.map(i anon(int i) {return i * scale});
> }
> 
> 
>     Map apply the function to each item of the array, creating a new array
> with the results. There are other usages, if you're interested I can dig
> some nice examples of Higher-Order Functions (HOF) expressiveness.
> 

I didn't understand something yet. I'll take myself time to study it.

> 
> 
>>>a foreach or forall statement for iterating over elements of a
> 
> collection:
> 
>>>"foreach person in newsgroup{.....}" where newsgroup is a
> 
> collection/array
> 
>>>of persons, and whatever's between the {}'s is code that is executed on
>>>each person.  to me this just seems a lot more intuitive to work with
> 
> than
> 
>>>"for(x = 0; x < Y; x++)..."
>>
>>I'm pretty much sure Walter is considering this right now.
>>
>>
>>>the obvious name of the following unfortunately clashes with that of the
>>>previous, but having just wrapped up a course in program correctness i'm
>>>thinking i'd like to see boolean "forall" and "exists" expressions for
> 
> use
> 
>>>in contracts to verify the program correctness.  "forall x in X(cond)"
>>>would be true if all the x's in X satisfy the cond, and "exists x in
>>>X(cond)" would be true in any one x in X satisfied the cond.
>>
>>Hm. {We} are afraid of too many keywords :> as well as of complex
>>parsing. So that features like ^^ runtime-generated functions could
>>become possible someday. Well, a keyword or two doesn't matter but...
>>Hm. What I am considering is an alternative plugin-driven parsing
>>possibility, which would make it possible to make some tests without
>>messing around with the actual language, as well as add a few functional
>>programming constructs. D better stay lighweight, so that it is as easy
>>to learn as Delphi, and yet to combine the powers of Perl and C++ and
>>everything needed really often. Whereas i don't consider pure english
>>keywords a danger for learnability.
>>
> 
> 
> 
>     With HOFs we can do this. Deimos Template Library
> http://www.minddrome.com/d/deimos/deimos-0.0.1.zip provides all, any and
> none quantifiers (I think they're in this release) for arrays as template
> functions, so you just write:
> 
> public boolean isOdd(int n) {
>     return n % 2 != 0;
> }
> instance TArrays(int) arrays;
> const int[] numbers = ...;
> if (arrays.all(numbers, &isOdd)) { ...}
> if (arrays.any(numbers, &isOdd)) { ...}
> 
> 
> 
>>>well, i think that's more than enough for now.  thanks for reading to
>>>anybody who actually got this far.  take care & good night.
>>>
>>>-scott
>>
> 
> 
>     Best regards,
>     Daniel Yokomiso.
> 
> "Lord save me from your followers."
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
> 
> 

Hi,

    Comments embedded.

"Ilya Minkov" <midiclub@8ung.at> escreveu na mensagem news:b0bj31$1a9a$1@digitaldaemon.com...
> Daniel Yokomiso wrote:
[snip]
> >
> >     The remark about Lisp is incorrect. AFAIK almost all Lisp compilers
> > compile also to native code (maybe there are a few exceptions). Check
out at
> > http://www.cons.org/cmucl where there is a free (as in freedom) implementation of Common Lisp. Other languages that have closures and
are
> > compiled are OCaml, Haskell, SML, Smalltalk (has blocks and can be
> > compiled), Java (using inner classes with final variables as closures).
It's
> > pretty much easy topic on non-interpreted environments. You just have to pack a data structure together with a function pointer. I saw one
message
> > some months ago (don't remember where) about a trick in C, where you
define
> > a function, access it through a function pointer, malloc something with
the
> > size of the function in memory, copy the fp to the memory area, access
it
> > via a pointer, and change the hardcoded values inside the function,
latter
> > executing it through the function pointer. It's a hack but it's
possible.
> >     Also closures can be inlined by smart compilers without much code
bloat
> > (some bloat is always inevitable if you inline things).
>
> HM. But is the lisp compiler *always at hand*? I don't know lisp.
>


    AFAIK it's not necessary but Lisp people like having the compiler
available at runtime. I would like that too ;-)


> I'll have to look up how closures are done in OCaml.
>
> OK, it basically means you need a piece of code which makes sense, then
> it can be compiled. But you can't eval() some run-time generated string
> like in perl. Such work is being done in "Tick C", where you always
> carry a compiler with you. It would also optimise out many operations
> depending on the run-time constants. The current Tick C compiler is made
>   out of the infamous LCC 3.6 and uses VCode as its back-back-end. I
> plan to finish the port of VCode to x86, and to adapt TickCC backend for
> D, adding the "tick" possibilities.


    At Paul Graham's site, http://www.paulgraham.com/rootsoflisp.html ,
there's a nice summary about Lisp two links. One to a paper from John
McCarthy, where he explains the Lisp language, and other to the code written
in this primordial Lisp. Notice that the eval function is written in Lisp
and use just Lisp types (atom and list). They don't need to eval strings,
because their list datatype is very powerful. Of course this eval is slow as
hell, but it proves some point.


>
> I wonder how you can keep track of so many languages - i chose D because it's almost nothing new to learn for me, not too many new problems to stumble over... Another language which I *have* to learn is OCaml, but i see a lot of sense in it and i'm doing it with plaesure. I have no more power to learn another different language, just for myself. But well, i also have hobbies like drawing, 3d gfx, music (hence my nickname).


    I had other hobbies too, poetry, martial arts, bike riding, comic book
reading. But I had to keep track of that many languages when I started
developing my own. Back in the far past of abril of 2001 I started growing
bored of Java and read a paper about Design by Contract in Java. It led me
to Eiffel and comp.lang.eiffel. Skimming old posts I've got into some wars
about OO vs. functional, Eiffel vs. C++ and had time to read them. In
comp.java.lang.advocacy I've got accross Java vs. C# wars, which were very
interesting, because I was designing a language to overcome the flaws in
those. In these kind of posts people always post links to their favourite
languages, or papers about some corner of computer science. As I'm addicted
to information I started reading about all of it, got into Sather, OCaml,
Haskell, Smalltalk, and others. Note that I don't develop in those
languages, just read a lot about their concepts, and tried to grok them. IMO
there's something good in every language and language construct. I don't say
"Perl sucks, it's just noise in form of code!" or things like that. I
usually think, hmmm these Perl guys have a nice feature in their language,
unfortunally the syntax is awful. Are there any way to make it clearer,
safer and as terse as (or with a minimum ammount of verbosity added)? But
there are some languages that every programmer should at least read a
tutorial about (all with tutorials available online): Smalltalk, Eiffel,
Sather, OCaml, SML, Lisp, Haskell, C++, C++ template expressions, Java,
Python, Perl, Ruby, C and, of course, D. There are others, some useful like
Prolog, Sisal or Scheme, some surreal like Befunge, Unlambda or Intercal,
which are also nice to read about. It open your horizon to different views
of programming.


[snip]

> >
> >
> >
> >     This kind of thing is very tricky. if you have:
> >
> > (int, int, int) a(int a) {
> >     return a,a,a;
> > }
> > int b(int a, int b, int c) {
> >     return a + b + c;
> > }
> >
> >     Can you do this or not?
> >
> > int six = b(a(2));
>
> My brain overheats. I'd say yes... but then it is the same as returning a structure. And taking a structure. Someone in the hread suggested ignoring extra parameters, but it's *very evil*. It would inevitably lead to a new class of bugs.
>
> Maybe it's the solution - anonymous structure defined by the types. It would also allow writing functions recieving structures, and feed them with any data of the corresponding types.
>


    As I said very tricky. But think about it:


(int, int) c(int a, int b) {
    return a / b, a % b;
}
int d(int a, int b, int c, int d) {
    return a + b + c + d;
}

int x = d(c(1,2), c(3,4));


    The possibilities are infinite. It may look nice or awful depending on
your point of view. And it should also fit in the other parts of the
language, or we'll become like C++ or Perl.


> >
> >     Using stack semantics we could do this, but it open some strange
> > possibilities. Other possibilitie is to use tuple semantics, but this
has
> > its complications too (changes the type system in several ways). Note
that a
> > template Pair or Triple can do a similar job here, simplifying our work.
> >
> > Triple(int,int,int) a(int a) {
> >     return new triple(a,a,a);
> > }
> >
>
> Good job, Daniel. I just have to take a look at the library when I have time. It's like you foresee everything :)
>


    Hey, I just copy the ideas from other people ;-) As I said I'm designing
my language too, and everytime I've read the Haskell prelude or the basic ML
functions I fell ashamed :-)

[snip]

> >
> >     If you do higher-order programming, closures are very useful,
specially
> > when you want some partial application. A good starting point is http://www.md.chalmers.se/~rjmh/Papers/whyfp.html or http://www.cs.ukc.ac.uk/pubs/1997/224/index.html A simple example is a
map
> > function:
> >
> >
> > int[] scale(int[] numbers, int scale) {
> >     return numbers.map(i anon(int i) {return i * scale});
> > }
> >
> >
> >     Map apply the function to each item of the array, creating a new
array
> > with the results. There are other usages, if you're interested I can dig some nice examples of Higher-Order Functions (HOF) expressiveness.
> >
>
> I didn't understand something yet. I'll take myself time to study it.
>


    Closures are tricky to grasp right, specially for us, people with
imperative programming backgrounds.


[snip]


    Best regards,
    Daniel Yokomiso.

"Creative minds have always been known to survive any kind of bad training." - Anna Freud


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003