Jarrett Billingsley wrote:
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.47.1203635455.2351.digitalmars-d@puremagic.com...
> 
>> And while we're on the subject of random falling over, am I the only
>> one who gets infuriated by the occasional "Win32 Exception" halting a
>> program with no further explanation? They happen when the flow of
>> execution hits the bottom of a function without returning, when it's
>> supposed to return something. I'm surprised we can't catch those at
>> compile time, but even a nice D Exception throw at runtime (...again,
>> in a debug build only...) would be useful.
> 
> Except that it _does_ throw an exception to that effect in a debug build. God, have you even _used_ D? 

Only on windows.  On any posix/unix platform it doesn't.  Throwing exceptions for these sorts of faults is dubious, imho, but windows has made it seem normal.

Later,
Brad

Ary Borenszweig wrote:
> Janice Caron escribió:
>> On 21/02/2008, Michiel Helvensteijn <nomail@please.com> wrote:
>>> It's silly that 'in' does not return a bool.
>>
>> Huh? But I don't want it to return a bool. If it retured a bool, I
>> wouldn't be able to do
>>
>>     auto p = key in aa;
>>     if (p is null)
>>     {
>>         /* do something */
>>     }
>>     else
>>     {
>>         return *p;
>>     }
>>
>> Without that ability, you'd have to do a double-lookup!
> 
> I think the best solution is the one in .Net:
> 
> object value;
> if (aa.TryGetValue(key, out value)) {
>   // Key found, value may be null
> } else {
>   // Key not found
> }

That would be better if the language allowed:
// value not defined
if (aa.TryGetValue(key, out object value))
{
  // ok, now I can use value
}
else
{
  // Key not found
}

Bill Baxter wrote:
> On the other hand, the "return a reference" solution also has drawbacks in that it exposes the implementation and gives up control over the element.  Consider for instance an array wrapper where you want to track every modification to every element.  Currently you can do that quite easily by making opIndexAssign the only means of modifying the data. But then you can't do things like a[10] += 5.   So I think there's a place for the solution you use in MiniD as well.  Even after reference returns become possible I'd be happy to see the compiler use that trick in cases where there is no reference-returning version of opIndex defined.
> 
> --bb

C# does exactly the same as MiniD. I don't recall how that works with opDot on structs, though.

Leandro Lucarella wrote:
> I think D1.0 is good enough and deserves a little love to finally polish
> all the rough corners and make it move forward in small and backward
> compatible steps to be a nice, maintained and usable language.

The frontend is open source; care to volunteer?

On Thu, 21 Feb 2008 16:24:11 -0800, Robert Fraser wrote:

> Moritz Warning wrote:
>> On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:
>> 
>>> bearophile wrote:
>>>> Another solution is to think "in" as an operator, and "!in" as two operators, where ! negates the result of the precedent "in", where "in" returns a pointer. I don't see this as silly :-)
>>> I should have read this first. Yes, that's exactly what I would like.
>> 
>> Fwiw:
>> "is" may be no boolean operator, but "!" is a boolean operator. Hence,
>> "!is" can be boolean operator the same way as "=" is not a boolean
>> operator, but "!=" is.
> 
> Did you man "in"? "is" is a boolean operator.

Yes, I meant "in", not "is". - memory corruption. ;)

"=" is no boolean operator, but "!=" is.
The reason for not having "!in" is weak, imho.

On 22/02/2008, Derek Parnell <derek@nomail.afraid.org> wrote:
>  > Have you seen std.xml?
>
> Which by the way is quite nice code and works well. (I was wondering how it
>  can be used to generate a DTD file from an XML document though.)

Right now, it can't. That's a "future direction" for it. Basically, right now, it can't parse inside so-called "XML instructions" - those weird things that you see in the prolog that start with "<!", like <!DOCTYPE...> and <!ATTLIST...> and <!...ENTITY>. Currently, it treats those things like opaque blobs and doesn't bother to look inside them. DTDs (which are specified inside the <!DOCTYPE...> instruction) are a whole level of complexity above and beyond XML itself - and not to mention, now pretty much obsolete, having already been replaced by XML Schema.

There are quite a few things I want to add to that module in time, including (in no particular order) full support for XML namespaces, DTDs and XML schemas (both full validation and creation thereof), XSL style sheets, and so on. But I think the next thing I want to tackle with regard to XML is the encoding. If a document starts "<?xml version="1.0" encoding="ISO-8859-1"> then we're screwed, because D only handles Unicode. Even reading in the document is hard! Tackling that is next on the list, to be (shortly) followed by namespaces, and probably the more tricky stuff some time after that.

But even without those things, it's a neat module to use. I was using it before it went public, and the really nice thing about the parser is that it makes use of closures. The handlers you give it can all use anonymous delegates, declared inline, and they can refer to variable in the enclosing scope, and that is something that I just find /amazing/, and cheers to Walter for that! It's really that that makes the parser such a joy to use, compared with, say, Expat. (Expat is written in C, so obviously it can't have closures).

The module could really do with a proper tutorial, and maybe I'll write one soon, but I'm hampered because all the auto-generated docs have to come from ddoc comments and it's a bit limiting what you can do with that (and sometimes it does the most bizarrely unexpected things). I'd love to be able to put HTML into a ddoc ... Wait - there's an idea for a feature request! Hmm... another thread coming up!

Anyway, while we're venturing far into the realms of topic drift, might I also mention that you should all look at where std.algorithm is at now. That has really, really matured with D2.011 and it is now absolutely fantastic. Thanks, Andrei.

Janice Caron wrote:


> I'd love to be able to put HTML into a ddoc ... Wait -
> there's an idea for a feature request! Hmm... another thread coming
> up!

I believe that has been asked for before and the answer from Walter was no, because he wants DDOC to be able to generate LaTeX or pdf or man pages or whatever format you desire just by changing the macros.

--bb

On 22/02/2008, Derek Parnell <derek@nomail.afraid.org> wrote:
> Compile with the "-w" switch. It checks for 'missing' return paths.

Ah great! Thanks. That will help a lot.

I thought D didn't have warnings, but obviously I was wrong.

It's a shame you can't /selectively/ enable warnings, because I don't actually want to be warned about "length" shadowing. Still - it's better than it's being an error. In general, I'd prefer that /all/ shadowing should be allowed. But that's another debate.

Anyway, thanks for the info. Will definitely be using -w from now on.

On 22/02/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> Janice Caron wrote:
>
>
>  > I'd love to be able to put HTML into a ddoc ... Wait -
>  > there's an idea for a feature request! Hmm... another thread coming
>  > up!
>
>
> I believe that has been asked for before and the answer from Walter was
>  no, because he wants DDOC to be able to generate LaTeX or pdf or man
>  pages or whatever format you desire just by changing the macros.

I actually did make another thread for that, in the end. You wanna head there and tell me that again? I do have a good response! :-)

Christopher Wright, el 21 de febrero a las 22:33 me escribiste:
> Leandro Lucarella wrote:
> >I think D1.0 is good enough and deserves a little love to finally polish all the rough corners and make it move forward in small and backward compatible steps to be a nice, maintained and usable language.
> 
> The frontend is open source; care to volunteer?

Yes, but the only problem here is not the source code. If I decide to change the frontend to admit, for example, !in, but Walter don't want to include it on DMD (which will mean that GDC probably will not follow), nothing will change. Other posibility will be to fork the language specification, but I don't know if that's even possible because of the licensing issues. Or one could just implemente that stuff in GDC documenting just the extra features.

Either way, I don't think it's very good for the language, we already have to problems of phobos vs. tango to add DMD vs GDC/whatever.

I think that, to be successful, it have to be some "official" support so a fork is not necessary.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Does humor belong in music? -- Frank Zappa
Yes it does, Frank. -- Kevin Johansen