Raised This Month: $12 Target: $400
 3% 

New API and Syntax


Post New Thread Reply   
 
Thread Tools Display Modes
Neuro Toxin
Veteran Member
Join Date: Oct 2013
Location: { closing the void; }
Old 11-21-2015 , 17:52   Re: New API and Syntax
Reply With Quote #661

I remember the pharse. Syntactical sugar. See I do listen
__________________
Neuro Toxin is offline
Wliu
Veteran Member
Join Date: Apr 2013
Old 11-21-2015 , 19:00   Re: New API and Syntax
Reply With Quote #662

Quote:
Originally Posted by WildCard65 View Post
I seem to recall asherkin saying something about spcomp for SM 1.7(and 1.8 as well) compiling to same bytecode and it makes sense as Lysis can still decompile the new syntax without any special casing for 1.7(I BELIEVE).
Lysis indeed does not have any special casing.
__________________
~Wliu

Last edited by Wliu; 11-21-2015 at 22:05.
Wliu is offline
Potato Uno
Veteran Member
Join Date: Jan 2014
Location: Atlanta, Georgia
Old 11-21-2015 , 21:44   Re: New API and Syntax
Reply With Quote #663

Quote:
Originally Posted by nergal View Post
IIRC, the new syntax uses actual types and not tagged 32-bit integer based types unless a certain someone was lying...

So how's it compiling to the exact same bytecode regardless of version used?

You've got alotta 'splainin' to do!
https://forums.alliedmods.net/showpo...&postcount=620

https://forums.alliedmods.net/showpo...3&postcount=36

inb4 banned for derailing.

Last edited by Potato Uno; 11-21-2015 at 21:45.
Potato Uno is offline
nergal
Veteran Member
Join Date: Apr 2012
Old 11-21-2015 , 22:15   Re: New API and Syntax
Reply With Quote #664

this is a discussion on the new api and syntax, I see no reason why me or you would be banned on this unless the mods tell us to cease and desist.

Logically, they have to compile to the same bytecode or they wouldn't run.

Another example like this, I believe, is that C/C++ compilers ultimately compile to Assembly language then executed.

old syntax is the C example in this case while new syntax is the C++ example.

Even if they run the same bytecode, the new syntax (you have to admit) makes development much easier and quicker to some degree.
__________________

Last edited by nergal; 11-21-2015 at 22:19.
nergal is offline
Potato Uno
Veteran Member
Join Date: Jan 2014
Location: Atlanta, Georgia
Old 11-22-2015 , 10:14   Re: New API and Syntax
Reply With Quote #665

Yes, all of that is correct, but that doesn't justify why the devs should break old syntax support. It's not like parsing old syntax is the barrier to having new amazing features. And even if it is, they can split spcomp to 2 and have one of them be incompatible with old syntax and the other one be fully compatible with an old and new syntax mix. That would still make both sides happy. (In fact, BAILOPAN said this might be a thing, but he doesn't know.)

I think the JIT implementation of new features is what is slowing them down more but I don't know; I'm only speculating here. I don't have a strong background on compiler or interpreter theory.

Last edited by Potato Uno; 11-22-2015 at 10:15.
Potato Uno is offline
nergal
Veteran Member
Join Date: Apr 2012
Old 11-22-2015 , 13:16   Re: New API and Syntax
Reply With Quote #666

Quote:
Originally Posted by Potato Uno View Post
Yes, all of that is correct, but that doesn't justify why the devs should break old syntax support. It's not like parsing old syntax is the barrier to having new amazing features. And even if it is, they can split spcomp to 2 and have one of them be incompatible with old syntax and the other one be fully compatible with an old and new syntax mix. That would still make both sides happy. (In fact, BAILOPAN said this might be a thing, but he doesn't know.)

I think the JIT implementation of new features is what is slowing them down more but I don't know; I'm only speculating here. I don't have a strong background on compiler or interpreter theory.
compilers typically have structures like the lexer/parser which takes in string/char input and scans it for tokens like "+=" for self-addition and stuff, the AST (abstract syntax tree) Generator which organizes the data given from the lexer/parser to setup grammar into nodes, and the code generator which processes the AST Nodes into the target code whether it's bytecode, assembly, or straight up machine code.

SourcePawn uses a recursive descent parser which basically scans the source file from top to bottom and processes it token by token until the end of the source file. I know this because I looked at the original compuphase pawn compiler and of course Bailopan told me lol.

They CAN split up spcomp into separate dialects but for all I know, 1.7+ spcomp will be the one getting all the updates and bugfixes compared to 1.6 spcomp.

Eventually, everybody will drop 1.6 spcomp in favor of 1.7+ spcomp. I think you misunderstand that I'm not asking for SM devs to intentionally break compatibility but I'm advocating for everybody to modify their currently supported plugins into 1.7+ syntax
__________________
nergal is offline
BAILOPAN
Join Date: Jan 2004
Old 11-24-2015 , 15:06   Re: New API and Syntax
Reply With Quote #667

Quote:
Originally Posted by Potato Uno View Post
Yes, all of that is correct, but that doesn't justify why the devs should break old syntax support.
If you think we're not going to fix mistakes and bugs just because someone was relying on them... you is dead wrong. Though, I'll make a small confession: I would consider pulling out every last backward compatibility stop under a multi-million dollar maintenance contract. I'm just waiting for that phone call from Bank of America or Deutsche AG.
__________________
egg
BAILOPAN is offline
BAILOPAN
Join Date: Jan 2004
Old 11-24-2015 , 15:14   Re: New API and Syntax
Reply With Quote #668

Transitional Syntax, as others have noted, is "syntactic sugar". The bytecode format remains the same (for now). The term "tag" is actually ambiguous in programming languages: in Pawn, it's an arbitrary identifier that has no semantics, and operators can be defined based on tags. I don't consider them to be real types because the underlying type is always "cell".

SourcePawn 1.7 introduces "real types" in that tag semantics are deprecated. Internally, the new type system still compiles to "cell" semantics underneath the hood. We will need a new JIT and bytecode format to change that.

The confusion might come from the concept of "tagging," which is an optimization strategy in implementations of untyped programming languages, like JavaScript. In these systems, "tagged" values have a compressed format where the type can be decoded by only inspecting a few bits of the value. SourcePawn's VM has never used tagging. SourcePawn doesn't need it since the only internal type is "cell", and the type system is built with higher-level mechanisms (like the float natives and Handle system).
__________________
egg

Last edited by BAILOPAN; 11-24-2015 at 15:16.
BAILOPAN is offline
nergal
Veteran Member
Join Date: Apr 2012
Old 11-24-2015 , 21:32   Re: New API and Syntax
Reply With Quote #669

Quote:
Originally Posted by BAILOPAN View Post
Transitional Syntax, as others have noted, is "syntactic sugar". The bytecode format remains the same (for now). The term "tag" is actually ambiguous in programming languages: in Pawn, it's an arbitrary identifier that has no semantics, and operators can be defined based on tags. I don't consider them to be real types because the underlying type is always "cell".

SourcePawn 1.7 introduces "real types" in that tag semantics are deprecated. Internally, the new type system still compiles to "cell" semantics underneath the hood. We will need a new JIT and bytecode format to change that.

The confusion might come from the concept of "tagging," which is an optimization strategy in implementations of untyped programming languages, like JavaScript. In these systems, "tagged" values have a compressed format where the type can be decoded by only inspecting a few bits of the value. SourcePawn's VM has never used tagging. SourcePawn doesn't need it since the only internal type is "cell", and the type system is built with higher-level mechanisms (like the float natives and Handle system).
a new JIT and bytecode format would take a while though. Just out of curiosity, how "finished" are those two projects?
__________________
nergal is offline
BAILOPAN
Join Date: Jan 2004
Old 11-24-2015 , 21:41   Re: New API and Syntax
Reply With Quote #670

Neither of those are projects that exist, so I would say... zero finished.
__________________
egg
BAILOPAN is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 02:26.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode