Shlomi Fish writes " I started forming the SPEC for Rindolf - a Perl dialect based on Perl 5. I'm doing it because I found most of the suggestions in the Apocalypses and Exegesis either incomprehensible or redundant. I think Perl 5 is all in all a good language that just needs a little cleaning up. Hence: Rindolf."
I consider Perl as a family of languages rather than a single language. Rindolf aims to be another dialect in this language which will be derived from Perl 5, with some influences from other languages, I am familiar with. The architect of Rindolf is me, but I'll accept suggestions and input from other Perl lovers (or haters). If you are interested join the mailing list which I set up.
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...
Re:hmmm....
Shlomi Fish on 2002-02-14T07:48:06
You could define:
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....
pne on 2002-02-14T09:14:27
Please preview your comments before submitting them. It appears that there is some text missing... you probably used literal < and > characters rather than < and >, causing use.perl to discard the unknown "tags"? At any rate, it looks as if $text is not assigned at all, the only thing in the parentheses of the open command is one double-quote character.Re:hmmm....
Shlomi Fish on 2002-02-14T12:02:38
I did preview but perhaps I missed it. I used
plaintext mode, but apparently I still have to
use < and >.
Sorry.Re:hmmm....
pne on 2002-02-14T12:09:52
Yes, that's right. That's because even in plain text you can use tags such as bold or italic (or emphasised and strongly emphasised). I suppose the only difference is that returns are replaced with <br> in "Plain Old Text" mode while with "HTML Formatted" you have to do it yourself with <p>...</p>.Re:hmmm....
pudge on 2002-02-14T13:25:40
I think what bothers people is losing the freedom and ability to do it simply without going to such a function.
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 for fun?Re:hmmm....
pne on 2002-02-14T09:12:02
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.
Re:Not a convert
kasei on 2002-02-13T22:38:29
From `perldoc -f reverse`:
- In scalar context, concatenates the elements of LIST and returns a string value with all characters in the opposite order.
.g Re:Not a convert
belg4mit on 2002-02-14T15:56:08
That is not reverse handling strings.
reverse handling strings means an entry
in perlfunc saying reverse STRING.
and
perl -e 'print reverse "foobar"'
outputting "raboof".
print puts its arguments into list context
pudge on 2002-02-14T21:14:35
% perl -le 'print scalar reverse "foobar"'
raboof
% perl -le '$x = reverse "foobar"; print $x'
raboof
Re:Not a convert
Shlomi Fish on 2002-02-14T07:54:27
Quite a long post, I say, but I address every issue in
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(",",/($a => $b)*/) (pardon the notation). I.e:
saying %myhash = ($a, $b); will generate a compile
time or run-time error.Re:Not a convert
pne on 2002-02-14T09:16:57
Please re-submit, this time with preview to make sure nothing is cut off.Special Variables
Shlomi Fish on 2002-02-14T08:20:23
I don't like "global" special variables one. They
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
{
my $local_f = Rindolf::Factory->new();
$local_f->set_line_delimiter("\n");
my $fh = $local_fh->open("open("readline();
>>>
Hope, I clarified everything.Re:Special Variables
pne on 2002-02-14T09:16:14
Please re-submit this text; there is something missing. Probably because you used literal less-than signs which were interpreted as beginning an HTML tag.
At any rate, my $fh = $local_fh->open("open("readline(); looks like seriously wrong syntax to me.Special Variables Re-submission
Shlomi Fish on 2002-02-14T12:07:47
I don't like "global" special variables one. They
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_line_delimiter("\n\n");
sub myfunc
{
my $local_f = Rindolf::Factory->new();
$local_f->set_line_delimiter("\n");
my $fh = $local_fh->open("<myfile.txt");
#
# $fh will be read one line at a time.
#
# .
# .
# .
# $local_f is destroyed. Has no effect on the system
}
&myfunc();
my $fh = $f->open("<myfile.txt");
# Now $fh reads an entire paragraph.
my $paragraph = $fh->readline();
>>>
I have an idea for a using() construct that will allow
using an object as a default factory.
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
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.
Arrow vs. Dot [was Re:Reservations]
Shlomi Fish on 2002-02-14T12:14:22
There is no reason to prefer a dot over an arrow
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 informationour
Shlomi Fish on 2002-02-14T12:22:16
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
malte on 2002-02-14T14:57:33
Its not the same. Check the docs.Re:our
autarch on 2002-02-14T15:52:38
It's deprecated! I'm going crazy with this error. Depreciated means it's value has been reduced. Deprecated means it has been mocked, but in computer-speak it means that particular feature/interface/whatever has been declared "old news".
Deprecated
deprecated
deprecated
No "i"!Re:our
pudge on 2002-02-14T16:19:29
I find it more troublesome that he's talking about deprecating a feature of a language that doesn't even exist yet.:-)
Re:Are you going to implement this yourself?
Shlomi Fish on 2002-02-14T12:19:02
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!
jdavidb on 2002-02-14T18:11:02
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 you like what you did, and that would be a bonus, but building something like Rindolf for yourself may be the neatest project you ever work on. If people don't like it, fine, they don't have to use Rindolf, and neither Perl 5 nor Perl 6 have to be like it.
If you go on to implementation, I seriously recommend you consider using C with glib or C++ with STL.
If you go any further, please keep us posted. Keep a journal here at use Perl; and/or start a Rindolf site.
The biggest question in my mind (seeing as how the most I'd ever be would be a user of Rindolf) is: WTF is Rindolf? What does that word mean? Where did it come from, if it doesn't mean anything?
Re:Simple Questions
jdavidb on 2002-02-18T18:13:10
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 on last night.)
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 being part of the overall concept of context is one of the fundamental cool ideas of Perl, one that massively distinguishes it from every other language I have ever seen. I routinely write code that behaves completely differently, yet completely intuitively depending on the context. A good example of this elgance and beauty is the localtime() function (as I hope you know well). If you call it in scalar context it returns a nice formatted version of the time. If you call it in list context it returns all of the time parts. So if you remove scalar context what do you do with functions like this? Add a flag to the function? Have two functions? Sounds like a mess to me.
If anything I would say that there should be _more_ forms of context (it would be lovely to be able to say
return wantarray ? @list : wantstring ? "This is a string" : wantref ? \@list;
or the like [err i am aware that might not be the best example.])
Anyway, I think you should review your thoughts on this subject and enhance your knowledge and understanding about perl before you propose to change it in such fundamental and IMO misguided ways.
regards, Demerphq
Re:On context...
Linda on 2003-05-13T11:22:25
Well said DemerphqRe:On context...
polettix on 2007-05-11T13:44:21
Do you know about Contextual::Return by Damian Conway? Even if I don't fully agree with having that many contexts, I can understand that others may find them useful.
