2019-09-05 18:23:42 +02:00
|
|
|
use crate::data::base::Block;
|
2019-09-23 22:24:51 +02:00
|
|
|
use crate::errors::ArgumentError;
|
2019-06-22 03:36:57 +02:00
|
|
|
use crate::parser::{
|
|
|
|
hir::{self, Expression, RawExpression},
|
2019-08-01 03:58:42 +02:00
|
|
|
CommandRegistry, Text,
|
2019-06-22 03:36:57 +02:00
|
|
|
};
|
2019-05-28 08:45:18 +02:00
|
|
|
use crate::prelude::*;
|
2019-10-28 18:51:08 +01:00
|
|
|
use crate::TaggedDictBuilder;
|
2019-05-28 08:45:18 +02:00
|
|
|
use derive_new::new;
|
2019-06-03 07:11:21 +02:00
|
|
|
use indexmap::IndexMap;
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
use log::trace;
|
|
|
|
use std::fmt;
|
2019-05-28 08:45:18 +02:00
|
|
|
|
|
|
|
#[derive(new)]
|
2019-07-24 00:22:11 +02:00
|
|
|
pub struct Scope {
|
2019-08-01 03:58:42 +02:00
|
|
|
it: Tagged<Value>,
|
2019-06-03 07:11:21 +02:00
|
|
|
#[new(default)]
|
2019-08-01 03:58:42 +02:00
|
|
|
vars: IndexMap<String, Tagged<Value>>,
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
impl fmt::Display for Scope {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
f.debug_map()
|
|
|
|
.entry(&"$it", &format!("{:?}", self.it.item))
|
|
|
|
.entries(self.vars.iter().map(|(k, v)| (k, &v.item)))
|
|
|
|
.finish()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-28 08:45:18 +02:00
|
|
|
impl Scope {
|
2019-08-29 13:08:28 +02:00
|
|
|
pub(crate) fn empty() -> Scope {
|
2019-05-28 08:45:18 +02:00
|
|
|
Scope {
|
2019-08-01 03:58:42 +02:00
|
|
|
it: Value::nothing().tagged_unknown(),
|
2019-06-03 07:11:21 +02:00
|
|
|
vars: IndexMap::new(),
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
}
|
2019-07-24 00:22:11 +02:00
|
|
|
|
2019-08-29 13:08:28 +02:00
|
|
|
pub(crate) fn it_value(value: Tagged<Value>) -> Scope {
|
2019-07-24 00:22:11 +02:00
|
|
|
Scope {
|
|
|
|
it: value,
|
|
|
|
vars: IndexMap::new(),
|
|
|
|
}
|
|
|
|
}
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
|
2019-08-29 13:08:28 +02:00
|
|
|
pub(crate) fn evaluate_baseline_expr(
|
2019-06-22 03:36:57 +02:00
|
|
|
expr: &Expression,
|
2019-07-24 00:22:11 +02:00
|
|
|
registry: &CommandRegistry,
|
2019-06-08 00:35:07 +02:00
|
|
|
scope: &Scope,
|
2019-06-22 22:46:16 +02:00
|
|
|
source: &Text,
|
2019-08-01 03:58:42 +02:00
|
|
|
) -> Result<Tagged<Value>, ShellError> {
|
2019-10-13 06:12:43 +02:00
|
|
|
let tag = Tag {
|
|
|
|
span: expr.span,
|
|
|
|
anchor: None,
|
|
|
|
};
|
2019-06-22 03:36:57 +02:00
|
|
|
match &expr.item {
|
2019-10-13 06:12:43 +02:00
|
|
|
RawExpression::Literal(literal) => Ok(evaluate_literal(literal.tagged(tag), source)),
|
2019-09-09 19:43:10 +02:00
|
|
|
RawExpression::ExternalWord => Err(ShellError::argument_error(
|
|
|
|
"Invalid external word",
|
|
|
|
ArgumentError::InvalidExternalWord,
|
2019-10-13 06:12:43 +02:00
|
|
|
tag,
|
2019-09-09 19:43:10 +02:00
|
|
|
)),
|
2019-10-13 06:12:43 +02:00
|
|
|
RawExpression::FilePath(path) => Ok(Value::path(path.clone()).tagged(tag)),
|
2019-09-13 03:54:17 +02:00
|
|
|
RawExpression::Synthetic(hir::Synthetic::String(s)) => {
|
|
|
|
Ok(Value::string(s).tagged_unknown())
|
|
|
|
}
|
2019-10-13 06:12:43 +02:00
|
|
|
RawExpression::Variable(var) => evaluate_reference(var, scope, source, tag),
|
|
|
|
RawExpression::Command(_) => evaluate_command(tag, scope, source),
|
2019-08-16 00:18:18 +02:00
|
|
|
RawExpression::ExternalCommand(external) => evaluate_external(external, scope, source),
|
2019-06-22 03:36:57 +02:00
|
|
|
RawExpression::Binary(binary) => {
|
|
|
|
let left = evaluate_baseline_expr(binary.left(), registry, scope, source)?;
|
|
|
|
let right = evaluate_baseline_expr(binary.right(), registry, scope, source)?;
|
2019-05-28 08:45:18 +02:00
|
|
|
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
trace!("left={:?} right={:?}", left.item, right.item);
|
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
match left.compare(binary.op(), &*right) {
|
2019-10-13 06:12:43 +02:00
|
|
|
Ok(result) => Ok(Value::boolean(result).tagged(tag)),
|
2019-07-09 06:31:26 +02:00
|
|
|
Err((left_type, right_type)) => Err(ShellError::coerce_error(
|
2019-10-13 06:12:43 +02:00
|
|
|
left_type.tagged(Tag {
|
|
|
|
span: binary.left().span,
|
|
|
|
anchor: None,
|
|
|
|
}),
|
|
|
|
right_type.tagged(Tag {
|
|
|
|
span: binary.right().span,
|
|
|
|
anchor: None,
|
|
|
|
}),
|
2019-07-09 06:31:26 +02:00
|
|
|
)),
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|
|
|
|
}
|
2019-08-02 21:15:07 +02:00
|
|
|
RawExpression::List(list) => {
|
|
|
|
let mut exprs = vec![];
|
|
|
|
|
|
|
|
for expr in list {
|
|
|
|
let expr = evaluate_baseline_expr(expr, registry, scope, source)?;
|
|
|
|
exprs.push(expr);
|
|
|
|
}
|
|
|
|
|
2019-10-13 06:12:43 +02:00
|
|
|
Ok(Value::Table(exprs).tagged(tag))
|
2019-09-14 18:30:24 +02:00
|
|
|
}
|
|
|
|
RawExpression::Block(block) => {
|
2019-10-13 06:12:43 +02:00
|
|
|
Ok(Value::Block(Block::new(block.clone(), source.clone(), tag.clone())).tagged(&tag))
|
2019-08-02 21:15:07 +02:00
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
RawExpression::Path(path) => {
|
|
|
|
let value = evaluate_baseline_expr(path.head(), registry, scope, source)?;
|
2019-06-24 02:55:31 +02:00
|
|
|
let mut item = value;
|
2019-05-28 08:45:18 +02:00
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
for name in path.tail() {
|
2019-06-24 02:55:31 +02:00
|
|
|
let next = item.get_data_by_key(name);
|
2019-05-28 08:45:18 +02:00
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
match next {
|
2019-06-24 02:55:31 +02:00
|
|
|
None => {
|
2019-09-23 22:24:51 +02:00
|
|
|
let possibilities = item.data_descriptors();
|
|
|
|
|
|
|
|
let mut possible_matches: Vec<_> = possibilities
|
|
|
|
.iter()
|
|
|
|
.map(|x| (natural::distance::levenshtein_distance(x, &name), x))
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
possible_matches.sort();
|
|
|
|
|
2019-10-14 07:00:10 +02:00
|
|
|
if possible_matches.len() > 0 {
|
|
|
|
return Err(ShellError::labeled_error(
|
|
|
|
"Unknown column",
|
|
|
|
format!("did you mean '{}'?", possible_matches[0].1),
|
|
|
|
&tag,
|
|
|
|
));
|
|
|
|
} else {
|
|
|
|
return Err(ShellError::labeled_error(
|
|
|
|
"Unknown column",
|
|
|
|
"row does not have this column",
|
|
|
|
&tag,
|
|
|
|
));
|
|
|
|
}
|
2019-06-24 02:55:31 +02:00
|
|
|
}
|
|
|
|
Some(next) => {
|
2019-10-13 06:12:43 +02:00
|
|
|
item = next.clone().item.tagged(&tag);
|
2019-06-24 02:55:31 +02:00
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
};
|
|
|
|
}
|
2019-05-28 08:45:18 +02:00
|
|
|
|
2019-10-13 06:12:43 +02:00
|
|
|
Ok(item.item().clone().tagged(tag))
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|
|
|
|
RawExpression::Boolean(_boolean) => unimplemented!(),
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-01 18:20:31 +02:00
|
|
|
fn evaluate_literal(literal: Tagged<&hir::Literal>, source: &Text) -> Tagged<Value> {
|
2019-06-22 03:36:57 +02:00
|
|
|
let result = match literal.item {
|
2019-08-30 19:29:04 +02:00
|
|
|
hir::Literal::Number(int) => int.into(),
|
2019-06-24 09:59:23 +02:00
|
|
|
hir::Literal::Size(int, unit) => unit.compute(int),
|
2019-09-14 18:30:24 +02:00
|
|
|
hir::Literal::String(tag) => Value::string(tag.slice(source)),
|
2019-10-27 02:01:58 +01:00
|
|
|
hir::Literal::GlobPattern(pattern) => Value::pattern(pattern),
|
2019-09-14 18:30:24 +02:00
|
|
|
hir::Literal::Bare => Value::string(literal.tag().slice(source)),
|
2019-06-22 03:36:57 +02:00
|
|
|
};
|
2019-05-28 08:45:18 +02:00
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
literal.map(|_| result)
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
fn evaluate_reference(
|
|
|
|
name: &hir::Variable,
|
|
|
|
scope: &Scope,
|
2019-06-22 22:46:16 +02:00
|
|
|
source: &Text,
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
tag: Tag,
|
2019-08-01 03:58:42 +02:00
|
|
|
) -> Result<Tagged<Value>, ShellError> {
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
trace!("Evaluating {} with Scope {}", name, scope);
|
2019-06-22 03:36:57 +02:00
|
|
|
match name {
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
hir::Variable::It(_) => Ok(scope.it.item.clone().tagged(tag)),
|
2019-10-28 18:51:08 +01:00
|
|
|
hir::Variable::Other(inner) => match inner.slice(source) {
|
|
|
|
x if x == "nu:env" => {
|
|
|
|
let mut dict = TaggedDictBuilder::new(&tag);
|
|
|
|
for v in std::env::vars() {
|
|
|
|
dict.insert(v.0, Value::string(v.1));
|
|
|
|
}
|
|
|
|
Ok(dict.into_tagged_value())
|
|
|
|
}
|
|
|
|
x if x == "nu:config" => {
|
|
|
|
let config = crate::data::config::read(tag.clone(), &None)?;
|
|
|
|
Ok(Value::row(config).tagged(tag))
|
|
|
|
}
|
|
|
|
x => Ok(scope
|
|
|
|
.vars
|
|
|
|
.get(x)
|
|
|
|
.map(|v| v.clone())
|
|
|
|
.unwrap_or_else(|| Value::nothing().tagged(tag))),
|
|
|
|
},
|
2019-05-28 08:45:18 +02:00
|
|
|
}
|
|
|
|
}
|
2019-08-16 00:18:18 +02:00
|
|
|
|
|
|
|
fn evaluate_external(
|
|
|
|
external: &hir::ExternalCommand,
|
|
|
|
_scope: &Scope,
|
|
|
|
_source: &Text,
|
|
|
|
) -> Result<Tagged<Value>, ShellError> {
|
|
|
|
Err(ShellError::syntax_error(
|
2019-09-14 18:30:24 +02:00
|
|
|
"Unexpected external command".tagged(*external.name()),
|
2019-08-16 00:18:18 +02:00
|
|
|
))
|
|
|
|
}
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
|
|
|
|
fn evaluate_command(tag: Tag, _scope: &Scope, _source: &Text) -> Result<Tagged<Value>, ShellError> {
|
|
|
|
Err(ShellError::syntax_error("Unexpected command".tagged(tag)))
|
|
|
|
}
|