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
kldck_hul#21
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 :)
The speed of statics (not using lookups) is also mostly because they are function calls instead of labels. I'm adding labels in the future, and the only cost you'll incur using those is going between the PRG slots.
Defaultio#22
Can you use this to make 3d games/raycasting fster?
kldck_hul#23
Replying to:Defaultio
Can you use this to make 3d games/raycasting fster?
No, but you can use this to make 3D games/raycasting at the exact same speed.
kldck_hul#24
Replying to:Defaultio
Can you use this to make 3d games/raycasting fster?
To expand on this: When SmileBasic BIG comes out, we'll have ample performance to handle more complex 3D scenes and Lowerdash's overhead won't be noticeable. Lowerdash will make it easy to think about 3D design patterns such as scene graphs, and can enable advanced 3D techniques given a fast enough processor.
kldck_hul#25
Did I make ELSEIF not work again... ?
haloopdy#26
I'm sorry I never commented, but this is still REALLY impressive. I hope you continue to work on it, and I'm sorry the website doesn't provide the best place for documentation. I'll probably use this for a large project... if I ever make one.
Defaultio#27
Replying to:haloopdy
I'm sorry I never commented, but this is still REALLY impressive. I hope you continue to work on it, and I'm sorry the website doesn't provide the best place for documentation. I'll probably use this for a large project... if I ever make one.
#randomouscrapBigProject 2016
chemicalex#28
Replying to:haloopdy
I'm sorry I never commented, but this is still REALLY impressive. I hope you continue to work on it, and I'm sorry the website doesn't provide the best place for documentation. I'll probably use this for a large project... if I ever make one.
^
haloopdy#29
So... how stable is your syntax specification? If I start making a project that's going to take months, am I going to be messed up if Lowerdash updates?
RNGesus#30
Replying to:haloopdy
So... how stable is your syntax specification? If I start making a project that's going to take months, am I going to be messed up if Lowerdash updates?
looks like random is starting to become interested in making SB games. I wanna see what you make!
kldck_hul#31
Replying to:haloopdy
So... how stable is your syntax specification? If I start making a project that's going to take months, am I going to be messed up if Lowerdash updates?
I'm happy with where the syntax is at. Going forward I really only want to add a few additional commands for sweetening entity systems. With REGEX in place, commands like EACH might gain more "attributes". One thing that I am considering going into 0.6, was brought up by AGAaron: Should MODULE have a MODEND or similar tag? Right now, the compiler can infer when to close the Module in every situation; but is this the BASIC way of doing it?
haloopdy#32
Replying to:haloopdy
So... how stable is your syntax specification? If I start making a project that's going to take months, am I going to be messed up if Lowerdash updates?
I think you should do whatever is consistent. If END is used for some top-level constructs, it should probably be used for all of them. That being said, making it optional (if possible) would be nice.
kldck_hul#33
Replying to:haloopdy
So... how stable is your syntax specification? If I start making a project that's going to take months, am I going to be messed up if Lowerdash updates?
0.6 has an optional END for MODULES. It does look slicker with it I gotta say. Should be the last syntax I touch. Hopefully.
16bitcoder#34
Do you mind IF I make this A REAL CODING LANGUAGE? With credit to you ofcoarse (*cough*Before they start the language and make something so they are reminded YOU MADE THIS *cough**cough*) Well excuse me...
kldck_hul#35
Replying to:16bitcoder
Do you mind IF I make this A REAL CODING LANGUAGE? With credit to you ofcoarse (*cough*Before they start the language and make something so they are reminded YOU MADE THIS *cough**cough*) Well excuse me...
What do you mean a real coding languages? ;p And I might actually be confused what you mean. If you're taking about building a library, Lowerdash was built for that. See Ways to Use if you want to publish something that runs on top of Lowerdash. I have mixed feelings on an actual fork of the compiler since its still evolving. With the move to Regex, syntax can be added and removed through plugins; and I'll make that a public interface in a future release.
Yolkai#36
Won the "Captain's Award" in the 4th Ogiri contest: http://smilebasic.com/en/ogiri4/
Captain's Comment This is exactly the sort of thing we anticipated when developing the SmileBASIC language in the way that we did. Excellent! More like this, please!
ChangeV#37
Replying to:Yolkai
Won the "Captain's Award" in the 4th Ogiri contest: http://smilebasic.com/en/ogiri4/
Captain's Comment This is exactly the sort of thing we anticipated when developing the SmileBASIC language in the way that we did. Excellent! More like this, please!
Congratulations!
MCGamer20000#38
Could you add support for : as a line separator? That's the one thing that is discouraging me from using Lowerdash.
kldck_hul#39
Replying to:MCGamer20000
Could you add support for : as a line separator? That's the one thing that is discouraging me from using Lowerdash.
You can use " : " but there is a gotcha. The current parser can't find two LD statements that separated by " : " - mostly because it can't tell if the symbol is inside a string. In the future, this won't be the case. You can write lines of SB with only LD expressions, and it will compile fine. I figured statements and expressions might be a little too confusing to think about for beginners, so thats why the limitation exists. I also find readability goes out the window if you're doing anything too complex and trying to fit it on one line. It's also worth noting that having commands on successive lines is faster than using : and does not make your program larger.
raimondz#40
I suggest that you use sprites instead of graphic for ball.prg because the drawing functions are too slow. In O3DS the speed test give the following values: Spirtes: 71542 Drawing lines: 18811 With that, the demo will slow down when the number of balls is greater than 30.
123