Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2015-04-27

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:36 basiliscos joined #perl11
09:29 rurban joined #perl11
12:22 ToApolytoXaos joined #perl11
14:03 willthechill bulk88:
14:04 willthechill <willthechill> bulk88: looks like Docker could provide an open source and automated method for helping people get RPerl to run in Windows if they don't want to go the possibly-difficult manual installation route
14:04 willthechill <willthechill> https://docs.docker.com/installation/windows/
14:04 willthechill <willthechill> basically Docker-on-Windows uses VirtualBox to load a Docker-specific tiny Linux VM, which then loads any Docker container (RPerl in our case)
14:04 willthechill <willthechill> so there's the not-insignificant overhead of VirtualBox in this case, supposedly Docker itself has little-to-no overhead so that part is okay
14:04 willthechill <willthechill> but this method of RPerl-on-Windows is the "easy way" for people who don't want to struggle with cygwin or Microsoft compiler suites, etc.
14:04 willthechill <willthechill> "boot2docker is essentially a super-lightweight Linux instance running the Docker daemon"
14:05 willthechill ToApolytoXaos: greetings sir!  :)
14:06 willthechill rurban: I would like to talk to you about finalizing the datatypes standard for RPerl v1.0
14:06 ToApolytoXaos there he is :) greetings to you too sir!
14:07 willthechill ToApolytoXaos: haha yes sorry I was an absentee yesterday, Sunday is supposed to be a "day of rest" and sometimes it literally turns into a day of sleep!  ;)
14:07 ToApolytoXaos no worries; it's good to remind yourself that you are human being too lol
14:07 willthechill well, after I got home from church and took care of my critical errands, etc.
14:07 willthechill but yeah, basically I fell asleep, ha!
14:07 ToApolytoXaos you needed it
14:08 willthechill ah well, early start today!
14:08 willthechill I've got a cluster half-booted on cloudatcost
14:08 willthechill so I'm about to finish that
14:08 ToApolytoXaos brilliant
14:08 willthechill the head node for the compute cluster is already set up
14:08 willthechill or at least MOSTLY set up
14:08 ToApolytoXaos and i'm about to finish editing some photos and then to continue with "Learning Perl"
14:08 willthechill it DOES have RPerl installed and running!  :)
14:09 ToApolytoXaos that's so wicked
14:09 willthechill I love the "llama book"
14:09 ToApolytoXaos i have that too
14:09 ToApolytoXaos slowly-slowly
14:09 willthechill haha "wicked", yes I love 90's slang!
14:09 ToApolytoXaos heh, i'm doing my best to learn English
14:10 willthechill "the llama book" is the affectionate slang name for "Learning Perl"
14:10 ToApolytoXaos i'm constantly confusing those two
14:10 ToApolytoXaos the camel and llama book
14:11 willthechill "wicked" is what kids my age used to say when we were 10 - 15 years old
14:11 willthechill so I remember that slang fondly
14:11 willthechill yes it is easy to confuse camel vs llama!
14:11 willthechill I've made the same mistake myself, I'm sure
14:11 ToApolytoXaos you should use Guanaco for your book
14:11 ToApolytoXaos http://en.wikipedia.org/wiki/Guanaco
14:12 willthechill LOL I am not against Guanaco, although this is the first I've heard of it!
14:13 willthechill of course the official RPerl animal mascot is the roadrunner
14:13 willthechill but we will have multiple O'Reilly books
14:13 willthechill after "Learning RPerl" is "Intermediate RPerl", etc...
14:13 ToApolytoXaos ah...then add some roller skates to Guanaco and you will be fine lol
14:13 willthechill haha rollerblade guanaco
14:14 willthechill that would be a great meme picture for internet humor
14:14 ToApolytoXaos powered by ACME
14:14 willthechill yes, acme-brand rocket skates
14:14 willthechill to propel Perl as fast as possible!
14:15 ToApolytoXaos there's a photo somewhere about Perl
14:15 ToApolytoXaos let me find it lol
14:15 ToApolytoXaos http://1.bp.blogspot.com/-O4-eEDzyXZQ/VMp70VhgTwI/AAAAAAAANl8/P0DElnLYFgQ/s1600/perl_in_one_image.jpg
14:18 rurban willthechill: here I am. I came up with some by myself in the meantime
14:19 rurban mine are now: undef, int, int?, num, num?, str, str?
14:19 rurban int? being int|undef
14:19 willthechill rurban: my basic types are:  undef void integer number string  hash_ref array_ref
14:20 rurban no scalar?
14:20 willthechill then I have specific sub-types:  integer__hash_ref number__hash_ref string__hash_ref
14:20 willthechill OH YEAH scalartype
14:20 willthechill sorry I forgot
14:20 rurban scalartype or scalar?
14:20 willthechill I can't use 'scalar' because it is already used by Perl 5
14:20 willthechill 'scalartype'
14:20 willthechill it is the only one I had to add the word 'type' at the end
14:20 rurban i see, the op named scalar.
14:20 willthechill :P
14:20 rurban hmm
14:20 willthechill yes the operation named 'scalar' in Perl 5 is a namespace conflict in all namespaces
14:20 rurban what about SCALAR
14:20 rurban and VOID
14:21 willthechill uh well hang on, let me finish
14:21 rurban hash_ref sounds odd, hashref is used in all the docs
14:21 willthechill also integer__array_ref number__array_ref string__array_ref
14:21 rurban ditto for arrayref
14:21 willthechill and I think I also have scalartype__hash_ref scalartype__array_ref
14:21 willthechill yes I'm pretty sure I have those as well
14:22 rurban and I don't like the long names for int/num/str. perl6 uses the short names
14:22 rurban php uses the long names though
14:22 rurban and php uses ?string, and not str?
14:23 willthechill okay so we have several different opinions: Perl 5 Artur Bergman types http://search.cpan.org/dist/types/
14:23 willthechill Perl 6 types
14:23 willthechill rurban P2 types
14:23 rurban your type combinations are joiued with "__"?
14:23 willthechill willthechill RPerl types
14:23 rurban nope, my perl5 coretypes. not p2
14:23 willthechill yes type combos are joined with double-underscore '__'
14:24 willthechill OH YEAH also *__method
14:24 rurban I'm just working on the new perl5 type system, with checker and inferencer
14:24 willthechill appending '__method' is how I distinguish methods from normal subroutines
14:24 rurban I use attributes for such
14:24 willthechill void__method integer__method number__method string__method hash_ref__method array_ref__method
14:24 rurban i.e. :method (the CvMETHOD flag)
14:24 willthechill scalartype__method
14:25 willthechill no attributes in RPerl
14:25 willthechill no magic allowed!  ;)
14:25 rurban most types are internally represented by flags, which can be set via attributes.
14:25 willthechill yes except I am using C++ types for fast RPerl mode
14:25 willthechill no flags allowed
14:25 willthechill real types only
14:25 rurban how do you represent the function return type now?
14:26 rurban I use a simple attribute, like with php7
14:26 willthechill normal subroutine return types are just the normal types I already listed above
14:26 willthechill just append '__method' to tell RPerl the subroutine is actually a method
14:26 rurban and the syntax?
14:26 willthechill my number__hash_ref $foo_sub = sub { ... };
14:26 willthechill that is a subroutine named foo_sub() which returns a number__hash_ref
14:26 willthechill my number__hash_ref__method $foo_method = sub { ... };
14:27 rurban I use :method for this. this is even used by core as such.
14:27 rurban I see, via lexical assignment
14:27 willthechill my number__hash_ref__method $foo_method = sub { (my object $self, ... ) = @_; };
14:27 willthechill oops forgot to mention $self in my method syntax
14:27 rurban and in the the normal sub bla() {} syntax?
14:27 willthechill no normal sub blah() {} syntax
14:27 willthechill not in RPerl
14:28 willthechill because we can't use types correctly in that syntax
14:28 willthechill I wish we could!
14:28 rurban i have now: sub bla (type args) :rettype {body}
14:28 rurban or sub bla (args:type) :rettype {body}
14:29 rurban and you can use multiple sub attributes, like :method, :-caller and many more
14:29 willthechill and this is in your personal implementation of Perl 5 data types in your own personal fork of the Perl 5 core code written in C and C macros?
14:31 rurban the cpanel variant, yes. p5p will not adopt it for sure.
14:31 rurban but first I finish it and we'll use it internally for a while.
14:32 rurban perl6 uses a different syntax for return types, which perl5 didn't adopt.
14:32 rurban all other languages also went for simple attribute syntax recently
14:33 rurban i just don't know if to support :unsigned as type attribute also (UV, unsigned_integer)
14:33 rurban :const for everything
14:34 rurban these :unsigned and :const are attributes for type classes. for subs/methods I have many more
14:35 rurban like :pure, :method, :lvalue
14:35 rurban and :const. only :const and :pure are new. maybe :caller also, in the negative :-caller form, this is from perl6
14:36 rurban and it makes no sense at all to bring it up on p5p, as they have no idea what they are talking about., I rather go forward and just do it.
14:38 rurban do you have a syntax to declare types? like typedef integer__undef { integer | undef }?
14:39 rurban number__hash_ref is normally called HASH<number>
14:40 rurban or in my syntax: my num %hash; # hash of number values
14:40 willthechill no typedefs
14:40 rurban my int @a[10] = (0..9);
14:40 willthechill that is too much magic!
14:41 willthechill NO MAGIC ALLOWED!
14:41 rurban for typed and sized arrays
14:41 rurban this is no magic, just declaration syntax.
14:41 willthechill I have not made sized arrays yet, I know that is bad
14:41 willthechill because the C++ types I am using are vector
14:41 rurban you will get rid of run-time bounds checks then.
14:41 willthechill well we will add sized arrays in v2.0 I'm sure
14:42 rurban the type checker will do it at compile-time if possible
14:42 willthechill I must limit features for v1.0
14:42 willthechill yes the RPerl type-checker can do sized arrays at compile time
14:42 willthechill but like I said it will just have to wait for v2.0
14:42 willthechill I do not have pure or lvalue or caller or any of those attributes
14:42 willthechill I do not have unsigned type
14:42 willthechill I do not even have normal float type yet
14:43 willthechill number type is long double
14:43 rurban I'll do a short rperl summary at the german perl workshop in 2 weeks
14:43 willthechill I mean in RPerl the type 'number' is compiled into a C++ long double
14:43 willthechill okay that is good, german perl workshop
14:43 rurban long double as NV fine
14:43 willthechill let me know if you want me to be available on IRC or google video chat
14:43 rurban http://act.yapc.eu/gpw2015/talk/5979
14:44 rurban I'll send you my rperl paragraph and you can fix it.
14:44 willthechill wow nice!
14:44 willthechill okay great!
14:44 willthechill :D
14:44 willthechill I am conflicted about 'const'
14:44 rurban I'll also present the cpanel perl very shortly
14:45 willthechill so we will call it "cpanel perl" for now, meaning your Perl 5 core fork with your own personal Perl 5 types?
14:45 rurban and an overview of all the 5.22 and perl6 news
14:45 rurban cpanel perl is just an informal code name
14:46 willthechill anyway, I'm conflicted about const because C/C++ has 2 different kind of const-like things: actual 'const' variables, and #define pre-processor constants
14:46 rurban it's much more than that, I wrote blog posts about my TODO list some years ago.
14:46 willthechill okay yes I understand, informal code name, but better than no name at all, haha!  :)
14:46 rurban cperl is the current name
14:46 willthechill haha cperl sheesh
14:46 willthechill :P
14:46 willthechill I like it, haha!
14:46 willthechill oh boy
14:46 willthechill TOO MANY PERLS
14:46 rurban there's is also the new constexpr
14:47 rurban in c++14, crazy spec bugs in this though.
14:47 willthechill yes I have not yet looked at C++14
14:47 willthechill so my current implementation of constants is the following:  in RPerl we say "use constant" and that compiles to C++ #define code
14:48 rurban http://b.atch.se/posts/non-constant-constant-expressions/
14:48 willthechill ALSO I am currently conflicted, how to use the 'const' type modifier
14:48 willthechill such as const__array_ref or const__number__array_ref
14:48 willthechill or const__string__hash_ref
14:49 rurban I use SvREADONLY and do special compile-time optimizations on them
14:49 willthechill that would be the way to do fixed-size arrays and hashes
14:49 rurban so :const maps to SvREADONLY
14:49 willthechill that *COULD be a way to do fixed-size arrays and hashes
14:49 rurban and const can be used for all types. subs, classes, methods, data, @INC (esp. @INC)
14:50 rurban :const on arrays and hashes only affects the keys. disallow adding the number of keys. with hashes even the keys itself.
14:51 willthechill so my issue is that I've already had to modify a bit of Perl 5 behavior in order to add types
14:51 willthechill I don't want to modify any more Perl 5 behavior
14:51 rurban this is in my old perltypes.pod, written and implemented 2 years ago.
14:51 willthechill that way the interpreted RPerl code will match the compiled RPerl code
14:52 rurban I only changed bugs. everything new is new syntax, not any changed syntax
14:52 willthechill there are 2 different (but related) issues: the syntax of how to define types, and the actual list of valid types themselves
14:52 rurban yes
14:52 willthechill okay sorry, not clear, the syntax of how a user defines which types their variables and subs are
14:53 willthechill NOT the syntax of how the system designer (you or me) defines types
14:53 rurban I define types currently in XS only, but adding | combinations is done by adding them to the @ISA of the class
14:53 rurban DEF_CORETYPE("str?");
14:53 rurban TYPE_EXTENDS("str?", "str", "undef");
14:53 willthechill because as I said we don't let the RPerl user define new types, the list of valid RPerl types is hard-coded by the system designer (me)
14:53 rurban #define DEF_CORETYPE(s) \
14:53 rurban stash = GvHV(gv_HVadd(gv_fetchpvs("main::" s "::", GV_ADD, SVt_PVHV))); \
14:53 rurban Perl_set_version(aTHX_ STR_WITH_LEN(s "::VERSION"), STR_WITH_LEN("0.01c"), 0.01);  \
14:53 rurban isa = GvAV(gv_AVadd(gv_fetchpvs(s "::ISA", GV_ADD, SVt_PVAV)));         \
14:53 rurban mg_set(MUTABLE_SV(isa));
14:53 rurban #define TYPE_EXTENDS(t, t1, t2)          \
14:53 rurban av_push(isa, newSVpvs(t1));          \
14:53 rurban av_push(isa, newSVpvs(t2));          \
14:53 rurban mg_set(MUTABLE_SV(isa));             \
14:53 rurban SvREADONLY_on(MUTABLE_SV(isa));      \
14:53 rurban SvREADONLY_on(MUTABLE_SV(stash));
14:54 willthechill yeah I have not used any of that SvREADONLY stuff
14:54 willthechill nor the MUTABLE stuff
14:54 rurban isa and stash is need for the class/method optimizations.
14:54 rurban MUTABLE_SV is just a simple cast
14:54 willthechill although to be honest I am not yet smart enough to know whether or not I will need to use MUTABLE or SvREADONLY in the CPPOPS_PERLTYPES mode
14:55 willthechill RPerl does give the ability to create very light-weight classes that become directly C++ classes
14:55 willthechill so that can be used as a way for users to define sub-types
14:55 willthechill although they will not be real RPerl sub-types, they will all be objects
14:55 rurban when a class is closed I can bind it early, and call it directly, not via vtable dispatch. I can even inline most small accessor methods
14:55 willthechill where the class becomes the pseudo-sub-type
14:56 rurban types are classes for me, not objects.
14:56 willthechill well I should have little to no interpreted or dynamic code in the final compiled RPerl CPPOPS_CPPTYPES mode
14:56 rurban the problem is the @ISA
14:56 willthechill yes correct, I was saying that RPerl users can create new RPerl classes to be used as pseudo-sub-types
14:56 rurban which can be changed at run-time, also the stash (list of methods)
14:57 willthechill RPerl classes are created at compile time only
14:57 willthechill because they are C++ classes
14:57 rurban with a const stash you can forbid monkey patching of classes
14:57 rurban yeah, i have to support monkeypatching and dynamic behaviour. just need syntax for early binding
14:58 rurban like Moose->meta->make_immutable
14:58 rurban which is of course horrible syntax
14:59 rurban and not optimizable at all.
14:59 willthechill yes I understand that you must support all dynamic and high-magic behavior
14:59 willthechill and remember that I must KILL all dynamic and high-magic, haha!  ;)
15:00 rurban we willl only slowly convert our code to be fast. mostly starting with loops and typed methods
15:00 willthechill our internal system representations and implementations of types are radically different
15:00 willthechill when you say "we" do you mean cPanel as a corporation?
15:00 rurban but warnings, Config and unicode is already fast and non-magic for me.
15:00 rurban yes
15:00 willthechill okay
15:01 rurban and many more such system modules
15:01 willthechill SO back to the 2 main questions which I need to answer: type syntax and list of valid types
15:01 rurban I allow it as attributes after the data, and as the old lexical declaration in front.
15:01 willthechill I really need to NOT change my wacky subroutine syntax for v1.0 unless it is CRITICALLY necessary
15:01 willthechill because I have already finished and frozen the grammar
15:01 rurban list of valid types: every class is a type and vice versa. as in perl5 already
15:02 rurban type combinations are done via the @ISA
15:02 willthechill okay hang on you are going to fast
15:02 willthechill go back to question number 1: type syntax
15:02 rurban types are selected via the names, not via the structure.
15:03 rurban https://github.com/rurban/perl/blob/typed/const/pod/perltypes.pod
15:03 willthechill when you showed me your syntax, does that currently exist in Perl 5 or or only in cperl?
15:03 willthechill sub bla (type args) :rettype {body}
15:03 rurban that's cperl only
15:04 willthechill okay well if that is cperl only then I don't mind if rperl has it's own different syntax
15:04 willthechill since the rperl syntax WORKS already!  :)
15:04 rurban perl5 does not understand types in sigs yet (a 4 line patch)
15:04 willthechill so that answers question number 1
15:04 rurban but the attribute syntax works in perl5 proper also
15:04 willthechill yes I know that p5p is terrible, everybody knows that
15:04 rurban I don't care anymore about p5p at all. it a waste of valuable time
15:05 willthechill well just because YOU don't care about p5p doesn't mean they aren't still IN CHARGE OF PERL
15:05 willthechill so you should put your personal emotions aside on that issue
15:06 rurban 2. definition of types: package unsigned__integer 0.01 { @ISA = ('integer', 'unsigned'); }
15:06 willthechill multiple inheritance is not allowed in RPerl
15:06 willthechill because it may not match between Perl and C++
15:07 willthechill so RPerl can not do your definition of combo types using @ISA multiple inheritance
15:08 rurban single inheritance only; unsigned__integer extends integer by adding unsigned
15:08 rurban only two elements allowed currently (not with my version, but it's easier to implement)
15:09 willthechill uh well I guess I could add RPerl syntax for v2.0 that allows 2 types but does not actually compile to C++ multiple inheritance
15:09 rurban or const__integer, which disallows assignment
15:09 willthechill but like I said I'm not trying to allow RPerl users to define types!
15:09 willthechill const__integer is already an RPerl type (unless I recently removed it during my type purge)
15:09 rurban or integer__number which can do both. or integer__undef
15:09 rurban (int? for me)
15:10 rurban or stringification: integer__string (PVIV)
15:10 willthechill that is bad because combo types are dynamic
15:10 willthechill I already am unhappy that I have to support scalartype which is totally dynamic
15:10 willthechill in fact I want to REMOVE sclartype!
15:10 rurban all these combos explode with its ops. esp. with int, num, bigint, undef and stringification
15:11 rurban scalartype can fall back to slow dynamic perl ops
15:11 willthechill scalartype can still use C++ ops, but it needs to fall back to slow Perl types
15:11 rurban only typed data will be optimized
15:11 willthechill remember, OPS and TYPES are different
15:12 willthechill yes you are mostly correct, only typed data can be FULLY optimized
15:12 rurban I have fast ops very every fast type
15:12 rurban but no multidispatch yet
15:13 willthechill the 3 RPerl modes are: PERLOPS_PERLTYPES (test mode 1x speed), CPPOPS_PERLTYPES (7x speed), CPPOPS_CPPTYPES (200x speed)
15:13 rurban the biggest win is const and sized arrays, and closed classes
15:13 willthechill C++ vector type and unordered_map type allow fast non-fixed-size arrays and hashed
15:13 willthechill *hashes
15:14 rurban sized arrays are even better than typed arrays. the bounds check is heavier then the type dispatch
15:15 rurban but for big arrays the memory win is also good, and for integer iterators. for my int $i (0..9) {}
15:16 rurban with sized lists the loops can also be inlined/unrolled
15:17 rurban the const range here, but a sized array would be the same
15:18 rurban unordered_map still needs to check for not-existing keys. I can generate constant perfect hashes, which are a bit better
15:18 rurban I use them for warnings, Config and unicode
15:19 rurban Does the C++ the vector type do bounds checking? I think so
15:22 ToApolytoXaos your question is answered in here: http://www.gotw.ca/gotw/074.htm
15:24 willthechill ToApolytoXaos: thanks for the link, although it is a bit obtuse and I'm not sure the answer is exactly CLEAR from just glancing at the academic problems and code
15:24 ToApolytoXaos i meant the bound checking only; sorry for not making it clearer
15:24 willthechill rurban: I am not doing any of my own optimizations yet, such as loop unrolling etc
15:25 willthechill ToApolytoXaos: can you please type a brief description of what your link says about bound checking?
15:25 rurban so the names are no real problem for me, as I can define my types to alias to yours. it's just a class
15:26 rurban the compiler/optimizer can deal with custom types and core attributes (like :const, :method, ...)
15:27 ToApolytoXaos willthechill: well, basically it demonstrates the uses and abuses of vectors, like when to use [] and when to use at()
15:28 rurban multiple inheritance is theoretically possible, but not effcicient. esp. with multi dispatch. scalar @ISA is mostly 1, but roles overcomes this
15:28 rurban (roles are compile-time class compositions, mixins)
15:28 willthechill okay so my question #1 is answered already, I don't need to change my type syntax right now
15:28 willthechill so question #2 is about list of valid types, you are saying that you don't care what I use because you can make your types alias to mine
15:28 rurban the declaration syntax for subs is a bit odd.
15:28 willthechill and similarly, I can make my types alias to yours
15:28 rurban yes.
15:29 willthechill I know the declaration syntax for subs is odd, but I have no other choice!
15:29 ToApolytoXaos brb
15:29 rurban either copy the class, or alias it. *mine:: = \%yours::
15:29 rurban and the ISA also, so do it for the stash and the @ISA
15:30 rurban but the ISA is a key of the type stash anyway
15:30 rurban "magic" keys are @ISA and $VERSION for me.
15:31 rurban $VERSION to fill the stash with something, so that it exists, and the type is valid, accepted by the perl5 parser
15:31 rurban and @ISA if it extends some other class
15:31 rurban coretypes have an empty const @ISA
15:32 rurban but I have no special type names for arrays or hashes or subs. same type name.. this is different
15:33 rurban my int @a; is an array of ints
15:33 rurban my int \@a is an array ref to int values
15:34 rurban so I dont need array_ref or integer__array_ref. the types are stored in the PADNAME slot of the lexical
15:34 rurban so the compiler can pick it up there
15:35 rurban the only trick is for subs, an extra slot for the return type, and some new CvFLAGS for the other attributes
15:35 rurban but there's enough room there
15:36 rurban not sure if to declare dynamic types at all. like object or any or dynamic... this is the slow default anyway
15:37 rurban typed ruby (http://crystal-lang.org/) needed it..
15:38 willthechill hmmm well again all that is very different than how RPerl works internally
15:38 willthechill but I think I mostly understand what you are saying
15:39 willthechill so back to question #2, list of valid types...  should I really care at all what Perl 6 is doing for types?
15:40 willthechill because I do NOT like the camelcase abbreviated types
15:40 willthechill Str Int etc
15:42 rurban Str Int Numm are for the checked user-type variants. int str num are the internal coretype variants
15:43 rurban But then it soon gets crazy. http://doc.perl6.org/type.html
15:43 willthechill well the "internal" types for RPerl are C++ types
15:43 willthechill so for question #2 I'm talking about the user-accessible RPerl types
15:43 willthechill void undef scalartype integer number string hash__ref array__ref etc
15:44 rurban my problem is only with  hash__ref array__ref, because they are obvious anyway. no need to declare as such, or?
15:45 rurban maybe for no magic, and not blessed
15:45 willthechill you mean to do hashref instead of hash_ref, just remove the underscore?
15:45 rurban looks nicer to me, yes
15:45 rurban that's how it is in the existing documentation
15:46 willthechill which documentation?
15:46 rurban perl5 docs. but why do you need a coretype for this at all? to forbid magioc and bless?
15:47 willthechill I'm confused by your question.  RPerl requires all data is typed.
15:47 willthechill hash_ref (or hashref) is a type
15:47 willthechill obviously Perl will be much less useful without hashref type!
15:48 rurban But this type comes with the syntax already
15:49 willthechill inferring type is magic
15:49 rurban and internally represented as RV of HV
15:49 willthechill even if it is low magic
15:49 willthechill yes you are correct about RV of HV
15:49 willthechill no type inference allowed!
15:49 willthechill explicit types only!
15:49 willthechill 100% explicit static types
15:49 willthechill that is why I do not even like scalartype
15:50 willthechill and I may DELETE scalartype
15:50 willthechill because it is dynamic
15:50 rurban the only meaning would be to assert !SvMAGIC and !SvSTASH for those at compile-time
15:50 rurban scalartype is just a combination of all other scalar core types
15:51 rurban plus to allow magic and objects
15:51 rurban so a scalartype like undef|integer|number|string and maybe with object might be needed. to disallow magic attached to it.
15:51 willthechill scalartype is a combination of integer, number, string
15:52 rurban undef also I guess
15:52 willthechill maybe also undef, yes
15:52 rurban and sub/callable/method
15:53 willthechill 'method' is a type modifier
15:53 willthechill the only other possible type modifier is 'const', like I said I haven't decided on that one yet because we already have 'use constant'
15:53 willthechill anyway, if we change hash_ref to hashref and array_ref to arrayref, then we can collapse double-underscore-type-separator to single-underscore
15:54 rurban lvalue is allso alllowed upstream
15:54 willthechill integer__hash_ref becomes integer_hashref
15:54 rurban sounds good
15:54 willthechill what do we need lvalue for?
15:54 rurban lvalue subs, can appear in the lhs
15:54 rurban slice = "bla"
15:55 rurban substr $s... = "bla"
15:55 willthechill yeah we don't allow that in RPerl
15:55 willthechill so I don't need lvalue
15:55 rurban good :)
15:55 willthechill haha yes good!  :)
15:55 rurban very good
15:55 willthechill okay so the answer to question #2 is collapse underscores and that is it?
15:56 rurban the perl5 compiler converts some internallly to lvalue subs though. but shoulld be no problem for you
15:56 rurban what about hash and array as types?
15:56 rurban only refs of it?
15:57 willthechill RPerl disallows hash and array types
15:57 willthechill we can use @{} and %{} to deref as needed
15:57 rurban hmm, big deal I guess
15:57 willthechill but all variables start with $
15:57 willthechill no refs of scalars allowed, ONLY refs of non-scalars allowed
15:57 rurban ok, no problem I guess
15:58 rurban \0 is invalid?
15:58 willthechill correct, no ref of scalar
15:58 rurban ok, sounds like a plan
15:59 rurban I'll mention that. do you give a YAPC::US talk about it?
15:59 willthechill so we must always put push and pop in square brackets
15:59 willthechill yes I do still plan to go to YAPC::NA
15:59 willthechill probably do a lightning talk
15:59 willthechill but no plan finalized yet
16:00 rurban push and pop internally can deal with the refs, special ops for this.
16:00 rurban so it's pretty fast even in perl mode
16:00 willthechill yes I noticed that recently
16:00 rurban and multideref with 5.22 is also nice
16:00 willthechill and I also noticed that Dumper can take non-refs
16:01 rurban uuh, that's new to me
16:01 willthechill multideref?
16:01 rurban http://perl5-porters.perl.narkive.com/oJUTauTN/op-multideref-now-in-blead
16:02 rurban one op for cascade of refs (array keys mostly)
16:03 rurban $h->{x}->{y} in one op, not 4.
16:03 willthechill yes I see that from dave mitchell, looks good!
16:03 willthechill aelem_fast haha the good ol' days
16:03 willthechill or was it the BAD ol' days?  :P
16:04 willthechill I am SO glad I am not worried about trying to do dynamic interpreter optimizations any more
16:04 rurban aelemfast is still the best, until we have typed and sized arrays
16:04 rurban uh, lightning strikes here
16:04 willthechill yes I know it is the best, that is what makes me unhappy!
16:04 rurban :)
16:04 willthechill lightning strikes, like actual physical rain weather?
16:05 rurban thunderstorm, yes. hope the electricity holds up
16:05 rurban but I'm now in a first world country, so should not happen
16:07 willthechill ah yes first world country, that is good to hear!  :)
16:10 rurban have to go into the kitchen now to eat something...
16:11 willthechill sounds good!
18:12 ToApolytoXaos willthechill: i might be totally wrong, but based on your conversation with rurban into my mind came a middleware that could be used to allow the creation of multiple front-ends for any kind of programming language.
18:13 ToApolytoXaos it reminds me of JVM / Common Language Infrastructure.
18:13 willthechill haha wow that sounds a little crazy, but okay!  :)
18:13 willthechill we need LESS complexity and middleware in languages
18:14 willthechill jvm is generally NOT seen as a "good thing"
18:14 willthechill or at least, I would argue it is not
18:14 willthechill it was a good experiment 20 years ago
18:14 willthechill the only thing that has any hope is maybe LLVM
18:15 willthechill if you were interested in that sort of thing, I would suggest working on LLVM somehow
18:15 willthechill like creating an LLVM back-end for RPerl, etc.
18:17 ToApolytoXaos i haven't played with LLVM IR before, because I'm very much in love with GCC i'm afraid
18:18 ToApolytoXaos it's one of those crazy things i have lol
18:18 willthechill oh well gcc is just fine by me!
18:18 willthechill it is what I use as well
18:24 ToApolytoXaos brilliant
18:25 ToApolytoXaos to be honest with you, i wanted to develop a middleware language in the near future that would allow people to use it either as their main language or as their IR to develop their own front-end
18:25 willthechill NO DUDE don't do it
18:26 willthechill there are WAY too many intermediate languages already
18:26 willthechill the only one with any hope for the future is LLVM IR
18:26 willthechill all others are a waste of time and a distraction and general BAD thing
18:26 ToApolytoXaos the GCC team has to do something about it
18:26 ToApolytoXaos i disagree with LLVM's license
18:26 willthechill the gcc team needs to work with the LLVM team
18:27 ToApolytoXaos OR they have to fix their freaking structure
18:27 ToApolytoXaos they really need to add modularity in GCC
18:27 willthechill structure?
18:27 willthechill license?
18:27 ToApolytoXaos yep
18:27 ToApolytoXaos in LLVM everything is separated and anyone can choose where to work
18:28 ToApolytoXaos for instance, we have back-end separated from IR
18:28 ToApolytoXaos with GCC everything is merged as one
18:28 willthechill well that is a project management issue it sounds like
18:28 ToApolytoXaos it was their way in the past to prevent companies from isolating GCC as part of their proprietary tools
18:33 ToApolytoXaos so, to reiterate yet another time; RPerl will be used to generate binary code to be used either individually or as part of Perl's module system?
18:37 willthechill yes, if I understand you correctly, then the answer is yes
18:39 ToApolytoXaos wow...i can't wait to see RPerl finally stable and your smile when peoples' jaws will be dropped on the floor lol
18:40 willthechill haha yeah true!
18:41 ToApolytoXaos I'm pretty sure at the end of it will be doing this https://www.youtube.com/watch?v=j6UBNCE_aW0
18:47 willthechill LOL okay the dance is funny
18:53 ToApolytoXaos exactly :D
18:54 ToApolytoXaos trust me, when you see people dropping their jaws on the floor will be like this singing "mission accomplished!"
20:20 basiliscos1 joined #perl11
20:53 rurban joined #perl11

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary