Emerald Editor Discussion
March 26, 2017, 12:34:37 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Scripting language proposal  (Read 16078 times)
0 Members and 1 Guest are viewing this topic.
jonnymind
Miner
**
Posts: 18


« on: March 05, 2007, 09:10:40 pm »

Hello to the kind people in this community.

This is my first message here, so I hope not to sound presumptuous.

I've been developing a new embeddable scripting language, called "The Falcon Programming Language", for a couple of years now. Cutting the story short, I have come to the conclusion that the version that I am issuing this day will be the public "start codebase", so I am shaping up things a bit.

I was searching for a good editor, possibly multi platform, that would have supported Falcon grammar so to provide users with a easy start-to-code-NOW plan, i.e providing grammar files and settings for Falcon.

A second feature I was searching for in the "preferred editor for Falcon" was, possibly, that of being open source, or at least to provide an API for integration, so that I could provide some scripts in Falcon both as samples for my users and as facilities in using Falcon.

My idea was NOT that of having a cheap Falcon IDE, but rather that of providing early Falcon pioneers with some pre-configured tool to start the easy way.

In my search for "the perfect editor", I reached your site. I scanned your newsgroups and I found the work you're performing extremely interesting. AFAIK, excluding the Great Old Ones in the editors world (EMACS, VI and so on), this is the only text editor project with a wide coder base and born to be fully open source, I mean, born to be collectively developed.

I've been reading you were arguing about providing Emerald Editor with scripting features. In case the Falcon Programming Language may meet the interest of this community, I would be extremely glad to participate the project. As I know a bit about scripting (... ;-) I may also help to implement other scripting engines, as i.e. Python, LUA and/or Ruby, both as a built-in feature or as semi external engines (script + plugin model).

I recommend Falcon, besides the obvious reasons (you know, I wrote it), also because, exactly as YOUR project has been designed to BE like this, Falcon was BORN to be "Your Application Scripting Engine(TM)". Ruby, Python, Perl and PHP were born for other reasons, and eventually became popular also as scripting engine, while LUA was born to be a "game industry" scripting engine, and didn't move a lot from that position. Contrarily, Falcon is meant to be friendly with the host application AND with the script writers.

Also, Falcon is coded in C++ (but no STL, so the engine DLL can be plugged nearly into every C++ application).

I don't want to bother you more than this; the main facts of Falcon are on the front page at http://www.falconpl.org. There are also quite complete docs; the latest features have still not been written in the downloadable PDF manuals, and are available through the WIKI. The embedder's guide, that you can find in the wiki, may give you an idea of how much simple is embedding Falcon with respect to other scripting languages.

About stability, I use it professionally in a set of control systems for financial (trading) applications... and our community, while still small, is beginning to grow.

Best regards,
Giancarlo Niccolai.


Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #1 on: March 06, 2007, 12:58:00 am »

It sounds good to me, but I'm not in high up enough to make decisions like this. We'll have to see what some of the higher-ups say.

Phil
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #2 on: March 06, 2007, 07:21:44 pm »

This does sound good, and may be an appropriate answer to the Lua/Squirrel debate we previously had.

I'm probably more in favour of this, now I've looked over it a bit, but Derek or Soulfish probably need to give it the final nod.
Logged

"Cleverly disguised as a responsible adult!"
jonnymind
Miner
**
Posts: 18


« Reply #3 on: March 06, 2007, 11:37:41 pm »

:-)

Let me add a thing that is not immediately obvious from the front page of the site: anyone who knows how to program in Python, Ruby or LUA can be proficient in Falcon in a few hours. The grammar is not radically different from the mainstream script languages line; just, it is thought with user comfort in mind. So, Falcon scripts won't look alien to anyone that has programmed a bit in modern scripting languages, and this would definitely help as it won't restrict the user base to the few gurus willing to learn esoteric grammars.

Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #4 on: March 10, 2007, 08:11:08 pm »

Are explicit variable declarations possible in this language? One of the things that annoys me most about PHP is that you cannot declare your variables. I accidentally misspell a variable and it just introduces it as a new variable which introduces a bug which would be much easier to detect if I could just declare the thing and have PHP crash because I misspelled it.

Phil
Logged
jonnymind
Miner
**
Posts: 18


« Reply #5 on: March 11, 2007, 12:30:31 am »

In a sense: atm. variables are declared as they are assigned. When you use them without being assigned, Falcon declares them as being "external". They are linked at link time, before your script runs. So...

Code:
alpha = 0
if alfa != 0: ...

would generate a link error, unless some other module exports the "alfa" variable.

Anyhow, the list of symbols is available for the embedder, which may warn on similar symbols. Also, if this is an issue, we may warn for assigned but not used symbols, as in this example:
Code:
alpha = 0
...
alfa = 1
...
if alpha = 0...

Finally, if this gets really nasty, and if you really want it, we may easily introduce a "declarator"; it may work like this: variables must be assigned the first time using the declarator, like in example, something as the following:
Code:
declare alpha = 0, beta ="hello world", gamma
declare delta
...


and can then be assigned or accessed freely. Then, we may either

1) force variable declarations only if (after) we find a "declare" in the program, so that the users are free to use it or not use it (at their own risk). I.e. assignments to unknown variables AFTER a single declare statement has been used in a context (global/function/method etc.) will raise an error.

2) set it as a compiler option for the embedders / command line switch option for the falcon compiler. I.e. force usage of the declarator for your embedding app.

I would lean for the first; Falcon has already "use on your own risk or do it clean" choices, and I think they are good for scripting programming languages. Some scripts are "dirty and fast", others are good examples of good programming habits; it's up to the scripter to be wise enough to do things fine. All that we can do is to help him by providing him with good tools to express his ideas.

In general, I don't dislike the idea at all, so I may introduce it anyhow... however, after this prebeta5 is released.
Logged
John Yeung
Senior Miner
***
Posts: 85


« Reply #6 on: March 11, 2007, 07:28:39 pm »

I think Phil is after something like the "option explicit" directive in VBScript.  If your script contains that statement, then explicit declaration is required; otherwise, variables are automatically created when assigned.

I would definitely keep this optional though, because users of many scripting languages (including a lot of VBScript users) are very happy with automatically created variables and will be very annoyed if they have to declare them beforehand.

John
Logged
jonnymind
Miner
**
Posts: 18


« Reply #7 on: March 11, 2007, 08:42:47 pm »

Ok... actually I couldn't resist, and I have already added it :-)

Once you declare a variable with "def", every symbol in the rest of the module must be also declared with def.
So:

Code:
function test()
   def a = 0, b = [1,2]
   ...
end
...
function test1()
   c = 0 // signals error.
end

d = 0 // this too.
a = 0 // and this too: a was undefined in THIS context.

ATM I am not providing an explicit import directive, as undefined symbols were already trapped at link phase (where it is actually better to trap them).
But we may think about it ;-)

Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #8 on: March 12, 2007, 01:07:52 pm »

A nice extension to that would be the ability to define var types for declared vars.

Code:
def int x
def string y
def z

in the above code X can only be an integer, Y can only be a string but Z can be anything.

so that IF you declare a var to be of a specific type an error will be thrown if it does not conform later in your code.
Logged
jonnymind
Miner
**
Posts: 18


« Reply #9 on: March 20, 2007, 08:22:45 pm »

There is a basic difference between typed and untyped languages. Untyped languages are more powerful, even if more dangerous. So, they make perfect ground for scripting languages.

Forcing the definition of types is not in Falcon project plans; However, an optional variable type "forcing", rather than "declaration", may help in some circumstances... we'll see, but not now.

However,
I just built Emerald Editor on windows and Linux. I'd like to put my fingers on it, but I am waiting for that "nod" Arantor was talking about...

Waiting...
waiting...
wait...

Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #10 on: March 20, 2007, 09:01:09 pm »

Forcing the definition of types is not in Falcon project plans; However, an optional variable type "forcing", rather than "declaration", may help in some circumstances

That's what i was talking about..

Code:
def int x
def string y
def z
in the above code X can only be an integer, Y can only be a string but Z can be anything.
so that IF you declare a var to be of a specific type an error will be thrown if it does not conform later in your code.

I thought the example showed that IF you delcared a type then that type was forced otherwise it was untyped
Logged
jonnymind
Miner
**
Posts: 18


« Reply #11 on: March 21, 2007, 09:55:04 am »

In fact; I wasn't arguing directly on your reply, but on the typed/untyped issue in general.
The idea you proposed, that is, optional type declaration is not bad at all.
Just, it doesn't seem an urgent matter to me; however, if a wishful coder was eager to code that in, I wouldn't be the one to stop it... ;-)
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #12 on: March 21, 2007, 10:00:43 am »

Smiley i would love to but my skills only go as far as modifying other peoples code.. Sad or i would!
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #13 on: April 01, 2007, 09:33:53 pm »

So, to move the discussion along; what options do we have and what are the benifits of the different proposals? I have so far seen four languages proposed:
  • C
  • LUA
  • Falcon
  • Ruby
Other languages have been mentioned as well, but where do we really end up if we try to summarize this? What are the actual benefits for each of the languages and what are the flaws? Also, what benefits are we looking for in the language? Here are a few thought of mine:

If we hold simplicity and power against each other, I would say we should go for power. With a good enough program, I am sure a future community will take care of most plugins, providing those with little programming knowledge with the plugins they want. Sure, we still need something relatively simple, but its more important to focus on power. I think Ruby would balance those two in a good way.

When thinking power vs. size, we obviously want the plugins to be as small as possible. A more powerful plugin will naturally contain more code so I think that having a language that produces small and efficient plugins would be preferable. This also means that we should go for a language that is fast.

I have other things on my mind, but they'll have to wait. I have a search engine optimization worth about 4000 SEK (about 572 USD) to do right now.
Logged

"Cleverly disguised as an original signature..."
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #14 on: April 02, 2007, 07:32:07 pm »

I am thinking that one language will probably not fit all and EE might have to support multiple plug-in languages.

Just a thought,
Phil
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.128 seconds with 18 queries.