about gmac script language

[dark100]

Hi All!

I have been developing an embedded macro script language (called gmac) for some time, and I would like to ask your opinion about it.

Here is a quote from the introduction part (in the readme):

Gmac is more like an embedded script language (like JavaScript), than a
common macro preprocessor. You can execute small scripts enclosed in '[;'
and ']'. These scripts are executed by gmac. Other parts of the input
are left unchanged. Well, this is not entirely true, since some commands
can further read the input. (These read commands can help you to write
your own custom preprocessor)

Short feature list:
- C style script language (at least not far from that)
- simple types: int, float, string, array, object
- type-less variables (conversions are checked run-time)
- object oriented (classes and virtual methods are supported)
- function context save (these saved contexts are called frames)
- built in error handling (try blocks)
- small memory footprint (useful for embedded systems)

You can download it from:
http://sourceforge.net/project/showfiles.php?g roup_id=160876

Areas where it may be useful:
* Many programs has limited parsing abilities. Gmac can push these limits, and, in the same time, you can put your code where it will be used, not in several hard-to-find scripts.

My qestions:
* Do you think the overall direction of this project is good? Or are there better tools? Do not hesitate to tell me, I want to learn :)

* Are there any good websites, where such new tools can be discussed? I am not sure this is the right place (I mean, this is a "Misc Qestions" category, but gmac seems not really fit in other categories as well).

[joedeene]

i think this an appropriate spot for this thread, the only other possible threads it could go under, POSSIBLY, are software development, or maybe the programming language you used to make this program, but i think this is an appropriate thread, and as far as is the overall direction of the program is good, well i havent used it so i cant compare and judge but i think it can always be a good thing to have a commited programmer trying to make something new, thats beneficial, so i mean as long as you dont have virus' in your program, then it is heading in a good direction with your commitment to keep at it, keep fixing bugs, make it more advanced and just the experience gained can be benefical to in the end, *This is my opinion*

[JosAH]

Can gmac be used as an embedded script engine for compiled languages as well?
(e.g. C, C++ etc.)
Do we need an extra preprocessing phase then? On the side: what has gmac
to offer that other languages don't offer?

kind regards,

Jos

ps. Just curious but your link didn't work for me (my WiFi has hiccups)

[dark100]

Thank you for your encouragement! This is the third major revision of this project (I don't like the syntax of the first one, the second one was too slow. This version is partially inspired by the JavaScriptCore subproject of Apple's WebKit)

It was strange this link was not work:
http://sourceforge.net/project/showfiles.php?g roup_id=160876

This is an outdated old site of this project, but the "download" link still works: http://gmac.sourceforg e.net/

You can also find it, if you search the word "gmac" in the sourceforge portal. (And google also can find it sometimes, however, not always the most recent version...)

JosAH, your guess is right. An extra preprocessor phase is needed, if the library is not included by the other tool (the main.c shows how you can extend any existing tool with gmac, it is practically a getc, putc pair).

You can extend anything with gmac (even C, C++), but perhaps, it is better for non-procedural languages, since they have more limitations. I worked with a program, which uses .ini configuration files, and it does not offer any kind of expression evaluation. Gmac was great help there.

However, ther are some things I used gmac and C before:

* Directories are separated by backslash under Windows and slash under Linux. This can be automatically done during preprocessor phase.

* I made a game, and the game uses "items". These "items" are constant objects, with several properties. With gmac, I can describe them in object level, and it made several define constants and arrays from those objects. It is much easier to maintain high level structures.

[JosAH]

I'll check out that link again because Google only gave me General Motor stuff,
mortgage schemes named gmac and some mysterious genetic modification
house of horror somewhere in Asia ;-)

As a premature question: how's the language interaction between a language X
and gmac? Can X use gmac's objects/values and/or vice versa? How fast is it?
Does that link contain a user guide or some language definition text?

kind regards,

Jos

[dark100]

Perhaps google don't think much about this project :) I must admit, although this project is two years old, it has not gained too much attention so far.

- interaction: There is no interaction now. But that is a very good idea! Well, I don't know about other languages internal working, but with a little help, I think I can implement some nice things.

- speed: I think it is two times slower than the mentioned JavaScriptCore engine. For me, a highly configurable engine, and working without memory leaks are more important that the raw speed at the current development stage.

Currently you can configure:
* character type (char, wchar_t)
* integer type (int, long int, long long int, __int64, etc)
* float type (can be disabled) (float, double, long double)
* win32, linux32, linux64 are ok, except some issues with floating point - integer conversion things, which seems dependent on the compiler not the OS.

- docs: the zip file contains a 26 kbyte README file, all source codes, binaries for linux and windows.

[Curtis Rutland]

Well, as Jos mentioned, GMAC is General Motor's financing company. Don't ever expect to get top google hits :p

[JosAH]

Maybe it would be fun to see how fast gmac is on this recursive benchmark.
It's just three functions: Ackermann, Fibonacci and Tak; they're completely
useless of course but are real speed killers for (more or less) functional programming
language interpreters.

My own toy language can only perform the tests fast when I enable memoization
but others consider that cheating ;-)

If you can compare it to the C version on your computer we can see a speed ratio.

kind regards,

Jos

[dark100]

Hi Jos!

That page is interesting! I haven't heard about it before.

The results for N = 11 (user time):

C: 0m1.508s - 1,5 sec (using the implementation provided by that site)
GMAC: 5m59.182s - 359.182 sec -> 239.3 times slower

2.36 * 239.3 --> probably 564.82 sec on their measurement system.

The speed is around the other interpreted languages. I plan speed optimizations later, but that is not my focus now. (I made coverage tests with gprof and gcov, and it seems the id resolving should be faster)

[JosAH]

The results for N = 11 (user time):

C: 0m1.508s - 1,5 sec (using the implementation provided by that site)
GMAC: 5m59.182s - 359.182 sec -> 239.3 times slower

2.36 * 239.3 --> probably 564.82 sec on their measurement system.

According to the table in that link your language has about the speed of Python,
which is reasonable. I read your readme file but I couldn't figure out whether you
do dynamic binding or lexical binding. The former is more fun (and quite a bit
older than lexical binding) but quite a bit slower when deep recursion is involved.

kind regards,

Jos

ps. my toy language uses deep binding which is slow as molasses when that
memoization feature is turned off ;-)

[dark100]

Dynamic binding. I agree, dynamic binding is far more fun :)

That means this code is ok:

[;
  func = sub() {
    func2()
  }

  func2 = sub() {
  }

  func()
]

Well, gmac is focuses on stream parsing, which usually not involves deep recursion. Instead, many string fragments are passed through a pipeline (with in and out operators). This is the preferred way instead of making large strings with += . To tell you the truth, gmac is not wanted to be another pyton, javascript, C, or any common procedural or object oriented language. It is more like a 'sed' or 'awk' in its unique way, bit its approach is quite different.

Can I have a question? What is molasses? :) Wikipedia says it is a thick syrup.

(I will be away for 2 days, but after that I hope we can continue this discusson. I have learnt much from you. Thanks)

[Curtis Rutland]

Molasses is a thick syrup. It pours quite slowly, more so when it is cold. Hence the common expression: "as slow as molasses in January." I'm not sure how many languages/cultures that expression spans though.

[JosAH]

Can I have a question? What is molasses? :) Wikipedia says it is a thick syrup.

(I will be away for 2 days, but after that I hope we can continue this discusson. I have learnt much from you. Thanks)

There is a (slang) Dutch saying that goes "it's as slow as thick horse sh*t through
a physician's funnel". I hope that explains it ;-)

I don't understand the deep binding from your gmac example but I think that's
just me. Maybe a few paragraphs in your readme fille that would explain your
gmac's paradigm a bit more would go well with it.

And I think a bit of a language binding would go well with the popularity of your
gmac language.

kind regards,

Jos

[dark100]

Hi!

I made some performance optimizations in gmac. Now, the local variable references are stored in an array, so they can be accessed very fast, and some functions are changed to inline. Those changes greatly improve the md5 calculation benhmark (down to 101 msec from 126 msec), and slightly improve the recursive benchmark (5 min 43 sec from 5 min 59 sec).

Do you have any general ideas (experiences) which makes interpreted, non-typed, stack-based languages fast? (Except JIT or tracing :) ) Now, a high level byte-code is generated from the abstract syntax tree. That byte-code is interpreted by the main loop.

Thanks in advance.

[JosAH]

Well, memoization is great for speed (but uses quite a bit of memory); it can only
be used for referential transparent functions (i.e. f(x) always returns the same
value for the same x and has no side effects). Keep a table of f(x1), f(x2) ... f(xn)
and when f(x) is called with a known x, simply retrieve the function value from that
table because there is no need anymore to call the actual function. When x isn't
known yet in the table, call f(x) and register its return value when f returns.

kind regards,

Jos