Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

Post reply on HN
Print view View original

101–110 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#101

Post by lloeki »

bmn__ wrote: post #77
lloeki wrote: post #43

Earlier quoted context omitted.

It is formally proven that Perl can't be parsed! https://www.perlmonks.org/index.pl?node_id=663393

It can be externally parsed with ambiguities. The article is written by someone who authored such a parsing toolkit about three years later. Despite what you may have learnt, an ambiguous parse tree is still a useful thing to have, we can build tools taking it into account, also most existing tools can be modified in a straightforward fashion to make use of the extra nodes. The real Perl parser disambiguates with heu…

Yeah, I always found the linked post to not be all that serious about it anyway, just a funny, satisfying hacker thing.

Re: Perl code that is syntactically correct only on Fridays

#102

Post by ycombobreaker »

gerikson wrote: post #28
jfk13 wrote: post #21

Earlier quoted context omitted.

To be pedantic, this is an area where pedantry occasionally matters. For the vast majority of (casual) usage, it doesn't.

Indeed. I get invites from people from the UK who simply refer to the current local time (GMT or BST) as "GMT". It just means current London time to them.

Same happens in the US, people use EST/EDT interchangeably (and incorrectly) when they mean Eastern timezone. Or Central/Mountain/Pacific.

Re: Perl code that is syntactically correct only on Fridays

#103

Post by knodi123 »

darkwater wrote: post #98
inquist wrote: post #64

Earlier quoted context omitted.

> an intern who wrote code .... his code had been in production You get what you pay for, eh?

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

Re: Perl code that is syntactically correct only on Fridays

#104

Post by adhoc_slime »

ihateolives wrote: post #47
johnnyo wrote: post #10

I 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.

I once had to implement date picker that returned the date to be sent to backend to fetch the day's reservations. It seemed to work fine the day I implemented it. Next day it broke. Turned out the widget returned MM/DD/YYYY instead of DD/MM/YYYY. And I implemented it on 10th of October.

I've learned the hard way that this is also dependent on the user's date format set on their computer in some libraries(iirc it was jquery ui date picker a few years back). its liberating when you decide to throw it all out and just use integers for all things not facing an end user.

Re: Perl code that is syntactically correct only on Fridays

#105

Post by bitemix »

sandinmyjoints wrote: post #66
bentcorner wrote: post #61

Earlier 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.

Love the Rich references.

Re: Perl code that is syntactically correct only on Fridays

#106

Post by wutbrodo »

reneberlin wrote: post #75

I 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?

You can write code in any language that fails at runtime depending on the day. What's notable about this is that its _syntactical correctness_ depends on the day, which is not possible to achieve in many languages.

What's being noted is the degree of flexibility that Perl has with respect to its execution environment.

Though if you include preprocessors, you expand the number of languages for which you can do something similar.

Re: Perl code that is syntactically correct only on Fridays

#107

Post by Sophira »

G3rn0ti wrote: post #40

This is how it works: BEGIN { # an execution block that runs when the module is compiled *f = # assigns to the symbol "f" inside the symbol table ... (localtime->wdayname eq 'Fri') # is it Friday? ? sub() {} # ... on friday an anonymous subroutine taking no arguments : sub {}; # ... on every other day a subrouting taking arguments } # closes the execution block # The following line executes the subroutine "f" and div…

This is generally correct, but your final analysis is slightly wrong and this is a perfect example of why Perl can be difficult to parse.

If you add a 1 to the end of the "f/1;#/+" line, so that it becomes "f/1;#/+1", the code will become correct.

What's actually happening is that on Fridays, the "f/1;#/+" line means "call f, divide the result by 1, and throw away the result", followed by a comment. On any other day, it means "call f with the regex parameter /1;#/ and add an unspecified parameter to it". Since the right hand side of the + operator isn't specified, it is syntactically incorrect.

Re: Perl code that is syntactically correct only on Fridays

#108

Post by Sophira »

darrenf wrote: post #72
G3rn0ti wrote: post #40

This is how it works: BEGIN { # an execution block that runs when the module is compiled *f = # assigns to the symbol "f" inside the symbol table ... (localtime->wdayname eq 'Fri') # is it Friday? ? sub() {} # ... on friday an anonymous subroutine taking no arguments : sub {}; # ... on every other day a subrouting taking arguments } # closes the execution block # The following line executes the subroutine "f" and div…

> # The following line executes the subroutine "f" and divides the result by 1 on fridays > # but on other days causes the interpreter to trigger a syntax error You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments. Removing all the "only on a Friday" stuff boils down to the difference between these two: # this compiles sub f…

> You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments.

Isn't that what the parent said, going by your quote? They said "the following line [...] on fridays but on other days causes the interpreter to trigger a syntax error".

Re: Perl code that is syntactically correct only on Fridays

#109

Post by jwilk »

im3w1l wrote: post #42
JohnDeHope wrote: post #19

Earlier quoted context omitted.

Right, the beauty of this is that it's a syntax error he's produced. Sure any language can write code to produce a runtime error under any condition at all. And a lot of languages have features that allow them to run code at compile time, and similarly produce errors then too. But those languages don't allow you to ruin the syntax of the language. I guess it's something that requires macros. Would it be safe to say t…

Bash parses as it runs so something as simple as this works if [ $(date +%u) -ne 5 ] then exit fi (

You could check syntax of the whole file (even the unreachable parts) with the -n option.

But that's not bulletproof; consider this code (adapted from https://hal.archives-ouvertes.fr/hal-01513750/document>):

  if [ $(date +%u) -eq 5 ]
  then
      alias maybe=''
  else
      alias maybe=:
  fi
  maybe for x in; do :; done
"sh -n" always reports syntax error, even thought the script syntax is correct on Fridays.
Post reply on HN