use Perl Log In
Rindolf - A Perl Dialect
What is Rindolf? Rindolf to Perl 5 is like Java is to C++, or Arc is to LISP. I.e: not as much a revolution but rather a re-organization of the language to make it cleaner, more consistent and more fun. Which is good because computer languages generally evolve rather than revolve.
Rindolf will not be backward compatible to Perl 5, because I think some of elements of Perl 5 are frustrating and need a little re-thinking and re-designing. I do hope that most Rindolf code will look like Perl 5 code at first glance, and that most Perl 5 scripts and code would be ported to Rindolf pretty easily.
I told Larry Wall and Damian Conway about Rindolf. Damian said he could not help me too much, but that I can go for designing it in any case. Larry suggested that I should propose the changes to the Perl 5 people, and try to get it there first. However, I see Rindolf as a distinct language and quite a leap forward from Perl 5. If the Perl 5 declares it as the next Perl 5 or accept its most important changes, I may stick to Perl 5. Else, Rindolf will stand on its own.
In the rest of this scope I will bring some highlights from the decisions I have made so far, about cleanups and modifications that will be brought by Rindolf. Note that nothing is implemented yet, they are just proposals "on paper". Also, they are subject to change, because I've only been Rindolfing around for a few days.
1. The -> operators and
2. Classes will be declared with a class {
3. An on_destroy() primitive that calls a callback when it is garbage collected
4. Globs will be replaced by return values:
my $I = open("<file.txt"); print $I, "Hello there!\n"; close($I);
5. local is gone. Long live my() and our().
6. Distinction between =< and
7. Re-organization features: easier stubs programming, a better garbage collector that can handle circular references, Full Unicode support.
8. A command-line switch that toggles proper tail recursion on and off.
9. Factories: setting the default behaviour of Perl in an Object-Oriented way. You can keep several same settings at the same time, and they will be de-allocated when they go out of scope.
10. Unambiguous "x" operator:
"hello" x 5 ==> ("hello","hello","hello","hello","hello") join("", "hello" x 5) ==> "hellohellohellohellohello" repeat_string("hello", 5) ==> "hellohellohellohellohello"
11. General Depreciation of the scalar() context. scalar(@a) will be replaced by count(@a). Reversing a string will be performed by a function other than reverse().
There are other changes I have in mind which I'm not too sure about. Like being able to define new operators at the code's compile time. Or a "block" structure with which one can define map, sort and friends in user-land. Or a default integrated literate programming Scheme for either TeX/LaTeX or DocBook.
However, I'm also going to consider the overhead of implementing those changes, and make sure the compiler or the back-end would not be too slow that way. Like I said, I think Perl 5 is a great language (probably my favourite for most practical purposes), but I think it could use a little cleaning up and re-organization. So, enter Rindolf...
hmmm.... (Score:1)
What would you propose as the new idiom for file slurping? (== read an entire small file into a scalar as quickly as possible)
-matt
Re:hmmm.... (Score:1)
sub read_entire_file
{
my $filename = shift;
my $f = open(");
close($f);
return $text;
}
I can put it in a standard module, if that is
what bothers you.
Re:hmmm.... (Score:1)
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Re:hmmm.... (Score:1)
plaintext mode, but apparently I still have to
use < and >.
Sorry.
Re:hmmm.... (Score:1)
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Re:hmmm.... (Score:2, Insightful)
What is the target audience for this new language? Do you expect people to use it instead of Perl 5 or Perl 6? That is, do you expect people to say "I hate typeglobs and scalar context so much that I am willing to use a language that has very little support instead of the very well-supported Perl 5 or Perl 6"? Or do you expect there to be a large developer following for it? Or is this mainly
Re:hmmm.... (Score:2, Informative)
Well, I usually use "read FH, $data, -s FH", which is supposed to be pretty fast. That would work even without local, $/, or scalar vs. list context.
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Not a convert (Score:2, Interesting)
several Perl 6 changes, particulary
the . operator. Nad you rougly had me
up until #3.
I don't much care either way for 2 or 3
(I do little OO).
I dislike #4, it drastically changes
the return valuer system in place
to no good ends. I'll grant typeglobs
are at best weird, at worst dysfuinctional,
but there must be a better way than this.
As somebody else pointed out local serves
a purpose that neither my nor our can serve.
That is unless you allow my on special variables.
Were that I say, pancakes?
Re:Not a convert (Score:1)
Re:Not a convert (Score:1)
a separate post.
I had a typo regarding => and , (I used = $b) would be an atomic
key/value pair, and not the same thing as ($a,$b).
A hash will need to be intialized with
join(",",
saying %myhash = ($a, $b); will generate a compile
time or run-time error.
Re:Not a convert (Score:1)
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Special Variables (Score:1)
are a bit hard to understand and can wreak havoc in
multi-threaded programs. I'd like to thing of a better
solution that will eliminate most of them, while keeping
the important ones of $_, $@, @_, etc. in a thread
safe, possibly lexically-scoped manner.
At the moment my best solution is Rindolf factories,
which I probably did not explain too well. Here is
a snippet of code from my "Ideas" file:
new();
$f->set_line_delimiter("\n\n");
sub myfunc
{
Re:Special Variables (Score:1)
At any rate, my $fh = $local_fh->open("open("readline(); looks like seriously wrong syntax to me.
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Special Variables Re-submission (Score:1)
are a bit hard to understand and can wreak havoc in
multi-threaded programs. I'd like to thing of a better
solution that will eliminate most of them, while keeping
the important ones of $_, $@, @_, etc. in a thread
safe, possibly lexically-scoped manner.
At the moment my best solution is Rindolf factories,
which I probably did not explain too well. Here is
a snippet of code from my "Ideas" file:
<<<
my $f = Rindolf::Factory->new();
$f->set_
Reservations (Score:4, Interesting)
Rindolf to Perl 5 is like Java is to C++
Are you saying that you want to take a Byzantine language and create a dumber, slightly broken implementation? :)
1. The -> operators and . will remain the same as in Perl 5.
I like dropping the arrow in favor of the dot. I didn't at first, but I see no reason to raise the barrier of entry to Perl by not using what is almost an industry standard syntax. I can't think of any reason not to switch to the dot as this will help to eliminate one of the most prevalent (and ridiculous) objections about Perl.
3. An on_destroy() primitive that calls a callback when it is garbage collected
Well, how is garbage collection going to be handled? Perl's GC is essentially in a random order and this can cause some subtle bugs. I've had database transactions fail to commit because an object containing a reference to the db handle was reaped prior to my committing a transaction (that was using DESTROY as a fallback). Very annoying. You mention later that you want a better garbage collector, so I'm curious to see how you'll do that.
5. local is gone. Long live my() and our().
I hope you weren't serious about "long live ... our". I think our was a mistake. Lexically scoped globals? If that doesn't cause the occasional BrainMelt, I don't know what will. "use vars" is better.
10. Unambiguous "x" operator:
This is not a serious design issue that would merit the rewrite of a language. It might be an appropriate thing to change (I dunno, I have no problem with how "x" currently works), but it seems a bit trivial in comparison to what else you have here.
11. General Depreciation of the scalar() context. scalar(@a) will be replaced by count(@a).
I like scalar context. In fact, I sometimes use it with "x" to assign defaults to a hash:
my %hash; :)
@hash{ @array } = (1) x @array; #
The question that I have to ask is: why is this better than Perl5? Further, the changes in Perl6 are so exciting (well, to me at least), that I think you're better off building on Perl6 than Perl5, if you want to clean things up. I have no problem with anyone coming along trying to create something new, but I want to be sold on why it's better than what we already have. I don't see that here, but I'd like to hear more.
Reply to This
Arrow vs. Dot [was Re:Reservations] (Score:1)
for member accesses, just because it is the
"industry standard". I think the arrow is a
cognitively-sound choice, because that's how
people think about references and data-structures.
Check the following URL:
http://groups.yahoo.com/group/hackers-il/message/1878
for more information
our (Score:1)
I'm not too familiar with our, but I heard it is the same as use vars qw( ... ).
In any case, Rindolf will have a similar mechanism
to usr vars qw( ... ). I make call it
global(@a,$b,%hello), or something else.
I'll probably keep use vars for compatibility , but it will be depreciated.
Re:our (Score:1)
Re:our (Score:2, Funny)
Are you going to implement this yourself? (Score:2, Interesting)
I'm just wondering, since the Perl5 core isn't that small, and I think it takes quite a while to wrap your head around it in order to be able to make changes.
--
Esli epei eto cumprenan, shris soa Sfaha.
Aettot ibrec epesecoth, spakhea scrifeteis.
Re:Are you going to implement this yourself? (Score:1)
At the moment, I'm not going to implement everything. I'm just going to write and present a SPEC of its changes from Perl 5. After I have a SPEC, I'll see what to do next.
Making the SPEC is enough hard work as it is because I need to solve the small problems and inconsistencies, and make sure I like it as it is.
You go, Shlomi! (Score:2, Insightful)
Best of luck, Shlomi. I'm going the way of Perl 6, but I keep toying with thoughts of "how I would do it." (Zero time to design or implement anything myself. Make that negative time.) Do Rindolf, but do it for yourself. Put what you want in it, and take out what you want. (It's interesting to me to compare the feature set you've chosen with what I would have chosen.)
Don't let anyone dissuade you, because Rindolf is for you. If you do what you want, you may someday find that people who think like yo
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
No more local? (Score:2, Interesting)
e.g.
my %args = (
username => 'Foo',
password => 'Bar',
}
{
local $args{password} = 'Barr'
# test that login fails
}
Tony
On context... (Score:2, Interesting)
The two most glaring examples of this are your comments about local() and scalar context.
local is an absolutely useful feature, (albeit somewhat misnamed) that afaict cant be replaced. Or at least cant be replaced with any degree of elegance without simply renaming the thing.
Scalar context is through be
Re:Simple Questions (Score:2)
Me, too. I thought it was a takeoff on Gandalf or something. (Since I haven't read LOTR, I thought it might even be a character.)
google seems to find only this article and a posting by Shlomi on advogato. Oh, and also someone on the python email lists with an email address of rindolf2@yahoo.com . Same person as Shlomi? If so, I noted another weird intersection of space and time: the same person has posted to mailing lists for the lilypond project, something I'm interested in. (And stayed up hacking
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers