Glyph Cee

GlyphC is a new interpreted VisualProgrammingLanguage/HieraticLanguage and DomainSpecificLanguage designed for graphical and simulation tasks by LayneThomas. Instead of classes, composable structures called constructs are used. A construct is essentially a collection of sub-constructs. Interaction is accomplished through a SymbolicUserInterface. Every construct has an associated glyph(icon or visualization/thumbnail) that gives the visual representation. GlyphC is still in it's infancy and while it is not vaporware, it is most definitely not mature.

One of the key features of GlyphCee is the ability to represent the tokens in a compiled GlyphCee program as constructs and operate on them using code appropriate to it's atomic level.

Technical Features:

• Fourth generation AgileLanguage/InterpretedLanguage with syntax similar to the CeeLanguage
• Construct oriented - intra-construct pipes, inheritance, atomic decomposition
• One of the SymbioticLanguages with the CeeLanguage - i.e. it is a SoftLayer?
• BNF LanguageGrammar specified using lexx/yacc(flex/bison)
• Compiles to IntermediateDefinitionLanguage? and runs on a VirtualMachine embedded in application.

Limitations:

• Currently only available for Win32, although porting should be easy.
• Leverages the speed of low-level(i.e. non-GlyphC) routines by allowing them to be called by the VirtualMachine ROM/interrupt style.

Future:

• Ability to embed and interface with the CeeGeeLanguage (or whatever shader languages end up winning)
• Distributed constructs
• Perl-like regular expressions for string processing

References:

• Parts of GlyphC based on work by KevinHarris?(www.codesampler.com)

---

GlyphCee compilation phases

 +-------------------+-----------------------------+
 | PHASE             | OPERATION                   |
 +-------------------+-----------------------------+
 | Lexical analysis  | Source(*.kgc) to Tokens   |
 | Parsing           | Tokens to Tree              |
 | Semantic checking | Tree to Correct tree        |
 | IDL generation    | Correct tree to IDL         |
 | Compilation       | IDL to Interpretable IDL    |
 | Interpretation    | Interpretable to executed   |
 +-------------------+-----------------------------+

---

Some example code:

 //Test numerical operations and string coercion
 val = (((1+2)/3)*4)+34;
 print "val=" + val;

 //Test compares
 if (val != 38) print "FAILED";
 else print "ok";

 //Test shl,shr
 s=2 << 4 >> 4;
 print s;

Bear in mind that this is the textual representation of the code. Usually the code would be represented graphically - either as text using glyphs, or as compiled code with constructs representing the tokens

---

So you said it's available for Win32. Where?

I haven't decided on a software license yet(proprietary, gpl, lgpl, ??) for the code, but I'll put the binaries up on my website as soon as it gets fixed.

• Screenshots too, I hope, since it's visual?

Any LicenseAdvocates? willing to argue a certain side?

Sure. Proprietary is extremely hard to do. New languages or even new implementations of old languages (e.g. lcc for C, which was beaten so soundly by gcc that few even know the name) face huge barriers to acceptance even under the best of circumstances. Proprietary is a large barrier.

It's also very difficult to make money on such things for similar reasons. A few years ago a friend of mine prototyped a visual language and hit up the venture capitalists here in silicon valley. "Forget it, there's not a big enough market." is what he was told.

One can try to make money in a small trickle, but that's hard, too. ToonTalk is an interesting example of this. It's an extremely powerful visual language, and it's fun. The author has put massive amounts of work into it for a decade, and has had good exposure from the beginning with very smart and influential people in the field (I first saw it at Ted Selker's NEW PARADIGMS FOR USING COMPUTERS WORKSHOP). But his very-affordable CDROMs just don't sell well. He probably has made the proverbial minimum-wage from this approach.

If you want to minimize the barriers to other people using it, open source is the way to go, and has the side benefit that, if it begins to interest other people at all, people will begin to contribute bug fixes and new features.

If one doesn't have other overriding concerns, the obvious approach these days is GPL, with the libraries under LGPL. Widest adoption by commercial companies, for instance, would require a less restrictive license (e.g. the one used by X11), but is not as friendly to the original author. One can also allow such an alternate license by request only ("What? Sun wants to ship it under the MIT license? Well, ok.")

What are your other concerns? If you have any, they would be the source for arguments for a different open source license.

Well, GlyphCee is the language aspect. I wrote the language to use in KatascopeStudio 2 (lack of a scripting language for KatascopeStudio caused its collapse). So I'm not sure which parts to release. The layers for KatascopeStudio 2 are actually like this:

1. Backlite - C++ Debug/memory tracking/logging/developer hooks
2. Base - The C++ base layer/standard api/foundation classes/utility layer/VM ROM/etc
3. GlyphC VM - The GlyphC intepreter
4. GlyphC Constructs - The set of GlyphC scripts that contain the logic for things like scene,texture,element,rgb,transform,etc

so I'm ok with releasing layer 3(GlyphC VM) as GPL, but I'd have to release layer 1 and 2 as well. Layer 4 is what comprises the "uniqueness" of KatascopeStudio 2, but I'd need to distribute the scripts as well, so it's kind of all or nothing. . .

The real problem is that this is for visuals(I do projections for shows), and I've released software as winamp plugins before - only to see them used by my competition at shows. . . and I don't think I can release the software as GPL and include a non-compete agreement as part of that. . .

This last part summarizes your concerns? That's understandable. One interesting approach was taken by the author of GhostScript, the open source implementation of PostScript. He releases proprietary new versions with cool fonts 6-12 months earlier than he releases the same thing open source without the cool fonts. So there are clever little things one can do to address tradeoffs like that.

That sounds like a reasonable solution. . . i.e. release the proprietary software with special textures, models, scenes, etc. later release it as GPL minus all the goodies. . . Kinda crippleware, but it's still free and others could make their own artwork

A non-compete is contrary to GPL, true. You could release some piece of it under a special non-compete license, and the rest of it under GPL, for instance.

Did your competition severely hurt you financially? If not, another possibility is just to work on being more Zen about taking such things in stride.

Hard to say, I never made any profit on the business anyhow - it was just for fun(writing industrial control software pays the bills), so maybe moving to a higher level - i.e. toolmaker, not show man would open up new avenues.

• Or risk taking away the fun. When profit isn't the focus, most people find considerable satisfaction in creating something that other people like and use; you've apparently experienced that in doing shows, and I would think that you could get something similar from doing software.

One "feature" of going GPL is that there is a lot of GPL'd SDK's and libraries that I could put in at the "ROM" level and greatly amplify the GlyphC VM. . . I'd have to go completely GPL and figure out the interfaces for it all, but it might be worth it.

Note that the LGPL was created for libraries, so that they could be used with non-GPL software without virally tainting everything they're linked with, so these days almost all libraries are not GPL, they're LGPL. Which means that you might benefit from going completely LGPL but maybe or maybe not GPL. Not sure if that's what you meant, but there's a significant difference.

---

See: IssuesForLanguageDesigners