Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

I've already mentioned some things that differs from lambdas. Another big difference is speed: No call overhead, local variables outside the block are faster to access, and it allows the optimizers to work across the block boundary.

2 1

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

An annoying thing with C and languages with C-like syntax is the distinction between statements and expressions. Specifically, that you lose some expressiveness in expression contexts since declarations and statements like for/while/switch etc can't be used in there. Gcc has an extension to allow blocks inside statements: One just puts a block inside parenthesis and writes statements there. E.g: ({ int y = foo (); int z; if (y > 0) z = y; else z = - y; z; }) The result of the expression is the last statement. It occurred to me that it would be really simple to add this to pike too. We already have gauge and catch which can open up statement blocks inside expressions, so we only need a variety that returns the value of the last statement expression. The gcc syntax doesn't work since ({ }) means arrays, so among the existing keywords I picked "inline": werror ("%d\n", inline { int s = 1; for (int i = 2; i < 7; i++) s *= i; s; }); Type checking of the last statement etc works just fine since the statement/expression distinction doesn't exist on the abstract syntax tree level anyway. If the last statement isn't an expression then the inline block will be of void type, so this gives "assigning a void expression": mixed c = inline { for (int i = 0; i < 10; i++) werror (" %O\n", i); }; This construct is different from lambdas (implicit or not) since the block is not a function of its own, but rather just another nested block. I.e. it's possible to exit it using "break" and "continue", and "return" will return from the surrounding function. I only made this for fun and haven't committed it yet. Here's the patch if someone wants to play around with it: --- src/language.yacc 30 May 2008 11:20:41 -0000 1.426 +++ src/language.yacc 31 May 2008 13:59:55 -0000 @@ -3674,6 +3674,10 @@ free_node ($3); } | expr4 TOK_ARROW line_number_info error {$$=$1; free_node ($3);} + | TOK_INLINE '{' statements comma_expr2 expected_semicolon end_block + { $$ = mknode (F_COMMA_EXPR, $3, $4); } + | TOK_INLINE '{' statements end_block + { $$ = $3; } ; idents2: idents The syntax is still open for discussion, of course. It would work to use e.g. "block {...}" instead; the new "block" keyword would not conflict with identifiers.

3 4

Void expressions in arguments
by Mirar ＠ Pike developers forum 31 May '08

31 May '08

Why can't an expression have a void result, then?

1 0

Void expressions in arguments
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

Maybe it can compile typeof(expr) first to find out? Or would that give side effects in compilation errors etc?

1 1

Void expressions in arguments
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 31 May '08

31 May '08

But then it would only need to be promoted on assignment, no?

1 0

Void expressions in arguments
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 31 May '08

31 May '08

Why?

1 0

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

Try it yourself. It introduces two new shift/reduce conflicts only, which are benign: One is for a TOK_LEX_EOF error production, and the other is for comma_expr (as part of statements). The second gets cleared up when end_block is shifted.

1 0

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

Because a block is always a void expression: statement_with_semicolon: unused2 expected_semicolon ; /.../ unused2: comma_expr { $$=mkcastnode(void_type_string, $1); } ;

1 0

precompile.sh
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 30 May '08

30 May '08

Currently precompile.sh will continue testing different methods, even if it succeeds in running a pike script, if that pike script then fails for some reason. This hides some errors during the build process. Is there any way of getting around this?

1 0

Parsing RXML entities result (was: Re: [Bug] Parser.HTML crash)
by bertrand.lupart＠linkeo.com 25 May '08

25 May '08

> It *is* a bit odd, but it used to be the default behaviour, so it was > made like that for compatibility reasons, iirc. These things are > old... :) One can expect that an RXML entity can output another RXML entity, which would then be parsed. I'm not fond of RXML as a programming language, but out of curiosity, what is the expected behaviour? -- Bertrand LUPART http://bertrand.gotpike.org/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel