YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

2 Pages12>
RFC: Making "<-" operator optional
pfalcon
#1 Posted : Tuesday, July 30, 2013 8:54:14 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Intro

This is old and hot topic. I'm sure that a lot of people looked into Squirrel and turned away due to confusion "<-" has. I did that too, and looked at a lot more small languages, and still found Squirrel the most promising choice for small/deep embedded usage.

One of the recent discussions is http://forum.squirrel-la...aspx?g=posts&t=3006 . As fagiano said there, "No offense but it is unlikely that I would change such fundamental behavior in the language. You'd have to have a very good argument :)". I agree with such approach. Actually, we already see counter-examples, like generally very good fork by mingodad: http://code.google.com/p/squilu/ . Extensions he adds are amazing - that's probably one and only real-world usage beyond game scripting. But multitude of changes done to language core appear to be uncontrolled, without good argumentation, and mostly done on a whim.

So, let's be strict and thoughtful about changes to the core language. If the change can easily be not done (like another pretty acceptable alternative exists), let's not do it. Let's do only unavoidable changes. Like making no-prior-art operators optional (note - not removing them!) ;-).

Many people come to Squirrel from Lua. I come from Python (it's too bloated for me for all usecases, unfortunately). Changes to Python are proposed in the form of well-versed and detailed PEP (Python Enhancement Proposal) documents. I wrote something similar for the "<-" matter.

RFC: Making "<-" ("create new slot") operator in Squirrel optional

"a <- 5" as used in Squirrel is a strange syntax for assigning (first time!)
to a global variable. Ditto, map["foo"] <- is a strange syntax
for adding element (first time!) to a map/dictionary type. There's no
analog to this operator in the most commonly used scripting languages,
moreover extra details like "first time!" make it not just strange,
but confusing to novices.

Common response why it's needed starts with "Because global namespace
in Squirrel is implemented using table, so ...". But that's as helpful
as saying that, because a computer using only 0s and 1s internally, then
all input/output should happen with 0s and 1s too. Nope, it shouldn't
and doesn't. Just the same, the fact that globals are implemented using
"table" structure in Squirrel should not concern novices. And regular
users should not be subjected to always bow down to this internal detail
either.

But is "<-" a useful in particular cases and usages? Let's first consider
how other languages deal with variable initialization, assignment, and
acces, ordered from the most relaxed to the most strict.

1. Bourne Shell, Lua, Perl

Bourne Shell (default Unix shell) treats non-existent variables as having
empty (string) value. That's being used in small scripts to skip explicit
variable initialization. But everyone knows that developing and
maintaining (sic! always think about maintenance) large shell scripts
is cumbersome and effort-consuming, and avoids that like a plague.

Lua treats non-existent variables as having "nil" value, so it's not possible
to tell non-existent (mistyped, renamed, etc.) variable from one holding
otherwise legitimate nil value. That might be acceptable for target usage
of Lua - non-programmers writing simple scripted actions for games, but
any programmer would consider developing and maintaining more or less
complicated program in Lua as a way to slowly shoot oneself in feet.

2. Perl

Perl falls somewhere inbetween Lua and JavaScript in regard to sloppiness
of variablee handling. My mind is cleared of it by now, and being very
tangled language, you can't just google and get an idea how it is.

3. JavaScript

JS still allows to use undeclared and uninitialized variabled, but at least
value gotten from such - special "undefined" value differs from any other
value, including "null" value. So, you can tell uninitialized from initialized
variable in JS, but you will need to do that yourself. If you want to write
application in JS which is robust over long lifetime with refactoring and
usage in initially unconceived ways, you'd need to prefix each and every
usage of each variable with "if (x === undefined) throw Undefined", or
it will break sooner or later. So, real programmers shrug at JS and all
the recent "run everyting and your grandma's stuff in browser" folly.

4. Python, Ruby, most other scripting languages.

With these, you get error or exception trying to access uninitialized
variable, which is basic program security measure protecting from the
most basic and most embarrassing to debug errors. But they don't
differentiate between "initialization" and "assignment". You need
variable? Get one by assigning a value to it. Similarly, you can't
get non-existent value out of mapping type, and to add a key/value
pair, you do the same as to update - just use map[key] = val assignment.

5. Squirrel

That's where Squirrel comes - it's more strict than most other normal
scripting languages. In squirrel, you kinda need to "define" variable
using <- operator, and can assign initial value to it. Afterwards,
you can use normal "=" assignment. Or - strange - you can keep using
<-. And above applies only to global and object member variables.
You can't use it with local variable whatsoever! From mapping type
perspective, you have to "init" any new key added with <- operator,
afterwards you can use "=". Or can keep using <- ! In other words,
"<-" in Squirrel does the same thing as what "=" does in most
other languages like Python (but it doesn't work with local variables!).
And "=" is a limited form of assignment which won't let you to assign
to non-existent variable or key. Overall, it's counter-intuitive
and confusing, like was said.

6. C, C++, most other compiled languages

Here, a variable needs to be defined or declared before it can
be assigned to, Not defined/declared - error on any access, read
or write. But they use separate syntax features for definition
and initialization, and initialization uses same intuitive "="
operator.

7. Haskell and other "immutable data" lanuages
Some functional languages, e.g. Haskell has immutable variables -
they can be assigned just once, second assignment is error.


So, looking at at the continuum, Squirrel appears to be above
median in strictness of High and Very High Level Language. It
offers few more program security features, but they are hardly
consistent and intuitive.

So, how to alleviate the situation? Let's look how "<-" and
"=" operators are actually implemented by Squirrel VM. So,
there's _OP_NEWSLOT for current "<-", and _OP_SET for "="
operators.

Following changes can be proposed to make it more intuitive:
"=" should still generate _OP_SET for local variables, but
otherwise should generate _OP_NEWSLOT. This will allow for
intuitive usage of "=" as in most other scripting languages.
If "assignment only to defined variable/member/key" feature
is required, a new operator for that can be introduced,
":=" seems like good choice (will generate _OP_SET all the
time). Finally, "<-" can stay as is for compatibility with
existing code (will keep generating _OP_NEWSLOT as before).

Finally, some kind of pragma ("#pragma old-assign") can be
added to actually switch between new and old behavior of
"=", but that wouldn't buy more compatibility: any debugged
code would work the same, and any non-debugged, in-development
code should just switch to use := operator if catching assignments
to non-defined variables is desired.
m0pey
#2 Posted : Wednesday, July 31, 2013 10:32:30 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 12/19/2005(UTC)
Posts: 90
Man
Location: Oxford

Thanks: 0 times
Was thanked: 9 time(s) in 9 post(s)
Having <- as the new slot operator prevents you from accidentally creating a new variable which I like a lot. If you switch to using = for new slot then your faced with the same problems of lua where typos in variable names can accidentally create new variables.

Having used squirrel for quite a few years I prefer this stricter syntax over making it easier for new users, it's only a minor inconvenience and the error checking benefits you get are very useful.
pfalcon
#3 Posted : Wednesday, July 31, 2013 11:49:32 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Well, my RFC goes provides perspective of how the issue is handled in various well-known languages. Two outcomes of that is: 1) The median behavior for scripting languages is to protect against accessing undefined variable, but not allow to define any variable on spot; 2) There're much more stricter languages if you really need strictness. I understand that what you're saying is "after many years with Squirrel, I put up with its misfeatures and even think they're features", but please look at the perspective - it's not possible to stick with only Squirrel, and then peculiarities of Squirrel make it harder to switch between many languages (which many people do daily nowadays).

And it would be 75% of a problem if only (global, member) variables used "<-" syntax, but it also applies to dictionaries. What's in most other languages written as "dict[key] = val" in Squirrel should be written as:

Code:
if (key in dict)
   dict[key] = val
else
   dict[key] <- val


Or just use "dict[key] <- val", but then "<-" is not "new slot" operator like doc says, but "use existing or create new slot" operator. More words, more confusion. And then there're local variables to top up confusion to a real mess. No other language has such mess, and people are wary of it. Quoting Alberto himself from this post: "Plus in lua stuff like ~= instead of != but == like in C drives me mad. It sounds they are just trying to be different for no reason(or at least non that I can see)." So, it seems that with "<-", Squirrel does the same - enforces its usage for no apparent reason (note that the enforcement is what concerns me, I'm all for <- to be available - as optional feature for those who need it).


And finally, I do not propose to replace "<-" with "=". In no way. "<-" stays the same, so people who love it can use it. But I do propose to clean up namespace for "=" to be what it is in most other languages. That means that current Squirrel's "=" becomes ":=". Curtainly, using ":=" instead of "=" would be just another "minor inconvenience" if you already find usage of "<-" acceptable.

So, there would be 2 coding styles to use with Squirrel:

For comers from other mainstream languages like Python, JavaScript, etc., etc.:

Code:
a = 1
a = 2


For apologists of Squirrel zen:

Code:
a <- 1
a := 2



I don't see why everyone wouldn't be happy with such solution. As the last effort, we can make "=" behavior changeable on a per-file basis using pragmas. But I'd avoid that, because everything seems to fall into place really well even without it.
m0pey
#4 Posted : Wednesday, July 31, 2013 1:31:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 12/19/2005(UTC)
Posts: 90
Man
Location: Oxford

Thanks: 0 times
Was thanked: 9 time(s) in 9 post(s)
Won't having two different ways of writing the same thing be pretty confusing for people? If = is available then people new to a squirrel project that uses the <- and := and new to the language will just use = and not realise that they should be using <- and :=.

You are proposing that = behaves exactly the same as <- which would remove its purpose of guarding against accidental slot creation. It's not enforcing different syntax for no reason, it means people that are new to the language and adding scripts to a project don't pollute the global table with accidental assignments which was something I found happened when working with lua on a large project with others.

Do you mean having a pragma within the script file itself? I think that would be pretty confusing as well.

Ultimately it's up to fagiano but I would vote against this change.
pfalcon
#5 Posted : Wednesday, July 31, 2013 6:57:08 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
m0pey wrote:
Won't having two different ways of writing the same thing be pretty confusing for people? If = is available then people new to a squirrel project that uses the <- and := and new to the language will just use = and not realise that they should be using <- and :=.


Correct, if this change would go live and people would ask *me* about "<-" and ":=", I would say "forget about them, just use =". And no, I don't agree that people "should be" using "<-" ;-). IMHO, if someone needs more strictness than median level represented by Python and friends, then next stop is C++ or Haskell ;-)
But again, I don't want to deny people who find "<-" and ":=" useful to use them - I don't see problem with Squirrel to become "multi-paradigm" in this respect (all differences are parse-time, they don't cost anything runtime).

Quote:

You are proposing that = behaves exactly the same as <- .


Not exactly, to be fully technical. I propose that "=" would work consistently for all of: global vars, member vars, mappings, local variables. "<-" doesn't work like that.

Quote:

which would remove its purpose of guarding against accidental slot creation.


:= will guard against that.

Quote:

It's not enforcing different syntax for no reason, it means people that are new to the language and adding scripts to a project don't pollute the global table with accidental assignments which was something I found happened when working with lua on a large project with others.


There're many ways to get things wrong. Again, Haskell and friends may offers more strict discipline. But even they will allow to create infinite loops. And the talk is not about robbing Squirrel of its secure programming features, but about being more compliant with well-known median in that respect. If you are a project manager for a big Squirrel project, you can establish rule for using only "<-" and ":=", just the same as particular C++ may choose to prohibit use of templates, or vice-versa, prohibit use of raw pointers and require use of smart pointers.

Quote:

Do you mean having a pragma within the script file itself? I think that would be pretty confusing as well.


Yes, that's why I'd like to avoid it, and keep single semantics model of the language, where each of "<-", ":=", "=" has stable and hopefully easy to undertstand way of working.

Quote:

Ultimately it's up to fagiano but I would vote against this change.


That's true, and I appreciate your comments and discussion. Maybe I should elaborate more what I'd like to achieve with Squirrel (or for Squirrel). And that's being its mainstream usage as a standalone general-purpose scripting language. That requires a lot of people being ready to use it, and that in turn requires "massaging away" any deviations from well-known paradigms, or people will keep passing by and turning away.

It's clear that I'm not the only one who imagines that Squirrel fully deserves to be a competitor to Python, JavaScript, Node.JS, etc. - I can quote mingodad's project on building good extension library around Squirrel to be suitable as a web app server. Unfortunately, his project is more of a fork, as many his changes are unmergeable to mainline (or at least I hope so, because they're too much even for me ;-) ). I'd like to try another approach - to collect known issues which preclude Squirrel to go mainstream and try to propose well-thought and discussed RFCs how to resolved them.
pfalcon
#6 Posted : Wednesday, July 31, 2013 7:40:19 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Initial implementation of this feature as available at https://github.com/pfalc...5998ea442063d7b98bf19ee (note - it's initial version and can be rebased, so link may stop working, but the patch should be available in this branch: https://github.com/pfalc...mmits/squirrel3-pfalcon).

As expected, the changes are pretty simple and unobtrusive. It works as expected with simple examples, and I really hope to get response about testsuite to be able to test it more thoroughly.
bonch
#7 Posted : Thursday, August 1, 2013 12:14:02 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/13/2012(UTC)
Posts: 38

Thanks: 13 times
Was thanked: 1 time(s) in 1 post(s)
The "<-" operator is easy to understand when viewed as a "newslot" operator, recognizing that variables are slots in a table. Though you dismissed this as an internal detail that novices shouldn't be concerned with, it's an exposed behavior of the language that one interacts with in most Squirrel projects.
pfalcon
#8 Posted : Thursday, August 1, 2013 10:43:21 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Surely, if most variables are stored in tables, then user "interacts" with tables just by virtue of using variables. Just the same can be said of machine code when using C++ - a program is compiled into machine code, and that's what is being run, so it's fair to say that C++ user "interacts" with machine code. But there's difference of "interacting" and "know/being concerned with internal details of". Purpose of C++ is exactly to shield user of machine code and allow to express algorithms at higher level (and yet there're good uses for inline asm - but not for everyone!).

Same applies to very high-level languages - they definitely use some lower-level means to deal with language features, but goo design abstracts that away. For example, Python just the same uses dictionaries for module namespace, implementation of classes, etc. And its "exposed" in the sense that it's not concealed, and documented as an implementation detail. You can get access to those dictionaries, but nope, it's pretty possible to write application without that!

One case when this idea doesn't work is when underlying implementation "bleeds thru" in unpredictable/unexpected/illogical ways onto higher levels. That's exactly the case with Lua and JavaScripts. These language play against programmer, ready to stab one in the back on every step, so a programmer needs to know each and every dirty detail of underlying implementation, and on each statement he writes question oneself "hey, how this will work with underlying implementation, will it stab me here?" Hell, but that's not programming. And Squirrel is not like that. But it does have some issues, some can be put up with, selected few - hardly (that's subjective and needs consensus of course). One such issue is targeted in this thread. I know at least one another, on which I'll open topic too.
fagiano
#9 Posted : Thursday, August 1, 2013 5:50:59 PM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 1,056

Thanks: 0 times
Was thanked: 78 time(s) in 60 post(s)
I think this argument doesn't have a absolute right or wrong. It depends on the context in which you want to use the language.
I agree that <- is kind of ugly, I considered := in early prototypes of Squirrel but I found that it wasn't very easy to spot. It was hard too differentiate from = . So I've chosen <-, I saw this operator in some functional language (I think some dialect of ml).
I agree is something new and it has to be learned but in my experience(in my project and with the type of programmer that I deal with, for about 10 years now) it solves a problem that is much greater than learning a new operator/semantic.
In fact The <- operator is so different from = to underline that you are doing something different. Is like saying "hey, here I'm creating a slot, I know what I'm doing"

You have to put my choice in perspective. Squirrel was designed for writing large amounts of game code for complex games like MMOs. Our product team only uses Squirrel. Our app framework exposes everything to squirrel, rendering pipeline a WPF-like gui all backend server code, patching even our build server and admin tools are 100% squirrel code.
So with hundreds of thousands of lines of Squirrel often running around a shared global scope, adding variables whenever someone mistype something is a serious problem. Having to pay attention between = or <- is a requirement. This is one of the features I wanted at all costs when I decided that Lua was just too permissive for large codebases.
I must admit your solution is rather elegant and I understand that in certain cases, when squirrel is used for small code bases written by inexperienced programmers <- might be an inconvenience. Simply that is not Squirrel's target audience.
I'm sure if you ask a programmer from our game team writing server code in Squirrel all day long, he would tell you he cherish the fact that this ugly operator makes him stop and think for an instant.

I really appreciate this very methodical way of proposing changes, in fact there are few aspects that I would actually try to improve(enums and constants for instance) but the bottom line is that I'm not sold on this one.

ciao
Alberto
Follow me on Twitter @squirrellang
Mephisto
#10 Posted : Friday, August 2, 2013 1:17:06 PM(UTC)
Rank: Member

Groups: Registered
Joined: 12/5/2010(UTC)
Posts: 20
Location: Roslindale, MA

Thanks: 9 times
Was thanked: 2 time(s) in 2 post(s)
How about a keyword synonym for <- like newslot or simply slot?
pfalcon
#11 Posted : Friday, August 2, 2013 6:21:09 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
fagiano, thanks for reading thru this RFC and for detailed response. I'm glad that you appreciate detailed proposals - I don't really have much time on my hands, but whatever I have, I figured makes more sense to spend trying to make better the known good language, instead of trying to find something better on source code dumps around Internet (I did that a lot too).

fagiano wrote:
when squirrel is used for small code bases written by inexperienced programmers <- might be an inconvenience. Simply that is not Squirrel's target audience.


I guess that's crucial difference in our approaches - embedded usage for a particular (even if big) project(s) vs providing general-purpose language for as many people and as many projects as possible, on which I now elaborated in separate thread. (I would like to make it clear that I can not only about novices - I may be novice with Squirrel, I have been doing quite a lot of languages, and I can't see me using "<-" as it is now in Squirrel.) Well, I do understand points you make because, well, it's actually in use and features like "<-" were designed to make it work per your requirements.

On the other hand, "general-purpose language" is my wishful thinking. So, I'm not going to negotiate alternatives like pragmas now, as there's no target use for that yet. I definitely cannot turn Squirrel into general-purpose language myself, so let this and the other thread be a manifest for people who may share this outlook. We'll see if it leads anywhere ;-).
bonch
#12 Posted : Friday, August 2, 2013 9:55:28 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/13/2012(UTC)
Posts: 38

Thanks: 13 times
Was thanked: 1 time(s) in 1 post(s)
pfalcon wrote:
Surely, if most variables are stored in tables, then user "interacts" with tables just by virtue of using variables. Just the same can be said of machine code when using C++ - a program is compiled into machine code, and that's what is being run, so it's fair to say that C++ user "interacts" with machine code. But there's difference of "interacting" and "know/being concerned with internal details of". Purpose of C++ is exactly to shield user of machine code and allow to express algorithms at higher level (and yet there're good uses for inline asm - but not for everyone!).


I was referring to the equivalence of a.b and a["b"] and how a design can take advantage of treating variables as table slots. Lua is permissive with its assignments (all possible table elements are treated as pre-existing and set to nil), and it has led to the need for static analyzers to catch common mistakes. In my opinion, the newslot operator stands out in a block of code and is worth the added safety. I think it's mostly a pedagogical issue.
pfalcon
#13 Posted : Sunday, August 4, 2013 6:39:01 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
bonch wrote:


I was referring to the equivalence of a.b and a["b"]


Actually, when I wrote "I know at least one another [issue with Squirrel]" I meant that too ;-). I call it "JavaScript curse". Don't get me wrong - I'm not against allowing to access keys by both operators, its just they should not be compltely equivalent - they should use different lookup order. Anyway, I'll post on that someday (low priority).

Quote:
In my opinion, the newslot operator stands out in a block of code and is worth the added safety. I think it's mostly a pedagogical issue.


Except that if some professor would want to use it in academy, he would get neverending stream of questions about why global and local variables are initialized differently. All blah-blah about slots would fall on deaf ears - the only thing students would think in response is "Ugghh, what a mess!". And the only thing they'd learn out of it is that they should track type of var (global/dict vs local), and *always* use <- for global/dict and *always* use = for local.

That's btw why I "don't buy" that presence of <- offers any real protection. It could if it would error out on second use for the existing slot, but then using dictionaries would be hell. Otherwise, using "<-" to init variable and "=" to assign is just a *convention*, not enforced by the language, and could be easily subverted by using "<-" all the time.
bonch
#14 Posted : Monday, August 5, 2013 1:36:45 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/13/2012(UTC)
Posts: 38

Thanks: 13 times
Was thanked: 1 time(s) in 1 post(s)
pfalcon wrote:
Except that if some professor would want to use it in academy, he would get neverending stream of questions about why global and local variables are initialized differently. All blah-blah about slots would fall on deaf ears - the only thing students would think in response is "Ugghh, what a mess!". And the only thing they'd learn out of it is that they should track type of var (global/dict vs local), and *always* use <- for global/dict and *always* use = for local.


I don't agree that it's as confusing as you're portraying it. Nor is this use of associative arrays unique to Squirrel.
pfalcon
#15 Posted : Saturday, September 21, 2013 6:10:16 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/9/2013(UTC)
Posts: 59

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Ok, playing with my patch more, I figured that it missed cases of object properties and array item assignment, i.e. with my "=" as new "<-", following gives errors:

Quote:

class Foo {
v = null
function foo() { v = 1 }
}

a[0] = 5


And should be written as "v := 1" and "a[0] := 5". Of course, that's easy to patch, but overall it becomes less and less clean. Given also lack of interest from upstream Squirrel and its users, I guess it makes no sense to go out of the way to preserve possibility to use original Squirrel semantics. And then my aim is very specific - make "=" to work as "<-" for tables, while everything else should stay the same. Easiest way to achieve this is to alias SQTable::Set() to SQTable::NewSlot().
msakuta
#16 Posted : Sunday, April 3, 2016 6:15:24 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 4/3/2016(UTC)
Posts: 4
Location: Massachusetts, US

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Well, this thread is pretty dead, but I have something to say on this as I have been used Squirrel for years.

I understand the intention of the operator "<-" and I agree that it is helpful to some extent, but it's... too ugly.
It resembles the comparison operator "<=" too much.
The only other language that use "<-" for assignments I know is R, whose user base is very limited.

Another problem is that local variable can not be initialized with "<-" but "=".
This is counter-intuitive and hard to memorize which is which. If all initialization must be done with "<-", it would be (at least) consistent, but it isn't.

Probably it's too late to suggest anything, but how's to use "new" keyword symmetrically to "delete" operator?

Quote:
new table.slot = value


Then the syntax looks more consistent.

Quote:

new table.slot = value
table.slot = value2
delete table.slot

local variable = value
variable = value2


`new`, `delete`, `local` or probably `function` come as first token in a line. And they all mean creating or deleting something.
With a proper editor, keyword highlighting can easily distinguish "new" assignments.
msakuta
#17 Posted : Sunday, April 3, 2016 7:01:46 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 4/3/2016(UTC)
Posts: 4
Location: Massachusetts, US

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
I have prototyped the "new" operator: https://github.com/msaku...af51574add0c70d6532d16d
Sharing is so easy with official GitHub repository!

The changes to the code are not as simple as pfalcon's approach, but I have managed to make it work.
The instruction set is left intact. It's purely a compiler modification.
Basically, it is a new expression with "delete" and "local" syntaxes mixed, so you can write like

Code:
a = (new b = c)


which is equivalent to:

Code:
a = (b <- c)


I tested the code with VC2015, with scripts like this:

Code:
new a = 1
print(a)
delete a


Code:
local t = {}
new t.a = 10
print(t.a)
delete t.a


Code:

local t = {}
new t.nested = {}
new t.nested.a = 123
print(t.nested.a)
delete t.nested.a
delete t.nested


Code:

local l = (new a = 10)

print(l)
print(a)


and it's working so far.
absence
#18 Posted : Monday, April 4, 2016 8:45:05 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/23/2014(UTC)
Posts: 109
Man
Location: Northern Germany & Lincolnshire, U.K.

Thanks: 1 times
Was thanked: 10 time(s) in 10 post(s)
uhm, i see several reasons why i would not want a new and delete operator, and the <= operator is more like the sql "create ... if not exist", which new and delete won't match.
However, you really should test this, too:
Code:

local t = {}
new t.nested = {}
new t.nested.a = 123
print(t.nested.a)
delete t.nested        ; //this will delete t.nested.a, too.
delete t.nested.a      ; //Hence this MUST assert!


which, as you probably see, is a damn problem to people used to c++, for example
msakuta
#19 Posted : Wednesday, April 6, 2016 7:31:55 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 4/3/2016(UTC)
Posts: 4
Location: Massachusetts, US

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Mind you, the delete operator is already a part of the language. I only suggested to add "new" operator which is symmetric to existing "delete".
I admit that the meaning of "new" and "delete" is not synonymous to that of C++. The problem is that "delete" operator is already not synonymous.
"Delete" in C++ means actually deleting an object, while that of Squirrel means just deleting a slot of a table (which, in turn, can delete the actual object if the reference count becomes zero.)

If the resemblance to C++ really bothers you, the "new" keyword could be anything, like "newslot" or "create" or anything apart from C++ "new".
Unfortunately "delete" is already there and we cannot re-spell it. I would pick "delslot" or something if I could.

FYI JavaScript also has the "delete" operator in the same meaning as Squirrel's. I think fagiano adapted this syntax from JavaScript.


I tested the code and it raised an error as expected. I did not touch the "delete" operator whatsoever so it would not change anything.
Think the code of yours is identical to this:

Code:

local t = {}
t.nested <- {}
t.nested.a <- 123
print(t.nested.a)
delete t.nested        ; //this will delete t.nested.a, too.
delete t.nested.a      ; //Hence this MUST assert!


fagiano
#20 Posted : Thursday, April 7, 2016 1:57:23 PM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 1,056

Thanks: 0 times
Was thanked: 78 time(s) in 60 post(s)
Actually I almost removed 'delete' at some point. As you say the fact that changes C++ semantic sucks. I couldn't find a syntax that I liked. Instead of adding 'new' I'd be more prone in removing 'delete', <- is fine for me.

Alberto

HISTORICAL NOTE: indeed 'delete' comes from JavaScript. Initially my idea was to write a JavaScript interpreter with ref-counting, however after some thinking based on my previous JavaScript experience(I used JavaScript server-side back in the late 90s) I arrived to the conclusion that JS was just too broken for any real use(apparently the "modern" web industry disagrees :) ). So Squirrel was born but I kept looking into JS for ideas. delete was a bad one.
Follow me on Twitter @squirrellang
Users browsing this topic
Guest (2)
2 Pages12>
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.226 seconds.