Skyla  Feeney

Skyla Feeney


Fuzzy Name Matching Datasets

You are given a few datasets from a client who wants to match entities between multiple disparate datasets. Your target variable are the entities, and your features could be the entity’s address, Country, Zipcode, Vendor ID, etc.

All of these features definitely help you with your search for the same entities, but the only problem is that the client gave you a dataset with a lot of missing values for each of those useful columns that could significantly aid you in your search.

#python #data-science #matching

What is GEEK

Buddha Community

Fuzzy Name Matching Datasets
Rust  Language

Rust Language


Macros - The Rust Programming Language

Rust For Beginners Tutorial - Macros

In this video we take a look at how to define and use simple macros that generate code for us at compile time!

Exercise solutions: 

0:00 Intro
0:27 Exercise 1
2:55 Exercise 2
4:13 Exercise 3
4:55 Exercise 4
6:33 Exercise 5
8:59 Outro


We’ve used macros like println! throughout this book, but we haven’t fully explored what a macro is and how it works. The term macro refers to a family of features in Rust: declarative macros with macro_rules! and three kinds of procedural macros:

  • Custom #[derive] macros that specify code added with the derive attribute used on structs and enums
  • Attribute-like macros that define custom attributes usable on any item
  • Function-like macros that look like function calls but operate on the tokens specified as their argument

We’ll talk about each of these in turn, but first, let’s look at why we even need macros when we already have functions.

The Difference Between Macros and Functions

Fundamentally, macros are a way of writing code that writes other code, which is known as metaprogramming. In Appendix C, we discuss the derive attribute, which generates an implementation of various traits for you. We’ve also used the println! and vec! macros throughout the book. All of these macros expand to produce more code than the code you’ve written manually.

Metaprogramming is useful for reducing the amount of code you have to write and maintain, which is also one of the roles of functions. However, macros have some additional powers that functions don’t.

A function signature must declare the number and type of parameters the function has. Macros, on the other hand, can take a variable number of parameters: we can call println!("hello") with one argument or println!("hello {}", name) with two arguments. Also, macros are expanded before the compiler interprets the meaning of the code, so a macro can, for example, implement a trait on a given type. A function can’t, because it gets called at runtime and a trait needs to be implemented at compile time.

The downside to implementing a macro instead of a function is that macro definitions are more complex than function definitions because you’re writing Rust code that writes Rust code. Due to this indirection, macro definitions are generally more difficult to read, understand, and maintain than function definitions.

Another important difference between macros and functions is that you must define macros or bring them into scope before you call them in a file, as opposed to functions you can define anywhere and call anywhere.

Declarative Macros with macro_rules! for General Metaprogramming

The most widely used form of macros in Rust is declarative macros. These are also sometimes referred to as “macros by example,” “macro_rules! macros,” or just plain “macros.” At their core, declarative macros allow you to write something similar to a Rust match expression. As discussed in Chapter 6, match expressions are control structures that take an expression, compare the resulting value of the expression to patterns, and then run the code associated with the matching pattern. Macros also compare a value to patterns that are associated with particular code: in this situation, the value is the literal Rust source code passed to the macro; the patterns are compared with the structure of that source code; and the code associated with each pattern, when matched, replaces the code passed to the macro. This all happens during compilation.

To define a macro, you use the macro_rules! construct. Let’s explore how to use macro_rules! by looking at how the vec! macro is defined. Chapter 8 covered how we can use the vec! macro to create a new vector with particular values. For example, the following macro creates a new vector containing three integers:

let v: Vec<u32> = vec![1, 2, 3];

We could also use the vec! macro to make a vector of two integers or a vector of five string slices. We wouldn’t be able to use a function to do the same because we wouldn’t know the number or type of values up front.

Listing 19-28 shows a slightly simplified definition of the vec! macro.

Filename: src/

macro_rules! vec {
    ( $( $x:expr ),* ) => {
            let mut temp_vec = Vec::new();

Listing 19-28: A simplified version of the vec! macro definition

Note: The actual definition of the vec! macro in the standard library includes code to preallocate the correct amount of memory up front. That code is an optimization that we don’t include here to make the example simpler.

The #[macro_export] annotation indicates that this macro should be made available whenever the crate in which the macro is defined is brought into scope. Without this annotation, the macro can’t be brought into scope.

We then start the macro definition with macro_rules! and the name of the macro we’re defining without the exclamation mark. The name, in this case vec, is followed by curly brackets denoting the body of the macro definition.

The structure in the vec! body is similar to the structure of a match expression. Here we have one arm with the pattern ( $( $x:expr ),* ), followed by => and the block of code associated with this pattern. If the pattern matches, the associated block of code will be emitted. Given that this is the only pattern in this macro, there is only one valid way to match; any other pattern will result in an error. More complex macros will have more than one arm.

Valid pattern syntax in macro definitions is different than the pattern syntax covered in Chapter 18 because macro patterns are matched against Rust code structure rather than values. Let’s walk through what the pattern pieces in Listing 19-28 mean; for the full macro pattern syntax, see the reference.

First, a set of parentheses encompasses the whole pattern. A dollar sign ($) is next, followed by a set of parentheses that captures values that match the pattern within the parentheses for use in the replacement code. Within $() is $x:expr, which matches any Rust expression and gives the expression the name $x.

The comma following $() indicates that a literal comma separator character could optionally appear after the code that matches the code in $(). The * specifies that the pattern matches zero or more of whatever precedes the *.

When we call this macro with vec![1, 2, 3];, the $x pattern matches three times with the three expressions 1, 2, and 3.

Now let’s look at the pattern in the body of the code associated with this arm: temp_vec.push() within $()* is generated for each part that matches $() in the pattern zero or more times depending on how many times the pattern matches. The $x is replaced with each expression matched. When we call this macro with vec![1, 2, 3];, the code generated that replaces this macro call will be the following:

    let mut temp_vec = Vec::new();

We’ve defined a macro that can take any number of arguments of any type and can generate code to create a vector containing the specified elements.

There are some strange edge cases with macro_rules!. In the future, Rust will have a second kind of declarative macro that will work in a similar fashion but fix some of these edge cases. After that update, macro_rules! will be effectively deprecated. With this in mind, as well as the fact that most Rust programmers will use macros more than write macros, we won’t discuss macro_rules! any further. To learn more about how to write macros, consult the online documentation or other resources, such as “The Little Book of Rust Macros” started by Daniel Keep and continued by Lukas Wirth.

Procedural Macros for Generating Code from Attributes

The second form of macros is procedural macros, which act more like functions (and are a type of procedure). Procedural macros accept some code as an input, operate on that code, and produce some code as an output rather than matching against patterns and replacing the code with other code as declarative macros do.

The three kinds of procedural macros (custom derive, attribute-like, and function-like) all work in a similar fashion.

When creating procedural macros, the definitions must reside in their own crate with a special crate type. This is for complex technical reasons that we hope to eliminate in the future. Using procedural macros looks like the code in Listing 19-29, where some_attribute is a placeholder for using a specific macro.

Filename: src/

use proc_macro;

pub fn some_name(input: TokenStream) -> TokenStream {

Listing 19-29: An example of using a procedural macro

The function that defines a procedural macro takes a TokenStream as an input and produces a TokenStream as an output. The TokenStream type is defined by the proc_macro crate that is included with Rust and represents a sequence of tokens. This is the core of the macro: the source code that the macro is operating on makes up the input TokenStream, and the code the macro produces is the output TokenStream. The function also has an attribute attached to it that specifies which kind of procedural macro we’re creating. We can have multiple kinds of procedural macros in the same crate.

Let’s look at the different kinds of procedural macros. We’ll start with a custom derive macro and then explain the small dissimilarities that make the other forms different.

How to Write a Custom derive Macro

Let’s create a crate named hello_macro that defines a trait named HelloMacro with one associated function named hello_macro. Rather than making our crate users implement the HelloMacro trait for each of their types, we’ll provide a procedural macro so users can annotate their type with #[derive(HelloMacro)] to get a default implementation of the hello_macro function. The default implementation will print Hello, Macro! My name is TypeName! where TypeName is the name of the type on which this trait has been defined. In other words, we’ll write a crate that enables another programmer to write code like Listing 19-30 using our crate.

Filename: src/

use hello_macro::HelloMacro;
use hello_macro_derive::HelloMacro;

struct Pancakes;

fn main() {

Listing 19-30: The code a user of our crate will be able to write when using our procedural macro

This code will print Hello, Macro! My name is Pancakes! when we’re done. The first step is to make a new library crate, like this:

$ cargo new hello_macro --lib

Next, we’ll define the HelloMacro trait and its associated function:

Filename: src/

pub trait HelloMacro {
    fn hello_macro();

We have a trait and its function. At this point, our crate user could implement the trait to achieve the desired functionality, like so:

use hello_macro::HelloMacro;

struct Pancakes;

impl HelloMacro for Pancakes {
    fn hello_macro() {
        println!("Hello, Macro! My name is Pancakes!");

fn main() {

However, they would need to write the implementation block for each type they wanted to use with hello_macro; we want to spare them from having to do this work.

Additionally, we can’t yet provide the hello_macro function with default implementation that will print the name of the type the trait is implemented on: Rust doesn’t have reflection capabilities, so it can’t look up the type’s name at runtime. We need a macro to generate code at compile time.

The next step is to define the procedural macro. At the time of this writing, procedural macros need to be in their own crate. Eventually, this restriction might be lifted. The convention for structuring crates and macro crates is as follows: for a crate named foo, a custom derive procedural macro crate is called foo_derive. Let’s start a new crate called hello_macro_derive inside our hello_macro project:

$ cargo new hello_macro_derive --lib

Our two crates are tightly related, so we create the procedural macro crate within the directory of our hello_macro crate. If we change the trait definition in hello_macro, we’ll have to change the implementation of the procedural macro in hello_macro_derive as well. The two crates will need to be published separately, and programmers using these crates will need to add both as dependencies and bring them both into scope. We could instead have the hello_macro crate use hello_macro_derive as a dependency and re-export the procedural macro code. However, the way we’ve structured the project makes it possible for programmers to use hello_macro even if they don’t want the derive functionality.

We need to declare the hello_macro_derive crate as a procedural macro crate. We’ll also need functionality from the syn and quote crates, as you’ll see in a moment, so we need to add them as dependencies. Add the following to the Cargo.toml file for hello_macro_derive:

Filename: hello_macro_derive/Cargo.toml

proc-macro = true

syn = "1.0"
quote = "1.0"

To start defining the procedural macro, place the code in Listing 19-31 into your src/ file for the hello_macro_derive crate. Note that this code won’t compile until we add a definition for the impl_hello_macro function.

Filename: hello_macro_derive/src/

extern crate proc_macro;

use proc_macro::TokenStream;
use quote::quote;
use syn;

pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
    // Construct a representation of Rust code as a syntax tree
    // that we can manipulate
    let ast = syn::parse(input).unwrap();

    // Build the trait implementation

Listing 19-31: Code that most procedural macro crates will require in order to process Rust code

Notice that we’ve split the code into the hello_macro_derive function, which is responsible for parsing the TokenStream, and the impl_hello_macro function, which is responsible for transforming the syntax tree: this makes writing a procedural macro more convenient. The code in the outer function (hello_macro_derive in this case) will be the same for almost every procedural macro crate you see or create. The code you specify in the body of the inner function (impl_hello_macro in this case) will be different depending on your procedural macro’s purpose.

We’ve introduced three new crates: proc_macro, syn, and quote. The proc_macro crate comes with Rust, so we didn’t need to add that to the dependencies in Cargo.toml. The proc_macro crate is the compiler’s API that allows us to read and manipulate Rust code from our code.

The syn crate parses Rust code from a string into a data structure that we can perform operations on. The quote crate turns syn data structures back into Rust code. These crates make it much simpler to parse any sort of Rust code we might want to handle: writing a full parser for Rust code is no simple task.

The hello_macro_derive function will be called when a user of our library specifies #[derive(HelloMacro)] on a type. This is possible because we’ve annotated the hello_macro_derive function here with proc_macro_derive and specified the name, HelloMacro, which matches our trait name; this is the convention most procedural macros follow.

The hello_macro_derive function first converts the input from a TokenStream to a data structure that we can then interpret and perform operations on. This is where syn comes into play. The parse function in syn takes a TokenStream and returns a DeriveInput struct representing the parsed Rust code. Listing 19-32 shows the relevant parts of the DeriveInput struct we get from parsing the struct Pancakes; string:


DeriveInput {
    // --snip--

    ident: Ident {
        ident: "Pancakes",
        span: #0 bytes(95..103)
    data: Struct(
        DataStruct {
            struct_token: Struct,
            fields: Unit,
            semi_token: Some(

Listing 19-32: The DeriveInput instance we get when parsing the code that has the macro’s attribute in Listing 19-30

The fields of this struct show that the Rust code we’ve parsed is a unit struct with the ident (identifier, meaning the name) of Pancakes. There are more fields on this struct for describing all sorts of Rust code; check the syn documentation for DeriveInput for more information.

Soon we’ll define the impl_hello_macro function, which is where we’ll build the new Rust code we want to include. But before we do, note that the output for our derive macro is also a TokenStream. The returned TokenStream is added to the code that our crate users write, so when they compile their crate, they’ll get the extra functionality that we provide in the modified TokenStream.

You might have noticed that we’re calling unwrap to cause the hello_macro_derive function to panic if the call to the syn::parse function fails here. It’s necessary for our procedural macro to panic on errors because proc_macro_derive functions must return TokenStream rather than Result to conform to the procedural macro API. We’ve simplified this example by using unwrap; in production code, you should provide more specific error messages about what went wrong by using panic! or expect.

Now that we have the code to turn the annotated Rust code from a TokenStream into a DeriveInput instance, let’s generate the code that implements the HelloMacro trait on the annotated type, as shown in Listing 19-33.

Filename: hello_macro_derive/src/


fn impl_hello_macro(ast: &syn::DeriveInput) -> TokenStream {
    let name = &ast.ident;
    let gen = quote! {
        impl HelloMacro for #name {
            fn hello_macro() {
                println!("Hello, Macro! My name is {}!", stringify!(#name));

Listing 19-33: Implementing the HelloMacro trait using the parsed Rust code

We get an Ident struct instance containing the name (identifier) of the annotated type using ast.ident. The struct in Listing 19-32 shows that when we run the impl_hello_macro function on the code in Listing 19-30, the ident we get will have the ident field with a value of "Pancakes". Thus, the name variable in Listing 19-33 will contain an Ident struct instance that, when printed, will be the string "Pancakes", the name of the struct in Listing 19-30.

The quote! macro lets us define the Rust code that we want to return. The compiler expects something different to the direct result of the quote! macro’s execution, so we need to convert it to a TokenStream. We do this by calling the into method, which consumes this intermediate representation and returns a value of the required TokenStream type.

The quote! macro also provides some very cool templating mechanics: we can enter #name, and quote! will replace it with the value in the variable name. You can even do some repetition similar to the way regular macros work. Check out the quote crate’s docs for a thorough introduction.

We want our procedural macro to generate an implementation of our HelloMacro trait for the type the user annotated, which we can get by using #name. The trait implementation has one function, hello_macro, whose body contains the functionality we want to provide: printing Hello, Macro! My name is and then the name of the annotated type.

The stringify! macro used here is built into Rust. It takes a Rust expression, such as 1 + 2, and at compile time turns the expression into a string literal, such as "1 + 2". This is different than format! or println!, macros which evaluate the expression and then turn the result into a String. There is a possibility that the #name input might be an expression to print literally, so we use stringify!. Using stringify! also saves an allocation by converting #name to a string literal at compile time.

At this point, cargo build should complete successfully in both hello_macro and hello_macro_derive. Let’s hook up these crates to the code in Listing 19-30 to see the procedural macro in action! Create a new binary project in your projects directory using cargo new pancakes. We need to add hello_macro and hello_macro_derive as dependencies in the pancakes crate’s Cargo.toml. If you’re publishing your versions of hello_macro and hello_macro_derive to, they would be regular dependencies; if not, you can specify them as path dependencies as follows:


hello_macro = { path = "../hello_macro" }
hello_macro_derive = { path = "../hello_macro/hello_macro_derive" }

Put the code in Listing 19-30 into src/, and run cargo run: it should print Hello, Macro! My name is Pancakes! The implementation of the HelloMacro trait from the procedural macro was included without the pancakes crate needing to implement it; the #[derive(HelloMacro)] added the trait implementation.

Next, let’s explore how the other kinds of procedural macros differ from custom derive macros.

Attribute-like macros

Attribute-like macros are similar to custom derive macros, but instead of generating code for the derive attribute, they allow you to create new attributes. They’re also more flexible: derive only works for structs and enums; attributes can be applied to other items as well, such as functions. Here’s an example of using an attribute-like macro: say you have an attribute named route that annotates functions when using a web application framework:


#[route(GET, "/")]
fn index() {

This #[route] attribute would be defined by the framework as a procedural macro. The signature of the macro definition function would look like this:


pub fn route(attr: TokenStream, item: TokenStream) -> TokenStream {

Here, we have two parameters of type TokenStream. The first is for the contents of the attribute: the GET, "/" part. The second is the body of the item the attribute is attached to: in this case, fn index() {} and the rest of the function’s body.

Other than that, attribute-like macros work the same way as custom derive macros: you create a crate with the proc-macro crate type and implement a function that generates the code you want!

Function-like macros

Function-like macros define macros that look like function calls. Similarly to macro_rules! macros, they’re more flexible than functions; for example, they can take an unknown number of arguments. However, macro_rules! macros can be defined only using the match-like syntax we discussed in the section “Declarative Macros with macro_rules! for General Metaprogramming” earlier. Function-like macros take a TokenStream parameter and their definition manipulates that TokenStream using Rust code as the other two types of procedural macros do. An example of a function-like macro is an sql! macro that might be called like so:


let sql = sql!(SELECT * FROM posts WHERE id=1);

This macro would parse the SQL statement inside it and check that it’s syntactically correct, which is much more complex processing than a macro_rules! macro can do. The sql! macro would be defined like this:


pub fn sql(input: TokenStream) -> TokenStream {

This definition is similar to the custom derive macro’s signature: we receive the tokens that are inside the parentheses and return the code we wanted to generate.


Whew! Now you have some Rust features in your toolbox that you won’t use often, but you’ll know they’re available in very particular circumstances. We’ve introduced several complex topics so that when you encounter them in error message suggestions or in other peoples’ code, you’ll be able to recognize these concepts and syntax. Use this chapter as a reference to guide you to solutions.


The functionality and syntax of Rust can be extended with custom definitions called macros. They are given names, and invoked through a consistent syntax: some_extension!(...).

There are two ways to define new macros:

  • Macros by Example define new syntax in a higher-level, declarative way.
  • Procedural Macros define function-like macros, custom derives, and custom attributes using functions that operate on input tokens.

Macro Invocation

MacroInvocation :
   SimplePath ! DelimTokenTree
DelimTokenTree :
      ( TokenTree* )
   | [ TokenTree* ]
   | { TokenTree* }
TokenTree :
   Tokenexcept delimiters | DelimTokenTree
MacroInvocationSemi :
      SimplePath ! ( TokenTree* ) ;
   | SimplePath ! [ TokenTree* ] ;
   | SimplePath ! { TokenTree* }

A macro invocation expands a macro at compile time and replaces the invocation with the result of the macro. Macros may be invoked in the following situations:

When used as an item or a statement, the MacroInvocationSemi form is used where a semicolon is required at the end when not using curly braces. Visibility qualifiers are never allowed before a macro invocation or macro_rules definition.

// Used as an expression.
let x = vec![1,2,3];

// Used as a statement.

// Used in a pattern.
macro_rules! pat {
    ($i:ident) => (Some($i))

if let pat!(x) = Some(1) {
    assert_eq!(x, 1);

// Used in a type.
macro_rules! Tuple {
    { $A:ty, $B:ty } => { ($A, $B) };

type N2 = Tuple!(i32, i32);

// Used as an item.
thread_local!(static FOO: RefCell<u32> = RefCell::new(1));

// Used as an associated item.
macro_rules! const_maker {
    ($t:ty, $v:tt) => { const CONST: $t = $v; };
trait T {
    const_maker!{i32, 7}

// Macro calls within macros.
macro_rules! example {
    () => { println!("Macro call in a macro!") };
// Outer macro `example` is expanded, then inner macro `println` is expanded.

Macros By Example

MacroRulesDefinition :
   macro_rules ! IDENTIFIER MacroRulesDef
MacroRulesDef :
      ( MacroRules ) ;
   | [ MacroRules ] ;
   | { MacroRules }
MacroRules :
   MacroRule ( ; MacroRule )* ;?
MacroRule :
   MacroMatcher => MacroTranscriber
MacroMatcher :
      ( MacroMatch* )
   | [ MacroMatch* ]
   | { MacroMatch* }
MacroMatch :
      Tokenexcept $ and delimiters
   | MacroMatcher
   | $ IDENTIFIER : MacroFragSpec
   | $ ( MacroMatch+ ) MacroRepSep? MacroRepOp
MacroFragSpec :
      block | expr | ident | item | lifetime | literal
   | meta | pat | pat_param | path | stmt | tt | ty | vis
MacroRepSep :
   Tokenexcept delimiters and repetition operators
MacroRepOp :
   * | + | ?
MacroTranscriber :

macro_rules allows users to define syntax extension in a declarative way. We call such extensions "macros by example" or simply "macros".

Each macro by example has a name, and one or more rules. Each rule has two parts: a matcher, describing the syntax that it matches, and a transcriber, describing the syntax that will replace a successfully matched invocation. Both the matcher and the transcriber must be surrounded by delimiters. Macros can expand to expressions, statements, items (including traits, impls, and foreign items), types, or patterns.


When a macro is invoked, the macro expander looks up macro invocations by name, and tries each macro rule in turn. It transcribes the first successful match; if this results in an error, then future matches are not tried. When matching, no lookahead is performed; if the compiler cannot unambiguously determine how to parse the macro invocation one token at a time, then it is an error. In the following example, the compiler does not look ahead past the identifier to see if the following token is a ), even though that would allow it to parse the invocation unambiguously:

macro_rules! ambiguity {
    ($($i:ident)* $j:ident) => { };

ambiguity!(error); // Error: local ambiguity

In both the matcher and the transcriber, the $ token is used to invoke special behaviours from the macro engine (described below in Metavariables and Repetitions). Tokens that aren't part of such an invocation are matched and transcribed literally, with one exception. The exception is that the outer delimiters for the matcher will match any pair of delimiters. Thus, for instance, the matcher (()) will match {()} but not {{}}. The character $ cannot be matched or transcribed literally.

When forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type. The second macro can't use literal tokens to match the fragments in the matcher, only a fragment specifier of the same type. The ident, lifetime, and tt fragment types are an exception, and can be matched by literal tokens. The following illustrates this restriction:

macro_rules! foo {
    ($l:expr) => { bar!($l); }
// ERROR:               ^^ no rules expected this token in macro call

macro_rules! bar {
    (3) => {}


The following illustrates how tokens can be directly matched after matching a tt fragment:

// compiles OK
macro_rules! foo {
    ($l:tt) => { bar!($l); }

macro_rules! bar {
    (3) => {}



In the matcher, $ name : fragment-specifier matches a Rust syntax fragment of the kind specified and binds it to the metavariable $name. Valid fragment specifiers are:

In the transcriber, metavariables are referred to simply by $name, since the fragment kind is specified in the matcher. Metavariables are replaced with the syntax element that matched them. The keyword metavariable $crate can be used to refer to the current crate; see Hygiene below. Metavariables can be transcribed more than once or not at all.


In both the matcher and transcriber, repetitions are indicated by placing the tokens to be repeated inside $(), followed by a repetition operator, optionally with a separator token between. The separator token can be any token other than a delimiter or one of the repetition operators, but ; and , are the most common. For instance, $( $i:ident ),* represents any number of identifiers separated by commas. Nested repetitions are permitted.

The repetition operators are:

  • * — indicates any number of repetitions.
  • + — indicates any number but at least one.
  • ? — indicates an optional fragment with zero or one occurrences.

Since ? represents at most one occurrence, it cannot be used with a separator.

The repeated fragment both matches and transcribes to the specified number of the fragment, separated by the separator token. Metavariables are matched to every repetition of their corresponding fragment. For instance, the $( $i:ident ),* example above matches $i to all of the identifiers in the list.

During transcription, additional restrictions apply to repetitions so that the compiler knows how to expand them properly:

  1. A metavariable must appear in exactly the same number, kind, and nesting order of repetitions in the transcriber as it did in the matcher. So for the matcher $( $i:ident ),*, the transcribers => { $i }, => { $( $( $i)* )* }, and => { $( $i )+ } are all illegal, but => { $( $i );* } is correct and replaces a comma-separated list of identifiers with a semicolon-separated list.
  2. Each repetition in the transcriber must contain at least one metavariable to decide how many times to expand it. If multiple metavariables appear in the same repetition, they must be bound to the same number of fragments. For instance, ( $( $i:ident ),* ; $( $j:ident ),* ) => (( $( ($i,$j) ),* )) must bind the same number of $i fragments as $j fragments. This means that invoking the macro with (a, b, c; d, e, f) is legal and expands to ((a,d), (b,e), (c,f)), but (a, b, c; d, e) is illegal because it does not have the same number. This requirement applies to every layer of nested repetitions.

Scoping, Exporting, and Importing

For historical reasons, the scoping of macros by example does not work entirely like items. Macros have two forms of scope: textual scope, and path-based scope. Textual scope is based on the order that things appear in source files, or even across multiple files, and is the default scoping. It is explained further below. Path-based scope works exactly the same way that item scoping does. The scoping, exporting, and importing of macros is controlled largely by attributes.

When a macro is invoked by an unqualified identifier (not part of a multi-part path), it is first looked up in textual scoping. If this does not yield any results, then it is looked up in path-based scoping. If the macro's name is qualified with a path, then it is only looked up in path-based scoping.

use lazy_static::lazy_static; // Path-based import.

macro_rules! lazy_static { // Textual definition.
    (lazy) => {};

lazy_static!{lazy} // Textual lookup finds our macro first.
self::lazy_static!{} // Path-based lookup ignores our macro, finds imported one.

Textual Scope

Textual scope is based largely on the order that things appear in source files, and works similarly to the scope of local variables declared with let except it also applies at the module level. When macro_rules! is used to define a macro, the macro enters the scope after the definition (note that it can still be used recursively, since names are looked up from the invocation site), up until its surrounding scope, typically a module, is closed. This can enter child modules and even span across multiple files:

//// src/
mod has_macro {
    // m!{} // Error: m is not in scope.

    macro_rules! m {
        () => {};
    m!{} // OK: appears after declaration of m.

    mod uses_macro;

// m!{} // Error: m is not in scope.

//// src/has_macro/

m!{} // OK: appears after declaration of m in src/

It is not an error to define a macro multiple times; the most recent declaration will shadow the previous one unless it has gone out of scope.

macro_rules! m {
    (1) => {};


mod inner {

    macro_rules! m {
        (2) => {};
    // m!(1); // Error: no rule matches '1'

    macro_rules! m {
        (3) => {};


Macros can be declared and used locally inside functions as well, and work similarly:

fn foo() {
    // m!(); // Error: m is not in scope.
    macro_rules! m {
        () => {};

// m!(); // Error: m is not in scope.

The macro_use attribute

The macro_use attribute has two purposes. First, it can be used to make a module's macro scope not end when the module is closed, by applying it to a module:

mod inner {
    macro_rules! m {
        () => {};


Second, it can be used to import macros from another crate, by attaching it to an extern crate declaration appearing in the crate's root module. Macros imported this way are imported into the macro_use prelude, not textually, which means that they can be shadowed by any other name. While macros imported by #[macro_use] can be used before the import statement, in case of a conflict, the last macro imported wins. Optionally, a list of macros to import can be specified using the MetaListIdents syntax; this is not supported when #[macro_use] is applied to a module.

#[macro_use(lazy_static)] // Or #[macro_use] to import all macros.
extern crate lazy_static;

// self::lazy_static!{} // Error: lazy_static is not defined in `self`

Macros to be imported with #[macro_use] must be exported with #[macro_export], which is described below.

Path-Based Scope

By default, a macro has no path-based scope. However, if it has the #[macro_export] attribute, then it is declared in the crate root scope and can be referred to normally as such:

m!(); // OK: Path-based lookup finds m in the current module.

mod inner {

mod mac {
    macro_rules! m {
        () => {};

Macros labeled with #[macro_export] are always pub and can be referred to by other crates, either by path or by #[macro_use] as described above.


By default, all identifiers referred to in a macro are expanded as-is, and are looked up at the macro's invocation site. This can lead to issues if a macro refers to an item or macro which isn't in scope at the invocation site. To alleviate this, the $crate metavariable can be used at the start of a path to force lookup to occur inside the crate defining the macro.

//// Definitions in the `helper_macro` crate.
macro_rules! helped {
    // () => { helper!() } // This might lead to an error due to 'helper' not being in scope.
    () => { $crate::helper!() }

macro_rules! helper {
    () => { () }

//// Usage in another crate.
// Note that `helper_macro::helper` is not imported!
use helper_macro::helped;

fn unit() {

Note that, because $crate refers to the current crate, it must be used with a fully qualified module path when referring to non-macro items:

pub mod inner {
    macro_rules! call_foo {
        () => { $crate::inner::foo() };

    pub fn foo() {}

Additionally, even though $crate allows a macro to refer to items within its own crate when expanding, its use has no effect on visibility. An item or macro referred to must still be visible from the invocation site. In the following example, any attempt to invoke call_foo!() from outside its crate will fail because foo() is not public.

macro_rules! call_foo {
    () => { $crate::foo() };

fn foo() {}

Version & Edition Differences: Prior to Rust 1.30, $crate and local_inner_macros (below) were unsupported. They were added alongside path-based imports of macros (described above), to ensure that helper macros did not need to be manually imported by users of a macro-exporting crate. Crates written for earlier versions of Rust that use helper macros need to be modified to use $crate or local_inner_macros to work well with path-based imports.

When a macro is exported, the #[macro_export] attribute can have the local_inner_macros keyword added to automatically prefix all contained macro invocations with $crate::. This is intended primarily as a tool to migrate code written before $crate was added to the language to work with Rust 2018's path-based imports of macros. Its use is discouraged in new code.

macro_rules! helped {
    () => { helper!() } // Automatically converted to $crate::helper!().

macro_rules! helper {
    () => { () }

Follow-set Ambiguity Restrictions

The parser used by the macro system is reasonably powerful, but it is limited in order to prevent ambiguity in current or future versions of the language. In particular, in addition to the rule about ambiguous expansions, a nonterminal matched by a metavariable must be followed by a token which has been decided can be safely used after that kind of match.

As an example, a macro matcher like $i:expr [ , ] could in theory be accepted in Rust today, since [,] cannot be part of a legal expression and therefore the parse would always be unambiguous. However, because [ can start trailing expressions, [ is not a character which can safely be ruled out as coming after an expression. If [,] were accepted in a later version of Rust, this matcher would become ambiguous or would misparse, breaking working code. Matchers like $i:expr, or $i:expr; would be legal, however, because , and ; are legal expression separators. The specific rules are:

  • expr and stmt may only be followed by one of: =>, ,, or ;.
  • pat and pat_param may only be followed by one of: =>, ,, =, |, if, or in.
  • path and ty may only be followed by one of: =>, ,, =, |, ;, :, >, >>, [, {, as, where, or a macro variable of block fragment specifier.
  • vis may only be followed by one of: ,, an identifier other than a non-raw priv, any token that can begin a type, or a metavariable with a ident, ty, or path fragment specifier.
  • All other fragment specifiers have no restrictions.

When repetitions are involved, then the rules apply to every possible number of expansions, taking separators into account. This means:

  • If the repetition includes a separator, that separator must be able to follow the contents of the repetition.
  • If the repetition can repeat multiple times (* or +), then the contents must be able to follow themselves.
  • The contents of the repetition must be able to follow whatever comes before, and whatever comes after must be able to follow the contents of the repetition.
  • If the repetition can match zero times (* or ?), then whatever comes after must be able to follow whatever comes before.

#rust #programming #developer 

Inside ABCD, A Dataset To Build In-Depth Task-Oriented Dialogue Systems

According to a recent study, call centre agents’ spend approximately 82 percent of their total time looking at step-by-step guides, customer data, and knowledge base articles.

Traditionally, dialogue state tracking (DST) has served as a way to determine what a caller wants at a given point in a conversation. Unfortunately, these aspects are not accounted for in popular DST benchmarks. DST is the core part of a spoken dialogue system. It estimates the beliefs of possible user’s goals at every dialogue turn.

To reduce the burden on call centre agents and improve the SOTA of task-oriented dialogue systems, AI-powered customer service company ASAPP recently launched an action-based conversations dataset (ABCD). The dataset is designed to help develop task-oriented dialogue systems for customer service applications. ABCD consists of a fully labelled dataset with over 10,000 human dialogues containing 55 distinct user intents requiring sequences of actions constrained by company policies to accomplish tasks.

The dataset is currently available on GitHub.

#developers corner #asapp abcd dataset #asapp new dataset #build enterprise chatbot #chatbot datasets latest #customer support datasets #customer support model training #dataset for chatbots #dataset for customer datasets

vinay bajrangi


Why We Need To Match Kundli Before Marriage?

When a date is set for marriage between two individuals, perhaps the first thing that the two families do is go for kundli matching by date of birth. Considered one of the most significant and foremost aspects of an arranged Indian marriage, matching Kundli or horoscopes is necessary before two people decide to get hitched, whether they are having a love or arranged marriage. Since matching kundlis can help you to know about any impending problems that await you on the other side of your marriage, experienced astrologers like Dr. Vinay Bajrangi always advise their clients to match horoscopes before marriage to avoid any major mishaps in the future.
Some of the reasons why astrologers recommend using a horoscope match calculator for marriage are as follows –
Compatibility - Kundli matching is important to ascertain compatibility between two individuals in terms of their mental and physical conditions, including mindset, temper, attitude and behaviour. It is considered the basic premise for a successful union. In order to assess that there is a sufficient amount of mutual desirability between the couple, the horoscopes are also analysed for physical attraction, because that is an important tool for a long-lasting relationship.
Finances/Career - Kundli matching is also a way to know about the future prospects of your spouse like career growth, business progress, promotion, financial stability, etc.
Dashas - Sometimes, the negative impact of Dashas (planetary combinations) can ruin your future as a married couple. There is a chance that a person’s horoscope could have Dashas like the ‘Mangal Dasha’ and ‘Shani Dasha’ right since the time they are born, depending upon the stars and the planets’ positions at that time. Such Dashas can create several problems at a later stage of marriage, about which none of the partners can do anything. The process of Kundli matching can help you overcome the negative impact before taking the step towards the marriage altar.
Health – Kundli matching helps you find out about the health prospects of your children, who would be born later in your life. The 8th guna of your Kundli, Nadi, represents childbirth and potential problems that might arise out of it. Therefore, Kundli matching is significant not just for yourself but also for the future generations to come.
Love Marriage – In case of love marriages, matching kundlis or using a horoscope match calculator for marriage is equally important as it helps the couple take care of any possible negative impacts awaiting them in the future. Matching of horoscopes is a sure-shot way to resolve any impending problems for a married couple.

Astrological Combinations for Healthy Marriage

The compatibility of partners as well as their health and finances are all necessary points that should be taken care of before finalizing a match. Birth charts of the two individuals provide all the answers, provided you consult a highly experienced astrologer for the same. In case of malefic effects of the planets, your married life might feel hindrance, which can be avoided with the help of some specific astrological combinations, as given below –

• Mercury and Venus are the two most significant planets in an individual’s horoscope.
• Manglik Yoga, one of the most malefic yogas, is formed in a person’s birth-chart when Mars is in the 1st, 4th, 7th, 8th or the 12th house. This yoga can be nullified only when two persons with similar yoga get married.
• Saturn and Rahu are two other planets that hold great significance in a person’s kundli with respect to his or her marriage prospects.
• When the moon is in the 2nd house of the Venus, it is considered to be highly inauspicious for the bride’s life span.
• The lifespan of both the groom and the bride is similar when the kundli shows a connection between planets Mercury and Venus.
• A groom’s life is at risk when Mercury aspects planets Sun and Rahu. Same is the case when Venus aspects planets Sun, Moon and Rahu.
• An individual whose kundli shows Jupiter aspected by Venus or Rahu aspected by Sun and Moon can expect more than one marriage in their life.

Marriage is a holy union guided by planets and houses in your birth-chart, as well as by a multitude of astrological combinations. Talk to an ace astrologer like Dr. Vinay Bajrangi to know more about kundali matching and its various aspects. What you must understand is that avoiding kundli matching before love or arranged union could keep you unaware of the vagaries of married life, if any. An individual’s nature as well as future is predicted through their kundli and it helps to seek help from a knowledgeable astrologer before making final decision about marriage. Meanwhile, if you want to have your doubts and queries addressed as per the Vedic Astrology, you can connect with Dr. Bajrangi on or on phone - +91 9278665588 / 9278555588.

#kundli matching by date of birth #horoscope match calculator for marriage #free kundli matching #horoscope matching for marriage #free horoscope matching by name

What is MATCH (MATCH) | What is MATCH token | MATCH (MATCH) ICO

What is MATCH Token?

MATCH token is a utility token for the De-Fi and Decentralized Bet (De-Bet) platforms. MATCH token is developed by a group of people who want to share the equal great opportunity to the holders through a decentralized network. MATCH token leverages the decentralized (blockchain) network because it offers more greatness compared to a centralized network. They believe as a token, it can be nurtured to become a priceless token to the holders while at the same time to be used on an application that provides secure and transparent transactions on top of a smart contract designed to get all involved persons to have the same opportunities to grow their accounts actively and passively on an ecosystem

Where MATCH token is deployed and why?

MATCH token is running on top of the TRON network which is one of the largest blockchain-based operating systems in the world. The token leverages the TRON network because it offers high-throughout, high-availability, and high-scalability. Supported by 1,332 nodes across the globe, TRON can support MATCH tokens in rendering a swift transaction time with the lowest fees compared to other smart contract networks, whereas pace is one of the nowadays application requirements. TRON TPS has exceeded the TPS of Bitcoin and Ethereum, which is one of our main reasons for selecting TRON as our main blockchain network.

Can MATCH token’s value steady and tend to be increased?

MATCH token team’s vision is to grow the token’s value by using it actively and passively in an ecosystem. Thus, the value of the token can be maintained and tend to be increased over time. This vision can be gained through De-Fi and Decentralized Bet (De-Bet) platforms.

How does the MATCH token apply De-Fi in the ecosystem?

The other proven way that can be used to grow the holders’ account passively is through a liquidity stake as part of Decentralized Finance running on top of blockchain systems to apply the Automatic Market Makers (AMM) principle. The token holders can become Liquidity Providers that could earn Swap Fee and MATCH tokens through mining based on existing APY (Annual Percentage Yield). As a Liquidity Provider, you are eligible to earn a portion of fees from the Liquidity Pool as much as 0.3% from each swap activity performed in the platform with respect to pool shares. By staking your token in the Liquidity Pool, you can be eligible to yield a MATCH token based on the current APY. The transparent calculation is performed in the background systematically without any human interference and purely mathematical logarithm and financial investment fusion.

What is Decentralized Bet (De-Bet)?

MATCH token is a token that can only be used actively on a decentralized application (DApp) named De-Bet which is a transparent and trusted sports betting. Moreover, De-Bet is the first decentralized betting for sports in the TRON network. De-Bet focuses on User Experience and the Smart Contract technology that can help Makers and Takers to play their own roles without any human’s interference, in order to get another uplifted level of amusement in the betting arena with the benefit of Blockchain technology. De-Bet will be delivered in two phases: (1) Decentralized Betting Smart Contract and (2) Decentralized Betting for other Providers in Smart Contract. For detailed information on improvement and process flow can be found in our whitepaper (link).

How can I participate in MATCH token development?

MATCH token team will initiate ICO (Initial Currency Offering) through Private Sale and Pre-Sale events.

When is the MATCH Token Private Sale started?

The Private Sale will be opened on 6-13 Dec 2020 for limited investors. Throughout this Private Sales, we expect to gain 1,250,000 MATCH tokens with 5 TRX for each MATCH token. Be the first holder of MATCH Token! By joining this private sale you will have the opportunity to get MATCH tokens at 50% of the market price.

  • Private Sale price: 5 TRX
  • Minimum contribution: 500 TRX
  • Normal price: 10 TRXQ



When is the MATCH Token Pre-Sale started?

There will be a Pre-Sale on 20 - 27 December 2020 which will be opened to the public for enthusiastic investors. From this Pre-Sale, we expect to acquire 5,000,000 MATCH tokens with 6 TRX for each MATCH token. By joining this pre-sale you will have the opportunity to get MATCH tokens at 60% of the market price.

  • Private Sale price: 6 TRX
  • Minimum contribution: 500 TRX
  • Normal price: 10 TRX

How do I get MATCH tokens during the Sale event?

It is very simple. What you need to do is have TRX in your wallet and you can just click the “Buy MATCH token" link on our site.

Can you recommend a digital wallet?

Most people are using the TRON Link wallet. Disclaimer: The MATCH team does not endorse, recommend, or make any representations with respect to digital wallets. It’s advisable to always conduct your own due diligence before trusting any third party or third-party technology.

How can I get a MATCH token after the Sale event?

You will be able to trade MATCH once MATCH listed in which we aim to be listed in January 2021. Disclaimer: Please note that the MATCH team does not endorse, recommend, or make any representations with respect to Internet lists or exchanges more generally. Every exchange has a different process for trading MATCH tokens and their customer support and policies and practices may vary widely. It’s advisable to conduct your own due diligence before trusting any third party or third-party technology.

Can I get an airdrop from MATCH Token?

MATCH will announce the airdrop the very first time we launch our product, and the airdrop itself will be dropped in Q1 2021. Make sure you will not miss this opportunity, follow our community channel to keep yourself updated

Instagram :

ICO DATE: Dec 6, 2020 - Dec 27, 2020

Private Sale: Dec 6 — Dec 13, 2020

Private Sale price: 5 TRX (50% Discount from the public sale price)

Pre-Sale: Dec 20 — Dec 27, 2020

Private Sale price: 6 TRX (40% Discount from the public sale price)

Would you like to earn many tokens and cryptocurrencies right now! ☞ CLICK HERE

Looking for more information…

☞ Website
☞ Explorer
☞ Whitepaper

Create an Account and Trade Cryptocurrency NOW


Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #crypto #match #match token

Skyla  Feeney

Skyla Feeney


Fuzzy Name Matching Datasets

You are given a few datasets from a client who wants to match entities between multiple disparate datasets. Your target variable are the entities, and your features could be the entity’s address, Country, Zipcode, Vendor ID, etc.

All of these features definitely help you with your search for the same entities, but the only problem is that the client gave you a dataset with a lot of missing values for each of those useful columns that could significantly aid you in your search.

#python #data-science #matching