none
Feature to add at Final Version 1.0 (TCP IP) RRS feed

  • General discussion

  • Hi all!

    The newest version 0.9 is realy awsome but to put the cherie at the cake, is to implement network comunication, to create lan/online multiplayer games!

    I've good and simple ideias to implement this.

    Create these functions:

     

    Network.listen - Function TCPListenCreates a socket listening for an incoming connection.

    Function TCPListen

    Parameters

    IPAddr Internet Protocol dotted address(IpV4) as "192.162.1.1".
    port port on which the created socket will be connected.
    MaxPendingConnection [optional] Maximum length of the queue of pending connections. By default the maximum reasonable value will be set.

     

    Function TCPListen

    Return Value

    Success: Returns main socket identifier.
    Failure:

    Returns -1

     

    Function TCPSendNetwork.Send - Sends data on a connected socket.

    Function TCPSend

    Parameters

    mainsocket The connected socket identifier (SocketID) as returned by a TCPConnect function.
    data binary/string to be send to the connected socket.

     

    Return Value

    Success: Returns number of bytes sent to the connected socket.
    Failure: Returns 0

     

    Function TCPConnectNetwork.Connect - Function TCPConnectCreate a socket connected to an existing server.

    Function TCPConnect

    Parameters

    IPAddr Internet Protocol dotted address(IpV4) as "192.162.1.1".
    port port on which the created socket will be connected.

     

    Return Value

    Success: Returns main socket identifier.
    Failure: Returns -1 or 0

     

     

    All of these ideias are in the AutoIt programming language, and it's very easy!

    For more information check the AutoIt site: http://www.autoitscript.com/

    To get these infomation about TCP, install the AutoIt and go AutoIt Help -> Function reference -> Network Management

    This is will get even MORE fun in Small Basic to create games!

     

    I hope you will consider this idea!!!


    Street Racer http://SmallBasicTutorial.BlogSpot.com/
    Saturday, June 12, 2010 10:31 AM

All replies

  • Here is my last pitch for subroutine parameters.

    The problem is scope. I know this. And I really ,really like that SmallBasic  has a single global scope. This is good, and I am not suggesting a change to that. What I am suggesting is a little "Syntactic  Sugar" to the job of calling a subroutine. As it stands now:

    str = "my message"
    lft = 3
    GetLeft()
    c = rtnValue
    TextWindow.WriteLine(c)

    Sub GetLeft
      hld = text.GetSubText(str,1,lft)
      rtnValue = hld
    EndSub

    All of the processing of variables has to be handled in the main program. What I am proposing is a parameter system that simply makes copies of the parameter values. Once again I am not proposing creating a separate scope, or local variables. All I am suggesting is a mechanism to save a lot of typing (the main use for subroutines when you are a newbie) and have the result resemble   what will be seen in other programming languages:

    a = GetLeft("my message", 3)
    TextWindow.WriteLine(a)

    Sub GetLeft(str, lft)
      GetLeft = text.GetSubText(str,1,lft)
    EndSub


    Nothing about that requires a local scope for the subroutine. The values from the subroutine call are copied to the variable names listed in the subroutine's signature. That is all.  The subroutine's name is then used as a variable to allow for a function value return. Once again, the value is simply copied. Because of how odd the syntax looks, I would even give on the return value and say it is optional.

    No local variables. No secondary scope.  I will say it again. No local variables. One big scope.

    This is the last big piece missing from SmallBasic. With this one little change subroutines go from being a lot of nearly pointless work, to a very cool time saver. From a teaching stand point, this is huge. It would take the topic from almost impossible to get the point across, to a topic that teaches itself.

    When this topic comes up, everyone states it as "You must have a secondary scope". And it is all or nothing. I'm saying that global scope is perfect the way it is. Just add this little extra functionality while keeping that very cool global scope.

    Fingers crossed.
    • Edited by Coding CatEditor Saturday, June 12, 2010 7:13 PM copy and paste error - hate word so much
    Saturday, June 12, 2010 7:11 PM
    Answerer
  • CodingCat,

    I can see what you suggest doesn't require major scope changes etc, but it does add complexity - the rules could be clear, but still added complexity.  The idea of scope is to be clear what can change where.  The simplest is global scope everywhere - if we deviate from this then the rules need to be very clear and intuative.

    1] You are using the subroutine name to be the same as the function name - a bit like a FORTRAN function - possible confusion is this a variable or a subroutine name.  Do we need a return keyword to make this clear.

    2] What if I change an argument variable value inside the subroutine, is it changed on return from the function or not (presumably not, it is passed by value not reference - it is a copy only available inside the subroutine).  So the variables that can change are the return value (same name as the subroutine) and all variables not passed as variables.  This makes the passed variables 'different' or 'special' or 'local scope'.

    3] What if I change one of my argument variables inside the subroutine, this change will be lost on return from the subroutine - sometimes I may want this and other times not - confusion.  What does the beginner not privy to this discussion expect to happen.

    4] Possible confusion with recursive calls - a subroutine with arguments calling itself - perferctly possible, but harder to get your head round and debug - multiple local scope versions of variables at different layers or recursion.

    5] Can event subroutines have arguments - what are the consequences for this - if not will they still need empty () argument lists.

    Do all these make sense, what would be the result.

    a = 1
    Add(a)
    TextWindow.WriteLine(a)

    Sub Add (a)
      a = a+1
    EndSub

    OR

    a = 1
    Add(a)
    TextWindow.WriteLine(x)

    Sub Add (x)
      x = x+1
    EndSub

    OR

    a = 1
    Add(a)
    TextWindow.WriteLine(Add)

    Sub Add (x)
      Add = x+1
    EndSub

    OR

    a = 1
    Add (a)
    TextWindow.WriteLine( Add )

    Sub Add (x)
      x = a+1
     
    Add = Add(x)
    EndSub

    OR

    a = 1
    Add (a)
    TextWindow.WriteLine( Add (a))

    Sub Add (x)
      x = x+1
     
    Add = x
    EndSub

    OR

    a = 1
    Add (a)
    TextWindow.WriteLine( Add (Add))

    Sub Add (x)
      x = x+1
     
    Add = x
    EndSub

    These are not all the possible issues or show stoppers, just added complexity and room for confusion.

    I think this is still a valid discussion with more opinions useful and it may be sensible in the long run, but its not clear that the gains outweigh the added complexity.

     

    Saturday, June 12, 2010 9:04 PM
    Moderator
  • Keep to the simple rule that parameters are copied, and there is no weirdness or confusion. Actually, the only perceived confusion is from people who have experience with other environments.

    To answer your points directly:

    1) Using the subroutine name as a return variable is an idea I borrowed from an example I saw recently. You are right in that it may create confusion as to weather a name is a variable or a subroutine. Creating a return keyword may make more sense, or doing away with the idea of a return value all together.

    2) Copies, the parameters are just copies. All one big scope. Changing a parameter value is just like changing any other variable, It effects the value everywhere in the program.

    3) All one big scope. If it happens in a subroutine the changes take place everywhere. This is exactly the same as it is now.  For newbies this will be very easy to understand, and that is all that really matters for SmallBasic. If you want local variables it is time to move up to Java or Visualbasic.

    4) Recursive calls will be a problem. But recursive calls will not be any more of a problem then they are right now. This is the main argument for a local scope. I think a better argument is that easy recursion is beyond Smallbasic and should be disallowed before a local scope is implemented to make it easy.

    5) Event subroutines with parameters, I think this is a non-problem. As designed now, none of the events pass in parameters. If a developer creates a subroutine with parameters and uses it as an event handler, the parameter copy would have nothing to work with, so the variables named would not change. In other words, the parameter list would be ignored.

    Now let's address your examples:
    a = 1
    Add(a)
    TextWindow.WriteLine(a)
    Sub Add (a)
      a = a+1
    EndSub

    The variable a remains the variable a. The parameter value would be copied to itself.  The value of a would be 2.

    a = 1
    Add(a)
    TextWindow.WriteLine(x)
    Sub Add (x)
      x = x+1
    EndSub

    Again the idea is copying. The variable a would be copied to x at the launch of the routine.  As a design, x could either be copied back to a or not as the routine finishes. My opinion is not. In either case x is set to 1 at the start of the routine, one is added, the end result of x is 2.

    Add(a)
    TextWindow.WriteLine(Add)
    Sub Add (x)
      Add = x+1
    EndSub

    This the return value issue. Using the subroutine name for return values was a bad idea. On the whole, to get the main point of subroutines across, return values are not needed. If they are used I think the "return" key word would be needed. This would be syntax error, subroutine name used without the ().

    For the next example, lets rewrite to use the return keyword:
    a = 1
    b = Add (a)
    TextWindow.WriteLine( b)
    Sub Add (x)
      x = a+1
      return Add(x)
    EndSub

    Regardless of the fact that this is a recursive call, you still stick to the idea of copying. Each time you jump into the routine the value of x would be replaced by the parameter variable. Since there is no escape logic this is an infinite loop and would crash the program when the stack is overflowed. Before the crash though, you would be adding one each time.

    a = 1
    Add (a)
    TextWindow.WriteLine( Add (a))
    Sub Add (x)
      x = x+1
      return x
    EndSub

    Again I modified the syntax to use "return" as a keyword.  As I stated the parameter values can be copied back when the routine exists or not depending on the design style decided on. Assuming my suggestion of no-copy-back is taken, the variable a is never changed. The second call would go again with the 1 and a 2 would be printed.

    a = 1
    Add (a)
    TextWindow.WriteLine( Add (Add(a)))
    Sub Add (x)
      x = x+1
      return x
    EndSub

    One last time with the minor rewrite for return, and adding a parameter to the inside call. As described above, the first call is pointless as a is never changed. The inside call of the writeline would return a two to the outside call which would then display a 3.

    The complexity of subroutines and their parameters only starts when you bring in expectations from the outside, and divide up the scope allowing local variables. Just keep the simple rule: The parameters are copied. That is it.  Just copied. You have the same gains and the same troubles as if you copied the values manually in the main program.  

    What you gain is a subroutine design that is easy to teach and a good example of what is available in other languages.
    Sunday, June 13, 2010 12:32 AM
    Answerer
  • Well, I'm against global parameters copying. It's a very odd idea since it will break what exists in every other language. And the main objective of Small Basic is still to learn how to make a program.

    I'm rather in favor of a very different approch, were only one variable would have to be local. It's based on what I've seen working in VB, but it's somehow adapted to SmallBasic. The idea would be to have a (local) variable named under the name of the function. This object would behave like an array and would allow as many local variables as we want, since we can add objects to the array. A special key ("ReturnValue") would be used at the end of the Sub to return a value, if it's needed.

    It would require the following internal changes :

    > Modifying the SmallBasicCallback from "void <FuncName>()" to "Primitive <FuncName>(Primitive <FuncName>)"
    > Adding at the end of a function, at compiler time, a return instruction having <FuncName>["ReturnValue"] as argument
    > Adding at the beginning of a function, a line for parameter mapping (<FuncName>["n"] = <FuncName>[0], ...)

    Samples of how it should works :

    Sub Fact(n)
         If Not IsNumber(Fact["n"]) Then
              Fact["ReturnValue"] = 0
              Goto EndFact
         EndIf
         If Fact["n"] <= 1 Then
              Fact["ReturnValue"] = 1
         Else
              Fact["ReturnValue"] = Fact["n"] * Fact(Fact["n"]-1)
         EndIf
    EndFact:
    EndSub

    ' This function uses the global variable AddI and would
    ' therefore not support recursivity
    Sub Add()
         AddI = 0
         While Array.ContainsIndex(Add, AddI)
              Add["ReturnValue"] += Add[AddI]
              AddI += 1
         EndWhile
    EndSub

    Allowing myVariable.0 as synonym for myVariable["0"] would make things a lot easier to write, since it would avoid the repeated use of " and [. Don't think it would make things more complex for the beginners. JavaScript is an exemple of language where . and [] are true synonyms. Newly introduced Dynamic objects allows that in C# and VB.NET too, but it's less usual.


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Sunday, June 13, 2010 8:44 AM
  • With all due respect Fremy, I just don't see how your proposal is simpler, or less complex.  I have never seen this style of parameter access before and you introduce the need for a local scope. I will grant that this will make the resulting language more powerful; especially in the use of recursive subroutines.

    But Big Deal!

    The insistence on breaking up a program into multiple scopes and insisting on the need for local variables is why the idea of parameters keeps getting killed.

    I do not see the importance of introducing multiple scopes and local variables simply because other languages have them. SmallBasic is a teaching and self learning language. For the target audience, this will be the first language that they use. There will be no preconceived notions, and they will not be looking to other languages for examples. There will be no confusion. When they move on to another language, local scope will simple be another advanced feature to learn.

    What you are proposing adds unnecessary complexity and pushes Smallbasic in the directions of a working, production environment.

    What I propose is a simple mechanism that makes subroutines a more teachable topic, without adding complexity, and without violating the classic BASIC design of a single scope.

    Let's add this feature: single scope, copy only, subroutine parameters. And let's add it without killing the idea by insisting that be more than it needs to be.
    Sunday, June 13, 2010 10:34 PM
    Answerer
  • Since I seem to have co-opted this topic for a general discussion of subroutine and new features I thought I would throw out another small request/suggestion. Can the new hidden textwindow operation ReadKey() be modified to be non-halting? There are already two "halt the task until complete" input routines in the form of Read and ReadNumber. I would like to see ReadKey() be more in the style of inkey$, and allow some background processing while the computer is waiting for a keypress.
    Sunday, June 13, 2010 10:43 PM
    Answerer
  • The problem with parameter copying is that you'll end up with a lot of unused global variables and strange bugs that will remain unexplained.

    Consider something like that :

    For X = 1 to 10

         PrintNumbersTo(X)

    EndFor

    Sub PrintNumbersTo(Max)

         For x = 0 to Max-1

              TextWindow.WriteLine(x)

         EndFor

    EndSub

    To avoid such conflicts, you'll have to give a unique name to your "local" variables. By doing this, you're polluating the global namespace more and more. Having the function name to be a (special) variable that can contains "local" variables is very natural, and I don't see any complexity here. BTW, I didn't invent this idea from nothing, you already have a similar system in JavaScript (even if this is not very used because we can name parameters and use them as local variables, which is simpler for a programmer point of view).

    function Add() {

         var x = 0; var y = 0;

         while (Add.arguments[x] != undefined) {

             y += Add.arguments[x];

         }; return y;

    }

    The problem of functions with parameters is that if they don't have a way to have a local scope, it's completly useless, because you'll end up with the non-possibility to call a function from another because they share the same parameter name. It's not all about recursivity, it's simply about calling another function. It's easy to see when I look at my extension. Those functions are proved useful and are (for the most part) in the scope of what a Small Basic programmer would like to do itself. And, well, I've lot of function that share the same parameters name, because it's the same object they need. If I had to name each parameter DrawLineGraphicsObject, DrawRectangleGraphicsObject, .... it would be very unefficient at typing time, I would increase small error amount and it would not allow to copy & paste efficiently parts of code. It would make the program slower, too, since all those (unused) variables would be kept in the memory because never deleted or reset to nothing.

    BTW, there's no need for the "local variables container" to be named under the name of the functions. It could be named "Args" or "Arguments" in every function, it would make things simpler to learn. It's clearly logical that arguments are not global variables. This is how they are defined. Even in qBasic, the first language I used (and which I learned alone, whithout any help at that time), parameters of functions were local (and variables defined in a function were local too, btw). It never hurt me. I read it was like that, I assumed it. I don't see any complexity.

    http://www.jgsee.kmutt.ac.th/exell/PracMath/IntrodQB.htm (look at chapter 17 and 19)

    Assuming that beginners are not as smart to understand that a "Arguments" object could be local is a wrong assumption and following this assumption is conducing to bad solutions, at my eyes. When you call a native Small Basic function, you don't expect that function to modify the global scope. Why would functions you're defining on your own do? BTW, when you begin to learn small basic, you don't specifically need to have functions with parameters. The learning of the use of parameters could be learnt after, but it should be possible in a stackable point of view. Keep in mind it's the number one request of people using Small Basic on this forum. There's clearly a need you can't ditch like that.

    I would like to comment a frequent critics I've heard about Basic when I said I had learnt the programmation with qBasic. I was told : "It surely has been giving you bad habbits you'll have difficult to overcome". I firstly thought they were wrong, because I saw no bad habbit in the way I had to make programs. Few years later, I must agree that I had learnt some bad design pattern (too frequent use of Goto instead of well formed code, lack of sub-functions in my code (too monolythic programs), ...). Well, if we want Small Basic to be widely usable a learning programming language, it should not suffer from this. Having parameters being global variables is really a point which would be highly criticable, would make the use of function less easy, and would make it difficult for Small Basic to become a widely used learning language.


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, June 14, 2010 8:14 AM
  • This is such a ridiculous argument against adding parameters to Subs.

    In a language that provides Controls and Interrupts, separate Graphical and Text windows, and very strange image handling and interaction, can you possibly argue the angle of 'simplicity' in your support for NOT adding parameters???  

    Sheesh, the most common introduction to programming in education is LOGO, which SmallBasic already recognises by including the LOGO element.  Other than SmallBasic, I am yet to come across a version of LOGO used in education that does not provide parameters.

    Even most of the SmallBasic functions are handled via the passing of parameter values and accepting return values, so to argue that they are too complex for the average SmallBasic user to understand is just taking the p*!#. 

    Heck, it's is so easy to disprove the argument that 'it is too difficult for new programmers to understand'... simply post a poll on here to ask them - or are you claiming these fictional people are too dumb to work out how to answer a poll too???

    Monday, June 14, 2010 7:57 PM
  • Bad habits. That is the main argument brought up when BASIC is suggested as a teaching language . And the argument is total ____.

    When I first branched forth from BASIC to other languages I did have to unlearn a few habits. But what I gained when learning those bad habits was a great deal of experience with the idea of programming.  Way more experience than anyone I encounter that started out in a more complex language.

    Fremy, your contention is that subroutine parameters without a local scope are useless. That is just plain silly.  The goal of SmallBasic is not to be a production language, but rather the goal is to give a sample of what programming has to offer. While keeping a global scope subroutine parameters meet the same goal as subroutines in general. They show that subroutines: 1) Make for smaller programs (you don't have to copy values before doing the call), 2) Make your code more reliable (less code, less chances for mistakes), 3) Help with decomposition (breaking the code up into smaller pieces without adding more code) 4) make the code easier to read (parameters in the call are far easier to follow then variable copying before the call).

    The first subroutine a newbie writes will not be a call from a loop, and it will not have a loop inside of it. This first subroutine will be some version of "Hello World". By the time they start creating complex examples like the one Fremy showed they will be comfortable with the topic. All that will be needed is a blurb explaining how parameters are copied and any confusion goes away.

    Keeping a single global scope makes sense. It keeps SmallBasic in the family of BASIC languages and it simplifies a lot of topics.

    But let us not use this as an excuse to disallow subroutine parameters. They will make SmallBasic an easier language to use. As long as the rules governing their use are simple and straight forward, any resulting conflicts will be minimal and easy to understand.
    Monday, June 14, 2010 11:58 PM
    Answerer
  • Keeping a single global scope makes sense. It keeps SmallBasic in the family of BASIC languages and it simplifies a lot of topics.
    Well, if you had read my post entirely, you would have seen that qBASIC, the first lanugage I learnt, had support for scopes and local variables. And it's clearly a learning language (the one supported by Microsoft at that time, if I remember correctly).
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Tuesday, June 15, 2010 6:18 AM
  • Well, if you had read my post entirely, you would have seen that qBASIC, the first lanugage I learnt, had support for scopes and local variables. And it's clearly a learning language (the one supported by Microsoft at that time, if I remember correctly).

    I read your entire message. I have simply never considered QuickBasic or VisualBasic as being in the family of BASIC languages. QuickBasic was the step where Microsoft started the their languages down the lines from BASIC to Basic. From a beginners teaching language as the original Dartmouth version was intended, to the irritatingly complex production language that VisualBasic it is today.

    Keep SmallBasic small. Add subroutine parameters because they helps in teaching the topic of subroutines; But keep it simple, with a single scope and copied values.

    CodingCat - Developer and Teacher; BASIC, QuickBasic, VisualBasic, C/C++/C#, Java, Java Script, Assembler, Pascal, COBOL, Forth, Fortran and others.

     

     

    Wednesday, June 16, 2010 1:37 PM
    Answerer