www.digitalmars.com         C & C++   DMDScript  

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

reply "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
next sibling parent "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
prev sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
next sibling parent reply 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
next sibling parent reply "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
parent reply "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
next sibling parent 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
prev sibling next sibling parent reply 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
next sibling parent 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
prev sibling parent 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
prev sibling parent reply 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
next sibling parent reply 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
next sibling parent reply 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
parent 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
prev sibling parent reply "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
next sibling parent 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
prev sibling parent 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
prev sibling parent 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
prev sibling next sibling parent reply 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
parent "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
prev sibling parent 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
prev sibling parent "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