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

41–50 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#41

Post by WesolyKubeczek »

sundarurfriend wrote: post #39
WesolyKubeczek wrote: post #25

Why only things like these float up to the front page, and not elegant and/or wholesome things written in Perl?

Because with its declining popularity, most people here are unfamiliar with the language except for its meme status as "that weird line noise language". Things that confirm pre-existing beliefs are easy to accept and upvote, whereas good Perl code would require (a) some actual thinking, and (b) challenging the socially accepted narrative - both of which are relatively much harder.

Good Perl code would also look pretty boring, almost like enterprise Java.

I'd wager that all code that "just works", in any language, looks bland and predictable.

But I'd rather have that than cute and clever any day.

Re: Perl code that is syntactically correct only on Fridays

#42

Post by im3w1l »

JohnDeHope wrote: post #19
saba2008 wrote: post #11

Earlier quoted context omitted.

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.

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
  (

Re: Perl code that is syntactically correct only on Fridays

#43

Post by lloeki »

JohnDeHope wrote: post #19
saba2008 wrote: post #11

Earlier quoted context omitted.

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.

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…

It is formally proven that Perl can't be parsed!

https://www.perlmonks.org/index.pl?node_id=663393

Re: Perl code that is syntactically correct only on Fridays

#45

Post by samatman »

lmm wrote: post #35
rabbits77 wrote: post #17

Earlier quoted context omitted.

Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If it could not be parsed it could never work! And this is totally OK in my book, I use Perl for prototyping ideas and an expressive language that allows creativity from me the programmer is a feature as it promotes looking at a problem from multiple aspects.

> Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If you're going to be pedantic, it's important to be correct; there's no such thing as dynamic parsing. > If it could not be parsed it could never work! What's the logic here? An interpreter doesn't have to operate on an AST, a language doesn't have to have a nontrivial grammar (consider Brainfuck). Perl…

> there's no such thing as dynamic parsing

As long as we're indulging in pedantry, this is incorrect presuming dynamic means what it usually means. Any regular expression constructed at runtime contradicts you.

Modifying your core parser at runtime though, who would do such a thing? Other than reader macros in Common Lisp I mean. Are we going to argue this means Common Lisp doesn't parse if we add reader macros at runtime? A peculiar argument.

Now. Should we talk about whether doing that is a good idea? A lovely and separate conversation. I agree with GP that since Perl will spit out a parse tree, it does in fact parse, and since it's not static, well, it's dynamic.

Which we can prove by, I dunno, writing some Perl which only parses on Fridays. Right?

Re: Perl code that is syntactically correct only on Fridays

#47

Post by ihateolives »

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.

Re: Perl code that is syntactically correct only on Fridays

#48

Post by skissane »

JohnDeHope wrote: post #19
saba2008 wrote: post #11

Earlier quoted context omitted.

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.

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…

Common Lisp is another language in which this should be possible. Common Lisp allows you to run arbitrary code at compile-time, and that code is allowed to modify the language syntax (*READTABLE*, SET-MACRO-CHARACTER, etc). So code could make itself syntactically invalid on Fridays by changing the language syntax depending on the day of the week.

This goes beyond mere Lisp macros, in that ordinary Lisp macro invocations still look like Lisp lists, while with this you can make arbitrary changes to the syntax, you could even make Common Lisp look like Pascal (if you really wanted to)

The designers of Scheme intentionally left this feature out (which was also found in some of Common Lisp’s ancestors, such as Maclisp), but some Scheme implementations/descendants included it anyway (as an extension), such as Racket, Guile and Chicken Scheme.

Re: Perl code that is syntactically correct only on Fridays

#49

Post by lloeki »

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 (

Bash even reads the file as it goes, so if you run a "long-running" script (a sleep is enough), edit far enough down, and write the file again, the previously started bash will end up running the new content once it gets up to reading where the change happened.

Re: Perl code that is syntactically correct only on Fridays

#50

Post by metalliqaz »

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…

Thank you for this. I hate trying to read Perl so much.

What is the "#/+" for?

Post reply on HN