x from xs where x > 10 select x

var result = from x in xs
             where x > 10
             select x;

var closestMarker = (from body in bodies
                      where body != ignoreBody
                      from part in body.Parts
                      from marker in part.attachables.OfType<Marker>()
                      let distance = Vector3.Distance(marker.WorldPosition, pointerPosition)
                      where distance < SNAP_DISTANCE_LIMIT
                      orderby distance ascending
                      select marker).FirstOrDefault();

foreach (from xs var x)

namespace CSharp
{
  syntax module Linq
  {
    using Nitra.Core;

    using CSharp.TokenNames;
    using Literals;
    using CSharp.CsIdentifiers;
    using Types;
    using Expressions;

    keyword regex ['A'..'Z', 'a'..'z', '_'..'_']+ rule S;

    alias BooleanExpression   = Expression;

    extend syntax Expression
    {
      | Query = &("from") LinqClause+;
    }

    token LinqKeyword
    {
      | Name=LinqKeywordToken !CsIdentifiers.IdentifierPartCharacters
        {
          // "from" ignored
          regex LinqKeywordToken = "where" | "join" | "on" | "equals" | "into" | "let" | "orderby" | "ascending" | "descending" | "select" | "group" | "by";
        }
    }

    syntax LinqExpression  = !LinqKeyword Expression;
    syntax LinqType        = !LinqKeyword AnyType;
    syntax LinqName        = !LinqKeyword Name;

    syntax LinqClause
    {
      | FromCommon = "from" sm             LinqName sm "in" sm LinqExpression;
      | FromCasted = "from" sm LinqType sm LinqName sm "in" sm LinqExpression;

      | Let        = "let" sm LinqName sm "=" sm LinqExpression; // let-clause
      | Where      = "where" sm BooleanExpression; // where-clause
      | JoinCommon = "join" sm             LinqName sm "in" sm LinqExpression sm "on" sm LinqExpression sm "equals" sm LinqExpression (sm IntoClause)?; // join-clause && join-into-clause
      | JoinCasted = "join" sm LinqType sm LinqName sm "in" sm LinqExpression sm "on" sm LinqExpression sm "equals" sm LinqExpression (sm IntoClause)?; // join-clause && join-into-clause
      | Orderby    = "orderby" sm (Ordering; ","sm)+ // orderby-clause
        {
          regex OrderingDirection = "ascending" | "descending";
          syntax Ordering = LinqExpression OrderingDirection?;
        }

      | Select     = "select" sm LinqExpression;
      | Group      = "group"  sm LinqExpression sm "by" sm LinqExpression;

      | IntoClause = "into" sm LinqName;
    }
  }
}

namespace CSharp
{
  syntax module LinqExt
  {
    using Nitra.Core;
    using CSharp.Linq;
    extend syntax LinqClause
    {
      | Distinct = "distinct" что там дистинкту надо;
      | FirstOrDefault = "first" "or" "default";
    }
    extend token LinqKeyword
    {
      | Distinct = "distinct";
      | FirstOrDefault = "first" "or" "default";
    }
  }
}

... SQL query editors don’t have a crystal ball that can predict what table or view you’re querying when you write:

SELECT Na

How is it supposed to autocomplete what you’re writing when it hasn’t seen the FROM clause (here spelled all caps because we’re talking about SQL) just yet? Moreover, it doesn’t make sense to write SELECT first because it’s the last thing that happens: Tell the source, filter items, sort them, and so on. But projecting the result happens at the very end. So why does it come syntactically first? I don’t know. If there’s a SQL language designer reading this book, send me an email and enlighten me!

DON’T REPEAT MISTAKES
Assuming the SQL order of operations was a mistake (it is), it would be silly to repeat it in today’s language design even if it were for consistency and familiarity with the SQL language people may already know.
In fact, Visual Basic 9.0 was in this camp for a long while, going to great lengths to keep the Select clause (here using typical Visual Basic spelling of the keyword) in front, with intractable and confusing code editor jumps while typing a query.
It went roughly like this, if I recall correctly:

• Type Select and press space; a From clause would be inserted below what you already typed.
  
  
• The editor jumps to the From clause where you specify the source and range identifier.
  
  
• When you’re done with the From clause, as observed by the code editor upon pressing a space or Tab, you would go back to Select.
  
  
• Back in the Select clause, you can now use the range identifier introduced in the second step.

This was highly unintuitive, and the Visual Basic team eventually surrendered and made the From clause come first. The fear people would dislike it because of its difference from the already familiar SQL language has, as far as I know, never really materialized.

So, even if some SQL language designers would defend their design choices, the .NET developer audience has shown that having the From clause first is much more intuitive in the end.

Ты уперся в свою техническую реализуемость, хотя про нее никто кроме тебя не говорит.