Slashdot Mirror


Dao, a New Programming Language Supporting Advanced Features With Small Runtime

New submitter NeoHermit writes "This language (Dao) has never been mentioned on Slashdot before, but it might be interesting to many people here. As it has recently become feature-complete and just made its first beta release, it may be the right time to mention it here. Dao is an optionally-typed programming language that supports many advanced features with a small runtime. The feature list is probably as long as that of Python, but they are supported by a much smaller runtime (somewhere between Lua and Python, but closer to Lua). Besides optional typing, the other major features that worth mentioning include: built-in support for concurrent programming for multicore computers, very friendly C programming interfaces for embedding and extending, a LLVM-based JIT compiler, a Clang-based module for embedding C/C++ codes in Dao, and a Clang-based tool for automatic binding generation from C/C++ header files. You can also see many familiar features from other languages."

45 of 404 comments (clear)

  1. There's a reason nobody talks about it by antifoidulus · · Score: 4, Funny

    It's basically Go with fewer features, next!

    1. Re:There's a reason nobody talks about it by NeoHermit · · Score: 2

      You must be joking! Dao has almost all the major features that Go has, not vice versa. Just mention a few: tasklet (goroutine in a different form), channel, defer, defer-recover, interface etc.

    2. Re:There's a reason nobody talks about it by Anonymous Coward · · Score: 5, Interesting

      Dao (and Go) do not solve programming problems better than other mainstream alternative languages. Seriously, I looked through the list and asked myself what Dao could do that (say) C, C++, Java, Groovy, Scala, Clojure, or Haskell couldn't do, and I couldn't come up with anything.

      If someone is really interested in solving programming problems using language design, I need a language that satisfies the following:

      a) Object-oriented, when I want it. Not the C++ bullshit of multiple inheritance, but Java's OO model isn't bad as a start; maybe add Scala's mixins and traits as well to that.
      b) Functional, when I want it. But not Scala-functional: more like Haskell or Clojure functional.
      c) Strongly-typed, most of the time. When I'm solving specific domain problems, I want the type system to ensure I'm not jamming a Foo into a Bar.
      d) Optionally- or non-typed, once in awhile. Sometimes I'm just writing an algorithm that should be able to deal with any sort of object and don't care what the underlying object is. Java's generics are ok, but sometimes they just get in the way.
      e) Reasonable concurrency model - message passing, threads, actors, producers, consumers, event buses, etc.
      f) Garbage-collected. I used to do malloc()/free() and new/delete, but I'd rather have the underlying language handle objects for me. (That isn't to say that I don't care about memory pressures - I'm ok with allocating objects once and tracking their state instead of allocate/release/garbage-collect thrashing.)
      g) Proper closures and exception handling in the OO part. (Closures and monads should be part of the functional part of the language).

      Note to Scala crazies: the above may LOOK like Scala, but it sure as hell isn't Scala. No one in their right mind would develop something that had to be maintained in Scala, because part (h) that I don't want is this: arbitrary operator definition and overloading. That right there makes Scala a total disaster. For an example of this, see the Lift examples.

    3. Re:There's a reason nobody talks about it by Anonymous Coward · · Score: 3, Insightful

      Lisp?

    4. Re:There's a reason nobody talks about it by White+Flame · · Score: 4, Informative

      That's an assumption that hasn't been true since the 1950s. Common Lisp has full structures, OO classes & objects (and meta classes for defining the OO system itself and extending it), multimethod dispatch, complex & rational numbers, full Unicode strings, etc.

    5. Re:There's a reason nobody talks about it by gigaherz · · Score: 2, Informative

      Check C# 5.0, it meets most of the requirements in some form or another. Lambdas, Linq's meta-expressions and dynamic runtime allow for something rather close to functional and untyped code, the Generics are much nicer than java's and THe major feature of C# 5.0 is the async keyword for concurrency.

    6. Re:There's a reason nobody talks about it by chris.alex.thomas · · Score: 2

      he should have added h) readability, I need to read it back to myself in 6 months time and understand it.

    7. Re:There's a reason nobody talks about it by cyborg_zx · · Score: 5, Insightful

      That is what comments are for.

      No it isn't.

      Seriously I see stuff like this in legacy code all the time:

      // Add one to the iterator
      i--

      Comments lie, code doesn't. Someone is going to update the code and not bother with the comments.

    8. Re:There's a reason nobody talks about it by stjobe · · Score: 2

      he should have added h) readability, I need to read it back to myself in 6 months time and understand it.

      Perl is only as (un)readable as you make it; if you write readable Perl code, you won't have any problems reading and understanding it 6 months later.

      But yeah, you can write unreadable Perl code - but then again, is there any language in which you can't?

      --
      "Total destruction the only solution" - Bob Marley
    9. Re:There's a reason nobody talks about it by Anonymous Coward · · Score: 2, Insightful

      Perl: the expressive power of gibberish combined with the readability of gibberish!

      Seriously, you CAN write maintainable code in just about anything, but why would anyone want to write in a language which makes that so difficult?

    10. Re:There's a reason nobody talks about it by cyborg_zx · · Score: 3, Insightful

      True - there are many crap programmers around; but that is what things like code reviews should be for.

      Absolutely but I don't get to review every line (although I certainly try because I often wonder WTF is being check in other people's code reviews) and I can't do much about the code that was written years ago that has been left to bitrot.

      If you find a programmer who does that sort of thing do you want to continue to employ him ?

      No, not really. But fucked if it's my choice or if I know where the hell the programmers are who don't do this stuff.

    11. Re:There's a reason nobody talks about it by tolkienfan · · Score: 2

      Wouldn't it be better to write in a language where simple things DON'T need commenting?
      Otherwise you're coding twice, once in Perl and once in English (probably).

    12. Re:There's a reason nobody talks about it by Alain+Williams · · Score: 2

      No. We are not talking about the same thing. You are talking about line by line comments that say what actions the code is doing; in general someone competent in the language should be able to read/understand the actions[**]. The more important comments are about why the code is doing something, ie the purpose - you need comments like that in whatever language you use.

      [**]: but there will sometimes be occasions where a complicated RegEx, or something, needs explaining.

    13. Re:There's a reason nobody talks about it by DuckDodgers · · Score: 2

      For your part h), see also SBT, the Simple Build Tool for Scala, with operators
      Items I think you're missing:
      i) REPL for rapid exploration of language features.
      j) If the language is compiled, fast compilation times. This to me is a massive reason to prefer Go and D to C++ when you're building something that has to be near C++ for speed but does not need to hook deeply into existing C++ code.

      I also disagree on your need for strong static typing. Let's say you have some kind of object with functions doX and doY and some functions that manipulate those objects. Then you interface with a third party library that happens to have objects that also have doX and doY you should be able to use interchangeably with your functions and objects. In the world of Java and C#, you need to make a common interface and recompile the whole set, including the third party library, to get that to work. With Scala, you can work around it by using implicit conversions but it's still an added layer of complexity. In Python, Ruby, Perl, PHP, or Clojure, it just works. Sure you can screw up and have type errors - but you're three days into writing your unit tests when the Java/C#/C++/Scala guy is still defining his damn interfaces.

    14. Re:There's a reason nobody talks about it by DuckDodgers · · Score: 2

      That's not strong typing, though. Is it? You can do Object Oriented things with Common Lisp, but my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function. You also can't do, as far as I know, one aspect of Object Oriented programming: information hiding. At least, as far as I know. Now I have read that most Lisp gurus would argue that information hiding is overrated and that if you can't trust the people calling your code to use it properly, that's a human resource problem and not a programming language problem.

  2. end the lambda idolotry! by Anonymous Coward · · Score: 2, Interesting

    Have fun designing programs that manipulate massive amounts of state with functional programming style. Given that nobody has figured out how to do a first person shooter with a functional langauge, makes me suspect that they aren't the one answer to every problem. In fact even a relatively simple game is quite awkward in a functional style.

    I guess you can't solve every problem with lambda calculus and retain your sanity.

    1. Re:end the lambda idolotry! by j1m+5n0w · · Score: 2

      There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).

  3. Re:you had me at... by Anonymous Coward · · Score: 5, Funny

    Someone better go dig Strousoup out because he ain't dead, yet.

  4. Optionally typed by ThePeices · · Score: 5, Funny

    So if Dao is optionally typed, what are the other programming input options? Voice input? Graphical point n click input?

    1. Re:Optionally typed by Pseudonym · · Score: 2

      That settles it, then. I don't want to use a language if it encourages JavaScript-style code.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    2. Re:Optionally typed by Samantha+Wright · · Score: 2

      But it's in perl! You might summon Cthulhu. Do you really want that on your conscience?

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    3. Re:Optionally typed by Pseudonym · · Score: 5, Funny

      Surely I'd die of insanity before my conscience kicked in. Besides, "bind shoggoth" requires an import.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    4. Re:Optionally typed by Noughmad · · Score: 2

      Something like the OMG OCR Calculator?

      --
      PlusFive Slashdot reader for Android. Can post comments.
  5. Re:Do they have tail-recursion or lazy evaluation? by NeoHermit · · Score: 3, Interesting

    Tail-recursion: yes; Lazy evaluation: no. It does support some functional programming styles, at least as much as python or ruby supports. It's just that it is not branded that way. But if you are looking for a programming language that supports functional programming as its major programming paradigm, this is not the language you want. But certainly this is not the reason to dismiss it as failure.

  6. Re:you had me at... by girlintraining · · Score: 2, Informative

    Someone better go dig Strousoup out because he ain't dead, yet.

    Ack, I meant Dennis Ritchie, the inventor of the C programming language, not Stroustrup, who invented C++. My bad...

    --
    #fuckbeta #iamslashdot #dicemustdie
  7. The YAPPing language is for dogs by petteyg359 · · Score: 2

    "Yet Another Pissant Programming language". Can we quit pretending that "new is better" and just use the stuff that actually works?

  8. Re:you had me at... by dbraden · · Score: 5, Funny

    Sttroustrup ( you know youm could have gotten the name right )

    You sure you wanna be correcting folks?

  9. Re:you had me at... by girlintraining · · Score: 3, Interesting

    Way to fight the chauvanistic stereotype of girl geeks as dilettantes.

    I fail to see how making an educated assessment of the value of a new programming language meets the definition of a dilettante. I know of many geek girls (yes, girl comes second, we are geeks first and foremost -- pay attention Anonymous Coward, there will be a test) who know nothing of programming yet nobody would question their overall geekiness. Perhaps you're unaware that there's more than one kind of geek? I have one friend who's an art geek. She spends her days painting, sketching, and is a consumate book worm. I enjoy her company and her passion quite a bit. She has about as much computer sense though as a door mat and I have to fix or reimage her system on a seasonal basis. I don't begrudge her not knowing computers though; Not everyone can be a computer geek.

    --
    #fuckbeta #iamslashdot #dicemustdie
  10. Re:Feature complete with a small runtime? by Pseudonym · · Score: 5, Funny

    The Dao that is feature-complete is not the true Dao.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  11. Re:Do they have tail-recursion or lazy evaluation? by Greyfox · · Score: 5, Insightful
    Optional typing is not highly desirable. Everyone got all starry-eyed when they talked about how object oriented programming would allow you to have a container of objects and you could just put any arbitrary object into the container. Which is a great idea as long as you don't really think about it. Eventually you have to know what kind of object you're holding and you actually to use it to do some real work. The same thing goes for functional programming. Eventually you need to know what kind of data you're operating on, and you actually have to operate on it to do some real work. When the time comes to do some real work, you quickly realize just how much of a mess optional typing makes of your program.

    I've looked at a lot of code over the years that pushes the actual work to be done around like a two-year-old pushes peas around a plate. I've gotten to the point where I can read the mind of the programmer through the code he's written. He's thinking "If I push this over here maybe it will magically go away and I won't have to deal with it." Most of the time this is because he doesn't actually understand the business logic behind the code he's writing. He's writing to a series of requirements but he has no understanding of why the requirements exist or how they drive the business. So he tries to keep his code abstract as possible and hopes that no one notices.

    Sadly no one has yet written a language that forces you to actually understand the problem domain that you're coding. I'm sure it wouldn't be very popular if anyone ever did. Neither has anyone actually managed to write a language that allows you to write useful code without understanding the problem domain, and no one ever will. Now if someone could write a language that a non-programmer who understands why he needs code written to describe what needs to be done directly to the computer, that might fundamentally change my job description. Given that most of those people obviously can't even express this to another human being (Judging from their requirements docs,) I'm not losing any sleep over it.

    What the people who flit from language to language or framework to framework like bees are looking for is a tool that allows them to write code without understanding a problem. Someone who actually understands the problem will always outperform them in any given language. In other words, just because your language has an expressive syntax or any specific feature doesn't mean you can hire chimpanzees to code your application.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  12. Re:Small runtime? by Pseudonym · · Score: 2

    In programming language parlance, "runtime" refers to the implementation of the virtual machine. In compiled C, there's very little "virtual machine"; basically it's just startup and shutdown.

    The standard library is not the runtime. Indeed, many programs (e.g. OS kernels, firmware) don't bother with a standard library, though they also typically implement a custom runtime.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  13. Re:you had me at... by phantomfive · · Score: 4, Funny

    "concurrent programming" to me could even mean using two keyboards.

    Best misdefinition ever.

    --
    "First they came for the slanderers and i said nothing."
  14. Re:you had me at... by mwvdlee · · Score: 3, Insightful

    Strousoup doesn't exists, Stroustrup is still alive.
    "Optionally-typed" does not exclude type casting.
    Compiled languages have runtimes too.
    I think with "concurrent programming" they mean the widly accepted term "concurrent programming" http://en.wikipedia.org/wiki/Concurrent_programming
    Most popular programming languages have a C programming interfaces, including the ones you'd probably call "complete".

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  15. Re:Do they have tail-recursion or lazy evaluation? by Pseudonym · · Score: 2

    Optional typing is not highly desirable.

    Maybe.

    Strict typing a la Algol requires you to write more code (in the form of type declarations). Strict typic a la ML requires someone to write more compiler, which isn't a problem if you're shipping compiled code, but in a typical scripting scenario it requires there to be more compiler in your runtime and (more importantly) slows load time.

    Dynamic/optional typing requires you to write more tests (unless you want less robust code, of course), but tests typically don't impose a cost at run-time. If you only need a thin layer of scripting glue, then the tradeoff may be acceptable.

    I agree that it's not "highly desirable" as a general rule, but I can see the use case.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  16. Re:you had me at... by Pseudonym · · Score: 5, Funny

    That's called "agile".

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  17. Re:you had me at... by NeoHermit · · Score: 3, Interesting
    I was seriously trying to reply to your comment, but the more I read it, the less sense it makes. Where I start? Let's see:

    Dao is an optionally-typed programming language

    ARRRRGH! Comeon guys, type casting is so important even answers.com has a bloody writeup on it. Strousoup is right now spinning in his grave so furiously I'm sure it's causing a small earthquake right now on some pacific island...

    Do you really know what is optional typing (and type inference)? Otherwise you wouldn't be using the tiny example in that link as an argument against optional typing.

    that supports many advanced features with a small runtime.

    Runtime? So it's like Java then... it's interpreted. Ooookay, well, I suppose runtime languages have their place amongst the honored...

    As others already pointed it out, runtime is not just for interpreted language.

    The feature list is probably as long as that of Python

    And already we have our first example of why type casting is important: The programmer/submitter here isn't sure what the feature list of the language is, because everything is represented as an abstract object. /snark

    I don't see your logic here.

    Built-in support for concurrent programming for multicore computers,

    I'm not entirely sure what that even means. Does it support threading? Is it stackless? Are you talking about the ability to set processor affinity for a given thread or process? "concurrent programming" to me could even mean using two keyboards.

    Seriously, what do you expect? "set processor affinity for a given thread or process"??? Maybe "on" is a better preposition than "for" here, but anyone know about concurrent programming should understand what it really means immediately regardless the preposition.

    very friendly C programming interfaces for embedding and extending, a LLVM-based JIT compiler, a Clang-based module for embedding C/C++ codes in Dao, and a Clang-based tool for automatic binding generation from C/C++ header files.

    So basically, your language is incomplete so you're giving people the ability to link in stuff to makeup for it. Okay, that's cool... I guess.

    So in your opinion, any language that has interface to C or another language is incomplete. Do you also think any language that has external libraries is also incomplete?

    It's understandable that people like to bash new languages, but if you do, please make some more solid points.

  18. Re:you had me at... by Pseudonym · · Score: 4, Informative

    It seems that way because on a typical platform the C virtual machine is a very thin layer on top of the operating system and CPU. Its implementation is almost all initialisation and shutdown, and even then there's usually very little to do.

    If you don't believe me, I suggest you try it. Even if you don't use the standard entry point (avoiding the need to process argc/argc/envp) or exit point (avoiding the need for atexit), at the very least you'll need to set up a stack before you transfer control to C code for the first time. That is initialising a virtual machine.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  19. My opinion and some free unsolicited advice ;-) by aaaaaaargh! · · Score: 4, Interesting

    Okay, so here is my uninformed opinion and some free unsolicited advice ;-)

    First of all, some people here are just too defeatist. Yes, it looks a lot like Go and has only few exceptional features, but it's certainly not the worst programming language I've ever seen and e.g. seems to be overall better than Python - if we ignore, for the time being, the external library support which makes Python so great. I agree with others that optional typing is a bad idea, though. Many optimizations will be hard to implement in future and loose typing should be explicit (as e.g. in polymorphic types).

    Since I'm sort of a hobby programming language enthusiast, working on my own toy language in my spare time, there is one annoying thing I must mention, though. Why do so many contemporary language designers choose C-style syntax and not Algol/Pascal/Ada style? Just because they know C best? All of these C-clones, each of them with their own little quirks and specialities, don't really make the syntax more compelling or easier to read. (It would be okay if they behaved exactly like C, I guess, but then they wouldn't be languages on their own.) Why not go for block-style syntax or the Python wite space route instead?

    Take a look at Ada, for example. Yes, I know, the syntax is verbose and has to many double-uses of keywords. It is a bit archaic. However, on the bright side, Ada programs really are extremely readable. You can easily scan through GNAT's source code and understand how the packages work without looking at additional documentation! I'm not saying, "Hey, let's all switch to Algol-style syntax", and not everybody likes the way Python deals with white space either, but a little bit more variation would be nice.

    Which brings me to another issue. If you invent a new language, please make sure twice already in the design phase that it can be optimized later. Nothing is more annoying than an overall nice language that also becomes popular, only to turn out to be basically unoptimizable later. If a function has no side effects, if a data structure is immutable, if instructions or data structure traversals can be executed in parallel, please give us a way to indicate that within the language unless it can be inferred automatically. At least in theory, a new programming language ought to be capable of being as fast as C[1], Fortran, or Ada. Otherwise you could just save yourself lots of trouble and translate it to C++ or SBCL right from the start...

    Footnote [1]: To be taken with a grain of salt. Arguably, C is the the first in the list only because of extensive compiler optimizations not because of its language features.

  20. Re:you had me at... by XcepticZP · · Score: 2

    You must be new here. Stackoverflow moderaton has a sort of friend-system going for it. Friends moderate eachother's posts up. The more popular posters regularly get upvoted for mindless nonsense and regurgitation of the obvious. You stumbled on a particularly popular poster. You probably won't even get a response from her/him, as she/he doesn't see an opportunity to get more upvotes from a response to you.

    They found a way to gain the system, and they love it. That's why you see so many regular posters posting content with common themes and getting upvotes for them, meanwhile giving the rest of us a WTF-level through the roof.

    Personally, I think they derive some sort of pleasure out of it because they have confirmation addiction. But yeah, we can't deny that downvotes make us feel sad, and that upvotes make us feel good in a very basic way. Me, I just come here to possibly get some good debate, and to vent.

  21. Re:Do they have tail-recursion or lazy evaluation? by serviscope_minor · · Score: 2

    ventually you have to know what kind of object you're holding and you actually to use it to do some real work.

    I agree.

    Fundementally all a computer does is manipulate data. The type of the data is the only thing that defines which maniuplations are possible and meaningful. If you aren't thinking about the types, then there is nothing you can do.

    Of course, no one wants to be caught up in irritationg games to satisfy the compiler. This is why I really *really* like the look of concepts (and C++ templating which uses ad-hoc concepts).

    Types become exactly defined by the semantics of their operations, i.e. if it's addable, it's a number. If it's dereferencable and incrementable, it's a pointer like thing, and so on.

    --
    SJW n. One who posts facts.
  22. Re:you had me at... by serviscope_minor · · Score: 2

    Dao is an optionally-typed programming language

    By far the nicest "optional typing" I've seen is C++ concepts. The others I do not like. Af far as I see, a computer manipulates data and the type defines the semantics of maniuplation. Without types then there is no manipulation to even think about.

    Concepts is the best thing I've seen for optional typing since it allows you to specify the required semantics instead of the concrete type, which is what you want. (type classes are somewhat similar)

    The other ones just let you plug in any old crap and hope for the best

    Runtime? So it's like Java then... it's interpreted.

    I have not read TFA, but "runtime" doesn't necessarily imply interpreted.

    For example even hosted [in the standardede meaning of the term] C programs have a runtime, which generally just consists of a bunch of entry points for stdlib functions, and of course the startup code which initialises main. The latter in fact resides in crt1.o (C Run Time.o).

    Hosted C++ has (optionally) larger runtime requirements. As well as having a larger standard library (of course, since it subsumes the C one), it also needs vtables (if you have virtual functions), exception tables (if you use those) and RTTI names and stuff (if that's on).

    Those are definitely part of the runtime, and the tricky thing about a C++ kernel it seems is making sure all that stuff is set up correctly before starting the full execution, since you can't rely on the OS to do it for you...

    But yes, they have gon and implemented their own VM, so it is what one would generally consider "intrepreted". However, with LLVM's ability to interpret or bitcode, that distinction has almost gone now given that it's now much easier to do both.

    So basically, your language is incomplete so you're giving people the ability to link in stuff to makeup for it. Okay, that's cool... I guess.

    That's a little harsh. Even in a complete language, it's probably worth simply linking against a C library, rather than (for example) trying to reimplement things like libPNG or (much much worse) ffmpeg yourself.

    That said, it's "just another language", and apart from a few "quite neat" bits, there is nothing substantially new that greatly increases efficiency or expressiveness or etc over existing languages.

    --
    SJW n. One who posts facts.
  23. And may it die it's well deserved death... by gestalt_n_pepper · · Score: 2

    Not because it's a bad language. It may be great. The fact is that nobody... I mean *nobody* needs one more obscure little language whose wondrous new features would just be another add-in library in C++. This is a mental masturbation tool for the Mom's basement crowd. Nothing more.

    --
    Please do not read this sig. Thank you.
  24. Re:you had me at... by Pseudonym · · Score: 2

    I don't know. All I remember from the expensive five-day training session is that you're supposed to sit at the same keyboard as someone else, and that you stop coding and genuflect when a Scrum Master enters the room.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  25. Re:Do they have tail-recursion or lazy evaluation? by serviscope_minor · · Score: 2

    It's OOP as implemented by SmallTalk, where objects are meant to be thought of as computers that you send messages to, and they decide how to handle those messages. If an object responds to a message, then it's the correct type.

    Not quite.

    With concepts, the binding is much earlier. The way it's proposed that it will work is that you define (e.g.) a number concept, which encapuslates the idea that +,-,*,/ and perhaps exp and log are implemented.

    You then write the code, and it checks the code against the concept: i.e. if you try to use a feature which is not in the concept, compilation will fail. Note that concepts-lite does not implement this part.

    At instantiation time, the type is checked against the concept (i.e. does float have +,-,*,/,exp,log) and the compiler will only pass it if it does match. Concepts-lite does implement this part.

    Note that with concepts-lite you get late compile-time binding, os you can still get errors if (for example) your algorithm then tries to use ^ which isn't defined for floats. That's more like the message passing version (though at compile time---which means at runtime for the template program), where errors happen if you try an invalid operation on an object.

    With concepts, the checking happens earlier.

    --
    SJW n. One who posts facts.
  26. Clearing BSS first by tepples · · Score: 2

    Even if you're referring to a "freestanding" implementation of C without most of the standard library, the runtime still needs to clear uninitialized statically allocated variables to 0 (for numeric types) or (void *)0 (for pointer types) before calling main().