Beijer Electronics (formerly QSI Corporation)

This is the results of the brainstorming session we had about Qlarity last August or so.



Feel free to post any more items you wish to have included



What do we like about Qlarity I

∙ Objects

∙ Method overrides

∙ Simple to learn/simple syntax

∙ PC Simulation

∙ Ease of GUI development

∙ Powerful programming language

∙ Highly customizable (hardware and software)

Qlarity Language Enhancements / Compiler:

∙ Scoping/Namespace management (e.g. enumerations within templates)

∙ Constants accessible as strings

∙ Dynamic creation of objects

∙ JPEG/GIF/PNG graphics support

∙ +=, -=, *=, /= operators

∙ Multidimensional arrays

∙ Jagged (e.g. arrays of strings)

∙ Rectangular

∙ Objects can contain other objects.

∙ Generics

∙ Early bound

∙ Late bound

∙ Unicode for strings and comments

∙ Optional parameters

OS/Architecture

∙ Linux

∙ Provides lots of built in drivers

∙ Large footprint

∙ Application/FW in the file system

∙ More modern TCP stack

∙ Qlarity applications compile to:

∙ Native Code (compiler would need to understand each processor, including X86)

∙ JIT (not sure how complex this would be)

∙ QSI produced dynamically loaded native executable modules

∙ Consumer produced native (C/C++) code

∙ Multiple simultaneous applications/app threads

∙ Modular firmware (modules which reside in other files.)

∙ An alternative would be to build optional firmware modules into the BFF itself

∙ Full driver abstraction

∙ Different message enumeration scheme (i.e. linear instead of bit masked)

Firmware Services

(many may be implemented as loadable modules)

∙ Remote Debugging

∙ Drawing overhaul

∙ Allow objects to directly draw during non-draw messages

∙ Alpha blending (perhaps only on high-end machines and high color depths)

∙ Allow objects to replace portions of their regions already drawn with transparency

∙ Canvases

∙ Faster True Type (e.g. integer instead of fixed point math)

∙ Runtime graphics (JPEG/GIF/PNG, etc.) support

∙ Runtime image scaling

∙ Web browser

∙ Video decoder

∙ Audio (mp3 or similar) decoder

∙ SVG (vector) graphics

∙ Math

∙ 64 bit floating point

∙ 64 bit integers

∙ Unsigned 32 bit integers

∙ Bitwise operator (and/or/xor) support for integral types

∙ Signed bytes

∙ Bit shift operators

∙ Sub second clock resolution

∙ Code Profiling

∙ Non-resetting time span timer (i.e. GetProfileTick that doesnít reset)

∙ Associative arrays (i.e. C++ maps. Possibly implemented as language feature instead of firmware service)

∙ Reflection (i.e. code can query and use an objectís properties and methods)

∙ Regular expression matching

Hardware Options:

∙ USB

∙ Flash stick

∙ Keyboard

∙ Mouse

∙ more

∙ Higher color depth

∙ Larger screen sizes (possibly on better hardware)

Qlarity Foundry:

∙ Icon library

∙ Mac/Linux support

∙ Idiot proof the Collect for Output feature

∙ Layout View support even if some compile errors exist (within reason)

∙ Protocol Builder

∙ More complete simulation support

Other

∙ Win32 standalone client

∙ Real Time

∙ Java client

∙ .NET (via Mono) client

∙ More protocol objects (email, web server, FTP client etc)

_________________
Jeremy
http://www.beijerinc.com

Another item (I may edit and add more)



Validated property reads (i.e. some sort of "Get" validation)

_________________
Jeremy
http://www.beijerinc.com

- classes, structures, interfaces?

- enumerations, constants within objects

- revamp of auto-documentation

_________________
Ron L.

http://www.beijerelectronicsinc.com/

We already have what most languages would call classes.



Structures (data only, hetrogeneous aggregates) should be disucssed as to what value they provide over a straight object.



Interfaces. These would be nice, but will require a bit of discussion. It may be possible to add them at a later date (with some planning) as we were with inheritance.



Yes, scoped constants/enums are a must. But that is strictly a compiler thing -- as would allowing the compiler to evaluate constant expressions in the context of a constant (e.g. init TwoPi := 2*PI)



Regarding AutoDoc: I would consider defining object meta data as part of the language specification -- this would include any auto doc as well as whether an object is visible in layout view and any other Foundry specific information. Of course the compiler wouldn't actually act on the meta data, but placing it in the language specification would allow for more robust parsing of the data.

_________________
Jeremy
http://www.beijerinc.com

One more idea that was just suggested by a customer, which I like -- have Qlarity Foundry auto-save a workspace (subject to user preference) when downloading, compiling, going to Sim View (not necessarily at ALL of thise times) so that if he forgets to save he hasn't lost a lot.

_________________
Jeremy
http://www.beijerinc.com