luxe / unilang Goto Github PK

Should we add to the UniLang language [pre-conditions][post conditions] tags?
We have brief and detail right now. Do we need these. Hmm. Think about it.

-support different doxygen block styles
-have things return strings instead of directly printing them to streams

starting to get messy. Checking for constructor, and counting number of non-constructor methods is repeated across multiple modules.

Havea "general utilities" more specific from pre-jstd utilities to account for code duplication

Problems I ran into while creating objects for the sole purpose of wrapping some data:

• Don't create an input struct if there isn't any variables for it.
• Don't provide an update function if there is no API on the object
• Don't pass in the input struct to the Update function if there is none
• Change CPP wraper to not declare inputs if there are none.
• Change CPP wraper to only pass in the outputs if there is no inputs
• Change CPP wraper to not update at all if there are no API methods

Having an empty state specifier should be the same as not having any, and should NOT result in an error.

In Dia, or possibly something better

Get rid of the Exit_With_Red_Error. Replace with just Red_Error. When the exception is caught, we skip over the file, and move onto the next; so we don't want to terminate the pogram

label if an enum is iterable or not

especially for the bools. A matching green and red would be nice.
It just requires that weird nesting in the theme file

qt gui that maps to a c++ struct of (ints,floats,enums,bools)
kind of complicated; see what's out there...
Might have to bundle all of the types with meta information

Meta_Type<int> count;
count.value =5;
count.name ="count";
count.label = "blah blah;"
count.toolTip = "sdfsdf";

It might be better to Qt<->json<->C++ struct

No new unicode characters are needed for this.
The names of the functions will just need to be + - *, etc. and the language will deduce the right thing. Current code will need to be changed to ignore instances of these functions(or turn them into words for C code)(options for all that etc)

ObjectPlus(Obj x, Obj, y); //for c Code. if option allows.

all of the casing functions should be a part of varying portions; not all together

[header] //assume to be a local file, and assume the file extension if not specified
//evaluates to "header.h" on a c-exporter and "header.hpp" on a cpp-exporter

However,
[header.h] //evaluates to "header.h" on any exporter. (presumably)

[\header] //assumes to be a system header with no file extension
//evaluates to

However,
[\header.hpp] //evaluates to <header.hpp> on any exporter. (presumably)

make it configurable also.

Not sure if I really want this, but it will deal with a change someone made in code...

that would be cool

• self method call [do private thing]
• data member [data from inside the object]
• access member (. or -> deduced on usage)
• access method (. or -> deduced on usage)
• parameter
• return statement
• TRUE/true FALSE/false

trevor C++

That way I can convert things to true or TRUE and false or FALSE depending on the export languge.

Haha, that's probably a dumb idea.... maybe

It will need to parse the headers and tell you if that function exists
Similarly, data member access

and enum value name like this:
[enum value]

becomes:
ENUM VALUE

but it should be:
ENUM_VALUE

Something that could work, for the export_spawner, and the language_spawner, and the style_spawner, etc. Basically an object that does something similar to a giant if else but looks cleaner, and can be determined at run time.

Every part of the CodeLang structure should have an associated module used for printing.
Everyone of these printing modules should be associated with a configuration struct to explain how to print it.

NO! not print. string returners for it.

Eventually all of these options will probably need serialized into json, and eventually configurable that way.

If the class name(aka, the filename, is being used anywhere in the code), we should print a warning to use the unicode replacement instead!

• namespace parsed into CodeLang structure
• namespace printer

it can be deduced by the type, because the type will have a capital E at the end.
The code is already doing that, just remove the parameter, and fix the calls to it.

Got some pushback generating the 3 constants (FIRST,LAST,TOTAL) as constants outside the types. Provide an optional way to generate them as part of the enum instead.

From a user setting options, they should not need to set functions, only enums that will then call those functions.

Based on options, we are going to be changing the actual unilang structure.
adding methods to the methods section. Adding data members to objects. All kinds of things.
All of this data needs an enum for SPECIFIED/GENERATED. in accordance to what is contained in the actual .UniLang file.

• give inheritance an actual Name portion
• parse inheritance into CodeLang structure
• inheritance printer

• first enum constant
• last enum constant
• total enum constant
• first enum function
• last enum function
• total enum function
• next enum function
• previous enum function
• enum -> string
• string -> enum

The warning portion uses the CodeLang data structure to easily check if anything is worth warning about. Unfortunately if it finds something, it can't give any context as to where the warning occurred.
It seems like every single leaf element of the Codelang structure, and possibly some higher level stuff(not sure though) is going to need to carry around the file marker of where they physically exist in the file. This is just an extra data member, and it shouldn't break anything in terms of the rest of the code.

Use what was caught in the exceptions to write better error messages.

Error handle might be moved to a generative dependency soon.

that can be links to webpages with UML digrams, and call trees, etc.
This data should remain OUT of the Unilang language. It will need generated somehow through the settings.

Eventually we will need to find a way to keep the online site and the top comment in sync

Also, we want a URL validator to check and make sure that the links aren't ever invalid.
Add a setting whether or not generated URLs should be checked(since it will make compilation slower)

We need to move away from using the type_to_hungarian_notation_converter as it has all these extra bools that need to be passed. Everything should convert to using the functions in data_member_to_hungarian_notation_converter.

all the pre-jstd functions use string, but the entire CodeStructure stores it in wstring.
Too many conversions going on.

In Dia, or possibly something better

• [SELF_ENUM_TYPE]
• [SELF_ENUM_VALUE]
• [SELF_MACRO_NAME]

add something to the UniLang grammar that allows serialization stuff to be injected into the C++ class.
Probably boost serialization, some json library, some generic print function for debugging.

injectable, observable, and retrievable are all independent methods that may or may not exist.
should like
[ior] instead of the actual words as a string

It has multiple functions that are all similar. Should be a template. Not sure how hard it is to do templates in hcp, but I know it's definitely possible.

Not sure how we are going to do this yet. templated class will affect the methods and data members. It's possible, to use our code graph, and if the type isn't discovered, we'll know if the templating succeed.

For now though, knowing these kinds of things isn't THAT important. If we just add unicode characters for object templating, that will meet the generation requirement.

For some reason when I try to call a local method inside a local constructor method, it fails to find the method call. It also reports only seeing only one function total. So method_call_in_method is definitely only getting one method(the constructor itself passed in when evaluating the method)

Bad exception thrown and caught. make it more graceful

Hmm, this might not be entirely possible, but perhaps we could abstract away these symbols and keywords from the actual type.

Right now, these things are mixed in the actual type.
We parse them out ourselves and determine

bool is_const...
bool is_pointer...

Instead, we would replace them in the CodeLang structure as one of the following enum values:

COPY
REFERENCE
READ-ONLY

The correct implementation could be derived from these concepts.
This would be good for other languages, and even C/C++ in terms of const*const and const&

since every token can be read into an abstract data type, add functionality to reprint the CodeLang file in a desired standard format.

turn each exporter into a separate program, so that less flags need to be used.
They should also be generative dependencies, and then re-used for this compiler.

HAHA I know...
It may be easier to run another program after this compiler.
Some LibTooling with clang-check? Probably.

• This applies to literals as well
• we want to avoid explicit casts to the type that something already is