View Poll Results: Choice of project

Voters
24. You may not vote on this poll
  • A small scripting language, possible using bytecode.

    11 45.83%
  • A C compiler.

    6 25.00%
  • An internationalization (i18n) library.

    4 16.67%
  • An implementation of the C++ STL for C.

    5 20.83%
  • An operating system.

    7 29.17%
  • A portable build system.

    9 37.50%
  • A "modern" editor (MVC pattern).

    4 16.67%
  • A game maker.

    2 8.33%
  • An RPG.

    2 8.33%
  • An IDE with integrated SVN support.

    4 16.67%
Multiple Choice Poll.

CBoard Community Project: Poll #1

This is a discussion on CBoard Community Project: Poll #1 within the Projects and Job Recruitment forums, part of the Community Boards category; Originally Posted by MK27 However, it also a matter of syntax. In perl, and I believe C++, the syntax for ...

  1. #91
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,312
    Quote Originally Posted by MK27
    However, it also a matter of syntax. In perl, and I believe C++, the syntax for a method and a function are not quite the same. That means if you are parsing the language, you must provide a mechanism for doing both. Or, you could just use methods.
    If you use methods that have two different kinds of syntax for method calls, one of which does not involve an object when it normally would, then "that means if you are parsing the language, you must provide a mechanism for doing both". Or you could just differentiate between methods and free functions.

    For clarification, why can you write this?
    Code:
    if verifydir(pathsub)
        list[artist].dirpath = pathsub if list.has_key?(artist)
    Why is it that you can call verifydir without the syntax of foo.verifydir(pathsub), where foo is some class or object name?

    My understanding here is that verifydir is a free function. It is not bound to any class or object, but operates on an object. Yet, this is the same for C++ as well. If you contend that there is a uniform syntax, then it holds true that C++ has a uniform syntax for free functions and member functions.

    Quote Originally Posted by MK27
    After all, as a C programmer, I could turn this "duck typing" around and say of the object/method concept: looks like a function, works like a function, it is a function.
    Yes, that is a correct application of the principle.

    Quote Originally Posted by MK27
    Sounds exactly like OOP, right? Except I'd never heard of that -- but I did implement the concept intuitively (right down to the name of the "new" method) using the tools I did have (references are key to this).
    Yes, once you add in support for inheritance and polymorphism. You have stumbled upon the fact that it is possible to simulate OOP in certain languages that lack native OOP support.

    Quote Originally Posted by MK27
    I am sure this is how Mr. Stroupstuf also hit upon the idea.
    He also had the benefit of the existing literature, including certain object oriented programming languages, at the time, but yes: the output of the first C++ compiler was C programs.

    Quote Originally Posted by MK27
    And don't think I'm gonna let this drop til I make you dunderheads understand...
    Mind being more charitable to those who debate with you? I have never once accused you of being stupid, even though I can argue from authority, given that programming languages is one of the topics that I focussed on in my university studies.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #92
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    Mind being more charitable to those who debate with you? I have never once accused you of being stupid, even though I can argue from authority, given that programming languages is one of the topics that I focussed on in my university studies.
    Sorry laserlight, I do have a nasty mouth. All apologies. I don't really think you are stupid.

    As I mentioned early, the ruby documentation implies that the object to which a "free function" method belongs is intentionally opaque; however, I have only read so much and probably it will come up at some point. It still seems to me that if there are going to be objects in the language, meaning a mechanism to deal with methods, we might as well use the exact same mechanism to deal with "free functions". It should be simple to (eg) take a method without an object referent as understood to be part of the cosmic base object. DOM methods are like that, and the existence of ruby demonstrates that it is possible -- ie, this is an option to consider.

    Since the "cosmic object" is opaque, we could call these methods "functions", since apparently calling it a method sparks a flury of consternation amidst C++ programmers For the umpteenth time, my point was about the implementation, and since it seems fundamental, I just wanted to present the option right away. This doesn't mean we have to choose it, but I want to know what the choices are, and not just sleepwalk: "Well, we have to have functions, so we better come up with the function syntax" then "Well, we have to have methods, so we better come up with the function syntax".

    If this is just going to be a genericized "language" which constantly treads a middle ground it will end up being almost identical to something which already exists, and in that case the project is just an exercise. I don't mind doing that at all, but I would prefer to aim a little higher, and we do have a "purpose" ready made here as a focus -- the build system. Snafuist pointed out (using a concrete example) why he thinks OO would be good for that, I agree, and I'm just advancing a further suggestion. Of course *none* of this has been passed thru our peer group (not too sure who they all are), but these are the questions we need to be asking ourselves first.
    Last edited by MK27; 05-21-2009 at 10:38 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #93
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,312
    As I mentioned early, the ruby documentation implies that the object to which a "free function" method belongs is intentionally opaque; however, I have only read so much and probably it will come up at some point.
    Fair enough. I would appreciate it if you would link to relevant documentation so I can hear it from the horse's mouth. (Or read it from the gem's surface, if you prefer )

    It still seems to me that if there are going to be objects in the language, meaning a mechanism to deal with methods, we might as well use the exact same mechanism to deal with "free functions". It should be simple to (eg) take a method without an object referent as understood to be part of the cosmic base object. DOM methods are like that, and the existence of ruby demonstrates that it is possible -- ie, this is an option to consider.
    Ah, then that makes things much clearer. This would be good for consistency: we can just talk about methods, specify the syntax, and then note this one exception. However, it does not necessarily simplify parsing since the parser would still have to deal with a special case.

    Quote Originally Posted by MK27
    Since the "cosmic object" is opaque, we could call these methods "functions", since apparently calling it a method sparks a flury of consternation amidst C++ programmers
    No, if it really is bound to a cosmic base class or object, then "method" would be appropriate, since there may be implications for what exactly this function can access, and presumably one would still be able to use the more verbose syntax that involves the cosmic base class or object. (But then this depends on whether there are implications: the idea of extended methods being unable to access the non-public members of the class appeals to me.)

    As a side note, C++ has non-virtual (as in non-polymorphic) member functions, and C++ specific terminology reserves the term "method" for virtual member functions. Java also has non-polymorphic methods, but they are still called "methods", albeit "final methods". If we do end up designing a scripting language that is object oriented, the choice of whether to have non-polymorphic methods would be another decision to make.
    Last edited by laserlight; 05-21-2009 at 10:47 AM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #94
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    I don't know if you're still arguing about this (skipped the last 15 posts), but:

    Code:
    print("This and that")
    should be a free function, no method call on whatever, while
    Code:
    stdout.write("This and that")
    is a method on an open file-like object replacing the standard output stream. But if we do this:
    Code:
    stdout.write = somefunc
    stdout.write("This and that")
    we assign stdout.write to somefunc, where it replaces the method itself. So stdout.write is a free function and not related with stdout itself (except in the case where somefunc is a method). That was my point.

    My implementation approach: Every type has some related information (operators, methods, name) etc.accessible from ANY instance of that type. When you use dot notation, the interpreter first searches all the attributes in that specific instance. If it didn't found one, it finds a method. The method is wrapped with the implicit first argument and pushed onto a stack (or into a register). Then the method is called, and the call function passes also the saved first argument. Like:

    Code:
    stdout.write("This and that")
    
    Parsed, tokenized etc. I assume a stack-based machine:
    
    push stdout onto the stack - Easy
    Find an attribute named write. If you found one, push it. Else, search in stdout's type's methods. 
    If you found one, wrap it with stdout as first argument and push a copy. Else, raise an error.
    No explicit argument - Argc = 0
    Call the top of stack with no argument.
    Push the result
    
    ------ WHILE ------
    
    write_to_file(stdout, "This and that")
    
    Push write_to_file
    Push an argument stdout (Argc = 1)
    Another one ("This and that", Argc = 2)
    Pop Argc items, and call the last function with those arguments. 
    Push the result.
    
    While a method could be a struct of a function and first argument.
    I think in C++ a compiler rewrites method definitions with a first argument (this) and calls to "Class::Method(instance, ...)". But this is better for intepreted languages, don't you think? And absolutely no changes in syntax. Only the normal dot for attribute access (or method, in this case).
    Last edited by Brafil; 05-21-2009 at 10:58 AM.

  5. #95
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    Fair enough. I would appreciate it if you would link to relevant documentation so I can hear it from the horse's mouth. (Or read it from the gem's surface, if you prefer )
    I have just been using this:
    Programming Ruby: The Pragmatic Programmer's Guide
    If you skip straight to "Ruby.new" and scroll down to "Some Basic Ruby" he introduces the method syntax and uses it to write what you and I might call a function.

    There is also a section "Reflection and ObjectSpace" which might hold some clues. Ruby is open source, and there is also a C API, which documents "Ruby’s underlying C code".
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #96
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    EDIT: No parser being able to do both. Everything is just straightforward. On what would you call "print" (or puts)? On an universal object having > 1000 references and steadily used? What would that differ? And what if the user assigned something to stdout.write?

    Why so many ways to simply say goodnight?

  7. #97
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Brafil View Post
    I don't know if you're still arguing about this (skipped the last 15 posts), but:

    Code:
    print("This and that")
    should be a free function, no method call on whatever, while
    Code:
    stdout.write("This and that")
    I agree. But again we are now talking about jargon -- do you call it a car, or an auto? Hence the ruby model. Go back and skim those posts, you will see what I mean. What appears to be a free function, is, according to the creators and documentors of ruby, a method call. This implies to me something about the nature of the implementation, and again, I just wanted to be aware of the option.

    I certainly don't want
    Code:
    someplace.puts
    either, the point is, if you understand
    Code:
    puts
    to be either an object or a method call on some *completely opaque* base object, then you do not have to deal with the concept of function. They did it in ruby. That's all. It's an option, don't keep your old assumptions!

    And Brafil, please do go back and read those posts. There really is no point in trying to discuss anything otherwise. You will end up
    1. 1) talking to yourself
    2. 2) pointlessly rehashing something someone else already said
    3. 4) engaging in rehashed pointless redundancy


    Maybe that applies to functions vs. methods?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #98
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    OK. Don't care if I'm too silly; Bu I don't really know what a "jargon" is. I think I've missunderstood you. Maybe.

  9. #99
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Brafil View Post
    OK. Don't care if I'm too silly; Bu I don't really know what a "jargon" is. I think I've missunderstood you. Maybe.
    Don't worry. I've aired my point (if you read all the posts, it will become clear). I think there are other choices we have to make collectively first, before this one will become relevent.

    1) Do we want to use the build project as a focus/organizing principle?
    2) If not, do we need such a focus, or can we just get started on the task of "making a language"?

    IMO, it will be general purpose anyway, and we will have a better chance of "breaking new ground" if, from the beginning, we also have some more specific use in mind (such as for build scripting). That does not mean it will be "only usable for that". I imagine most of the applied perl in the world is cgi, but you can still do just about anything with it. I don't want to do something like PHP which is completely specialized (I think...)

    ps. by jargon I meant "jargon". no further special significance. Like, my "jargon" for auto is car.
    Last edited by MK27; 05-21-2009 at 11:41 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #100
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Oh. Well, we could make something between scripting and programming language.

  11. #101
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Brafil View Post
    Oh. Well, we could make something between scripting and programming language.
    I have never seen this distinction made. Do you mean compiled vs. interpreted?

    I do not see a categorical difference between perl and C, both of which I know pretty well, beyond that.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  12. #102
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    No. I mean, perl was designed as a scripting language, while ruby is more general-purpose. Both are interpreted. You can't comfortably write scripts in C. The nuances are important.

  13. #103
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Brafil View Post
    You can't comfortably write scripts in C. The nuances are important.
    What do you mean by script? As I said, I don't see any difference between perl "script" and C "source code".

    Do you (or any body else) have some books you might recommend in relation to the project? The Queens Central Library has a monster programming section, altho it is lite on pure CS stuff (plus I believe they will do transfers by request from the rest of NYC) so there is a decent chance I will be able to find something.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  14. #104
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    The question mark above my head has been getting bigger all through this thread but...
    Quote Originally Posted by Brafil
    I mean, perl was designed as a scripting language, while ruby is more general-purpose.
    ...what?
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  15. #105
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    So far, I don't see anything revolutionary here. That's perfectly fine. It's a rare thing for a person (or group of people) to come out of the woodwork with something that's obviously new, superior, never been tried before. This is about working on a project, even if to some extent, it is reinventing the wheel.

    I'd like to take the brainstorming in a slightly different direction (everyone, feel free to ignore me if you want), but one thing I had considered was a scripting language that was identical to C -- i.e., interpreted C.

    It's been done before, but I still think it's a neat idea. The benefits of interpreted C would include:

    * It's far easier to write an interpreter than an optimizing compiler, so this should be less intimidating than a compiler project
    * An interpreter is capable of far stricter run-time checking than a compiler. As long as we're wasting memory and slowing things down, we might as well be pedantic. Imagine Valgrind on steroids -- we can check even more than Valgrind does because we have access to type information
    * With an appropriately designed API, C code could access the interpreter in an "eval"-like fashion, allowing runtime code generation and self-modifying code
    * Since we control the execution environment, it's easy to implement things like state checkpointing, which we could use to implement a debugger capable of debugging in reverse (backwards in time) in order to watch bugs occur
    * Interpreted C can be more easily sandboxed than native C, which would allow us to put a compiler on a web site as part of a web-based IDE with less fear about potential code exploits

    That's all I thought of at the moment.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. cboard community project
    By zacs7 in forum Projects and Job Recruitment
    Replies: 76
    Last Post: 05-16-2009, 09:30 PM
  2. Problem Displaying a Struct
    By rockstarpirate in forum C++ Programming
    Replies: 16
    Last Post: 05-05-2008, 10:05 AM
  3. CBoard Project?
    By jverkoey in forum A Brief History of Cprogramming.com
    Replies: 40
    Last Post: 06-21-2004, 04:15 PM
  4. POLL! What was your first C project?
    By webguy899 in forum C Programming
    Replies: 8
    Last Post: 05-03-2002, 12:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21