Digital Mars - D - why no 'out' or 'inout' for bits ?

C/C++ Programming

↑ ↓ ← → "Mike Wynn" <mike.wynn l8night.co.uk> writes:

Walter,

is there a reason why
`char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
are not allowed ?
`builder.d(30): cannot have out parameter of type bit`

Mike.

Dec 08 2002

↑ ↓ ← → "Sean L. Palmer" <seanpalmer directvinternet.com> writes:

It seems to me that the compiler could automatically generate the glue code
needed to support out, and even inout if you're willing to bend the
semantics a little bit in the case of packed bits.  (other threads wouldn't
see the updates until the function returns).  Some care would have to be
taken to disallow storing of references to the temporary bit proxy.

I totally fail to see the rationale behind not allowing isolated bits to be
referenced with out.  Bit is the closest thing we have in D to a C++ bool
type, and references to bool were quite handy in C++.

Admittedly the restriction makes a D implementation a bit easier to write,
but that shouldn't be the sole criteria for a language feature.  I hate
special cases.

At very least I would like to see support in D for out and inout parameters
of type bit, but disallow passing of a packed bit into such a parameter.

Sean

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:at0bfg$5v0$1 digitaldaemon.com...
 Walter,

 is there a reason why
 `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
 are not allowed ?
 `builder.d(30): cannot have out parameter of type bit`

 Mike.

Dec 08 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

It's because a pointer can't point to a bit. A bit pointer would have to be
a two word quantity (address + bit number), meaning it's a lot of work to
implement. There's no reason it can't be done, it just isn't at the moment.

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:at0bfg$5v0$1 digitaldaemon.com...
 Walter,

 is there a reason why
 `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
 are not allowed ?
 `builder.d(30): cannot have out parameter of type bit`

 Mike.

Dec 09 2002

↑ ↓ ← → "Mike Wynn" <mike.wynn l8night.co.uk> writes:

can we have a boolean type then which is implemented as an int (well single
stack slot) so it can be passed by reference.
== 0 false, !=0 true.
and can be automatically converted to a bit.

does this mean a bit only uses one bit and can be packed when passed as
params or delared as locals ?

Mike.

"Walter" <walter digitalmars.com> wrote in message
news:at3jh1$1fj4$1 digitaldaemon.com...
 It's because a pointer can't point to a bit. A bit pointer would have to


 a two word quantity (address + bit number), meaning it's a lot of work to
 implement. There's no reason it can't be done, it just isn't at the


 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:at0bfg$5v0$1 digitaldaemon.com...
 Walter,

 is there a reason why
 `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
 are not allowed ?
 `builder.d(30): cannot have out parameter of type bit`

 Mike.

Dec 10 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:at4g56$2ec2$1 digitaldaemon.com...
 can we have a boolean type then which is implemented as an int (well


 stack slot) so it can be passed by reference.
 == 0 false, !=0 true.
 and can be automatically converted to a bit.


It could be done but the utility of it seems marginal.

 does this mean a bit only uses one bit and can be packed when passed as
 params or delared as locals ?


That would be up to the implementation.

Dec 12 2002

↑ ↓ ← → "Sab" <sab neuropolis.org> writes:

I may not be familiar enough with the D bool stuff, but
the issue is generic anyway. Bit and bool are two different
concepts. Bit is a numerical entity which is sometimes
good to represent bools, which is a logical entity. But
sometimes not. Sometimes int is better for that purpose.
Either way, I see it a big mistake to blur bit and bool.
Blurring int and bool is an equally big mistake -- in C++
they have fixed that eventually, but as coding is translating
concepts and ideas to a formal language, coding anomalies
have been there in most languages that don't treat bool
as it should be treated: as a concept (type) on its own.

(Sorry if I'm knocking on open doors... I need a goooood
sleep now...)

Cheers,
Sab


"Walter" <walter digitalmars.com> wrote in message
news:ataf99$2uh7$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:at4g56$2ec2$1 digitaldaemon.com...
 can we have a boolean type then which is implemented as an int (well


 stack slot) so it can be passed by reference.
 == 0 false, !=0 true.
 and can be automatically converted to a bit.


 It could be done but the utility of it seems marginal.

 does this mean a bit only uses one bit and can be packed when passed as
 params or delared as locals ?


 That would be up to the implementation.

Dec 14 2002

↑ ↓ ← → "Roberto Mariottini" <rmariottini lycosmail.com> writes:

"Sab" <sab neuropolis.org> wrote...
 I may not be familiar enough with the D bool stuff, but
 the issue is generic anyway. Bit and bool are two different
 concepts. Bit is a numerical entity which is sometimes
 good to represent bools, which is a logical entity. But
 sometimes not. Sometimes int is better for that purpose.
 Either way, I see it a big mistake to blur bit and bool.
 Blurring int and bool is an equally big mistake -- in C++
 they have fixed that eventually, but as coding is translating
 concepts and ideas to a formal language, coding anomalies
 have been there in most languages that don't treat bool
 as it should be treated: as a concept (type) on its own.


There were a big discussion about this, and I agree you.
But Walter seems to not agre with us, so I think we won't
have a boolean type in D.

What a pity.

Ciao

Dec 15 2002

↑ ↓ ← → hojtsy AT NOSPAM index.hu <hojtsy_member pathlink.com> writes:

In article <atk0q6$sng$1 digitaldaemon.com>, Roberto Mariottini says...
"Sab" <sab neuropolis.org> wrote...
 I may not be familiar enough with the D bool stuff, but
 the issue is generic anyway. Bit and bool are two different
 concepts. Bit is a numerical entity which is sometimes
 good to represent bools, which is a logical entity. But
 sometimes not. Sometimes int is better for that purpose.
 Either way, I see it a big mistake to blur bit and bool.
 Blurring int and bool is an equally big mistake -- in C++
 they have fixed that eventually, but as coding is translating
 concepts and ideas to a formal language, coding anomalies
 have been there in most languages that don't treat bool
 as it should be treated: as a concept (type) on its own.


There were a big discussion about this, and I agree you.
But Walter seems to not agre with us, so I think we won't
have a boolean type in D.

What a pity.

Ciao


I agree with you. I took part in that previous discussion. Seems that Walter
don't want implement new types which has the same asm level implementation as
some other type. Because users don't need it? Who are we if not the users of the
language?

Sandor Hojtsy

Dec 16 2002

↑ ↓ ← → "Sean L. Palmer" <seanpalmer directvinternet.com> writes:

My main fear is that everyone will make their very own typedef for bool and
enum for true and false, and the conflicts could cause a world of grief.

Even if there's no special low level type, at least the language should have
the typedef and enums be part of the standard.  But once you have that, what
makes bool powerful is when the comparison operators return bool, and bool
is not implicitly convertible to int, and the if (), while (), clauses take
bool.

If you ask me, having a bool type actually aids the implementor because it's
the only type that can fit into a flags register bit.  While it's in the
flags register it can be negated etc "for free" by changing the sense of the
tests.

Sean

"hojtsy AT NOSPAM index.hu" <hojtsy_member pathlink.com> wrote in message
news:atkksj$1igt$1 digitaldaemon.com...
 I agree with you. I took part in that previous discussion. Seems that


 don't want implement new types which has the same asm level implementation


 some other type. Because users don't need it? Who are we if not the users


 language?

 Sandor Hojtsy

Dec 16 2002

↑ ↓ ← → "Sab" <sab neuropolis.org> writes:

Waiting further for the Even Better Languge then... ;)
(Fortunately I'm not in a desperate need for it right now...)

Eiffel, Ruby, D, this new group of emerging "post-C++,
almost there" languages are the guarantee to me that
eventually someone will pick the best of them all and
come up with something like, er, an Even Better Language.

(Anyone interested in a project to formulate some sort
of "Common Language Platform" of widely established
components of syntax/semantics? Would it be nice to
standardize -- not a full language, but only some generic
features, so specific languages (e.g. for scripting, or system
programming) could be designed building on that common
platform, not reinventing the damn' wheel all the time on
and again... 1. Language desing could be easier. 2. Porting
code could be easier, and 3. the "language barrier" would
be much lower... Damn, sounds like Esperanto... Bad
omen... ;) But this would not be a language, only a set of
building blocks for languages. Mmm... Still too fantastic...
Maybe 20 years later...)

Good luck everyone,
Sab

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:atl6cm$212c$1 digitaldaemon.com...
 My main fear is that everyone will make their very own typedef for bool


 enum for true and false, and the conflicts could cause a world of grief.

 Even if there's no special low level type, at least the language should


 the typedef and enums be part of the standard.  But once you have that,


 makes bool powerful is when the comparison operators return bool, and bool
 is not implicitly convertible to int, and the if (), while (), clauses


 bool.

 If you ask me, having a bool type actually aids the implementor because


 the only type that can fit into a flags register bit.  While it's in the
 flags register it can be negated etc "for free" by changing the sense of


 tests.

 Sean

 "hojtsy AT NOSPAM index.hu" <hojtsy_member pathlink.com> wrote in message
 news:atkksj$1igt$1 digitaldaemon.com...
 I agree with you. I took part in that previous discussion. Seems that


 don't want implement new types which has the same asm level




 as
 some other type. Because users don't need it? Who are we if not the




 of the
 language?

 Sandor Hojtsy

Dec 19 2002

↑ ↓ ← → Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Sab wrote:
 Waiting further for the Even Better Languge then... ;)
 (Fortunately I'm not in a desperate need for it right now...)
 
 Eiffel, Ruby, D, this new group of emerging "post-C++,
 almost there" languages are the guarantee to me that
 eventually someone will pick the best of them all and
 come up with something like, er, an Even Better Language.
 
 (Anyone interested in a project to formulate some sort
 of "Common Language Platform" of widely established
 components of syntax/semantics? Would it be nice to
 standardize -- not a full language, but only some generic
 features, so specific languages (e.g. for scripting, or system
 programming) could be designed building on that common
 platform, not reinventing the damn' wheel all the time on
 and again... 1. Language desing could be easier. 2. Porting
 code could be easier, and 3. the "language barrier" would
 be much lower... Damn, sounds like Esperanto... Bad
 omen... ;) But this would not be a language, only a set of
 building blocks for languages. Mmm... Still too fantastic...
 Maybe 20 years later...)
 


That's a really fascinating idea.   I'm not sure how one would go about 
getting it to work.   It would require something like a 
metacompiler/compiler generator though, which is what I would see as the 
sticking point.  It would be an amazing piece of software that could 
take even an amazingly detailed language spec and then produce a 
prototype compler from it.  It would open up language design to the 
masses, though.

Evan

Dec 20 2002

↑ ↓ ← → Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:

Sab wrote:
 Waiting further for the Even Better Languge then... ;)
 (Fortunately I'm not in a desperate need for it right now...)
 
 Eiffel, Ruby, D, this new group of emerging "post-C++,
 almost there" languages are the guarantee to me that
 eventually someone will pick the best of them all and
 come up with something like, er, an Even Better Language.
 
 (Anyone interested in a project to formulate some sort
 of "Common Language Platform" of widely established
 components of syntax/semantics? Would it be nice to
 standardize -- not a full language, but only some generic
 features, so specific languages (e.g. for scripting, or system
 programming) could be designed building on that common
 platform, not reinventing the damn' wheel all the time on
 and again... 1. Language desing could be easier. 2. Porting
 code could be easier, and 3. the "language barrier" would
 be much lower... Damn, sounds like Esperanto... Bad
 omen... ;) But this would not be a language, only a set of
 building blocks for languages. Mmm... Still too fantastic...
 Maybe 20 years later...)


It's something worth considering.  Trouble is, the fundamental semantics 
of a language can vary greatly.  For instance, how can you define shared 
semantics between compiled, typesafe languages (like the C family) and 
interpreted, type-unsafe languages (like most scripting langages)?  It's 
hard to define "int is a 32bit integer" if the internal representation 
is not a literal representation like that.

Perhaps I'm thinking too low level?  Much of the things we debate here 
on this newsgroup are fairly high-level details.  I've been thinking 
that what we need is a standardized translation grammar that will allow 
a tool to convert a language from one for to another.

Such a tool would allow Walter to implement a very minimal form of D, 
and then add a layer of translation above it.  Call it "Core D" and 
"Standard D".  A program written in Standard D could be converted 
automatically (at compile time) to Core D.  This would greatly simplify 
compilers.

Going further, you could use such a tool for actually translating a 
lanugage altogether; you could write a spec file that converts D to C, 
and (perhaps) even convert C to assembly.  These spec files would be in 
some sort of human-readable format, meaning that you could edit them by 
hand.

If they are human readable, then we also have other possiblilites.  For 
instance, generics (that is, templates or similar things) could be 
constructed entirely by inlining a translation spec into the source. 
This would allow the programmer not only to add generics, but also whole 
new language features.  One could even go so far as embedding source 
code from several languages into the same source file.  You could write 
a D program but code a portion of it in Perl.  The compiler, if it had a 
Perl->D translator, it could translate that fragment into D at compile 
time, or if it had both D->C and Perl->C translators, then it could 
transform the entire program to C and compile it that way.

Anyhow, various thoughts...

Dec 20 2002

↑ ↓ ← → Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:

Going even further, this sort of spec could be used as a JIT compiler 
technology.  What if you could publish an executable, written in an 
arbitrary laguage, in source form, with the spec for the compiler 
included with it in the same file?  The OS on the user's machine could 
JIT compile it according to the specification built into the file.

Or, better yet, set up a repository of open-source translation specs; 
the user computer would download specs only when needed, caching both 
the spec and the compiled executable.

Dec 20 2002

↑ ↓ ← → Juarez Rudsatz <juarez nowhere.com> writes:

Russell Lewis <spamhole-2001-07-16 deming-os.org> wrote in
news:3E0388A8.8050103 deming-os.org: 

 Such a tool would allow Walter to implement a very minimal form of D, 
 and then add a layer of translation above it.  Call it "Core D" and 
 "Standard D".  A program written in Standard D could be converted 
 automatically (at compile time) to Core D.  This would greatly
 simplify compilers.
 


Take a look in C-- project.

Dec 26 2002

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

Eiffel, Ruby, D, this new group of emerging "post-C++,
almost there" languages are the guarantee to me that
eventually someone will pick the best of them all and
come up with something like, er, an Even Better Language.


And don't forget OCaml!
http://caml.inria.fr/
http://caml.inria.fr/users_comments-eng.html

I got the following private comments from a computer scientist.

"...my experience has been that only OCaml offers the speed of execution, ease
of foreign language [i.e. non-OCaml code] interfacing, and high-level functional
syntax, needed for real-world application development. Next to Lisp, OCaml is my
next choice for rapid prototyping. But for robust released code, OCaml is first
on the list because of the type safety.

"Yes, I have been following Eiffel for quite some time. About 12 years ago I
read Bertrand Meyer's book on Object Oriented Program Design, and I was
enthralled by his ideas. I subsequently got some copies of Eiffel and started
using it for semi-production work in a lab control environment. What I found in
practice was that Eiffel, with all of its tower of classes, became quite
confusing to program, and had a rather poor foreign language interface. Newer
versions may be much better in that regard. But the versions I used did not yet
have COM/OLE capabilities.

"All of these problems vanished the moment I got into OCaml. I am a strong
believer in OCaml for a lot of reasons, not the least of which is foreign
function interfacing. We almost never use a monolithic toolset here. We have
spreadsheets in Excel (VBA), Visual Basic written by the engineers, Mathcad,
Mathematica, Matlab, Lisp, Fortran, C, C++, COM/OLE, and on and on... So
interfacing to other modules is very high on my list."

Dec 25 2002

↑ ↓ ← → user domain.invalid writes:

Mark Evans wrote:
Eiffel, Ruby, D, this new group of emerging "post-C++,
almost there" languages are the guarantee to me that
eventually someone will pick the best of them all and
come up with something like, er, an Even Better Language.




good, styled and balanced language.


 And don't forget OCaml!
 http://caml.inria.fr/
 http://caml.inria.fr/users_comments-eng.html
 
 I got the following private comments from a computer scientist.


projects were other people are involved. It is quite hard to grasp, or 
at least seems so. I bet i can move a few C and C++ coders to switch to 
D and help me out, but NEVER into OCaml.

 
 "...my experience has been that only OCaml offers the speed of execution, ease
 of foreign language [i.e. non-OCaml code] interfacing, and high-level
functional


structures in C and OCaml differ to 100% - this inevitably means that 
you can only stop gaps in OCaml with bits of C code - not lead 
concurrent multi-language development in one project, "reuse" would be 
unappropriate since the C code has to be completely rewritten to work 
with OCaml.

 syntax, needed for real-world application development. Next to Lisp, OCaml is
my
 next choice for rapid prototyping. But for robust released code, OCaml is first
 on the list because of the type safety.


like a dual-linked list... then you're trapped and it starts working 
against you and complicating things.

 
 "Yes, I have been following Eiffel for quite some time. About 12 years ago I
 read Bertrand Meyer's book on Object Oriented Program Design, and I was
 enthralled by his ideas. I subsequently got some copies of Eiffel and started
 using it for semi-production work in a lab control environment. What I found in
 practice was that Eiffel, with all of its tower of classes, became quite
 confusing to program, and had a rather poor foreign language interface. Newer
 versions may be much better in that regard. But the versions I used did not yet
 have COM/OLE capabilities.


Eiffel a lot. But i can't used it in a project where everyone has 
C/C++/Java experience. It doesn't make easy many things that are useful 
in my craft - interfacing all kinds of all libraries, file formats, ets, 
which can be well done in a "dirty" C-way. D disencourages such things a 
bit, but doesn't make them hard or even impossible like many do. And 
thinking in 2 languages while working on 1 project is a BIG PAIN. I 
tried to code in BCX and C once, to enable both BASIC and C developers 
to contribute to the project. It was simply horrible. D and C are not 
different languages, they are dialects, most C code would work in D with 
little changes, and can be improved incrementally. To be frank I hate C 
syntax, but there's simply no other choise because it is simply too 
widespread.

COM/OLE Capabilities? The developer who writes this doesn't seem to be 
experienced. An OO language is not requiered at all to access them. They 
can be accessed even through C. As far as i'm conserned, there might be 
no automatic tool to do that, but wrapping COM C interface into an 
Eiffel class should be a snap.

 
 "All of these problems vanished the moment I got into OCaml. I am a strong
 believer in OCaml for a lot of reasons, not the least of which is foreign
 function interfacing. We almost never use a monolithic toolset here. We have
 spreadsheets in Excel (VBA), Visual Basic written by the engineers, Mathcad,
 Mathematica, Matlab, Lisp, Fortran, C, C++, COM/OLE, and on and on... So
 interfacing to other modules is very high on my list."


justified if you *know exactly* that you need this library and not 
another one. D is very similar to C, and automatic converters will 
arrive, enabling to try one or another C library out fast without 
writing an unterface to it.

-i.

Dec 28 2002

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

The developer who writes this doesn't seem to be experienced.


He's a Ph.D. computer scientist working as a high-level consultant for a large
corporation, with a working knowledge of probably a dozen languages, and at
least two decades of experience.  He coordinates with various engineers across
his company in many disciplines.  So he has serious real-world experience.

I've seen a bit more people comfused by OCaml then by Eiffel.


OCaml is a hybrid functional/imperative language.  Functional style often throws
off C/C++/Java/FORTRAN programmers.  Those are imperative languages with a
completely different feel to them.

Hybrid languages ask even more than pure functional languages.  They expect the
user to know when to employ the functional style, and when the imperative.  This
means the user must think in two different ways at the same time, constantly
deciding which paradigm is most appropriate.  Yet for those who can do it, this
combination yields real programming power.

Mathematica offers hybrid features and I've certainly heard people complain
about it being "hard" and "confusing."  But I know it as one of the most
productive tools in my chest.  The best Mathematica programs are roughly 80%
functional and 20% imperative.  I've personally instructed engineers and
mathematicians in Mathematica and learned, to my dismay, that some folks simply
have a mental block toward functional programming.  I find them writing the
equivalent of FORTRAN in Mathematica.  When it reaches that point, they might as
well use FORTRAN instead.  In those cases, the deficiency is really in the
programmer, not the language.  It's a bit like someone using a wrench as a
hammer and a hammer as a screwdriver.

I expect the same holds true of OCaml.  Software gurus who grok hybrid
programming use Mathematica and love it.  That's why I find it on the shelf of
software experts.  Then I walk across the aisle and find klunky old MATLAB on
the shelves of EEs who don't know programming very well. It's more "friendly"
but a whole lot less powerful, too.

What all of this means for D is that functional features are good, and OCaml may
have some things to offer in terms of specific implementation concepts.  I'm
sure the syntax could be improved but its heart is in the right place.

Mark

OCaml performance second only to C
http://www.bagley.org/~doug/shootout/craps.shtml

OCaml rapid application development
http://www.ocaml.org/
"10/2002. An Objective Caml program wins first prize at the ICFP 2002
programming contest....09/2000. Two Objective Caml programs win first and second
prizes at the ICFP programming contest. "

http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
"This paper is an attempt to demonstrate to the 'real world' that functional
programming is vitally important, and also to help functional programmers
exploit its advantages to the full by making it clear what those advantages
are."

http://www.mysternetworks.com/gmarceau/functional-programming.html
"If functional programming style is not more widely used, it is mostly because
of its higher bar of entry. As natural as they become, recursion, lambda's and
currying are challenging concepts the first time you meat them - not unlike
pointers (which most visual basic programmer still struggle with)."

http://www.cs.ait.ac.th/~kitt/caml/
"You might be surprised if I tell you that ML/OCaml is quite popular and being
used to develop software in many leading companies. Nortel, AT&T, Ericsson use
ML or some other functional languages to implement their telephone switching
firmware. Motorola uses ML to develop a symbolic simulation tool. They throwed
their original 3500-line fragile C code away, and rewrote the whole program in
ML. The result was 700-line ML code performing the same functions without bugs.
The process spent only a couple of weeks. Most people start to write ML without
knowing how to debug ML programs, but they still get bug-free programs."

"Functional programming is quite difficult for me, how is it important? ... This
is the classic question; students from all batches ask this question.... In the
past, you have learnt to program using imperative languages. Now, we change to
functional language, which is completely different programming paradigm. That's
why it is difficult -- if you already know some imperative language, you have to
change the way of thinking to write a program using functional language."

Newbie comments
http://opensource.lineo.com/~beppu/prose/ocaml.html

OCaml and COM
http://caml.inria.fr/camlidl/

Developing with OCaml (online book, discusses functional style)
http://caml.inria.fr/oreilly-book/html/index.html

Dec 28 2002

↑ ↓ ← → Ilya Minkov <midiclub 8ung.at> writes:

Mark Evans wrote:
The developer who writes this doesn't seem to be experienced.


 
 He's a Ph.D. computer scientist working as a high-level consultant for a large
 corporation, with a working knowledge of probably a dozen languages, and at
 least two decades of experience.  He coordinates with various engineers across
 his company in many disciplines.  So he has serious real-world experience.
 


mistakes - especially I do. :)

I've analyzed the way OCaml works. The basic underlying ideas are as 
simple as genious. But after you know that, you can also implement such 
things in C, and reach yet higher performance.

I somehow doubt about the test correctness. That depends on how you view 
it. It was eratosthenes sieve, right? I bet he chose the recursive 
solution in all langueges. OCaml does some magic: if it encounters a 
linear recursive function, it is converted into a loop... one of the 
basic C constructs. It is the breakthrough point, else a simple stepping 
through the linked list would take an age and eat up the whole stack. 
But that also means that if the one who wrote the benchmark chose the 
"naive" implementation, OCaml would with some luck make more out of it 
as "naive" C. However, for non-linear problems an additional effort must 
be taken, although OCaml code would still stay shorter than C. Besides, 
i guess C version chose an array for simplicity, and OCaml the linked list.

OCaml is absolutely wonderful for writing parsers and such. There is an 
example in the manual, which shows a small basic interpreter. If you 
look at the source file, it looks almost like a YACC source! I'm not 
really sure there's a need to integrate YACC into D, but i'll think if 
it's possible to think out some syntax which would be OK within D.

A most feature is a pattern matcher, which serves as an if-elsif-else 
sequence. You write something like:

(*1*)	let rec lSub first second = match (first, second) with
(*2*)	  | ([],_)  -> []
(*3*)	  | (xs,[]) -> xs
(*4*)	  | (xs,ys) when not (beginsWith ys xs) -> failwith "undefined"
(*5*)	  | (a::xs,b::ys) -> lSub xs ys ;;

I've marked line numbers in as comments for the convenience. You can see 
there are no types. They are all implicit. Let's take it apart.

1. Make a recursive function "lsub", which takes parameters "first" and 
"second" and let it return the result of pattern matching. The pattern 
matched object is a tuple (kind of a structure), composed of "first and 
second"
2. First pattern, applies when "first" is an empty list and "second" is 
anything. Then return an empty list.
NOTE: list is always a single-linked list, not an array.
TYPE DEDUCTION: "first" must be a list. Return must be a list.
NOTE: if the type of some later statement is different, you get an error.
3. If "second" is an enpty list, return "first".
TYPE DEDUCTION: "second" must be a list.
4. Calls the function "beginsWith" with parameters "first" and "second" 
and if it returns 'false' then an exception is raised.
5. Here happens an interesting thing: each of the lists is separated 
into 2 parts, the "head" element and the "tail" - the rest of the list. 
The syntax head::tail is both for joining, and for separating. So, the 
heads are discarded in this line, and tails are passed to the next 
instance of this function, a reult of which is returned.

The pattern matching cases apply from top to bottom, so you start with 
less general cases, and end with generally more common ones, so that 
usually the last one(or more) does the recursive call. Of course, as 
soon as some case actually applies, the pattermatching is finished and 
its result is returned. As opposed to the C fall-through. :)

Although it saves a couple of lines of code, every line simply contains 
more information. As soon as you've seen it, you can also simulate such 
a technique in C, evaluating the pattern to an scalar in a simple form 
and applying the "case" statement. BTW, it might be good to standardise 
this evaluation for a number of "big" types, not just for strings. Say, 
for "smart unions", using the information about current type, 
zero/nonzero or other things requiered by the "cases".
Maybe (anonymous) struct in case statement, evaluated to an extent 
requiered by the cases? How about it?

*Walter, your opinion?*

As you can see, the underlying basic types in OCaml are very powerful, 
and have a short operator synatax. Another powerful thing is, you can 
easily define trees of any configuration. I'll think a bit about how 
similar things can be implemented in D. In OCaml you do it by defining a 
"smart union":

typa 'a bintree = Empty | Node of ('a * 'a * 'a bintree);;

or something in that manner. "Empty" and "Node" are constructors, which 
initialize a bintree, which is a union, to one of the states, either 
"Empty", storing nothing, or a "Node", storing two values of an unknown 
type "'a" and one value of a type "bintree" based on the same type.

Maybe it doesn't look as good, but handling of this thing is really very 
simple! You can, for example

match mytree with
| Empty -> false
| Node (a,b,tree) -> true;;

Please note that the identifiers which appear after the with statement 
are not references to data, but "copies" of it, so that you don't tamper 
with it. They need not necessarily be real copies if not changed.

When I say "smart union" I mean a union which knows its current state.


 Mathematica offers hybrid features and I've certainly heard people complain
 about it being "hard" and "confusing."  But I know it as one of the most
 productive tools in my chest.  The best Mathematica programs are roughly 80%
 functional and 20% imperative.  I've personally instructed engineers and
 mathematicians in Mathematica and learned, to my dismay, that some folks simply
 have a mental block toward functional programming.  I find them writing the
 equivalent of FORTRAN in Mathematica.  When it reaches that point, they might
as
 well use FORTRAN instead.  In those cases, the deficiency is really in the
 programmer, not the language.  It's a bit like someone using a wrench as a
 hammer and a hammer as a screwdriver.




 I expect the same holds true of OCaml.  Software gurus who grok hybrid
 programming use Mathematica and love it.  That's why I find it on the shelf of
 software experts.  Then I walk across the aisle and find klunky old MATLAB on
 the shelves of EEs who don't know programming very well. It's more "friendly"
 but a whole lot less powerful, too.


a lot of care must be taken not to break it apart.

Though i'm not sure, i guess there's a flaw in OCaml: when using 
double-linked lists and such it forces you to step out of the functional 
domain. I thought it causes some kind of trouble, i'm not really sure what.

 
 What all of this means for D is that functional features are good, and OCaml
may
 have some things to offer in terms of specific implementation concepts.  I'm
 sure the syntax could be improved but its heart is in the right place.
 
 Mark
 
 OCaml performance second only to C
 http://www.bagley.org/~doug/shootout/craps.shtml


indirection. When working with trees and lists, it's the best. I'm 
pretty much conserned, that C allows to reach a yet higher performance. 
But the improvement might not be that important, if it's hard to 
develop. Or if it doesn't work at all in the end :)

Errh... i've noticed i've been using "C" too much here. It would usually 
mean "C or C-like programmimg in D".

 
 OCaml rapid application development
 http://www.ocaml.org/
 "10/2002. An Objective Caml program wins first prize at the ICFP 2002
 programming contest....09/2000. Two Objective Caml programs win first and
second
 prizes at the ICFP programming contest. "
 
 http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
 "This paper is an attempt to demonstrate to the 'real world' that functional
 programming is vitally important, and also to help functional programmers
 exploit its advantages to the full by making it clear what those advantages
 are."
 
 http://www.mysternetworks.com/gmarceau/functional-programming.html
 "If functional programming style is not more widely used, it is mostly because
 of its higher bar of entry. As natural as they become, recursion, lambda's and
 currying are challenging concepts the first time you meat them - not unlike
 pointers (which most visual basic programmer still struggle with)."
 
 http://www.cs.ait.ac.th/~kitt/caml/
 "You might be surprised if I tell you that ML/OCaml is quite popular and being
 used to develop software in many leading companies. Nortel, AT&T, Ericsson use
 ML or some other functional languages to implement their telephone switching
 firmware. Motorola uses ML to develop a symbolic simulation tool. They throwed
 their original 3500-line fragile C code away, and rewrote the whole program in
 ML. The result was 700-line ML code performing the same functions without bugs.
 The process spent only a couple of weeks. Most people start to write ML without
 knowing how to debug ML programs, but they still get bug-free programs."


which do the same, but this time without bugs. :)

Yes, C is extremely bug-prone. C with spLint is already much better than 
Delphi and alike. I wrote almost bug-free programms in Delphi from the 
beginning on, and couldn't get out of the bugs in the first days... 
weeks of C development. The design flaws are simply too obvious, bit D 
is even now much better than Delphi. And there may still be room for 
improvement.

 
 "Functional programming is quite difficult for me, how is it important? ...
This
 is the classic question; students from all batches ask this question.... In the
 past, you have learnt to program using imperative languages. Now, we change to
 functional language, which is completely different programming paradigm. That's
 why it is difficult -- if you already know some imperative language, you have
to
 change the way of thinking to write a program using functional language."
 
 Newbie comments
 http://opensource.lineo.com/~beppu/prose/ocaml.html
 
 OCaml and COM
 http://caml.inria.fr/camlidl/


bit of work. However, i'm usually against COM for performsnce reasons. I 
still code in C, not C++ you know. :)

 
 Developing with OCaml (online book, discusses functional style)
 http://caml.inria.fr/oreilly-book/html/index.html

Dec 29 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

<user domain.invalid> wrote in message
news:aulg0s$1toh$1 digitaldaemon.com...
 COM/OLE Capabilities? The developer who writes this doesn't seem to be
 experienced. An OO language is not requiered at all to access them. They
 can be accessed even through C. As far as i'm conserned, there might be
 no automatic tool to do that, but wrapping COM C interface into an
 Eiffel class should be a snap.


Doing OLE in C is of course doable, but I'd question the sanity of choosing
that route over using C++ to do OLE <g>. It's very tedious and error-prone,
just not worth it.

D has a sweet way to do OLE as interfaces map right onto OLE classes.

Dec 31 2002

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

Quick follow up on the language itself.  (I couldn't resist because both Walter
and I have a Caltech connection.)  This Caltech CS prof wrote a small
introduction to OCaml for his course on compilers.

http://www.cs.caltech.edu/courses/cs134/cs134b/

There's a full-blown OCaml IDE with debugger at

http://pauillac.inria.fr/~guesdon/Tools/tools.html

However I wish it were instead a suite of Eclipse plugins.  There is such a
project in planning at SourceForge.

Another tidbit is that someone has actually implemented Icon string scanning in
OCaml, a testimony to the strength of the language.

http://www.bagley.org/~doug/ocaml/

Mark

Jan 04 2003

↑ ↓ ← → Ilya Minkov <midiclub 8ung.at> writes:

Walter wrote:
 <user domain.invalid> wrote in message 
 news:aulg0s$1toh$1 digitaldaemon.com...
 
 COM/OLE Capabilities? The developer who writes this doesn't seem to
 be experienced. An OO language is not requiered at all to access
 them. They can be accessed even through C. As far as i'm conserned,
 there might be no automatic tool to do that, but wrapping COM C
 interface into an Eiffel class should be a snap.


 
 Doing OLE in C is of course doable, but I'd question the sanity of
 choosing that route over using C++ to do OLE <g>. It's very tedious
 and error-prone, just not worth it.
 
 D has a sweet way to do OLE as interfaces map right onto OLE classes.
 


important to me, the general design of interoperability appeals me a
lot. As well as all the other things. But using C as a "glue" between
Eiffel and OLE would still be an OK option, as the library user would 
access OLE wrapped into a native class. An automatic interface
generator should not be too hard to write. I'm actually not interested
in Eiffel anymore, i was just very surprised the man had *such* bad
experiences with it and OLE.

-i.

Jan 09 2003

↑ ↓ ← → Ilya Minkov <midiclub 8ung.at> writes:

I was the angry guy who replied to the message a minute ago. :)

The last message didn't contain my name and e-mail adress. This one 
does. Just for case you want to reply me.

Best Regards,
-i./MIDICLUB
currently coding volunteer for NUMEDIA CYCLOPS.

Dec 28 2002

↑ ↓ ← → Burton Radons <loth users.sourceforge.net> writes:

hojtsy AT NOSPAM index.hu wrote:
 In article <atk0q6$sng$1 digitaldaemon.com>, Roberto Mariottini says...
 
"Sab" <sab neuropolis.org> wrote...

I may not be familiar enough with the D bool stuff, but
the issue is generic anyway. Bit and bool are two different
concepts. Bit is a numerical entity which is sometimes
good to represent bools, which is a logical entity. But
sometimes not. Sometimes int is better for that purpose.
Either way, I see it a big mistake to blur bit and bool.
Blurring int and bool is an equally big mistake -- in C++
they have fixed that eventually, but as coding is translating
concepts and ideas to a formal language, coding anomalies
have been there in most languages that don't treat bool
as it should be treated: as a concept (type) on its own.


There were a big discussion about this, and I agree you.
But Walter seems to not agre with us, so I think we won't
have a boolean type in D.


 I agree with you. I took part in that previous discussion. Seems that Walter
 don't want implement new types which has the same asm level implementation as
 some other type. Because users don't need it? Who are we if not the users of
the
 language?


I don't want it, as it's completely redundant.  Bit is misnamed. 
Implicit casting to bit is disallowed; explicit casting to bit results 
in a logical cast, not a bitwise (this was a very recent change).  So it 
is, in every way but name, boolean.  We should probably change the name.

Back to the original discussion in this thread, I'd be willing to put 
bit pointers in DLI if Walter is willing to put them in DMD.  What 
current complexities exist in the frontend with dealing with that is a 
result of incomplete abstraction.  It'll be illegal to cast from a bit 
pointer to any other pointer type, of course.

Oh, this brings up something I've been needing to know a long time. 
Walter, what's the result of:

     bit [] x = new bit [400];
     bit [] y = x [2 .. 100];

Does y still refer to the same memory or a copied slice?

Dec 17 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:atn0f7$bru$1 digitaldaemon.com...
 Oh, this brings up something I've been needing to know a long time.
 Walter, what's the result of:
      bit [] x = new bit [400];
      bit [] y = x [2 .. 100];
 Does y still refer to the same memory or a copied slice?


At the moment, it simply doesn't work. I think the only practical way to
make it work is to copy it.

Dec 31 2002

↑ ↓ ← → Ilya Minkov <midiclub 8ung.at> writes:

hojtsy AT NOSPAM index.hu wrote:
 In article <atk0q6$sng$1 digitaldaemon.com>, Roberto Mariottini says...
 
"Sab" <sab neuropolis.org> wrote...




Just take a second and THINK! What happens it you apply binary "boolean" 
oberation to a bit? and now apply logical "boolean" operations. Guys, 
since it's only one bit it's THE SAME. To my opinion, using bit as a 
boolean type is natural ynd justified - unlike the use of int as boolean 
type which is a CATASTROPHE, which can lead to expression like 
((bitmask&bitmask) == TRUE), where bitmask&bitmask yields boolean true, 
but when compared to a constant it yields FALSE!!! it would drive 
beginners insane and cost professionals hours of debugging. And please 
note, since data is always "aligned", it is not a consern of a 
programmer whether it's stored as an int or as a bit, important is that 
it WORKS JUST LIKE BOOL in pascal and alike and prevents bugs. I think 
the underlying types should be both simple and powerful, and bit is THE 
BEST EXAMPLE of such a combination!!! It replaces a fairly powerful 
pascal "set" and a lot of other things in a wonderful manner, you don't 
need to worry about bugs in such essential code anymore, not cluttering 
the language with keywords or libraries with stuff. I bet such a smart 
definition saves thousands of library code lines.

A language which is not cluttered parses well, and is hence not only 
sutable for native code generation, but also for interpreting, bytecode, 
JIT, and so on. Don't limit the future use of D!!!

I may not be familiar enough with the D bool stuff, but
the issue is generic anyway. Bit and bool are two different
concepts. Bit is a numerical entity which is sometimes
good to represent bools, which is a logical entity. But
sometimes not. Sometimes int is better for that purpose.
Either way, I see it a big mistake to blur bit and bool.
Blurring int and bool is an equally big mistake -- in C++
they have fixed that eventually, but as coding is translating
concepts and ideas to a formal language, coding anomalies
have been there in most languages that don't treat bool
as it should be treated: as a concept (type) on its own.







There were a big discussion about this, and I agree you.
But Walter seems to not agre with us, so I think we won't
have a boolean type in D.

What a pity.

Ciao


 
 I agree with you. I took part in that previous discussion. Seems that Walter
 don't want implement new types which has the same asm level implementation as
 some other type. Because users don't need it? Who are we if not the users of
the
 language?
 
 Sandor Hojtsy

Dec 28 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:atk0q6$sng$1 digitaldaemon.com...
 There were a big discussion about this, and I agree you.
 But Walter seems to not agre with us, so I think we won't
 have a boolean type in D.

 What a pity.


D's boolean type is bit. The fact that right now there isn't a pointer to
bit is an implementation problem.

Dec 31 2002