Announcement

Collapse
No announcement yet.

uCalc Language Builder feedback (scripting and interpreted languages etc)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Daniel Corbier
    replied
    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?

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


  • Daniel Corbier
    replied
    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.

    Leave a comment:


  • Branko Spoljaric
    replied
    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.

    Leave a comment:


  • Daniel Corbier
    replied
    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.

    Leave a comment:


  • Eddy Van Esch
    replied
    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:

    Code:
            '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:

    Code:
            '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

    Leave a comment:


  • Daniel Corbier
    replied
    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.

    Leave a comment:


  • Emil Menzel
    replied
    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?

    Leave a comment:


  • Steven Picard
    replied
    Thanks for the reply.

    Leave a comment:


  • Daniel Corbier
    replied
    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.

    Leave a comment:


  • Steven Picard
    replied
    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.
    Last edited by Steven Picard; 15 Apr 2008, 05:59 PM.

    Leave a comment:


  • Daniel Corbier
    replied
    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.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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

    Leave a comment:


  • John Spikowski
    replied
    Any particular reason for hijacking Daniel's thread to pimp your product?
    Brice,

    What I got out this thread is that Daniel's offering may not be a good fit as an embedded scripting language. ScriptBasic is a LGPL open source Basic interpreter so I don't get your point saying I'm pimping my product. :thinking:

    Originally posted by Daniel
    I have spent a lot of time working on the technical aspects of uCalc LB. But when it comes to identifying the correct target audience, I haven't been successful in that aspect yet. I kind of hoped that people would figure out on their own what they might be able to do with it. Apparently, it's not going to happen that way. So I guess I'm going to try to figure out the target audience as I go along, hopefully with the help of those reading this thread.
    I guess I was also pimping the new HP mini-note when I made that post.

    Daniel,

    I apologize if my post about ScriptBasic as an alternative solution high-jacked your thread. I will remove the content if you wish.

    John
    Last edited by John Spikowski; 15 Apr 2008, 04:12 AM.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by John Spikowski View Post
    ScriptBasic is really easy to embed in your PowerBASIC programs if your looking for mature Basic interpreter. I will try to post an example here soon.

    http://www.scriptbasic.org

    Embedding the Interpreter


    John
    Any particular reason for hijacking Daniel's thread to pimp your product?
    Last edited by Brice Manuel; 15 Apr 2008, 02:54 AM. Reason: typo

    Leave a comment:


  • Elias Montoya
    replied
    uCalc is the best i have seen. Currently im very busy with the next upgrade of Egrid32,
    but my intentions are to create a full featured spreadsheet engine for Egrid32 using uCalc
    as soon as i can. This way i will be able to show my findings with uCalc at the same time
    i create a powerful example for Egrid32.

    Yeah! PowerBASIC... Power!

    Leave a comment:


  • John Spikowski
    replied
    ScriptBasic is really easy to embed in your PowerBASIC programs if your looking for mature Basic interpreter. I will try to post an example here soon.

    http://www.scriptbasic.org

    Embedding the Interpreter


    John

    Leave a comment:


  • Daniel Corbier
    replied
    I have spent a lot of time working on the technical aspects of uCalc LB. But when it comes to identifying the correct target audience, I haven't been successful in that aspect yet. I kind of hoped that people would figure out on their own what they might be able to do with it. Apparently, it's not going to happen that way. So I guess I'm going to try to figure out the target audience as I go along, hopefully with the help of those reading this thread.

    Maybe it's a little bit futile to highlight the aspects of LB that have a lot of competition. The ability to create a full-fledged scripting programming language is just one possibility. However, the thing that you create does not have to be a scripting language per se.

    uCalc Fast Math Parser represents one kind of "language" you can develop with uCalc LB. With PB, you can create a program that plots a sine wave for instance. However, if you wanted your program to be able to plot any kind of equation the user wants, you'd need some kind of "language" that interprets math expressions. In this case, the language ability to interpret a math expression is a must, and not a luxury for a plotting program. Math notation is very restrictive as a "language". If your plotting program is restricted to conventional math functions and operators, there is no chance at all that someone could come up with some kind of equation that would create a security risk. Plus, the math expression doesn't modify the core of the program.

    Another example is a mini-language that might control Microsoft Agent cartoon-type characters. PB comes with a demo for manipulating a MS Agent character (see the PBWin80\Samples\COM\MSAgent\MSAGENT.BAS file that comes with PB). The PB demo has a series of hard-coded animations. However, how about if you wanted to create some kind of presentation program that lets the user create a script of what the animated character will say, and what kind of movements it will make? It would be strictly limited to the actions supported by MS Agent, along with a few simple constructs like loops, and If/Then. It wouldn't need to be able to write to file, or access the Internet, or anything like that. uCalc LB may be fluid in how it lets you create your language. But once you have the syntax you want, you can lock it from being further modifiable. Your language is not required to allow access to sensitive API routines.

    (The following link: http://www.ucalc.com/mathparser/beta/intp0805.zip is an old and obsolete version of the language builder, bit it included an MS Agent language demo. For that one, I wasn't really concerned with restricted the language; but you'll get the idea).

    As Marco pointed out, the scripting ability does not have to be accessible to the user at all. In another kind of program, you can make scripting privately accessible only to you as the developer. The language itself can be plain for you, but maybe you'd pass it through a filter so that the text you give the user looks like undecipherable machine code. So there is no loss of revenue for you there. Full control is solely in your hand. For minor updates, you could simply e-mail a small text file with your "machine code" script.

    Leave a comment:


  • Daniel Corbier
    replied
    GOLD parser comparison

    James, it's been a while since I looked at the GOLD parser site prior to this thread. I have quickly re-visited it again based on your question. However, I don't want to be too authoritative on it for fear that I might misrepresent the way the GOLD parser works. But from what I gather looking at it again, GOLD is a variation (with improvements) on the conventional YACC way of creating a language. One key difference between GOLD and ULB is that with GOLD you must first define the language grammar in a text file, and then have the Builder engine create a grammar table file, which in turn must be combined with special source code from your host compiler in order to complete your language.

    uCalc LB uses a different approach that completely eliminates these intermediate steps, and lets you define both syntax and semantics in the same setting. In addition to greatly simplifying things, this allows you to create a language dynamically; even interactively. With uCalc, you can basically take a language definition file in plain text (such as the ones listed at www.ucalc.com/langbuilder.html ), and feed it into uCalc, and you instantly have a working language. There's nothing more to it. With GOLD, after feeding it your language grammar in BNF form, you have more steps before you can have a working language.

    GOLD prides itself in supporting many host languages for creating your own language, which is great (I didn't see PB listed on their site though). However, each supported language has its own separate engine. With uCalc LB, there is only one engine, regardless of the compiler you are using. All of the complicated action happens under the hood within uCalc. (You can, however, compile a series of core routines into a DLL, which would be usable from any compiler).

    In fact a compiler is not even needed. For instance, although the demo uCalc.Exe interpreter is written in PB, you do not have to compile any PB code before you have a working language. The demo interpreter (uCalc.Exe) automatically transforms itself to any language you load up.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Mike: They can only use the syntax you provide and you are the one parsing those commands. If somebody doesn't know how to properly implement a scripting language, then they shouldn't do it.

    Leave a comment:

Working...
X