Menu

Stallman asks for GNU project for free VB

2002-02-10
2002-04-29
  • Nobody/Anonymous

    In a letter to the Register, Stallman makes a side comment about the need for a free VB replacement.

    http://www.theregister.co.uk/content/4/23978.html

    As many know, there are already two projects that are really trying for this (1) KBasic and (2) GnomeBasic.  I had always thought GnomeBASIC was part of GNU but apparently, it is a Ximian project, not a GNU project.

    There are many small BASICS that are part of this group and indeed, it would take a consortium of authors to accomplish such a feat.  Stallman has asked for a capable team to contact GNU and I am looking to see who from this forum would be willing to participate in such a project.

    Having GNU backing is extremely useful for a project as it guarentees quite a large audience.  If you are interested, you can either reply to this thread or email me privately at ajl13@bellatantic.net

    Please also mention what you are willing to provide and what experience you can bring to the table as GNU is likely going to want to see some credentials prior to endorsing a project.

    Thanks for your time,
    Anthony Liguori
    Author - GLBCC (GNU/Liberty Basic Compiler Collection)

     
    • Dejan Lekic

      Dejan Lekic - 2002-02-12

      Huh... I am reading this forum and it seems like BASIC developers will never agree with some things and I suppose the only solution is to have separate versions of BASIC and the SAME development team. That can be done easily.
      Sure there is need of GNU BASIC powerfull enough to compete with VB! :) There are millions of VB programmers around world... Unfortunatelly, some BASIC developers won't agree with ObjectOriented aproach in BASIC, and some of them are "connected" to some specific GUI ToolKits (GnomeBASIC, KDE Basic, wxBasic). That is silly in my opinion - BASIC should be aware of GUI.
      Here on this foundry we have enough knowledge and experienced developers to form HUGE and powerfull team that can make EXTREMELY powerfull BASIC compiler/interpreter!

      Remember, THAT'S WHY I FORMED THIS FOUNDRY!

       
      • Eddie Penninkhof

        > Huh... I am reading this forum and it seems
        > like BASIC developers will never agree with
        > some things and I suppose the only
        > solution is to have separate versions of
        > BASIC and the SAME development team.
        > That can be done easily.

        I agree. We can create an extensible framework (backend) for a BASIC compiler (codegenerator, abstract syntax tree, symbol table, runtime library, ...). In the best case someone only has to provide a scanner, parser and code to build the AST to create a compiler for a BASIC dialect. In the worst case  there would be needed some extensions to the backend.

        IMHO the gcc backend is (sec) not suitable for it because it's largely undocumented and has a steep learning curve. I think a well-documented layer on top of the gcc-backend would be suitable.

        The easiest way is to use an existing compiler and 'generalize' it to a framework. Does anyone know a candidate for this? The current version of XBasic is not suitable for it. I am working (but it's far from finished) on a new version of XBasic that could be used for it.

        > Unfortunatelly, some BASIC developers
        > won't agree with ObjectOriented aproach in
        > BASIC, and some of them are "connected"
        > to some specific GUI ToolKits
        > (GnomeBASIC, KDE Basic, wxBasic). That
        > is silly in my opinion - BASIC should be
        > aware of GUI.

        (you seem to contradict yourself here: if BASIC should be aware of a GUI why is it silly that it is connected to a GUI).
        I don't agree with that. IMHO BASIC should be flexible enough to not depend on any GUI (and  should be usable without any GUI at all) but powerfull enough that it can be used with *any* GUI.

        > Here on this foundry we have enough
        > knowledge and experienced developers to
        > form HUGE and powerfull team that can
        > make EXTREMELY powerfull BASIC
        > compiler/interpreter!

        BTW Could we create a mailinglist for this discussion (or project)? IMHO a forum is a bit clumsy to use. If needed I can create one in the XBasic project. Or we could use yahoogroups or create a new Sourceforge project for it.

         
        • Nobody/Anonymous

          <The easiest way is to use an existing compiler <and 'generalize' it to a framework. Does anyone <know a candidate for this? The current version <of XBasic is not suitable for it. I am working   <(but it's far from finished) on a new version of <XBasic that could be used for it.
          Hey, why not use QBasic (I am a mager QBasic fan, before, I was a VB fan, before that, QW-Basic, well you get the general idea...). i have been programming since I was 10, when I got an American made Apple IIe. I THINK I might be able to do some of the coding. But, of course, in order for anything to work properly, one must use a VERY powerful language, or something quite old, or both. I would suggest for some things, use C++, (ie. things like text boxes, etc.). Even so, for other things, like for instance, a timer control, use this QBasic code:
          A = TIMER
          'B = AMOUNT OF TIME THE PROGRAMMER WANTS ELAPSED
          DO
          C = TIMER - A
          LOOP UNTIL C = B
          Just some thaughts.
          Iain McPhee
          Edinburgh, Scotland

           
          • Nobody/Anonymous

            > Hey, why not use QBasic

            QBasic is an interpretted language that requires the full ide to be installed to even run it.  Not a good language for doing anything practical.

            > I THINK I might be able to do some of the coding.

            Well, the idea was/is that the actual compiler only compiles the language proper.  What I consider the language proper, is just the means to perform primative operations (integer arithmetic, string manipulation) and API calling mechanisms.  The runtime library, which is really the heart of any language, would be written in the language itself.  Since a sizeable portion of the language would be written in VB itself, this should open the project to just about anyone with any BASIC experience.

            > But, of course, in order for anything to work
            > properly, one must use a VERY powerful language,
            > or something quite old, or both.

            Not necessarily.  C is a very simple language, at least, the C language proper is quite simplistic.  The runtime library is what is so robust.  At any rate, the big thing that we have to our advantage is that VB is at least a mature language with ample documentation.  This makes implementing a compiler rather straight forward.

            > I would suggest for some things, use C++, (ie.
            > things like text boxes, etc.). Even so, for
            > other things, like for instance, a timer
            > control, use this QBasic code:

            Let's not get ahead of ourselves here.  I didn't really receive the amount of interest that I wanted in order to start up a project and I am going to be away on business for the next few months.  When I get back, and have the time, I will try again to start up this project.

            As far as the suggestion against GCC as a backend, I think this is not a very good idea.  What GCC offers is a well-tested, and robust optimizer and assembler for virtually any platform.  It would literally take years to develop such a backend.  My estimates made developing a GCC front-end for VB at under 6 man months whereas developing a backend would be multiple man years.

            Anthony Liguori

             
            • Nobody/Anonymous

              > C is a very simple language, at least, the C language proper is quite simplistic.
              Evidently NOT! C has a very flexible and complicated syntax, not like basic. Also when we speak about C we should also consider it's huge libraries which are a part of the language as well.
              Basic has a lot of simple structures, also some things are impossible to do with such high-level language like Basic. But look, would anyone blame perl for the fact that it's impossible to write an OS with it. And what is that ill-fated idea about self-compilation? Why? What for? What a sense in it? Every language has it's own area of application.

               
              • Nobody/Anonymous

                > C has a very flexible and complicated syntax, not
                > like basic

                Ok, when I say that the C language proper is "simple," I mean simple in the sense that it presents few lexical or grammatical anomalies and that there are relatively few constructs.  While it may not be "simple" in the sense that it is intutive or natural, it definitely is simple from a compiler-writing persepective.

                BASIC on the other hand may be "simple" in that it is a more natural language and hence, more intutive, but as far as the compiler-writer is concerned, it is a beast.  The is very little similiarity between BASIC statements (gramatically) and there is a whole host of constructs that ambigious for most parsers.  Add in the context-specific lexical rules and BASIC is far from a simple langauge.

                > But look, would anyone blame perl for the fact
                > that it's impossible to write an OS with it.

                Perl is interpretted.  An OS can't be written in an interpretted language :)  BTW:  I will blame perl for being one of the potentially ugliest languages I've ever worked with (next to LISP perhaps) ;-)

                > And what is that ill-fated idea about
                > self-compilation? Why? What for? What a sense in
                > it?

                I couldn't agree more.  It would be silly to write a compiler in BASIC.  BASIC lacks the complex data structures needed to create an AST parsing tree or to develop a reasonable symbol table.

                Then again, there is no reason why a compiled BASIC language cannot be used for a majority of the high level BASIC runtime library.

                 
    • Nobody/Anonymous

      > I agree. We can create an extensible framework
      > (backend) for a BASIC compiler (codegenerator,
      > abstract syntax tree, symbol table, runtime
      > library, ...). In the best case someone only has
      > to provide a scanner, parser and code to build
      > the AST to create a compiler for a BASIC
      > dialect. In the worst case there would be needed
      > some extensions to the backend.

      The problem here is that we would not be sharing a terribly large amount of code.  Most of the code for a BASIC language comes from the runtime library which is likely to be very different for different languages.  The more modern parsers out there (ANTLR for example) automate all the AST building and stuff so there really isn't much a need for a framework that is capable of such because it already exists.

      I too am not necessarily the biggest fan of VB and it's nice to have many language choices.  Unfortunately, we could only take our own individual languages so far.  Pooling our combined resources into a single language will make for a much better end result.  Not to mention the fact that this is an oppertunity to improve VB for those that haves issues for it.  Is there really that many things that are fundamentally different from the language proper that people disagree with?

      > IMHO the gcc backend is (sec) not suitable for
      > it because it's largely undocumented and has a
      > steep learning curve. I think a well-documented
      > layer on top of the gcc-backend would be
      > suitable.

      GCC is quite a monster but it is such a monster for a reason.  Just about all of those complicated features our needed for a complete language.  Writing a GCC front-end is documented decently enough.  One may not find a book about it at Barnes and Nobles, but then again, who reads books anyway :)

      > BTW Could we create a mailinglist for this
      > discussion (or project)? IMHO a forum is a bit
      > clumsy to use. If needed I can create one in the
      > XBasic project. Or we could use yahoogroups or
      > create a new Sourceforge project for it.

      What I was planning on is waiting to see what the interest is in a GNU Basic and then starting a mailing list to work on a proposal of some sort.  Right now, I want to focus on GNU Basic so that I know whether or not to set up such a forum for it or not.

      Regards,
      Anthony Liguori
      Author - GLBCC (GNU/Liberty Basic Compiler Collection)
      http://lbpp.sf.net

       
      • Eddie Penninkhof

        > very different for different languages. The
        > more modern parsers out there (ANTLR for
        > example) automate all the AST building and
        > stuff so there really isn't much a need for a

        2 things I don't like about ANTLR (but I'm not an ANTLR expert, I could have missed something) is that they're typeless (no compile-time (node-)type checking) and 'ad hoc' (there's no fixed definition of the types and attributes). A tool I use and like that has those things is treecc (http://www.southern-storm.com.au/treecc.html), a separate part of dotGNU. It's 'pattern matching' features are really powerful!

        > framework that is capable of such because
        > it already exists.

        I wasn't thinking about building the tree but about processing it (code-generation, semantic analysis (but that's probably largely language-dependant). With a fixed AST specification you could create 1 code-generator for many BASIC-dialects.
        As for the runtime-library: I do think there is a lot of overlap between most BASIC dialects, e.g. string-handling and file support. Other parts are specific for 1 dialect, but those don't hurt the other dialects.

        OTOH you may be right. If there is a powerful, portable, 'free', well supported BASIC compiler with good GUI design and database support and the possibility to use '3rd party' libraries for any task, changes are many people will switch to it, instead of holding on to their previous dialect. But people that have a large codebase written in another dialect have a problem.

        CU, Eddie.

         
        • Eddie Penninkhof

          > 2 things I don't like about ANTLR

          This should have been: '2 things I don't like about ANTLR *trees*'

          CU, Eddie.

           
      • Nobody/Anonymous

        <GCC is quite a monster but it is such a monster <for a reason. Just about all of those complicated <features our needed for a complete language. <Writing a GCC front-end is documented decently <enough. One may not find a book about it at <Barnes and Nobles, but then again, who reads <books anyway :)
        I do!!!!!!!!!!!
        Iain

         

Log in to post a comment.