Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

pike version numbering
by Martin Bähr 31 May '08

31 May '08

hi, since i have seen a few references to pike version 7.10 i'd like to discuss the current versioning scheme. i'd like to suggest that the next version is numbered as pike 8. the main reason for that is that if we continue with 7.10, 7.12, etc, we will NEVER reach a state where the changes are large enough to get to pike 8 because after 7.10 and further switching to 8 will create expectations where pike 8 would be significantly different from pike 7. in other words: 7.8, 7.10 then will be our major versions, and the 7 in front would become rather meaningless. a succession like 7.6, 7.8, 8.0 seems natural and won't surprise anyone. ie: no one will expect a huge set of changes there. on the other hand the changes from 7.6 to 7.8 seem quite significant (syntax additions like getters and setters, etc) already, that i even think it may be waranted to go directly from 7.6 to 8. in any case however, we should never go to 7.10. greetings, martin.

3 2

Blocks inside expressions
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 31 May '08

31 May '08

That points towards the lack of need for inlined expression blocks, but it may just be that people have been conscious about the lambda overhead or thought a function would be more apropriate.

1 0

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

31 May '08

Aha, cute. Yes, that use would be exclusive with this one, unfortunately.

1 0

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

31 May '08

I don't know. What would these generators be?

1 0

Blocks inside expressions
by Mirar ＠ Pike developers forum 31 May '08

31 May '08

Sounds good to me. Is that keyword used?

2 1

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

31 May '08

Not only, as said. It seems like a waste of time to fix inlining of that particular kind of lambdas (and I think it wouldn't be nearly as simple as this) when the end result is only less versatile and clumsier to write. Other kinds of lambdas, like e.g. those commonly used with map() and filter() would still not be possible to inline, btw. For that to work we'd have to change map(), filter(), etc to special builtin constructs.

1 0

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

Jump to page:

2026

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