uCalc Language Builder feedback (scripting and interpreted languages etc)

[Brice Manuel]

ScriptBasic is a LGPL open source Basic interpreter so I don't get your point saying I'm pimping my product.

I am happy for you, but start your own thread to promote it. Don't hijack somebody else's product thread to promote your product. I am sure you wouldn't like it if somebody was rude and did that to you

[Daniel Corbier]

No apologies necessary. I do not mind John mentioning ScriptBasic. In fact I welcome this info. I had heard of other systems mentioned in this thread, such as Lua, GOLD parsing system, ThinBASIC, etc. But somehow ScriptBasic went undetected on my radar screen. (It's quite possible that I briefly looked at ScriptBasic at some point, but it hadn't stuck in my memory).

Anyway, I am always interested in looking into other solutions that might have something in common with uCalc. This gives me an opportunity to make comparisons when possible, or take note of things that are missing in uCalc. It can also help me sharpen the focus of what uCalc is supposed to be.

John's post gives me the chance to clarify that the ability to embed a scripting language in your program is a specific goal for uCalc LB. Whether or not the documentation or examples make it sufficiently clear exactly how this can be done is another matter. I may need to work a little more on this. As the developer, I am so close to the product that in my mind it seems very easy to embed a language. But I have in fact received at least some feedback indicating that it wasn't exactly clear how to do it from PB.

Perhaps what would help me is if people could give specific scenarios of how they would like to embed the scripting language. I have a very general idea, for instance, that a lot of games rely on scripting. But not being a game writer myself (though I did create a simple jigsaw puzzle kind of game long ago), I'm not sure exactly what specific sections of code the programmer envisions calling up the embedded language, and what kind of specific tasks the scripts would be performing, etc.

I don't mind people pointing out uCalc shortcomings, perceived or real. I feel confident that after everything is taken into consideration, uCalc can eventually become everything a programmer would want in a scripting system, provided that people do explain what they want, and provided interest in it is widespread enough.

[Steven Picard]

I personally can see many uses for this. My main concerns would be price and licensing restrictions (how and where can I use uCalc LB, for example?)

ETA: I am going to try and take you up on your offer (first post) but how long would I have to cash the Google coupon? I am hoping it will be still good when my tax return gets in.

[Daniel Corbier]

I have not decided on the final details for pricing and licensing yet. I want to hear from users on this. I want uCalc LB to be profitable. But at the same time, I don't want to set pricing and licensing in such a way that will cause a lot of people to miss out on all the fun.

There would likely be a one-time fee, and no additional royalties. I don't know exactly how or where people would be using uCalc. But whatever the case, I wouldn't want to place arbitrary licensing restrictions that get in the way of allowing people to accomplish that tasks they need to accomplish.

There is currently no expiration date on the coupon, though it's possible that towards the end of the year I might retire old coupons.

[Steven Picard]

Thanks for the reply.

[Emil Menzel]

The more I have studied ucalcLB the more I have wondered, What is there that ucalcLB cannot do? Doesn't it amount to a full-blown programming language on its own -- if not a mother of almost any other one, if its user so chooses? Or is it somehow dependent on one's owning at least one other programming language?

Could you comment on these questions?

In addition to its other potential uses, ucalcLB could make an excellent teaching tool, especially of course for classes that entail any content in math or programming. (Graphics can be handled very easily, which is nice, and macro capabilities & programmability are obviously built-in.) I'd be interested in knowing more about how ucalcLB manages to do what it does -- assuming of course that this is not a trade secret. With some enhancements to the editing capabilities of the console screen that is used for the tutorial, it could make a super interpreter, just as it stands.

Regarding the price, I am guessing that you would have at least two prices -- one for people (e.g. programmers) who should be able to recoup their investment from their own customers or from employers or grant-givers, and "others". Could you say more about e.g. student discounts?

[Daniel Corbier]

uCalc LB is an ambitious project that tries to do everything. However, now I need to try to shift the focus to those specific areas where it might stand out. uCalc LB itself is not meant to be a language. Instead it is meant to allow the creation of a language of your choice. Ideally, with the help of others, a library of versions of various popular languages would be created. In addition to versions of pre-existing languages, hopefully some people would use uCalc to experiment with new language ideas as well.

It does not depend on having a host programming language. For instance, the demo uCalc.Exe interpreter, although created with PB, is compiled as a standalone executable. And from that, you can create various other languages.

I'd love to reach into the educational community. Several have suggested that I write a "paper". This apparently is what it would take so that people in the edu community will take uCalc LB seriously. I've given it a try, but haven't gotten far with what I've written. So, if someone else out there is inclined to write a research paper about uCalc LB, this would be great. Maybe I can help as a co-writer if necessary and provide the technical details. By the way, I posted a call for a paper writer (white paper or article; which are a little different from research papers), in the "Positions Wanted/Offered" forum at:

http://www.powerbasic.com/support/pb...ad.php?t=36992

I'd by happy to have some kind of student discount, like I used to have for uCalc FMP. And if making it free for students is what it takes to popularize it in the educational community, I'd consider that as well, because I know today's students will tomorrow be working at for-profit companies that can pay for a license.

How uCalc LB works is not a secret. But I'd have to think about it more to give a better response. A paper might be what can give a more coherent answer. Meanwhile, here's a rough idea. One aspect is text substitution. Based on the list of syntax constructs you have defined, uCalc takes text, and iteratively replaces it with a simplified equivalent, until it reaches the form of a minimal language that uCalc understands. This minimal language consists of defining items.

Items are the building blocks. An item is defined by giving it various properties. Depending on the properties you assign to it, such as name, address, value, data type, code to execute, precedence, pattern, rank, etc, the Item can become a function, operator, variable, constant, pattern, syntax, data type, etc.

Pattern matching is an important aspect. uCalc allows you to connect a pattern directly to an action, bypassing the multiple, and more abstract steps required in Lex / Yacc. Instead of the conventional BNF, patterns are matched using a combination of RegEx, and a higher-level way of defining patterns.

There's more.

Since I developed it, the inner workings of uCalc seem more obvious to me. But I'm not sure how much sense this explanation makes to others reading this. Let me know.

Some have suggested that I use a more GUI oriented editor, instead of the console-based one that I currently have. I'll probably have to do that; it might even prove to be easier to develop than the console editor. I just have to get around to doing it. The uCalc.Exe interpreter / editor, by the way, is technically not a part of uCalc LB, but is really just a demo for one possible type of interface. I'm thinking of maybe even offering the code for it (maybe for sale), which could give someone insight into how they'd create their own new-and-improved editor interface.

[Eddy Van Esch]

Hi Daniel,

I have been following this thread from a distance for some time now. Maybe it is time for a small contribution from my side.

When I heared about uCalc LB some months ago, my first reactions were:
- Another language ..? There are already so many languages out there .. Why yet another one ..? What is there to do that the existing (script) languages can not already do ?
- A language builder ..? Let alone having to learn a new language, why would I want to build a new language ..?

Personally, I think the term 'language builder' causes people to hesitate to get acquainted with your product.
It basically implies that people must invest time and effort to build some new language before they can use it.

Months ago, when you first introduced the LB to the PB community I took a look at your manual and frankly, it scared me ...
It looked very complicated. Not something you learn in 10 minutes. It seemed very interesting, but to invest hours, maybe days just to get an impression of its possibilities was too much to ask, and I didn't look any further.

While I have no doubt that your product is a very powerful tool and can be very useful and time saving, I think maybe you need to use a different approach to present it to 'the public'.

Maybe, (this is just my personal point of view, and I don't even know if this is technically possible) you could present uLB as a tool to 'extend a programming language'. Not just to 'replace' any programming language but to add features to an existing language that it does not yet have.
This way, a user would not feel that he/she would have to learn or even build an entirely new language. Rather, he would be able to add features to his language-of-choice to make it more complete.

An example:
I am currently developing an arbitrary precision math library that allows programmers to do math calculations with any precision they desire.
As I am implementing it now, the math operations are all functions that have to be called like this:

        'Declare the arbitrary precision variables
lA = nu_AllocVar(%nu_DT_BinFloat)
lB = nu_AllocVar(%nu_DT_BinFloat)
lC = nu_AllocVar(%nu_DT_BinFloat)

        'Enter the arbitrary precision numbers
nu_PutString_DS("123.4567899*d-98765", lA)
nu_PutString_DS("9*d12345", lB)

        'Perform the multiplication
nu_Mul(lA, lB, lC)   'calculates   C = A * B

        'Get the result
msgbox nu_GetAny_DS(lC)

-------
It would be more user friendly or intuitively to be able to do something like this to achieve the same:

        'Declare the arbitrary precision variables
nuDeclare  lA  AS  %nu_DT_BinFloat
nuDeclare  lB  AS  %nu_DT_BinFloat
nuDeclare  lC  AS  %nu_DT_BinFloatat)

        'Enter the arbitrary precision numbers
lA = "123.4567899*d-98765"
lB = "9*d12345"

        'Perform the multiplication
lC = lA * lB        'calculates   C = A * B

        'Get the result
msgbox lC

This would be like C++ where you can define math operators for datatypes of your own. I'm sure this has a fancy name but I can't think of it right now.

I guess what I am trying to say is: do not focus that much on 'building a new language' but try to present uLB (for as much as possible) as a tool to 'extend any programming language'....

Kind regards

[Daniel Corbier]

Arbitrary precision math library etc

I think I agree with your point. Apparently there aren't many people dying to create another general purpose programming language (except maybe for fun or Computer Science projects). I do think, however, that there might be enough people who need to create Domain Specific Languages (DSLs) intended for a specific kind of task. Perhaps such systems might not even be thought of as "languages" per se. A "language" that evaluates math expressions can be such a DSL. Something like the Turtle macro language in the EZGUI thread, or equivalent DRAW command in old BASICs can be another. In those languages, it takes one line of code to perform a very specific kind of task, which would take many lines of more complicated code in a general-purpose language like PB or C++.

Extending a general-purpose programming language is nice too. Perhaps a small handful of 3rd party developers would create a library of various general purpose languages. Others could then pick a language and customize it according to their needs. You could start with BASIC.uc, and add nice string selection constructs from Python for instance.

One goal is that with uCalc LB, it would be as easy for you to build DSLs as it would be to write everyday programs in PB. It does require some learning; but so does programming in a general-purpose language. For instance, I'm not sure if there's anyone out there who could say they learned, or even formed a sufficient impression of PB or C++, in 10 minutes. So, the challenge is to convince people that it might be worth spending the necessary hours to see what uCalc can do. If I develop uCalc-made tools that people actually want to use as-is, maybe some will come back and want to learn uCalc LB to see how they can extend those tools.

I don't know how many months ago you first looked at uCalc LB, but the November beta comes with an interactive tutorial, so that you don't have to wade through the manual on your own to get an understanding of the product.

As for your arbitrary precision math library, that would be an ideal 3rd party add-on for uCalc. You wouldn't even need to worry about any details for building a language. You could simply link your library to uCalc as a data type. Then with uCalc Fast Math Parser, or any language later created with uCalc LB, others would be able to evaluate expressions with arbitrary precision numbers in them. I can help you get that going if you'd like.

[Branko Spoljaric]

Daniel, it looks like uCalc LB could be quite useful for what I am planning to do. In my spare time I am creating a train simulator and among other things I'd like to enable users to improve their experience by going beyond what is offered in the base package. A specialized scripting language, which is still under my control but completely free for the user to do whatever he/she wants seems to be a great way to go.

So, yes, I'd be interested in getting uCLB but since this is a non-commercial project the suggested price is prohibitively high.

Also, I would need to know if I can embedd uCLB into the language I am using for the project.

[Daniel Corbier]

Branko, please disregard the price. uCalc LB is still in beta, and a final pricing system has not been decided yet. I'd like to make a profit. But I want to make it as inclusive as possible. Perhaps there might be a Free License option. Or maybe to get things started, I could probably give out some free licenses to hobbyists who can showcase an interesting usage of uCalc LB. I don't know yet what I'll do. But whatever the case, don't let anything stop you from giving it a try, and returning some feedback.

Yes, you can embed uCalc LB in your project. That's the goal at least. If you run into difficulties and have questions, I'll be happy to answer.

By the way, everyone is welcome to run through the tutorial and provide feedback, even if you're not interested in the current discount coupon for FMP. Feedback from everyone will be very helpful.

[Brice Manuel]

Daniel: You might want to really think about the licensing and how you want to do it. If somebody would like to integrate your product into a project being done via contract work, often there can be "problems" when trying to use a third-party lib/plug in that has an unclear or even non-existent license.

[Daniel Corbier]

uCalc LB license

Brice: Licensing is something I want to give serious consideration. I'm not sure yet how I'm going to do it. If you have some ideas about how I should do it, or can point to an ideal license in another product that I can look at, please let me know. What kind of license would be suitable for people who do contract work?