LoginLogin

Lowerdash Beta

Root / Submissions / [.]

kldck_hulCreated:
Download:N334J313
Version:0.7.3 betaSize:65 KB

Lowerdash is an object-oriented language extension for SmileBasic v3.

It simplifies the structure of your code for you, leaving you free to focus on ambitious projects that can be compiled and distributed. It extends the SmileBasic instruction set to include fast constant dictionaries, namespaced modules and adds objects running on a dynamic memory model. Modules are designed to be used with or without dynamic objects. INCLUDES A PACKAGE MANAGER CHECK OUT THE MANUAL! REPORT ALL THE BUGS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Last update: 10/25/16 - New minor version removing privacy... !
Update History 10/22/16 - New minor version with _ 10/18/16 - New minor version with bug fixes 8/27/16 - Small bug fix 8/26/16 - Updated to 0.7 beta 3/20/16 - Updated to 0.6.5 beta 2/28/16 - Spicy new spoiler tags! 2/24/16 - Added code for 0.6 beta 2

Instructions:

To use Lowerdash initially, load "LDC" into PRG2. 
EXEC "PRG2:LDC"

Lowerdash 0.7 introduces an entirely new compiler architecture. This lets Lowerdash be a more flexible language

See the manual for usage!

Guides

Files BALL.PRG - Accelerometer influenced ball object-oriented demo. HELLO.PRG - A hello world demo. LD.KEYS - Changes the editor keys to simple text macros for Lowerdash features. LOWERDASH - The Lowerdash runtime and standard library. Automatically loaded in PRG3 by the compiler. LDC - The Lowerdash compiler. Should be loaded in PRG2. Slot not used at runtime. LPM - Package manager for copying libraries. TEMPLATE - Sample main layout with stubs. __PKG - file describing Lowerdash to LPM. Can install compiler & runtime. _{CLASSES} - files loaded by the demo programs

Notes:

LIMITATIONS:

 - No ON...GOSUB yet - No inline elseifs (I was too lazy to parse ifs in a loop... should be easy to add) - Calling a command like a function results in a command call with a single argument.

Version History:

 Version 0.7 Beta: Garden Parsley ----------------------------------------- This release features an entirely new architecture, with separate lexing and parsing - meaning powerful new features can be implemented N334J313 - remove module level privacy from members. You can now set a member or var from anywhere after looking it up. These games. You no need security. - fix a bug with "dot" not respecting the type of the left-hand operand BUGS: 8EDX83A4 - remove static dispatch from lookups on me. Static properties will now be found dynamically if they are being called this way. Which is slightly slower - add _ as a placeholder for the current module. Lookups on _ will be statically dispatched, and if not found, will be a compile-time error. BUGS: some calls to the "dot" operator will stringify the left-hand side under incorrect conditions 45W372QE - fix multiple FOR...IN uses in one def - != is now an operator - fix lookup on static names such as MyModule.static BUGS: WXNEY3JJ - fix array literals - fix module labels, added case for gosub from def BUGS: - multiple FOR...IN uses in one def redeclare the loop vars - I didn't declare != as an operator. WHOOPS! J534DV3E - New . (dot) operator - New instantiation syntax - Cleaner function and command calls from lookups - More tolerant, punctuation aware lexing - restrictions on colons, quotes, and operators are all gone - Find more syntax errors, earlier BUGS: - array literals are not initialized - module labels are slightly malformed Version 0.6.5 Ballerific-er Beta: ----------------------------------------- This release adds a few missing features and fixes critical bugs in preparation for a refactor 2383C3HE - Array literals - DO can now take arguments - Fixed a serious bug with deleting string type members - Bug fixes BUGS:
Older Versions Version 0.6 Ballerific Beta: ----------------------------------------- QKAEAX73 - Bug fixes - IMPORTs inside an IMPORT are now compiled first, so that their VARs are visible. (They are still only compiled once) - PROTO() does not use dynamic dispatch to find the next prototype - Added TYPE to dynamically dispatch to the type of me BUGS: - While using _DEBUG, RETURNing from a command (not function) early will cause a slightly wrong call history NRSDAXTD - Improved error messages - PROTO() - DO() - Bug fixiest yet. BUGS: √ IMPORT from inside a file being compiled quotes its argument, so the string needs to be unquoted (Whoops!) √ ERR requires a string. It should be more lenient to print numbers. √ PROTO recurses once; 3 or more nested PROTO() calls will cause a stack overflow. THIS IS ONLY THE ACCESSOR, INHERITANCE WORKS Version 0.5 Ogiri Beta ----------------------------------------- 5KV4N8NV - Proto parsing fix BUGS: [COMMON] DEFs cannot immediately follow a MODULE (STATIC and EXPORT can) COMPILE_LIB uses the removed function chomp$ Closing a MODULE with END results in an error. Modules with members will overwrite inherited members 43x3x336 BUGS: Static lookups may chain to the wrong prototype. Dynamic lookups are unaffect. FEATURES: - Change how instances work - Fewer slots taken up - Deallocating memory - EACH - VAR parsing with REGEX patch Version 0.4 BETA ----------------------------------------- XKE8N53P CK33E3RJ BUGS: * _ lookup on instance member setters fails Parse multiple Lowerdash expressions per line. Imports, Module labels and Module-level access to + namespacing on module vars. Compile libraries that don't include the Lowerdash runtime to be used in other Lowerdash projects! Version 0.3 BETA ----------------------------------------- E45QF3L4 Faster runtime at expense of slower constructor. Module Vars, Typed Members, Nil$, Parsing fixes. You can't use : as a line separator. Version 0.2 BETA ----------------------------------------- RADQA3Z4 Initial public release with hot off the stylus prototypal inheritance.

Roadmap

0.7: - Generate parser using REGEX - Standard Lib .Lib - Improved Iterator commands
Future Updates 0.8 - Incremental compile - plugin system 0.9 - 2-pass static resolver plugin (no me("") needed) - private plugin 1.0 - Macros Future: - import Lowerdash into your library to save spaaaaaace in your files - Array members - Operators? - Better handling of :
ProgramsToolsDevelopment Tool
Mariominer#1
This... looks... Deep. I knew somebody would try to make objects, and what the results are is amazing. Lots of other goodies too.
kldck_hul#2
I didn't even document the string library yet... Oh man... What am I doing with my life?
blizord#3
WTF, This looks like a different language....Awesome....
raimondz#4
This look good.However: -Can I do nested module on this framework? - the fact that you couldn't delete will cause memory leak, right?
kldck_hul#5
Replying to:raimondz
This look good.However: -Can I do nested module on this framework? - the fact that you couldn't delete will cause memory leak, right?
Theres no syntax for nested modules. Having another module in the same file just ends the previous module and starts a new one. You can however create a constant or variable that points to another module. 
subMod->"mySubMod"
...
_(myMod("subMod"), "meth")

VAR subMod = "mySubMod"
...
In the future I want to add a me$ accessor so this can be more dynamic per instance. For the memory leak question: YES. Implementing a minheap and storing that information in a symbol table is somewhat trivial at this point, but I still have to do it. I imagine V0.3 or V0.4 will let you deallocate memory. You can also build a singleton module with its own array that you use as an object pool. When you're done with an object it can return to the pool, so its allocated memory can be reused.
kldck_hul#6
Replying to:raimondz
This look good.However: -Can I do nested module on this framework? - the fact that you couldn't delete will cause memory leak, right?
the VAR subMod would only be available inside DEFs, and is not instance specific BTW. 
EXPORT DEF update
...
CALL _(subMod$, "stuff")
...
END
MasterR3C0RD#7
I really freaking wish this was for NodeJS That would be SO COOL!
kldck_hul#8
Replying to:raimondz
This look good.However: -Can I do nested module on this framework? - the fact that you couldn't delete will cause memory leak, right?
I made a demo using object pools: http://smilebasicsource.com/page?pid=61
kldck_hul#9
Replying to:MasterR3C0RD
I really freaking wish this was for NodeJS That would be SO COOL!
Shhh! You might give away my plans to turn 3DS's into highly redundant RESTful micro-services!
MasterR3C0RD#10
Replying to:MasterR3C0RD
I really freaking wish this was for NodeJS That would be SO COOL!
Lol
kldck_hul#11
Replying to:MasterR3C0RD
I really freaking wish this was for NodeJS That would be SO COOL!
We have a modem!
joelable#12
This is pretty cool! I like the idea of custom commands!
raimondz#13
I found a bug. I made a private method in a module to apply gravity based on a certain angle. I load the module's members and then use this condition to limit the gravity If VX*VX+VY*VY > GM*GM THEN VX=GM*COS(A) VY=GM*SIN(A) ENDIF but after running my program, lowerdash generate this: If VX*VX+VY*VY > GM*GM THEN ENDIF VX=GM*COS(A) VY=GM*SIN(A) ENDIF I don't know if this is enough to detect where is the cause of the bug, but If you need more details I can post a pic or upload the code.
kldck_hul#14
Replying to:raimondz
I found a bug. I made a private method in a module to apply gravity based on a certain angle. I load the module's members and then use this condition to limit the gravity If VX*VX+VY*VY > GM*GM THEN VX=GM*COS(A) VY=GM*SIN(A) ENDIF but after running my program, lowerdash generate this: If VX*VX+VY*VY > GM*GM THEN ENDIF VX=GM*COS(A) VY=GM*SIN(A) ENDIF I don't know if this is enough to detect where is the cause of the bug, but If you need more details I can post a pic or upload the code.
Thanks for reporting this! The IF... THEN parsing was kind of a last minute hack to enable me references in both statements. I think this might be caused by an extra space after THEN. Regardless, I will be improving the parsing for IF statements next release.
raimondz#15
Replying to:raimondz
I found a bug. I made a private method in a module to apply gravity based on a certain angle. I load the module's members and then use this condition to limit the gravity If VX*VX+VY*VY > GM*GM THEN VX=GM*COS(A) VY=GM*SIN(A) ENDIF but after running my program, lowerdash generate this: If VX*VX+VY*VY > GM*GM THEN ENDIF VX=GM*COS(A) VY=GM*SIN(A) ENDIF I don't know if this is enough to detect where is the cause of the bug, but If you need more details I can post a pic or upload the code.
I check the code and indeed that was the cause. Now I can go on with my project. Thanks.
Defaultio#16
Just wondering, what exzactly is this used for?
kldck_hul#17
Replying to:Defaultio
Just wondering, what exzactly is this used for?
From the description: "It provides a framework for writing structured modular code, that can be compiled and distributed." Modern programming languages often have constructs in them that let programmers compartmentalize logic and reuse code. SmileBasic harkens back to the old (dark) days, where your program is one big soup of "stuff"; And this soup can be physically painful to a software engineer. Lowerdash attempts to provide shortcuts and "sweeten" the experience of programming in SmileBasic. Real world use cases might include: * a physics library that is self contained (you don't have to copy paste it in) that lets you add 2d mass to anything with an (X,Y) coordinate. * An AI module that makes enemies have randomized, intelligent behavior. * Making a UI with buttons that can be stamped on the screen with different text and icons
NeatNit#18
This is very interesting, but at the same time very confusing - especially since I can't try it for myself just yet! Some questions: 1. Where did the name Lowerdash come from? 2. Can you give an example of something that this makes easier? (Vanilla SB code vs Lowerdash code) 3. Do you think this improves readability, or decreases it? 4. Have you tested the speed of Lowerdash compared to equivalent vanilla SmileBASIC code, and if so, what were the results? More technical: 5. How many lines is the main Lowerdash program? 6. How long does it take to compile a simple module, for example, the BALL in the screenshot? You don't have to answer all at once :)
kldck_hul#19
Replying to:NeatNit
This is very interesting, but at the same time very confusing - especially since I can't try it for myself just yet! Some questions: 1. Where did the name Lowerdash come from? 2. Can you give an example of something that this makes easier? (Vanilla SB code vs Lowerdash code) 3. Do you think this improves readability, or decreases it? 4. Have you tested the speed of Lowerdash compared to equivalent vanilla SmileBASIC code, and if so, what were the results? More technical: 5. How many lines is the main Lowerdash program? 6. How long does it take to compile a simple module, for example, the BALL in the screenshot? You don't have to answer all at once :)
Great questions! 1. Lowerdash is a play on the Javascript libraries Underscore and Lodash. Instead of providing functional sugar, it provides low level sugar. 2. This is going to be a huge answer... :P 3. I think this greatly improves readability. Your code is split apart by functionality. Variable names can be shorter or more descriptive and they don't have to be unique. 4. Yep. The speed has been improving with each release. Right now, 0.4 of Lowerdash is only a few frames slower (2-4) when avoiding lookups. Objects created using new have to have their properties looked up with a function that adds only about 6 more instructions per call. 5. 318 lines runtime. 283 lines compiler. 6. The BALL module is nearly instant. My current project has several thousand lines of code in close to 15 files. The compile time is around 1-2 seconds. Its fast enough that you do not have to distribute compiled code.
kldck_hul#20
Replying to:NeatNit
This is very interesting, but at the same time very confusing - especially since I can't try it for myself just yet! Some questions: 1. Where did the name Lowerdash come from? 2. Can you give an example of something that this makes easier? (Vanilla SB code vs Lowerdash code) 3. Do you think this improves readability, or decreases it? 4. Have you tested the speed of Lowerdash compared to equivalent vanilla SmileBASIC code, and if so, what were the results? More technical: 5. How many lines is the main Lowerdash program? 6. How long does it take to compile a simple module, for example, the BALL in the screenshot? You don't have to answer all at once :)
I should add I program on a New 3DS. I haven't tested on an original in any way.
123