It's mentioned in the source but it's based on this:
Perl code that is syntactically correct only on Fridays
121–130 of 233 posts
Re: Perl code that is syntactically correct only on Fridays
#122As a sister language of Perl, Raku can do the same trick.
constant &s = (now.DateTime.day-of-week == 7) ?? sub () {} !! sub (|) {};
constant c = s(42);
Modules are precompiled, programs are not (yet). So to make this really depend on the day of compilation we have to put it into a module (for now).
Re: Perl code that is syntactically correct only on Fridays
#123In similar vein: parsing C++ is literally undecidable: https://blog.reverberate.org/2013/08/parsing-c-is-literally-... You can't even decide if a particular "*" is multiplication or a pointer dereference until you resolve templates, which is Turing-complete.
Unless something has changed a lot, C++ templates at least only used to be Turing complete if you assume you're allowed unlimited recursive template applications, and compilers were free to restrict that (and did). Has that changed? In theory I agree with you that this is horribly ugly - I very much prefer simple grammars (the irony being my favourite language to use is Ruby, which has an atrocious grammar). In pract…
It's not the undecidability itself that is the problem though. The undecidability is just an indicator how horribly complicated C++ is to compile.
You cannot even construct the full parse tree before evaluating a mini-language that is Turing complete. Related article: why C++ compilation is slow (https://digitalmars.com/articles/b54.html)
Re: Perl code that is syntactically correct only on Fridays
#124Earlier quoted context omitted.
This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
> because how hard can it be to work with dates?
Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
Re: Perl code that is syntactically correct only on Fridays
#125This leverages Perl's BEGIN block which runs before the main part of the code. I suppose the same fun could be had in other languages: if day_of_week is "Friday" eval(piece_of_incorrect_code) else do_sane_operation
Most other languages would require `eval` and having incorrect code as syntactically correct string literal. But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
Sorry, but you're dead wrong. Perl is not parsed as it is executed, which can be verified easily by writing a program with a syntax error at the end, and seeing that it doesn't run code at the top. Try it with the following program.
print "Hello, world\n";
This line raises a syntax error before the previous line tries to execute.
In this case we're assigning to a symbol. And then the parsing of the final line is dependent on whether or not that symbol has a prototype. See https://perldoc.perl.org/perlsub#Prototypes for what Perl prototypes are, and to see why they would affect parsing.
Re: Perl code that is syntactically correct only on Fridays
#126I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.
It could have been much worse. At least you didn't have a leap year or timezone bug. I've exterminated more than one of those in my time as an engineer, and it's never really any fun.
Re: Perl code that is syntactically correct only on Fridays
#127Earlier quoted context omitted.
Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.
This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
The PHP interops group recently added a Clock interface for this purpose. There were many comments along the lines of “what’s the point?”
Re: Perl code that is syntactically correct only on Fridays
#128I don't get it! It is clearly written in the code, that the progam should behave this way. Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point? I read all the comments and still don't get it. What am i missing?
What makes it "special" here is the fact that it will COMPILE only on a friday. It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.
But isn’t this possible with any language that has a pre-compilation step? Perl is certainly conflating its passes (as explained by other comments above), but in rust you could add a check in build.rs or use macros in C to accomplish the same, right?
Re: Perl code that is syntactically correct only on Fridays
#129Earlier quoted context omitted.
Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
> because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.
Re: Perl code that is syntactically correct only on Fridays
#130Earlier quoted context omitted.
Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
> because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
I've been bit by bugs when coming to moment.js from other languages. It's the only datetime library I knew of, before you'll tell me about all the others, that mutates the datetime object when you do arithmetic.