Nossrec, The Precompiler Made To Replace SmileBasic

I considered making this compilable to C#. I am still pondering doing this, but the main purpose of Nossrec was to be an optional complete replacement of SmileBasic

I was thinking more a C# program that compiles to SB. That way we could send it over with the modem.

<- corresponds with the "new" keyword. "New" is used for two main purposes: creating arrays, and assigning class references to objects.

Why does this syntax need to be different? I generally think of new as returning a new instance, not being a variable type. EDIT: I realized you're trying to use new as a Let here. I wouldn't.

You can create an object variable type that does not correspond with a class (basically a variable that can hold any value) by not using the "new" keyword and using "=" instead of "<-"

This is very misleading and confusing. An object in most circles is a collection of properties represented by a type, not an un-typed primitive (Integer has 1 primitive int). What use cases would this serve? If the whole language is loosely-typed, it would make sense for EVERY variable to be this way. Except the whole language is strongly-typed. The F# syntax here also does not help. <- is not assignment, it is a message you can pass to the let function.

This compiles to legal code for my "switch/case" library, which has a few COMMON DEFs that deal with this. The "end" is required after every case, just as "break" would be required in C#. I replaced it with "end" because "end" is pretty much the universal keyword for something completing, like for/while/dowhile loops, ifs, switch/case, etc.

Break isn't required in C#.

Objects will have the functionality of C#, with syntax similar to what you might see in F# or Python.

The syntax of F# derives from the fact that its objects are functions and you can interact with them in a functional way. I don't see why you should be using Let syntax unless you really are creating immutable values.

I expect a lot to change too :). I'm not trying to tear this apart, I think it just needs a little more cohesion right now.

"Cannot fall from one case to another." Error appears when I don't use break

I googled this and got: " Execution of the statement list in the selected switch section begins with the first statement and proceeds through the statement list, typically until a jump statement, such as a break, goto case, return, or throw, is reached. At that point, control is transferred outside the switch statement or to another case label. " Assuming it would work just like C, I forgot to read: " Unlike C++, C# does not allow execution to continue from one switch section to the next. The following code causes an error. " My Bad.

<- is also assignment to a mutable value let mutable a = 5 a <- 6

I may not be describing this best, but I think of this style of "assignment" as manipulating the scope rather than a direct store instruction. You aren't putting 6 in a's memory; you're making 6 and pointing a at it. I might be holding this over from Lisp or Scheme...

New array declaration:

type[] name[dimensions]

Also, SB functions and commands are now overrideable. Nossrec-exclusive functions and commands are not overrideable. Overloading might be a thing soon. Private defs still need work. I've found and crunched a few bugs since Beta v1 was released. Also, I think I'll make

arrayname = [a, b, c, etc]

work like it would in Python. I have a way to do it that is ezpz. EDIT: I have a new implementation for objects that will utilize legit JIT compilation (compiling parts of the program while the actual program is running still). It should work. I also have a technique that should work for private functions (right now they don't work at all). EDIT EDIT: Should I add a boolean type (initialized with the "bool" keyword)? I know TRUE and FALSE are a thing in SB, but they're really just aliases for 1 and 0, respectively. I want to create a type that checks that it only has a value of 1 or 0 (TRUE or FALSE) and does not allow setting its value to something like 2. Converting it to a string will return "true" and "false" instead of "1" or "0." If you want, it will not be hard at all to change "true" and "false" to not be aliases to 1 and 0.

I'd like it better if syntax was similar to C++. Python code looks retarded.

I'd like it better if syntax was similar to C++. Python code looks retarded.

I think we are on complete opposite ends of the spectrum. I think most C++ syntax looks stupid (using "::" instead of "." for namespaces, bitshift operators with cin and cout, etc.) Also, private functions are complete. Private functions cannot be called outside the class they exist in. Public functions can be called from wherever in the code. If you're in the same class as a given public function, you can call it independently like "functionname(arguments)". However, if you're outside the class that holds a given function, you must call the class name with it like "classname.functionname(arguments)". EDIT: Update Beta v1.1 http://smilebasicsource.com/page?pid=146 I put a changelog on the page.

using "::" instead of "." for namespaces, bitshift operators with cin and cout

Just a quick history lesson ;) :: is what we used for message passing - think of it going right to left instead of left to right. list::head --> head(list) C++ is very much just message passing on top of C. Its archaic but it was designed to be consistent at the time. >> is also the append to file operator in *NIX. > would be pipe to file. The idea here is that cin and cout are standard *NIX pipes. They should be able to be worked with like standard *NIX pipes.

I really want to use arrow syntax (this <- or this ->) or fat arrow syntax (this <= or this =>) somewhere in Nossrec, but where? I think I'll use <- to add a class reference to an object, whereas = will assign a value to an object:

object a <- BigInt
a = BigInt.Parse("-191834674953410251238")
writeline a.Abs() //output: 191834674953410251238

As for fat arrows, I could figure out a spot where lambdas would be useful, and use => like in C#.

Yay objects work so much better now. Here's how I have objects implemented now. So a function's return value is not type-checked, just like any parameters. I exploit this by making any objects just a function with a return value in slot 3. When you initialize an object, this is the code:

object test=somevalue

and this is the output:

ASSIGN_ "test",somevalue

I then push the name onto a stack of declared objects, and push a bit of info onto another stack that lets the compiler know to replace any instance of "test" with "test()." During runtime, the function ASSIGN_ is called and the following output is made into slot 3:

COMMON DEF test()
RETURN somevalue 'this is a literal
END

Now objects should be mutable. This creates a small problem. Because of this method, assigning a new value to an object requires RUNTIME overwriting of the function (so now I have some real JIT compilation going on). If the precompiler encounters something along the lines of:

test="hi!"

it is compiled into

ASSIGN__ "test","hi"

I then have a function called ASSIGN__ that will find the function with the name "test," delete it, write a new function called "test" with a literal return value of "hi!" and execute slot 3. This redefines the function with the new return value, and all is good. The good about this method: *Objects behave just like they would in a language like C#. If you give an object the value 5, its type (found with the "typeof" function) becomes "int," but is still 100% mutable. Thus, changing its value afterwards to "u r a skrub" makes the "typeof" function return "string." *Conversion between objects and other data types is eliminated (using "obj" to convert to an object was previously required). The bad about this method: *Changing the value of an object is slow.

Beta 1.2 is out with the ability to make an object a class reference! Syntax:

object name <- classname

And to call a function in the "classname" class:

name.funcname

One question, how will mml be effected?

One question, how will mml be effected?

Seconded

MML is something I have not yet decided how to implement. The same applies for how I want to implement graphics, sprites, backgrounds, etc.

A few updates: Nossrec has been renamed to N#. Classes are complete Garbage collection is working Support for importing libraries (".lib" extension) MML library complete Graphics library in development Example code demonstrating some of these new features (following code is 100% functional):

use "MML"

static class entry
 def public void main()
  object mysong <- MML
  mysong = "T120O4C2D2E2"
  mysong.Play
  dealloc mysong
 end
end static

'Hello World program static class entry def public void main writeline "Hello World!" end end static This is just your basic PRINT/? Hello World. Line wasting much? I don't really see why this is to replace sb. It's just a clone of a popular language made to your liking. I'm not opposed just confused why 5 lines of code just print two words.

For a hello world it seems complicated. However, for projects with more modules this aproach is better because you can issolate each thing(example: player, enemies, projectiles, ui, etc) in classes and avoid global variables.

The point isn't to be short, it's to allow object-oriented programming in the smilebasic environment.

This is just your basic PRINT/? Hello World. Line wasting much? I don't really see why this is to replace sb. It's just a clone of a popular language made to your liking. I'm not opposed just confused why 5 lines of code just print two words.

Obviously you don't understand why the other four lines exist. Classes and objects are very powerful programming tools that SmileBasic does not have. "It's just a clone of a popular language." Do you know the definition of "clone?" According to your usage, D is the same language as C++. And even if it was a clone made to my liking, that's how language variants come into existence.

Seems legit.

Yes, it does.