"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhm0mh$ev$1@digitaldaemon.com...
> I'm curious if there are any others that can not be resolved easily (multi level redo is the only other thing that comes to mind, something I have wanted to do on the odd occasion)

Jumping forward into a loop. <g>

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhm1ga$1e4$1@digitaldaemon.com...
> I'm sure it would horrify you that I would also like to see the system
taken
> to what to me seem a logical conclusion of having
> D+ (superset of D syntax with goto and other "unsafe features")
> D  (the core D with a few "unsafe" ops but not too many)
> D# (sub set of D syntax allowing only safe operations, no pointers or
> sliceing stack alloced arrays, or passing inner functions as delegates (or
> has safe ways to allow this (stack frame promoted to heap etc)))

It doesn't horrify me, I just think the subset D's won't sell. It's enough work to learn one language, not three!

"Walter" <walter@digitalmars.com> a écrit dans le message de news:bhmbi1$g24$2@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhm1ga$1e4$1@digitaldaemon.com...
> > I'm sure it would horrify you that I would also like to see the system
> taken
> > to what to me seem a logical conclusion of having
> > D+ (superset of D syntax with goto and other "unsafe features")
> > D  (the core D with a few "unsafe" ops but not too many)
> > D# (sub set of D syntax allowing only safe operations, no pointers or
> > sliceing stack alloced arrays, or passing inner functions as delegates
(or
> > has safe ways to allow this (stack frame promoted to heap etc)))
>
> It doesn't horrify me, I just think the subset D's won't sell. It's enough work to learn one language, not three!
>
>

Maybe 3 warning levels:
- for beginner,
- for intermediate user
- for advanced one...

and the default one would be intermediate.

"Walter" <walter@digitalmars.com> wrote in message news:bhmbi1$g24$2@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhm1ga$1e4$1@digitaldaemon.com...
> > I'm sure it would horrify you that I would also like to see the system
> taken
> > to what to me seem a logical conclusion of having
> > D+ (superset of D syntax with goto and other "unsafe features")
> > D  (the core D with a few "unsafe" ops but not too many)
> > D# (sub set of D syntax allowing only safe operations, no pointers or
> > sliceing stack alloced arrays, or passing inner functions as delegates
(or
> > has safe ways to allow this (stack frame promoted to heap etc)))
>
> It doesn't horrify me, I just think the subset D's won't sell. It's enough work to learn one language, not three!
>
as I invisage it the D# is for those ppl happy with Java or C# (without
every using unsafe)
the D for those who want a safer C++ or C# with unsafe
and D+ for whose who want C++ stack scribbles and all.

the same syntax, just extra features (or extra types, pointer for instance would not be movable or sliceable in D#) so you are only learning one lang (although I would accept the point of view that there are 3 sets of conditions so its kind of 1 + 3 halfs so 2.5 langs)

I still don't realy know who your trying to sell D to, so can't comment on
if they would buy it or not.
it brings to mind a quote/puzzle my grandfather's used to always say to me
as a kid which was
how many beans make 5 ? (A. 4 a seller, 6 a buyer)
about Java/C#
what sells your computer lang ( interfaces and VM from the designer, MI and
cross platform from marketing)

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bhmk07$r98$1@digitaldaemon.com...
> Maybe 3 warning levels:
> - for beginner,
> - for intermediate user
> - for advanced one...
>
> and the default one would be intermediate.

Warnings sure are a seductive siren - they enable me to avoid making a hard choice. But after years of experience with warnings in C/C++ compilers, I've concluded that having a warning is either a fault in the language, or a lack of conviction the language designer has. Warnings are problematic for development managers, because are they a real bug or not? Some managers decree "thou shalt compile with all warnings enabled and none shall be tripped." This runs aground when some other compiler issues mutually contradictory warnings. Others download a package off the internet, and try to compile it. It gets warnings. Is the code broken? Do the warnings matter or should I ignore them?

Hence my eventual conclusion that code should either pass through the compiler cleanly or it should not. Each proposed warning should be evaluated and the language designer needs to make a decision of whether it is an error or not an error, or should the design be changed.

In other words, a set of N warnings means there are actually N factorial different languages being compiled.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhmkc2$s28$1@digitaldaemon.com...
> I still don't realy know who your trying to sell D to, so can't comment on if they would buy it or not.

C and C++ programmers who like the advantages of those languages but are ready to move on past the problems with them. Java pulled too much out to appeal to me.

"Walter" <walter@digitalmars.com> wrote in message news:bhn31p$1ho9$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhmkc2$s28$1@digitaldaemon.com...
> > I still don't realy know who your trying to sell D to, so can't comment
on
> > if they would buy it or not.
>
> C and C++ programmers who like the advantages of those languages but are ready to move on past the problems with them. Java pulled too much out to appeal to me.
>
as I've said before ... semanitics instead of implementation (and a more
robustness features)

I'm still a little unsure: advantages and problems are very subjective terms, to some putting objects onto the stack is an advantage, to others a disadvantage or potential bug waiting to go off.

and what architectures, Arm/thumb for instance is a great arch, waiting for
someone to write a lang that solves the interworking problems.
and the new PalmOS devices is a pain 68k under emulator with Arm/thumb (on
hardware) or x86 on the simulator.

lol!

"Walter" <walter@digitalmars.com> wrote in message news:bhjtte$m5b$1@digitaldaemon.com...
>
> "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bhjenm$7hh$1@digitaldaemon.com...
> > Oh, it's one of the topics best to avoid.  Religion, politics, and
gotos.
> <g>
>
> Reminds me of another story <g>. Another colleague of mine, long ago, was
a
> pascal zealot. We were a C shop, and he never lost an opportunity to point out how Pascal was better. One day, a person came to the office and asked
to
> see him. Our office was one large cavernous bay divided into cubicles. I said in a loud voice "Pascal sucks!". Up he popped "who said that?" I
spoke
> to the visitor: "he's right over there."
>
> He got teased about that one for years <g>.
>
>

On Fri, 15 Aug 2003 16:08:29 -0700 (08/16/03 09:08:29)
, Walter <walter@digitalmars.com> wrote:

>
> "Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message
> news:bhgh13$flp$1@digitaldaemon.com...
>> "Charles Sanders" <sanders-consulting@comcast.net> wrote in message
>> news:bhgdqv$cfh$1@digitaldaemon.com...
>> > It would be more elegenat if you didnt use goto's :P.
>> I know, but still, "goto" is part of the language.
>
> Goto's are like pointers. You rarely need them, but when you do, they're
> real nice to have!
>

I'm in 100% agreement with Walter here. However the emphasis is on *when you NEED them*. What would be nice to have is an understanding on what situations exist that we need to have a goto.

I vaguely remember reading Knuth (and I paraphrase) saying that the *only* justification for goto is in the single situation that ...

 1) Needs (in order to satisify requirements) to execute as fast as possible
AND

 2) Cannot be written that way without a goto.

I tend to agree with that too. However, if that is really the situation, the 'reverting' to assembler seems a better way to do it.

My philosophy with respect to using goto is that I refuse to use it in any language that is 'higher' than assembler. My primary reason for this stance is that the possiblity of goto being used increases the number of potential logic paths that have to be understood by a maintenance coder. Thus the net effect is that maintenace takes longer. A secondary reason is that the possibility of unintended side-effects increases when using gotos - making the probability of code using goto more prone to bugs. I believe that goto increases bugs because without goto you cannot explictly jump to an unintended location, that is, it is with goto it is possible to incorrectly specify a goto target and without goto you cannot.

That increased risk is enough for me to reject the use of goto. For other coders, it maybe an acceptable risk - and that's fine too. If they are willing to pay the increased cost that such code will impose then there is no issue.

The argument that goto can increase runtime effeciency and is therefore justifiable, fails to impress me. True, it can speed up programs. But can it do that to such an extent that it is significant to the people using the program. Other factors tend to swamp or negate the goto speed ups, such as disk I/O, User I/O (keyboard and mouse activity), processor cacheing... I recognise that there are times that extreme speed is required, and in such cases then do it in assembler, if you are really serious. The maintenance costs might otherwise make it not worth while.

But back to D. I regard a label as being a placeholder in the code. A bookmark, if you will. It represents a named location in the executable (generated) code. To force a coder to write in a empty D statement after a label, in order to satisfy the requirements of the parser is just plain silly.

-- 
Derek

On Fri, 15 Aug 2003 17:07:05 +1000 (08/15/03 17:07:05)
, Matthew Wilson <matthew@stlsoft.org> wrote:

>
>> > I like goto.
>>
>> And I like McDonald's BigMacs, but it doesn't mean they're good for me.
>
> Your analogy is not well founded. There are no circumstances under which a
> Big Mac is appropriate. Even if you do eat meat (though I cannot imagine
> anyone wishing to do so), then there are better forms of meat. Even if you
> do need a hamburgler, then there are less mass-produced, healthier, and
> (from what my carnivorous friends tell me) tastier alternatives.
>
> What we're talking about here is something that is almost always bad, but
> sometimes very good. A better analogy in this case would be a can of Coke.
> Bad in almost all conceivable circumstances, but if you've got a
> cycling-<substitute your sport of choice here, so long as it's not
> golf!>-headache, then the combination of water, high concentration of simple
> carbohydrates and big shot of caffeine are exactly appropriate. Rehydrates,
> gives your brain some well needed carbs, and opens up the blood vessels in
> the old grey matter to assuage the ache until the rehydration kicks in.
> Marvellous!
>
> Derek the Dietician


LOL. I'm so glad you missed my point. The ongoing discussion has been a welcome relief to the sometimes dry D deliberations.

I'll try not to be so obtuse this time.

BigMacs are bad. I still like them.

In other words, just because I like BigMacs, that doesn't make them good.

And, just because somebody likes gotos, that doesn't make them good.

-- 
Derek