-
Notifications
You must be signed in to change notification settings - Fork 14
FAQ
SPVM FAQs.
There is currently no stated policy to keep SPVM backward compatible.
If you look at Changes, you will notice that a lot of backward compatibility are broken .
However, this is inconvenient. Therefore, we list the grammars and features that will probably be kept backward compatible.
The following names of the keywords are probably kept backward compatible. These are all keywords in SPVM 0.9701.
# Keywords
alias
allow
as
break
byte
case
cmp
class
class_id
copy
default
die
divui
divul
double
dump
elsif
else
enum
eq
error
error_code
eval
extends
for
float
false
gt
ge
has
has_impl
if
isa
isweak
is_type
is_read_only
interface
int
interface_t
last
length
lt
le
long
make_read_only
my
mulnum_t
method
mutable
native
ne
next
new
new_string_len
of
our
object
print
private
protected
public
precompile
pointer
ref
refcnt
remui
remul
return
require
required
rw
ro
say
set_error_code
static
switch
string
short
scalar
true
undef
unless
unweaken
use
void
warn
while
weaken
wo
INIT
__END__
__CLASS__
__FILE__
__LINE__
If new keywords are added to Perl with a different meaning, we will not use them.
The reason for this is simply that our implementation was earlier, and we learned from the keywords used in the object-oriented CPAN modules and object-oriented keywords in Raku(Perl 6), and we already released more than 20 SPVM modules on CPAN(This was written at 2023-04-06). If keywords are changed, it is a lot of work to keep up with the changes.
Below are answers to your concerns.
Class variables are defined by our, not common field.
Fields are defined by has, not field.
Field getters and setters are defined by ro, wo, or rw, not redaer or writer.
Class methods are defined by static method, not common method.
Inheritances are defined by extends, not isa.
Interfaces are defined by interface_t not role.
Having interfaces is declared by interface, not does.
Weak references are checked using isweak not is_weak.
SPVM is designed to keep binary compatibility.
Even if the SPVM language itself is upgraded, previously installed SPVM modules and applications will work correctly without experiencing segmentation faults.
However, whether or not SPVM developers will actually keep binary compatibility is pending until version 1.0.
Here is how developers can keep binary compatibility after version 1.0 is reached.
Binary compatibility is not kept if the implementation of the SPVM operation code defined in spvm_implement.h is changed.
This is because the precompiled code contains the implementation of the operation code defined in spvm_implement.h.
On the other hand, implementation changes in spvm_api.c will not affect binary compatibility.
Binary compatibility is not be kept if the order of Native APIs defined in spvm_native.h is changed (i.e., the IDs are changed in the documentation).
Because the MIT license is the open source license that most developers know and understand.
The Perl Artistic License is a great open source license, but its biggest problem is that it is not well known outside of Perl developers.
Because the local variable name ($foo) has a sigil, it will not conflict with keyword names, class names, method names, or field names.
When declaring local variables, you can write programs without worrying about name conflicts.
You can write programs without worrying about name conflicts with keywords that may be added in the future.
Class variable names will conflict with local variable names, but this can be conventionally avoided by using upper case for class variable names($FOO) and lower case for local variable names($foo).
The SPVM string are simply a sequence of bytes of the string type. The sequence of bytes is exactly the same as the byte[] type.
A string are supposed to be represented in UTF-8, which is just a sequence of bytes.
A Perl string is converted to a SPVM string by the new_string method in the SPVM::ExchangeAPI class.
Whether the UTF-8 flag is set in the Perl string or not, the sequence of bytes stored in the PV slot of Perl's SV type is copied to the SPVM string.
A SPVM string is converted to a SPVM::BlessedObject::String object when is is returned to Perl.
A SPVM::BlessedObject::String has the SPVM string as it is.
If you want to convert it to a Perl string with UTF-8 flag, use the to_string method in the SPVM::BlessedObject::String class or use "" overloading, like "$blessed_object_string". The utf8::decode function is called and the UTF-8 flag is set to the Perl string.
If you want to treat it as a sequence of bytes, use the to_bin method in the SPVM::BlessedObject::String class.
The system calls used in the SPVM distribution are the following ones.
In the SPVM language, the print operator calls a system call of stdout. The warn operator calls a system call of stderr.
The modules contained in the SPVM distribution do not call any system calls.
The methods for system calls are implemented in SPVM::Sys distribution.