Mark T wrote:
<snip>
> I agree with Stewart about the library stuff, phobos is good enough for version
> 1.0.

Are these two clauses supposed to be related in any way?  If so, I can't see it.

And have you evaluated its every module for completeness?  For example, what about the issues here?

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <d09vbl$1d09$1@digitaldaemon.com>, Mark T says...
>
>>** Euphoria-to-D translator
>>---------------------------
>>I love using the Euphoria language for applications that don't need blistering speed (its an interpreted language). It is sort of like a dynamically typed D. But there are two aspects that irk me though.
>>  (a) Sometimes a bit of speed is required, but not As Fast As Possible
>>type speed. So translating Euphoria to D then compiling the D code should help speed up things.
>>  (b) It is not open source, and the "Walter"-type that controls its
>>evolution is really slow to add anything useful, and resists 'modernization'. Euphoria was designed in 1993 and is still only at v2.4.
>>
>>So this is my first step in creating an open source version of a language translator. This will be a springboard for creating an alternative interpreter. Currently, I'm implementing the built-in data types (all four of them) supported by Euphoria - integer, atom, sequence and object. This is progressing well and I'm about 50% done with that phase.
>>
>
>please post link to this language.

I think this is the "official" Euphoria web site if that's what you're seeking: http://www.rapideuphoria.com/

jcc7

Jan-Eric Duden wrote:

>> Strings in D are protected from overwriting by the Honor System™...
> 
> How can a D coder know if it is safe to store just the reference or if
> he needs to make a copy.
> Right now, to be on the safe side - he actually needs to make a copy.
> Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

Copy-on-Write and immutable strings have a great advantage over
deep copying and mutable strings, both when it comes to performance
and when it comes to thread-safety (avoiding locks is also performance)

Along with slices and garbage collection, it gives D great speed...

What is needed is a method in the language to make sure that this
is enforced, when passing arrays to other modules and functions ?
Without it, as you say, strings *could* be modified by the method.

But I'm still hoping that it can be done without const / class...

--anders

PS. See also the "immutable strings" thread, and others like it.

Anders F Björklund wrote:
> Jan-Eric Duden wrote:
> 
>>> Strings in D are protected from overwriting by the Honor System™...
>>
>>
>> How can a D coder know if it is safe to store just the reference or if
>> he needs to make a copy.
>> Right now, to be on the safe side - he actually needs to make a copy.
>> Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.
> 
> 
> Copy-on-Write and immutable strings have a great advantage over
> deep copying and mutable strings, both when it comes to performance
> and when it comes to thread-safety (avoiding locks is also performance)
> 
> Along with slices and garbage collection, it gives D great speed...
> 
> What is needed is a method in the language to make sure that this
> is enforced, when passing arrays to other modules and functions ?
> Without it, as you say, strings *could* be modified by the method.
> 
> But I'm still hoping that it can be done without const / class...
> 
> --anders
> 
> PS. See also the "immutable strings" thread, and others like it.
If i can get immutable string without a class and const, I'd be happy.:)

I wonder how this can be implemented without one of these concepts?

In article <d086f9$2kbb$1@digitaldaemon.com>, Dejan Lekic says...
>
>
>I very much dislike choice of having JAVA-like functionNames... That might
>even come to turning back to D. :( I thought pretty much about resons
>behind using that naming convention and there was none good reason i could
>come to. Seriously.
>Someone pointed out that people use it to distinct from class-names. Well,
>if i have dot (".") before it, it cannot be the class! :)

Many believe that it's important to distinguish type names from other symbols, and it's been shown that doing so increases readability.  I don't think it matters what the convention is so long as it's consistent.  Personally, I'm in the lowercase/underscore camp for C++ development (as it's the convention marginally established by the C/C++ standard libraries) but when in D...


Sean

"Glen Perkins" <Glen_member@pathlink.com> wrote in message news:d05f1m$vrd$1@digitaldaemon.com...
> In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>
> Yes, many things will still be changeable, but many will not. The "stake
> in the
> ground" is a stake thru the heart of anybody who still fervently hopes to
> pursuade you to change certain things before it's too late. Even though it
> is
> true that D will undergo continuous improvement, you will never again be
> completely free to "do things right" after 1.0 ships.

I agree with the heartache of a 1.0 that can't be changed.  But I'd like to make the point that D is a lot of best practices.  Take the success of C, Eiffel, Java, C++ and throw out the weaknesses where possible.  D doesn't have an all-new exception system or an all new X-oriented paradigm and way of thinking.  Aspect-Oriented is too new to know what will come of it... and it's not in D.  In other words, some of the exposing to the public has been done, and some of the critical thinking has been done... in the form of avoiding the obvious, well-vocalized mistakes of these other languages.

Maybe another way to approach this is to add those things which the current community want and that the world-at-large has never complained about (array and struct init, or whatever).  And *back out of* any features that are currently controvertial (unit testing powerful enough?) and unusual for the world.  Stake that as 1.0.

Then get more debate for 2.0 and the controversial features.

I think there is plenty of fruit juicy goodness in the non-controversial features.  (compiled, slices, etc.) to warrant a 1.0 and get some first-round libraries started.  (Will the APIs be formal enough so that the underlying impl can be improved?)

"Walter" <newshound@digitalmars.com> wrote in message news:d05hcn$12oe$1@digitaldaemon.com...
> C++'s groundbreaking ideas w.r.t. generic programming are, in a word,
> brilliant. But I, too, find the expression of those ideas in the C++
> syntax
> to be so flawed as to be well nigh unusable.

Maybe you've see the interview with the authors, but they had planned to write a new language to support the idea of generic programming.  Then templates were coming along and, I think, Stroustrup convinced them to write the STL.  They claim happiness, but I don't think it turned out as expected. Anyway, if all this is true, it's another good example of placing a stake to early.  I think Java was moving in about then and the C++ people were probably desperate to show off the power of a more complete language so they rushed out templates and STL.  (Not that this was expressed in the article.) Now we're stuck with it and the only way "back" is with a new language.

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:d07dbj$24e$1@digitaldaemon.com...
> Walter wrote:
> I think the most important component to woo C++/Java developers is Phobos.
> I have spoken with people who have shown an interest in D, but without a
> standard library that offers what they have come to take for granted most
> of them are hesitant to take the plunge.

This is my point, too.  However, I'm sitting on the fence between a Java library rip-off and something truly wonderful.  I was a bit disappointed when I looked through the Java libraries which were just the same old SmallTalk libraries.  No templates, no generics, not even any speed/memory trade-off possibilities.  I used to work in 3D graphics, so I could just have any old container without controlling it a bit algorithmically.

So would it be best to have a simple Java-like set of containers and libs? Or a cleaned-up STL with all it's power and then some?  Possibly it could be STL like in one layer, then have some quick and dirty "containers" written on top of that for rapid app development.

On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
> Anders F Björklund wrote:
>> Jan-Eric Duden wrote:
>>
>>>> Strings in D are protected from overwriting by the Honor System™...
>>>
>>>
>>> How can a D coder know if it is safe to store just the reference or if
>>> he needs to make a copy.
>>> Right now, to be on the safe side - he actually needs to make a copy.
>>> Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.
>>   Copy-on-Write and immutable strings have a great advantage over
>> deep copying and mutable strings, both when it comes to performance
>> and when it comes to thread-safety (avoiding locks is also performance)
>>  Along with slices and garbage collection, it gives D great speed...
>>  What is needed is a method in the language to make sure that this
>> is enforced, when passing arrays to other modules and functions ?
>> Without it, as you say, strings *could* be modified by the method.
>>  But I'm still hoping that it can be done without const / class...
>>  --anders
>>  PS. See also the "immutable strings" thread, and others like it.
> If i can get immutable string without a class and const, I'd be happy.:)
>
> I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters.

That will basically say, for this function:
  void foo(char[] a, inout char[] b);

a will not be modified, b might be modified.

It's a contract. It needs to be enforced.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm4wt1uo23k2f5@ally...
> On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
>> Anders F Björklund wrote:
>>> Jan-Eric Duden wrote:
>>>
>>>>> Strings in D are protected from overwriting by the Honor SystemT...
>>>>
>>>>
>>>> How can a D coder know if it is safe to store just the reference or if
>>>> he needs to make a copy.
>>>> Right now, to be on the safe side - he actually needs to make a copy.
>>>> Otherwise, somewhere in her system or in external libraries the string
>>>> might get changed without her knowledge.
>>>   Copy-on-Write and immutable strings have a great advantage over
>>> deep copying and mutable strings, both when it comes to performance
>>> and when it comes to thread-safety (avoiding locks is also performance)
>>>  Along with slices and garbage collection, it gives D great speed...
>>>  What is needed is a method in the language to make sure that this
>>> is enforced, when passing arrays to other modules and functions ?
>>> Without it, as you say, strings *could* be modified by the method.
>>>  But I'm still hoping that it can be done without const / class...
>>>  --anders
>>>  PS. See also the "immutable strings" thread, and others like it.
>> If i can get immutable string without a class and const, I'd be happy.:)
>>
>> I wonder how this can be implemented without one of these concepts?
>
> I think the first step is enforcing 'constness' on 'in' parameters.
>
> That will basically say, for this function:
>   void foo(char[] a, inout char[] b);
>
> a will not be modified, b might be modified.
>
> It's a contract. It needs to be enforced.
>
> Regan
>

Changing the semantics of "in" to also apply to references would be a huge change and it would go against the default semantics of C. A (slightly) more practical proposal is to have parameters explicitly declared as "in" be read-only but even then it would be a big change and we'd have to think about how the read-only-ness would be represented in the type and passed along to other variables. Basically I think the only real way to add this to D if it ever gets added is to have another type attribute like C/C++'s const.

Note that there really isn't anything special about strings, too. Any type with reference semantics is at the mercy of the functions it gets passed to. Class objects, arrays in general, etc. They all rely on implicit contracts that the functions do what they say they do.