lreplace - Replace elements in a list with new elements
lreplace list first last ?element element ...?
lreplace returns a new list formed by replacing one or more elements of
list with the element arguments.
first and last specify the first and last index of the
range of elements to replace. 0 refers to the first element of the
list, and end (or any abbreviation of it) may be used to refer
to the last element of the list. If list is empty, then
first and last are ignored.
If first is less than zero, it is considered to refer to the
first element of the list. For non-empty lists, the element indicated
by first must exist.
If last is less than zero but greater than first, then any
specified elements will be prepended to the list. If last is
less than first then no elements are deleted; the new elements
are simply inserted before first.
The element arguments specify zero or more new arguments to
be added to the list in place of those that were deleted.
Each element argument will become a separate element of
the list. If no element arguments are specified, then the elements
between first and last are simply deleted. If list
is empty, any element arguments are added to the end of the list.
Replacing an element of a list with another:
% lreplace {a b c d e} 1 1 foo
a foo c d e
Replacing two elements of a list with three:
% lreplace {a b c d e} 1 2 three more elements
a three more elements d e
Deleting the last element from a list in a variable:
% set var {a b c d e}
a b c d e
% set var [lreplace $var end end]
a b c d
list, lappend, lindex, linsert, llength, lsearch, lset, lrange, lsort
element, list, replace
Copyright © 1993 The Regents of the University of California.
Copyright © 1994-1996 Sun Microsystems, Inc.
Copyright © 2001 Kevin B. Kenny. All rights reserved.
Copyright © 1995-1997 Roger E. Critchlow Jr.


AFRIMA 2019: Burna Boy wins African artiste of the year (Video)
by Damilola IsmailBurna Boy has won the African Artiste of the year at the 6th AFRIMA which held at Eko Hotel and Suites in Lagos on Saturday.
Burna Boy is indeed the rave of the moment with his Grammy nomination announced earlier this week, he has now been crowned the AFRIMA African artiste of the year and Best Male artiste in West Africa
Although the 2019 All Africa Music Awards (AFRIMA) was held in Lagos, Nigeria on Saturday, Burna Boy and several other Nigerian artistes who won different categories were absent but represented by their managers unlike award winners from other regions of Africa who were in attendance.
Watch the moment Burna Boy was announced the winner below.
This year’s show was attended by Nigeria’s Minister of Information and Culture, Lai Mohammed.
Wizkid also won song of the year in Africa, with his song ‘Fever’, while Tiwa Savage won Best Female Artiste in Western Africa.
Congratulation to all the award winners.
Follow us on Facebook – @Lailasnews; Twitter – @LailaIjeoma for updates


|
Do you want to start a new session?
|
Do you have a session ID from someone you want to put in?
|
|
Beginner 1 hour |
Demo |
||
|
Beginner 2 hours |
Arithmetic |
||
|
Intermediate 2 hours |
Roman Numeral ConversionString Manipulation and Values |
||
|
Intermediate 2 hours |
Parsing JSON and objectsStudent Database |
||
|
Advanced 2 hours |
Time and Dates |
||
|
Advanced 2 hours |
Encryption |
Join a session shared by others. The session id should be a nineteen alphanumeric code.
Anything in your current session will stay in that session, but anything new will be in your joined session.
Create a New Session or Join a Session first to get session information.
Send your friend to http://codehort.appspot.com to download codehort, and then tell them to use that secret code to join you.
|
|
|
codehort.log


In charge of the camera vision, quadtrees/octrees culling and viewports. Hierarchy management of gameobjects. Console logs and visual debuging (AABB, OBB). UI Canvas, UI text and image rendering
In control of own file format, inspector properties, reference counting and resource management. In-editor assets browser and panel layout. Editor styling. UI Managment and structure
Copyright 2019 Oscar Pons and David Tello
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Use '[:lower:]' to support accents and foreign alphabets.
PLATFORM="$(uname -s | tr 'A-Z' 'a-z')"
PLATFORM="$(uname -s | tr '[:upper:]' '[:lower:]')"
A-Z
and a-z
are commonly intended to mean "all uppercase" and "all lowercase letters" respectively. This ignores accented characters in English, and foreign characters in other languages:
$ tr 'a-z' 'A-Z' <<< "My fiancée ordered a piña colada."
MY FIANCéE ORDERED A PIñA COLADA.
Instead, you can use [:lower:]
and [:upper:]
to explicitly specify case:
$ tr '[:lower:]' '[:upper:]' <<< "My fiancée ordered a piña colada."
MY FIANCÉE ORDERED A PIÑA COLADA.
If you don't want a-z
to match é
or A-Z
to match Ñ
, you can ignore this message.
As of 2019-09-08, BusyBox tr
does not support character classes, so you would have to ignore this message.
Note that the examples used here are multibyte characters in UTF-8. Many implementations (including GNU) fails to deal with them.


First Steps: Setting Up Your Environment
Once you’ve downloaded Puppet Enterprise, completed installation, and verified that all the parts are talking to each other, there are a few things you’ll want to do to set up your working environment.
Puppet’s manifests, as well as any modules, ENC’s, etc. you are writing or modifying, should be treated like any other code under development, which is to say they should be version controlled, tested prior to release, and backed up frequently. Below we’ll give you some suggestions for getting that done.
Version Control
Typically, a Puppet site consists of:
- A collection of modules, which contain classes that manage chunks of system functionality.
- A central manifest (typically,
site.pp
), which assigns classes from modules to the nodes at the site. - The PE console, which also assigns classes from modules to nodes. This overlaps with
site.pp
; the preferences of your site’s staff should guide you when choosing which to use. - Hierarchical data in Hiera, which can be used by module classes when they’re assigned to a node.
All of these (except the console) should be edited in version control and then deliberately deployed to the puppet master. Editing your manifests and data “live,” directly on the puppet master, is a dangerous habit. You can lose functioning code or, worse, your half-written manifest could get published to your agent nodes prematurely. To avoid this, we strongly recommend you use a version control system such as Git or Subversion to control development of your manifests. Generally speaking, we recommend Git and GitHub, but really any version control system will work.
Git Resources
A course in using Git is well beyond the scope of this guide, but there are many online tutorials, guides and other resources. Some of our favorites are: Pro Git, Git+Immersion and the tutorials on GitHub. If you prefer video, the author of Pro Git, Scott Chacon, has an excellent presentation. There are also some applications that wrap Git in a GUI (e.g., GitX) if you feel more comfortable working that way. The Git site has links to GUI tools for various platforms as well as tons of information on how to set up and use the tool.
Git Workflows and Your Infrastructure
While there are many ways to map Git workflows to infrastructure, one of the most popular patterns is to set up Git branches to map to puppet environments. For example, you can set up Git branches to correspond to the development, testing, and production environments favored by many companies’ workflows. You can even set things up to create environments dynamically as workflows change. For a detailed discussion and examples of this, refer to this blog post on git workflows and puppet environments.
If you are already familiar with Git and have some workflows and branch structures in place already, you can probably just bring your Puppet manifests into your usual controls. There’s no need to reinvent the wheel. If you’re setting up version control for the first time, and the above example using environments is too involved, there is a good overview of a fairly basic Puppet/Git workflow available here. Please note that the paths in this example refer to open source Puppet - modules in Puppet Enterprise are located in /etc/puppetlabs/puppet/modules
.
Testing
There are several resources you can turn to in order to test your manifests and modules. At this stage of the game, we don’t mean testing in the formal sense of unit tests, CI tests, etc. We simply mean making reality checks to make sure things are working in the way you want. So, first you’ll want to pick out the nodes you’re going to automate initially. Generally speaking, when you start to deploy PE, you’ll want to begin with low-risk nodes that are not mission critical. There are few approaches you can take in selecting nodes.
-
One approach is to select a sub-set of nodes in, say, your development pool (as opposed to production servers). Identify configurations and services those nodes have in common and automate those things one by one.
-
Another approach is to spin up a new machine that is a generic version of some group of servers in your infrastructure (again, choose things at first that aren’t mission critical). Gradually automate more and more of its configuration, checking as you go that it is working correctly. Gradually automate the configuration of services and applications, migrating data from existing servers as needed. Once you’re satisfied everything is working correctly, you can cut over to the newly automated machine and go live with it. You can use some (or all) of the classes, manifests and modules you used for this machine as the groundwork for automating other categories of nodes.
-
A third approach can actually let you get two things done. If you’re like most sysadmins, you have a backlog of things people have asked you for that are not for essential purposes. For example, a team has asked you for a server to test some new tool on, or to try out some new database/application/file server. Build up this server using PE.
This guide will give you some basic ideas for simple smoke testing of manifests and modules. Below we’ll briefly list a few tools and resources which can help you further test your PE implementation. For a more in-depth discussion, take a look at this blog post on syntax checking and automated testing.
However, all of that said, when you are first deploying Puppet, your best bet is to rely heavily on modules you can get from the Puppet Forge. Forge modules, especially those from frequent contributors or “Modules of the Week”, are proven solutions for the most common things sysadmins need to automate and they can save you a ton of time.
Noop
Don’t overlook the power of the --noop
flag. Noop lets you do a dry run of Puppet without actually doing anything. Instead, noop will sniff out catalog compilation errors and give you log output that shows what Puppet would have done to what, when. To run in noop mode, add the --noop
flag when running puppet agent
or puppet apply
. You will see the results of your run in the Console and in stdout.
Puppet Parser
Puppet parser is another simple tool that lets you check the syntax of Puppet code. You can run it manually to check a given file, for example, puppet parser validate site.pp
. This will check the manifest file for correct syntax and will return errors showing which line(s), if any, contain syntax errors such as missing curly braces or other typos and mistakes. You can also integrate syntax checking into your text editor, as explained in the previously referenced blog post.
Puppet-lint
Puppet lint is an easy to use style checker that runs through your manifests to ensure that they conform to Puppet Labs’s style guide. This standard is meant for developing reusable public code and may be more strict than you need, but much of it is good sense everywhere, and checking against it can guard you from many common mistakes. It’s available as a ruby gem. Install it by running $ gem install puppet-lint
. You can learn more about puppet-lint from this blog post.
Pre/Post Commit Hooks
Tools like Git or Subversion have hooks that allow you to run scripts before or after a commit. At minimum, you can use pre/post commit hooks to run puppet parser or puppet-lint automatically, but you will surely think of many more useful tests and other things to do with them. The Git site has good information to help get you started.
rspec-puppet
Writing tests with rspec is probably beyond the scope of this guide and not something you’ll want to tackle when you are first deploying PE. However, we mention it here so that when you move on to writing more complex manifests and/or your own modules you’re aware of the tool and what it can do to help you write the best puppet code you can. If you’re curious now, we recommend this tutorial to get you started.
Backing Up
We really don’t need to explain how or why you should back up your manifests and other files, but we will gently remind you to back up your SSL certificates along with everything else. In PE, SSL certificates exist under the /etc/puppetlabs/puppet/ssl
directory.
Organizing Your Users
Access to modules and manifests is controlled by your version control system and code deployment processes. Access to the PE console is controlled by its own system of users and permissions.
Figure out who at your institution should have access to PE and with what privileges. You can add and define users manually in the console, or you can access an existing directory via LDAP, etc. For more information, see the PE manual page on user management. Initially, you will probably want to limit access to a select group, possibly a group of one.
Ad Hoc Change Tools
You’ll want to have some kind of fall-back plan and tools for worst-case scenarios where something prevents you from controlling a machine with Puppet. In most cases, this simply means ensuring that you do nothing that would prevent you from SSHing into a given node and manually fixing whatever went wrong (e.g. with a DNS entry, a certificate, a root password, etc.). In addition to SSH, tools you might consider for this role include vintage things like Expect, Rsync, or even Telnet/FTP. As your skills with PE grow, you’ll be able to consign these tools to the ashbin of history, but for worst case scenarios, just keep them in mind.


---
layout: default
title: PgBouncer - lightweight connection pooler for PostgreSQL
---
{% for post in paginator.posts %}
{% if site.comments == true and post.comments == true and site.disqus != '' %}
Comments
{% endif %}
{{ post.excerpt }}
{% endfor %}


|
Erich von DänikenErich von Däniken believes that ancient alien astronauts visited Earth many millennia ago, in order to carry out a mission of extreme galactic importance -- building pyramids out of mud and rock. Däniken is so convinced of the truth of this statement that he has distorted real evidence and manufactured fraudulent evidence to support his claims. Because, you see, it's very important that you believe him. Important for humanity.There are few characters as weird as Däniken in the history of fake science. His career started when he dropped out of pre-junior-seminary school. This was a wise move on his part, since the Vatican tends to frown on heresy. A junior-junior-seminary school dropout in his native Switzerland, Däniken realized he wasn't cut out for the priesthood around the time that he decided the Bible's many descriptions of angels and other heavenly manifestations were actually historical records of UFO landings. von Däniken wandered the world in search of archaeological evidence that could be construed as evidence of extraterrestrial visitation -- by a sufficiently motivated observer. All this research led to the publication of his first book, Chariots of the Gods? Unsolved Mysteries of the Past, in 1967. von Däniken's early wanderings were underwritten by the Swiss hotel where he worked as a young man. Unfortunately, he hadn't bothered to inform the hotel it was underwriting his book, and management didn't take kindly to it when they found out, or so the story goes. The same year that Chariots of the Gods? hit the bookstands, Däniken was convicted of fraud and embezzlement and sentenced to more than three years in prison. (von Däniken claims the charges were "rubbish" and were later overturned.) While Däniken enjoyed a sabbatical penning his follow-up book in the Swiss prison system, Chariots of the Gods? was levitating its way up the bestseller lists, possibly through the use of alien electromagnetic antigravity technology. One year earlier, Time Magazine had famously proposed that God was dead. In the wake of that obituary, Däniken offered up a pseudoscientific explanation to fill the void. It didn't hurt that the UFO craze had shifted into high gear a few years earlier, after a wave of sightings and the infamous tale of Barney and Betty Hill, who claimed to have been abducted by aliens in New Hampshire in 1961. von Däniken's work tapped into a developing global zeitgeist in which radical ideas beat at the doors of academia. Unfortunately, Däniken differed from many of these radical thinkers in some key respects -- including logic and honesty. His main points can be summarized thusly:
You would think that a book based on blatant and admitted lies would quietly vanish from the bestseller lists in shame. But that's the sort of wrongheaded notion that belongs to a rational and just world. In the real world where we actually live, Däniken shrugged off the fraud as a momentary inconvenience. Today, there are something like 65 million copies of Däniken's various tomes in circulation worldwide. But that's just the tip of the merchandising iceberg. There are also the movies, the TV specials (aired with tedious predictability on The Learning Channel during sweeps) and, of course, the theme park. Yes, theme park. As Däniken approached his 70s, he realized his legacy to the world was incomplete. He rustled up about $70 million or $80 million in funding to build a lasting monument to his wacky theories. Mystery Park contains reproductions of the Egyptian pyramids, the Mayan pyramids and Stonehenge -- all no doubt meticulously accurate in their depiction of ancient astronauts. Conveniently located in the Swiss Alps, the theme park has been a surprising success. For just $38 dollars a head, tourists can see fake artifacts just like the fakes that got the whole ball rolling in Chariots of the Gods? in the first place. And really, what were you going to do with that $38 anyway, buy a gallon of gas? Like it or not, and many people don't, Erich von Däniken and his ideas are probably with us to stay. Although Däniken himself is a dodgy character, the idea of ancient astronauts has a wide appeal among the same people who gravitate toward Scientology (which also preaches of ancient astronauts). This demographic includes fairly bright people who have become disenchanted with religion but still want to believe in something -- anything! PLEASE! Däniken and his ilk paint a whisper of pseudoscience on top of the same old Biblical stories, giving them a fresh gloss for a new generation. After all, it's a pretty fine distinction between a belief in mysterious, wise, caring extraterrestrials and a mysterious, wise, caring God. Needless to say, there are many other options for the discriminating consumer of metaphysical weirdness. But none of the alternatives have their own theme park. Well, almost none. In between his pottery-forging projects and meetings of the amusement park board, the 70-year-old Däniken continues to find time to write on an astonishing array of topics, such as Gods from Outer Space, The Gold of the Gods, In Search of Ancient Gods, Miracles of the Gods, Signs of the Gods?, Pathways to the Gods, The Gods and Their Grand Design, I Love the Whole World, , The Day at the Gods Came, We All Are Children of the Gods, The Return of the Gods, The Arrival of the Gods, Odyssey of the Gods and The Gods Were Astronauts. What a Renaissance man!
|


About Me
Hello
I’ m Michlle, a Frontend developer based in New Zealand.
Education
01.
Graphic Design
Sichuan Sifan University / China
2006-2010
02.
Web Interactive
Media Design School / New Zealand
2016
About Me
I’ m Michlle, a Frontend developer based in New Zealand.
Sichuan Sifan University / China
2006-2010
Media Design School / New Zealand
2016


Elixir v1.3.4 Kernel
Provides the default macros and functions Elixir imports into your environment.
These macros and functions can be skipped or cherry-picked via the
import/2
macro. For instance, if you want to tell Elixir not to
import the if/2
macro, you can do:
import Kernel, except: [if: 2]
Elixir also has special forms that are always imported and
cannot be skipped. These are described in Kernel.SpecialForms
.
Some of the functions described in this module are inlined by
the Elixir compiler into their Erlang counterparts in the :erlang
module. Those functions are called BIFs (builtin internal functions)
in Erlang-land and they exhibit interesting properties, as some of
them are allowed in guards and others are used for compiler
optimizations.
Most of the inlined functions can be seen in effect when capturing the function:
iex> &Kernel.is_atom/1
&:erlang.is_atom/1
Those functions will be explicitly marked in their docs as “inlined by the compiler”.
Summary
Functions
Returns true
if the two items are not equal
Returns true
if the two items do not match
Arithmetic multiplication
Arithmetic unary plus
Arithmetic addition
Concatenates two lists
Arithmetic unary minus
Arithmetic subtraction
Removes the first occurrence of an item on the left list for each item on the right
Arithmetic division
Returns true
if left is less than right
Returns true
if left is less than or equal to right
Returns true
if the two items are equal
Returns true
if the two items are match
Matches the term on the left against the regular expression or string on the
right. Returns true
if left
matches right
(if it’s a regular expression)
or contains right
(if it’s a string)
Returns true
if left is more than right
Returns true
if left is more than or equal to right
Returns an integer or float which is the arithmetical absolute value of number
Invokes the given fun
with the list of arguments args
Invokes the given fun
from module
with the list of arguments args
Extracts the part of the binary starting at start
with length length
.
Binaries are zero-indexed
Returns an integer which is the size in bits of bitstring
Returns the number of bytes needed to contain bitstring
Performs an integer division
Gets the element at the zero-based index
in tuple
Stops the execution of the calling process with the given reason
Returns true
if module
is loaded and contains a
public function
with the given arity
, otherwise false
Gets a value and updates a nested structure
Gets a value from a nested structure
Returns the head of a list; raises ArgumentError
if the list is empty
Inspects the given argument according to the Inspect
protocol.
The second argument is a keyword list with options to control
inspection
Returns true
if term
is an atom; otherwise returns false
Returns true
if term
is a binary; otherwise returns false
Returns true
if term
is a bitstring (including a binary); otherwise returns false
Returns true
if term
is either the atom true
or the atom false
(i.e.,
a boolean); otherwise returns false
Returns true
if term
is a floating point number; otherwise returns false
Returns true
if term
is a function; otherwise returns false
Returns true
if term
is a function that can be applied with arity
number of arguments;
otherwise returns false
Returns true
if term
is an integer; otherwise returns false
Returns true
if term
is a list with zero or more elements; otherwise returns false
Returns true
if term
is a map; otherwise returns false
Returns true
if term
is either an integer or a floating point number;
otherwise returns false
Returns true
if term
is a pid (process identifier); otherwise returns false
Returns true
if term
is a port identifier; otherwise returns false
Returns true
if term
is a reference; otherwise returns false
Returns true
if term
is a tuple; otherwise returns false
Returns the length of list
Returns true
if module
is loaded and contains a
public macro
with the given arity
, otherwise false
Returns an almost unique reference
Returns the size of a map
Returns the biggest of the two given terms according to Erlang’s term ordering. If the terms compare equal, the first one is returned
Returns the smallest of the two given terms according to Erlang’s term ordering. If the terms compare equal, the first one is returned
Returns an atom representing the name of the local node.
If the node is not alive, :nonode@nohost
is returned instead
Returns the node where the given argument is located.
The argument can be a pid, a reference, or a port.
If the local node is not alive, :nonode@nohost
is returned
Boolean not
Pops a key from the given nested structure
Inserts value
at the given zero-based index
in tuple
Puts a value in a nested structure
Computes the remainder of an integer division
Rounds a number to the nearest integer
Returns the pid (process identifier) of the calling process
Sends a message to the given dest
and returns the message
Spawns the given function and returns its pid
Spawns the given module and function passing the given args and returns its pid
Spawns the given function, links it to the current process and returns its pid
Spawns the given module and function passing the given args, links it to the current process and returns its pid
Spawns the given function, monitors it and returns its pid and monitoring reference
Spawns the given module and function passing the given args, monitors it and returns its pid and monitoring reference
Creates and updates structs
Similar to struct/2
but checks for key validity
A non-local return from a function. Check Kernel.SpecialForms.try/1
for more information
Returns the tail of a list. Raises ArgumentError
if the list is empty
Returns the integer part of number
Returns the size of a tuple
Updates a key in a nested structure
Macros
Boolean not
Provides a short-circuit operator that evaluates and returns
the second expression only if the first one evaluates to true
(i.e., it is neither nil
nor false
). Returns the first expression
otherwise
Returns a range with the specified start and end
Concatenates two binaries
Reads and writes attributes of the current module
When used inside quoting, marks that the given alias should not be hygienized. This means the alias will be expanded when the macro is expanded
Boolean and
Returns the binding for the given context as a keyword list
Defines a function with the given name and body
Defines a function that delegates to another module
Defines an exception
Defines an implementation for the given protocol
Defines a macro with the given name and body
Defines a private macro with the given name and body
Defines a module given by name with the given contents
Makes the given functions in the current module overridable
Defines a private function with the given name and body
Defines a protocol
Defines a struct
Destructures two lists, assigning each term in the right one to the matching term in the left one
Gets a value and updates a nested data structure via the given path
Provides an if/2
macro
Checks if the element on the left-hand side is a member of the collection on the right-hand side
Returns true
if term
is nil
, false
otherwise
A convenience macro that checks if the right side (an expression) matches the left side (a pattern)
Boolean or
Pops a key from the nested structure via the given path
Puts a value in a nested structure via the given path
Raises an exception
Raises an exception
Raises an exception preserving a previous stacktrace
Raises an exception preserving a previous stacktrace
Handles the sigil ~C
Handles the sigil ~D
for dates
Handles the sigil ~N
for naive date times
Handles the sigil ~R
Handles the sigil ~S
Handles the sigil ~T
for times
Handles the sigil ~W
Handles the sigil ~c
Handles the sigil ~r
Handles the sigil ~s
Handles the sigil ~w
Converts the argument to a charlist according to the List.Chars
protocol
Converts the argument to a string according to the
String.Chars
protocol
Provides an unless
macro
Updates a nested structure via the given path
Uses the given module in the current context
When used inside quoting, marks that the given variable should not be hygienized
Pipe operator
Provides a short-circuit operator that evaluates and returns the second
expression only if the first one does not evaluate to true
(i.e., it
is either nil
or false
). Returns the first expression otherwise
Functions
Returns true
if the two items are not equal.
This operator considers 1 and 1.0 to be equal. For match
comparison, use !==
instead.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 != 2
true
iex> 1 != 1.0
false
Returns true
if the two items do not match.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 !== 2
true
iex> 1 !== 1.0
true
Concatenates two lists.
The complexity of a ++ b
is proportional to length(a)
, so avoid repeatedly
appending to lists of arbitrary length, e.g. list ++ [item]
.
Instead, consider prepending via [item | rest]
and then reversing.
Inlined by the compiler.
Examples
iex> [1] ++ [2, 3]
[1, 2, 3]
iex> 'foo' ++ 'bar'
'foobar'
Removes the first occurrence of an item on the left list for each item on the right.
The complexity of a -- b
is proportional to length(a) * length(b)
,
meaning that it will be very slow if both a
and b
are long lists.
In such cases, consider converting each list to a MapSet
and using
MapSet.difference/2
.
Inlined by the compiler.
Examples
iex> [1, 2, 3] -- [1, 2]
[3]
iex> [1, 2, 3, 2, 1] -- [1, 2, 2]
[3, 1]
Arithmetic division.
The result is always a float. Use div/2
and rem/2
if you want
an integer division or the remainder.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 / 2
0.5
iex> 2 / 1
2.0
Returns true
if left is less than right.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 < 2
true
Returns true
if left is less than or equal to right.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 <= 2
true
Returns true
if the two items are equal.
This operator considers 1 and 1.0 to be equal. For match
semantics, use ===
instead.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 == 2
false
iex> 1 == 1.0
true
Returns true
if the two items are match.
This operator gives the same semantics as the one existing in
pattern matching, i.e., 1
and 1.0
are equal, but they do
not match.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 === 2
false
iex> 1 === 1.0
false
Matches the term on the left against the regular expression or string on the
right. Returns true
if left
matches right
(if it’s a regular expression)
or contains right
(if it’s a string).
Examples
iex> "abcd" =~ ~r/c(d)/
true
iex> "abcd" =~ ~r/e/
false
iex> "abcd" =~ "bc"
true
iex> "abcd" =~ "ad"
false
iex> "abcd" =~ ""
true
Returns true
if left is more than right.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 > 2
false
Returns true
if left is more than or equal to right.
All terms in Elixir can be compared with each other.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> 1 >= 2
false
Returns an integer or float which is the arithmetical absolute value of number
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> abs(-3.33)
3.33
iex> abs(-3)
3
Invokes the given fun
with the list of arguments args
.
Inlined by the compiler.
Examples
iex> apply(fn x -> x * 2 end, [2])
4
Invokes the given fun
from module
with the list of arguments args
.
Inlined by the compiler.
Examples
iex> apply(Enum, :reverse, [[1, 2, 3]])
[3, 2, 1]
Extracts the part of the binary starting at start
with length length
.
Binaries are zero-indexed.
If start
or length
reference in any way outside the binary, an
ArgumentError
exception is raised.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> binary_part("foo", 1, 2)
"oo"
A negative length
can be used to extract bytes that come before the byte
at start
:
iex> binary_part("Hello", 5, -3)
"llo"
Returns an integer which is the size in bits of bitstring
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> bit_size(<<433::16, 3::3>>)
19
iex> bit_size(<<1, 2, 3>>)
24
Returns the number of bytes needed to contain bitstring
.
That is, if the number of bits in bitstring
is not divisible by 8, the
resulting number of bytes will be rounded up (by excess). This operation
happens in constant time.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> byte_size(<<433::16, 3::3>>)
3
iex> byte_size(<<1, 2, 3>>)
3
Performs an integer division.
Raises an ArithmeticError
exception if one of the arguments is not an
integer.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> div(5, 2)
2
Gets the element at the zero-based index
in tuple
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> tuple = {:foo, :bar, 3}
iex> elem(tuple, 1)
:bar
Stops the execution of the calling process with the given reason.
Since evaluating this function causes the process to terminate, it has no return value.
Inlined by the compiler.
Examples
When a process reaches its end, by default it exits with
reason :normal
. You can also call exit/1
explicitly if you
want to terminate a process but not signal any failure:
exit(:normal)
In case something goes wrong, you can also use exit/1
with
a different reason:
exit(:seems_bad)
If the exit reason is not :normal
, all the processes linked to the process
that exited will crash (unless they are trapping exits).
OTP exits
Exits are used by the OTP to determine if a process exited abnormally or not. The following exits are considered “normal”:
exit(:normal)
exit(:shutdown)
exit({:shutdown, term})
Exiting with any other reason is considered abnormal and treated as a crash. This means the default supervisor behaviour kicks in, error reports are emitted, etc.
This behaviour is relied on in many different places. For example,
ExUnit
uses exit(:shutdown)
when exiting the test process to
signal linked processes, supervision trees and so on to politely
shutdown too.
CLI exits
Building on top of the exit signals mentioned above, if the process started by the command line exits with any of the three reasons above, its exit is considered normal and the Operating System process will exit with status 0.
It is, however, possible to customize the Operating System exit signal by invoking:
exit({:shutdown, integer})
This will cause the OS process to exit with the status given by
integer
while signaling all linked OTP processes to politely
shutdown.
Any other exit reason will cause the OS process to exit with
status 1
and linked OTP processes to crash.
function_exported?(atom | tuple, atom, arity) :: boolean
Returns true
if module
is loaded and contains a
public function
with the given arity
, otherwise false
.
Note that this function does not load the module in case
it is not loaded. Check Code.ensure_loaded/1
for more
information.
Examples
iex> function_exported?(Enum, :member?, 2)
true
Gets a value and updates a nested structure.
It expects a tuple to be returned, containing the value retrieved and the update one.
It uses the Access
module to traverse the structures
according to the given keys
, unless the key
is a
function.
If a key is a function, the function will be invoked
passing three arguments, the operation (:get_and_update
),
the data to be accessed, and a function to be invoked next.
This means get_and_update_in/3
can be extended to provide
custom lookups. The downside is that functions cannot be stored
as keys in the accessed data structures.
Examples
This function is useful when there is a need to retrieve the current value (or something calculated in function of the current value) and update it at the same time. For example, it could be used to increase the age of a user by one and return the previous age in one pass:
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_and_update_in(users, ["john", :age], &{&1, &1 + 1})
{27, %{"john" => %{age: 28}, "meg" => %{age: 23}}}
When one of the keys is a function, the function is invoked. In the example below, we use a function to get and increment all ages inside a list:
iex> users = [%{name: "john", age: 27}, %{name: "meg", age: 23}]
iex> all = fn :get_and_update, data, next ->
...> Enum.map(data, next) |> :lists.unzip
...> end
iex> get_and_update_in(users, [all, :age], &{&1, &1 + 1})
{[27, 23], [%{name: "john", age: 28}, %{name: "meg", age: 24}]}
If the previous value before invoking the function is nil
,
the function will receive nil
as a value and must handle it
accordingly (be it by failing or providing a sane default).
The Access
module ships with many convenience accessor functions,
like the all
function defined above. See Access.all/0
,
Access.key/1
and others as examples.
Gets a value from a nested structure.
Uses the Access
module to traverse the structures
according to the given keys
, unless the key
is a
function.
If a key is a function, the function will be invoked
passing three arguments, the operation (:get
), the
data to be accessed, and a function to be invoked next.
This means get_in/2
can be extended to provide
custom lookups. The downside is that functions cannot be
stored as keys in the accessed data structures.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_in(users, ["john", :age])
27
In case any of entries in the middle returns nil
, nil
will be returned
as per the Access module:
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_in(users, ["unknown", :age])
nil
When one of the keys is a function, the function is invoked. In the example below, we use a function to get all the maps inside a list:
iex> users = [%{name: "john", age: 27}, %{name: "meg", age: 23}]
iex> all = fn :get, data, next -> Enum.map(data, next) end
iex> get_in(users, [all, :age])
[27, 23]
If the previous value before invoking the function is nil
,
the function will receive nil as a value and must handle it
accordingly.
Returns the head of a list; raises ArgumentError
if the list is empty.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> hd([1, 2, 3, 4])
1
Inspects the given argument according to the Inspect
protocol.
The second argument is a keyword list with options to control
inspection.
Options
inspect/2
accepts a list of options that are internally
translated to an Inspect.Opts
struct. Check the docs for
Inspect.Opts
to see the supported options.
Examples
iex> inspect(:foo)
":foo"
iex> inspect [1, 2, 3, 4, 5], limit: 3
"[1, 2, 3, ...]"
iex> inspect [1, 2, 3], pretty: true, width: 0
"[1,\n 2,\n 3]"
iex> inspect("olá" <> <<0>>)
"<<111, 108, 195, 161, 0>>"
iex> inspect("olá" <> <<0>>, binaries: :as_strings)
"\"olá\\0\""
iex> inspect("olá", binaries: :as_binaries)
"<<111, 108, 195, 161>>"
iex> inspect('bar')
"'bar'"
iex> inspect([0 | 'bar'])
"[0, 98, 97, 114]"
iex> inspect(100, base: :octal)
"0o144"
iex> inspect(100, base: :hex)
"0x64"
Note that the Inspect
protocol does not necessarily return a valid
representation of an Elixir term. In such cases, the inspected result
must start with #
. For example, inspecting a function will return:
inspect fn a, b -> a + b end
#=> #Function<...>
Returns true
if term
is an atom; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a binary; otherwise returns false
.
A binary always contains a complete number of bytes.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> is_binary "foo"
true
iex> is_binary <<1::3>>
false
Returns true
if term
is a bitstring (including a binary); otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> is_bitstring "foo"
true
iex> is_bitstring <<1::3>>
true
Returns true
if term
is either the atom true
or the atom false
(i.e.,
a boolean); otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a floating point number; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a function; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a function that can be applied with arity
number of arguments;
otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> is_function(fn(x) -> x * 2 end, 1)
true
iex> is_function(fn(x) -> x * 2 end, 2)
false
Returns true
if term
is an integer; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a list with zero or more elements; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a map; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is either an integer or a floating point number;
otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a pid (process identifier); otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a port identifier; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a reference; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns true
if term
is a tuple; otherwise returns false
.
Allowed in guard tests. Inlined by the compiler.
Returns the length of list
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> length([1, 2, 3, 4, 5, 6, 7, 8, 9])
9
Returns true
if module
is loaded and contains a
public macro
with the given arity
, otherwise false
.
Note that this function does not load the module in case
it is not loaded. Check Code.ensure_loaded/1
for more
information.
Examples
iex> macro_exported?(Kernel, :use, 2)
true
Returns an almost unique reference.
The returned reference will re-occur after approximately 2^82 calls; therefore it is unique enough for practical purposes.
Inlined by the compiler.
Examples
make_ref() #=> #Reference<<IP_ADDRESS>>
Returns the size of a map.
The size of a map is the number of key-value pairs that the map contains.
This operation happens in constant time.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> map_size(%{a: "foo", b: "bar"})
2
Returns the biggest of the two given terms according to Erlang’s term ordering. If the terms compare equal, the first one is returned.
Inlined by the compiler.
Examples
iex> max(1, 2)
2
iex> max(:a, :b)
:b
Returns the smallest of the two given terms according to Erlang’s term ordering. If the terms compare equal, the first one is returned.
Inlined by the compiler.
Examples
iex> min(1, 2)
1
iex> min("foo", "bar")
"bar"
Returns an atom representing the name of the local node.
If the node is not alive, :nonode@nohost
is returned instead.
Allowed in guard tests. Inlined by the compiler.
Returns the node where the given argument is located.
The argument can be a pid, a reference, or a port.
If the local node is not alive, :nonode@nohost
is returned.
Allowed in guard tests. Inlined by the compiler.
Boolean not.
arg
must be a boolean; if it’s not, an ArgumentError
exception is raised.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> not false
true
Pops a key from the given nested structure.
Uses the Access
protocol to traverse the structures
according to the given keys
, unless the key
is a
function. If the key is a function, it will be invoked
as specified in get_and_update_in/3
.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> pop_in(users, ["john", :age])
{27, %{"john" => %{}, "meg" => %{age: 23}}}
In case any entry returns nil
, its key will be removed
and the deletion will be considered a success.
Inserts value
at the given zero-based index
in tuple
.
Inlined by the compiler.
Examples
iex> tuple = {:foo, :bar, 3}
iex> put_elem(tuple, 0, :baz)
{:baz, :bar, 3}
Puts a value in a nested structure.
Uses the Access
module to traverse the structures
according to the given keys
, unless the key
is a
function. If the key is a function, it will be invoked
as specified in get_and_update_in/3
.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> put_in(users, ["john", :age], 28)
%{"john" => %{age: 28}, "meg" => %{age: 23}}
In case any of entries in the middle returns nil
,
an error will be raised when trying to access it next.
Computes the remainder of an integer division.
Raises an ArithmeticError
exception if one of the arguments is not an
integer.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> rem(5, 2)
1
Rounds a number to the nearest integer.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> round(5.6)
6
iex> round(5.2)
5
iex> round(-9.9)
-10
Returns the pid (process identifier) of the calling process.
Allowed in guard clauses. Inlined by the compiler.
Sends a message to the given dest
and returns the message.
dest
may be a remote or local pid, a (local) port, a locally
registered name, or a tuple {registered_name, node}
for a registered
name at another node.
Inlined by the compiler.
Examples
iex> send self(), :hello
:hello
Spawns the given function and returns its pid.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
current = self()
child = spawn(fn -> send current, {self(), 1 + 2} end)
receive do
{^child, 3} -> IO.puts "Received 3 back"
end
Spawns the given module and function passing the given args and returns its pid.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
spawn(SomeModule, :function, [1, 2, 3])
Spawns the given function, links it to the current process and returns its pid.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
current = self()
child = spawn_link(fn -> send current, {self(), 1 + 2} end)
receive do
{^child, 3} -> IO.puts "Received 3 back"
end
Spawns the given module and function passing the given args, links it to the current process and returns its pid.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
spawn_link(SomeModule, :function, [1, 2, 3])
Spawns the given function, monitors it and returns its pid and monitoring reference.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
current = self()
spawn_monitor(fn -> send current, {self(), 1 + 2} end)
Spawns the given module and function passing the given args, monitors it and returns its pid and monitoring reference.
Check the Process
and Node
modules for other functions
to handle processes, including spawning functions in nodes.
Inlined by the compiler.
Examples
spawn_monitor(SomeModule, :function, [1, 2, 3])
Creates and updates structs.
The struct
argument may be an atom (which defines defstruct
)
or a struct
itself. The second argument is any Enumerable
that
emits two-element tuples (key-value pairs) during enumeration.
Keys in the Enumerable
that don’t exist in the struct are automatically
discarded. Note that keys must be atoms, as only atoms are allowed when
defining a struct.
This function is useful for dynamically creating and updating structs, as
well as for converting maps to structs; in the latter case, just inserting
the appropriate :__struct__
field into the map may not be enough and
struct/2
should be used instead.
Examples
defmodule User do
defstruct name: "john"
end
struct(User)
#=> %User{name: "john"}
opts = [name: "meg"]
user = struct(User, opts)
#=> %User{name: "meg"}
struct(user, unknown: "value")
#=> %User{name: "meg"}
struct(User, %{name: "meg"})
#=> %User{name: "meg"}
# String keys are ignored
struct(User, %{"name" => "meg"})
#=> %User{name: "john"}
Similar to struct/2
but checks for key validity.
The function struct!/2
emulates the compile time behaviour
of structs. This means that:
when building a struct, as in
struct!(SomeStruct, key: :value)
, it is equivalent to%SomeStruct{key: :value}
and therefore this function will check if every given key-value belongs to the struct. If the struct is enforcing any key via@enforce_keys
, those will be enforced as well;- when updating a struct, as in
struct!(%SomeStruct{}, key: :value)
, it is equivalent to%SomeStruct{struct | key: :value}
and therefore this function will check if every given key-value belongs to the struct. However, updating structs does not enforce keys, as keys are enforced only when building;
A non-local return from a function. Check Kernel.SpecialForms.try/1
for more information.
Inlined by the compiler.
Returns the tail of a list. Raises ArgumentError
if the list is empty.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> tl([1, 2, 3, :go])
[2, 3, :go]
Returns the integer part of number
.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> trunc(5.4)
5
iex> trunc(5.99)
5
Returns the size of a tuple.
This operation happens in constant time.
Allowed in guard tests. Inlined by the compiler.
Examples
iex> tuple_size {:a, :b, :c}
3
Updates a key in a nested structure.
Uses the Access
module to traverse the structures
according to the given keys
, unless the key
is a
function. If the key is a function, it will be invoked
as specified in get_and_update_in/3
.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> update_in(users, ["john", :age], &(&1 + 1))
%{"john" => %{age: 28}, "meg" => %{age: 23}}
In case any of entries in the middle returns nil
,
an error will be raised when trying to access it next.
Macros
Boolean not.
Receives any argument (not just booleans) and returns true
if the argument
is false
or nil
; returns false
otherwise.
Not allowed in guard clauses.
Examples
iex> !Enum.empty?([])
false
iex> !List.first([])
true
Provides a short-circuit operator that evaluates and returns
the second expression only if the first one evaluates to true
(i.e., it is neither nil
nor false
). Returns the first expression
otherwise.
Not allowed in guard clauses.
Examples
iex> Enum.empty?([]) && Enum.empty?([])
true
iex> List.first([]) && true
nil
iex> Enum.empty?([]) && List.first([1])
1
iex> false && throw(:bad)
false
Note that, unlike and/2
, this operator accepts any expression
as the first argument, not only booleans.
Returns a range with the specified start and end.
Both ends are included.
Examples
iex> 0 in 1..3
false
iex> 1 in 1..3
true
iex> 2 in 1..3
true
iex> 3 in 1..3
true
Concatenates two binaries.
Examples
iex> "foo" <> "bar"
"foobar"
The <>
operator can also be used in pattern matching (and guard clauses) as
long as the first part is a literal binary:
iex> "foo" <> x = "foobar"
iex> x
"bar"
x <> "bar" = "foobar"
would have resulted in a CompileError
exception.
Reads and writes attributes of the current module.
The canonical example for attributes is annotating that a module
implements the OTP behaviour called gen_server
:
defmodule MyServer do
@behaviour :gen_server
# ... callbacks ...
end
By default Elixir supports all the module attributes supported by Erlang, but custom attributes can be used as well:
defmodule MyServer do
@my_data 13
IO.inspect @my_data #=> 13
end
Unlike Erlang, such attributes are not stored in the module by default since
it is common in Elixir to use custom attributes to store temporary data that
will be available at compile-time. Custom attributes may be configured to
behave closer to Erlang by using Module.register_attribute/3
.
Finally, notice that attributes can also be read inside functions:
defmodule MyServer do
@my_data 11
def first_data, do: @my_data
@my_data 13
def second_data, do: @my_data
end
MyServer.first_data #=> 11
MyServer.second_data #=> 13
It is important to note that reading an attribute takes a snapshot of
its current value. In other words, the value is read at compilation
time and not at runtime. Check the Module
module for other functions
to manipulate module attributes.
When used inside quoting, marks that the given alias should not be hygienized. This means the alias will be expanded when the macro is expanded.
Check Kernel.SpecialForms.quote/2
for more information.
Boolean and.
If the first argument is false
, false
is returned; otherwise, the second
argument is returned.
Requires only the first argument to be a boolean since it short-circuits. If
the first argument is not a boolean, an ArgumentError
exception is raised.
Allowed in guard tests.
Examples
iex> true and false
false
iex> true and "yay!"
"yay!"
Returns the binding for the given context as a keyword list.
In the returned result, keys are variable names and values are the corresponding variable values.
If the given context
is nil
(by default it is), the binding for the
current context is returned.
Examples
iex> x = 1
iex> binding()
[x: 1]
iex> x = 2
iex> binding()
[x: 2]
iex> binding(:foo)
[]
iex> var!(x, :foo) = 1
1
iex> binding(:foo)
[x: 1]
Defines a function with the given name and body.
Examples
defmodule Foo do
def bar, do: :baz
end
Foo.bar #=> :baz
A function that expects arguments can be defined as follows:
defmodule Foo do
def sum(a, b) do
a + b
end
end
In the example above, a sum/2
function is defined; this function receives
two arguments and returns their sum.
Function and variable names
Function and variable names have the following syntax: A lowercase ASCII letter or an underscore, followed by any number of lowercase or uppercase ASCII letters, numbers, or underscores. Optionally they can end in either an exclamation mark or a question mark.
For variables, any identifier starting with an underscore should indicate an unused variable. For example:
def foo(bar) do
[]
end
#=> warning: variable bar is unused
def foo(_bar) do
[]
end
#=> no warning
def foo(_bar) do
_bar
end
#=> warning: the underscored variable "_bar" is used after being set
Defines a function that delegates to another module.
Functions defined with defdelegate/2
are public and can be invoked from
outside the module they’re defined in (like if they were defined using
def/2
. When the desire is to delegate as private functions, import/2
should
be used.
Delegation only works with functions; delegating macros is not supported.
Options
:to
- the expression to delegate to. Any expression is allowed and its results will be evaluated at runtime. Usually evaluates to the name of a module.:as
- the function to call on the target given in:to
. This parameter is optional and defaults to the name being delegated (funs
).:append_first
- iftrue
, when delegated, the first argument passed to the delegated function will be relocated to the end of the arguments when dispatched to the target.The motivation behind this is because Elixir normalizes the “handle” as the first argument while some Erlang modules expect it as the last argument.
Examples
defmodule MyList do
defdelegate reverse(list), to: :lists
defdelegate other_reverse(list), to: :lists, as: :reverse
defdelegate [reverse(list), map(list, callback)], to: :lists, append_first: true
end
MyList.reverse([1, 2, 3])
#=> [3, 2, 1]
MyList.other_reverse([1, 2, 3])
#=> [3, 2, 1]
MyList.map([1, 2, 3], &(&1 * 2))
#=> [2, 4, 6]
Defines an exception.
Exceptions are structs backed by a module that implements
the Exception
behaviour. The Exception
behaviour requires
two functions to be implemented:
exception/1
- receives the arguments given toraise/2
and returns the exception struct. The default implementation accepts either a set of keyword arguments that is merged into the struct or a string to be used as the exception’s message.message/1
- receives the exception struct and must return its message. Most commonly exceptions have a message field which by default is accessed by this function. However, if an exception does not have a message field, this function must be explicitly implemented.
Since exceptions are structs, the API supported by defstruct/1
is also available in defexception/1
.
Raising exceptions
The most common way to raise an exception is via raise/2
:
defmodule MyAppError do
defexception [:message]
end
value = [:hello]
raise MyAppError,
message: "did not get what was expected, got: #{inspect value}"
In many cases it is more convenient to pass the expected value to
raise/2
and generate the message in the exception/1
callback:
defmodule MyAppError do
defexception [:message]
def exception(value) do
msg = "did not get what was expected, got: #{inspect value}"
%MyAppError{message: msg}
end
end
raise MyAppError, value
The example above shows the preferred strategy for customizing exception messages.
Defines an implementation for the given protocol.
See defprotocol/2
for more information and examples on protocols.
Inside an implementation, the name of the protocol can be accessed
via @protocol
and the current target as @for
.
Defines a macro with the given name and body.
Examples
defmodule MyLogic do
defmacro unless(expr, opts) do
quote do
if !unquote(expr), unquote(opts)
end
end
end
require MyLogic
MyLogic.unless false do
IO.puts "It works"
end
Defines a private macro with the given name and body.
Private macros are only accessible from the same module in which they are defined.
Check defmacro/2
for more information.
Defines a module given by name with the given contents.
This macro defines a module with the given alias
as its name and with the
given contents. It returns a tuple with four elements:
:module
- the module name
- the binary contents of the module
- the result of evaluating the contents block
Examples
iex> defmodule Foo do
...> def bar, do: :baz
...> end
iex> Foo.bar
:baz
Nesting
Nesting a module inside another module affects the name of the nested module:
defmodule Foo do
defmodule Bar do
end
end
In the example above, two modules - Foo
and Foo.Bar
- are created.
When nesting, Elixir automatically creates an alias to the inner module,
allowing the second module Foo.Bar
to be accessed as Bar
in the same
lexical scope where it’s defined (the Foo
module).
If the Foo.Bar
module is moved somewhere else, the references to Bar
in
the Foo
module need to be updated to the fully-qualified name (Foo.Bar
) or
an alias has to be explicitly set in the Foo
module with the help of
Kernel.SpecialForms.alias/2
.
defmodule Foo.Bar do
# code
end
defmodule Foo do
alias Foo.Bar
# code here can refer to "Foo.Bar" as just "Bar"
end
Module names
A module name can be any atom, but Elixir provides a special syntax which is
usually used for module names. What is called a module name is an
uppercase ASCII letter followed by any number of lowercase or
uppercase ASCII letters, numbers, or underscores.
This identifier is equivalent to an atom prefixed by Elixir.
. So in the
defmodule Foo
example Foo
is equivalent to :"Elixir.Foo"
Dynamic names
Elixir module names can be dynamically generated. This is very useful when working with macros. For instance, one could write:
defmodule String.to_atom("Foo#{1}") do
# contents ...
end
Elixir will accept any module name as long as the expression passed as the
first argument to defmodule/2
evaluates to an atom.
Note that, when a dynamic name is used, Elixir won’t nest the name under the
current module nor automatically set up an alias.
Makes the given functions in the current module overridable.
An overridable function is lazily defined, allowing a developer to override it.
Example
defmodule DefaultMod do
defmacro __using__(_opts) do
quote do
def test(x, y) do
x + y
end
defoverridable [test: 2]
end
end
end
defmodule InheritMod do
use DefaultMod
def test(x, y) do
x * y + super(x, y)
end
end
As seen as in the example above, super
can be used to call the default
implementation.
Defines a private function with the given name and body.
Private functions are only accessible from within the module in which they are
defined. Trying to access a private function from outside the module it’s
defined in results in an UndefinedFunctionError
exception.
Check def/2
for more information.
Examples
defmodule Foo do
def bar do
sum(1, 2)
end
defp sum(a, b), do: a + b
end
Foo.bar #=> 3
Foo.sum(1, 2) #=> ** (UndefinedFunctionError) undefined function Foo.sum/2
Defines a protocol.
A protocol specifies an API that should be defined by its implementations.
Examples
In Elixir, only false
and nil
are considered falsy values.
Everything else evaluates to true
in if/2
clauses. Depending
on the application, it may be important to specify a blank?
protocol that returns a boolean for other data types that should
be considered “blank”. For instance, an empty list or an empty
binary could be considered blank.
Such protocol could be implemented as follows:
defprotocol Blank do
@doc "Returns `true` if `data` is considered blank/empty"
def blank?(data)
end
Now that the protocol is defined it can be implemented. It needs to be implemented for each Elixir type; for example:
# Integers are never blank
defimpl Blank, for: Integer do
def blank?(number), do: false
end
# The only blank list is the empty one
defimpl Blank, for: List do
def blank?([]), do: true
def blank?(_), do: false
end
# The only blank atoms are "false" and "nil"
defimpl Blank, for: Atom do
def blank?(false), do: true
def blank?(nil), do: true
def blank?(_), do: false
end
The implementation of the Blank
protocol would need to be defined for all
Elixir types. The available types are:
- Structs (see below)
Tuple
Atom
List
BitString
Integer
Float
Function
PID
Map
Port
Reference
Any
(see below)
Protocols and Structs
The real benefit of protocols comes when mixed with structs.
For instance, Elixir ships with many data types implemented as
structs, like MapSet
. We can implement the Blank
protocol
for those types as well:
defimpl Blank, for: MapSet do
def blank?(enum_like), do: Enum.empty?(enum_like)
end
When implementing a protocol for a struct, the :for
option can
be omitted if the defimpl
call is inside the module that defines
the struct:
defmodule User do
defstruct [:email, :name]
defimpl Blank do
def blank?(%User{}), do: false
end
end
If a protocol is not found for a given type, it will fallback to
Any
. Protocols that are implemented for maps don’t work by default
on structs; look at defstruct/1
for more information about deriving
protocols.
Fallback to any
In some cases, it may be convenient to provide a default
implementation for all types. This can be achieved by
setting the @fallback_to_any
attribute to true
in the protocol
definition:
defprotocol Blank do
@fallback_to_any true
def blank?(data)
end
The Blank
protocol can now be implemented for Any
:
defimpl Blank, for: Any do
def blank?(_), do: true
end
One may wonder why such behaviour (fallback to any) is not the default one.
It is two-fold: first, the majority of protocols cannot implement an action in a generic way for all types; in fact, providing a default implementation may be harmful, because users may rely on the default implementation instead of providing a specialized one.
Second, falling back to Any
adds an extra lookup to all types,
which is unnecessary overhead unless an implementation for Any
is
required.
Types
Defining a protocol automatically defines a type named t
, which
can be used as follows:
@spec present?(Blank.t) :: boolean
def present?(blank) do
not Blank.blank?(blank)
end
The @spec
above expresses that all types allowed to implement the
given protocol are valid argument types for the given function.
Reflection
Any protocol module contains three extra functions:
__protocol__/1
- returns the protocol name when:name
is given, and a keyword list with the protocol functions and their arities when:functions
is givenimpl_for/1
- receives a structure and returns the module that implements the protocol for the structure,nil
otherwiseimpl_for!/1
- same as above but raises an error if an implementation is not foundEnumerable.__protocol__(:functions) #=> [count: 1, member?: 2, reduce: 3] Enumerable.impl_for([]) #=> Enumerable.List Enumerable.impl_for(42) #=> nil
Consolidation
In order to cope with code loading in development, protocols in Elixir provide a slow implementation of protocol dispatching specific to development.
In order to speed up dispatching in production environments, where
all implementations are known up-front, Elixir provides a feature
called protocol consolidation. For this reason, all protocols are
compiled with debug_info
set to true
, regardless of the option
set by elixirc
compiler. The debug info though may be removed
after consolidation.
For more information on how to apply protocol consolidation to
a given project, please check the functions in the Protocol
module or the mix compile.protocols
task.
Defines a struct.
A struct is a tagged map that allows developers to provide default values for keys, tags to be used in polymorphic dispatches and compile time assertions.
To define a struct, a developer must define both __struct__/0
and
__struct__/1
functions. defstruct/1
is a convenience macro which
defines such functions with some conveniences.
For more information about structs, please check Kernel.SpecialForms.%/2
.
Examples
defmodule User do
defstruct name: nil, age: nil
end
Struct fields are evaluated at compile-time, which allows
them to be dynamic. In the example below, 10 + 11
is
evaluated at compile-time and the age field is stored
with value 21
:
defmodule User do
defstruct name: nil, age: 10 + 11
end
The fields
argument is usually a keyword list with field names
as atom keys and default values as corresponding values. defstruct/1
also supports a list of atoms as its argument: in that case, the atoms
in the list will be used as the struct’s field names and they will all
default to nil
.
defmodule Post do
defstruct [:title, :content, :author]
end
Deriving
Although structs are maps, by default structs do not implement
any of the protocols implemented for maps. For example, attempting
to use a protocol with the User
struct leads to an error:
john = %User{name: "John"}
MyProtocol.call(john)
** (Protocol.UndefinedError) protocol MyProtocol not implemented for %User{...}
defstruct/1
, however, allows protocol implementations to be
derived. This can be done by defining a @derive
attribute as a
list before invoking defstruct/1
:
defmodule User do
@derive [MyProtocol]
defstruct name: nil, age: 10 + 11
end
MyProtocol.call(john) #=> works
For each protocol in the @derive
list, Elixir will assert there is an
implementation of that protocol for any (regardless if fallback to any
is true
) and check if the any implementation defines a __deriving__/3
callback. If so, the callback is invoked, otherwise an implementation
that simply points to the any implementation is automatically derived.
Enforcing keys
When building a struct, Elixir will automatically guarantee all keys belongs to the struct:
%User{name: "john", unknown: :key}
** (KeyError) key :unknown not found in: %User{age: 21, name: nil}
Elixir also allows developers to enforce certain keys must always be given when building the struct:
defmodule User do
@enforce_keys [:name]
defstruct name: nil, age: 10 + 11
end
Now trying to build a struct without the name key will fail:
%User{age: 21}
** (ArgumentError) the following keys must also be given when building struct User: [:name]
Keep in mind @enforce_keys
is a simply a compile-time guarantee
to aid developers when building structs. It is not enforced on
updates and it does not provide any sort of value-validation.
Types
It is recommended to define types for structs. By convention such type
is called t
. To define a struct inside a type, the struct literal syntax
is used:
defmodule User do
defstruct name: "John", age: 25
@type t :: %User{name: String.t, age: non_neg_integer}
end
It is recommended to only use the struct syntax when defining the struct’s
type. When referring to another struct it’s better to use User.t
instead of
%User{}
.
The types of the struct fields that are not included in %User{}
default to
term
.
Structs whose internal structure is private to the local module (pattern
matching them or directly accessing their fields should not be allowed) should
use the @opaque
attribute. Structs whose internal structure is public should
use @type
.
Destructures two lists, assigning each term in the right one to the matching term in the left one.
Unlike pattern matching via =
, if the sizes of the left
and right lists don’t match, destructuring simply stops
instead of raising an error.
Examples
iex> destructure([x, y, z], [1, 2, 3, 4, 5])
iex> {x, y, z}
{1, 2, 3}
In the example above, even though the right list has more entries than the
left one, destructuring works fine. If the right list is smaller, the
remaining items are simply set to nil
:
iex> destructure([x, y, z], [1])
iex> {x, y, z}
{1, nil, nil}
The left-hand side supports any expression you would use on the left-hand side of a match:
x = 1
destructure([^x, y, z], [1, 2, 3])
The example above will only work if x
matches the first value in the right
list. Otherwise, it will raise a MatchError
(like the =
operator would
do).
Gets a value and updates a nested data structure via the given path
.
This is similar to get_and_update_in/3
, except the path is extracted
via a macro rather than passing a list. For example:
get_and_update_in(opts[:foo][:bar], &{&1, &1 + 1})
Is equivalent to:
get_and_update_in(opts, [:foo, :bar], &{&1, &1 + 1})
Note that in order for this macro to work, the complete path must always be visible by this macro. See the Paths section below.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_and_update_in(users["john"].age, &{&1, &1 + 1})
{27, %{"john" => %{age: 28}, "meg" => %{age: 23}}}
Paths
A path may start with a variable, local or remote call, and must be followed by one or more:
foo[bar]
- access the keybar
infoo
; in casefoo
is nil,nil
is returnedfoo.bar
- access a map/struct field; in case the field is not present, an error is raised
Here are some valid paths:
users["john"][:age]
users["john"].age
User.all["john"].age
all_users()["john"].age
Here are some invalid ones:
# Does a remote call after the initial value
users["john"].do_something(arg1, arg2)
# Does not access any key or field
users
Provides an if/2
macro.
This macro expects the first argument to be a condition and the second argument to be a keyword list.
One-liner examples
if(foo, do: bar)
In the example above, bar
will be returned if foo
evaluates to
true
(i.e., it is neither false
nor nil
). Otherwise, nil
will be
returned.
An else
option can be given to specify the opposite:
if(foo, do: bar, else: baz)
Blocks examples
It’s also possible to pass a block to the if/2
macro. The first
example above would be translated to:
if foo do
bar
end
Note that do/end
become delimiters. The second example would
translate to:
if foo do
bar
else
baz
end
In order to compare more than two clauses, the cond/1
macro has to be used.
Checks if the element on the left-hand side is a member of the collection on the right-hand side.
Examples
iex> x = 1
iex> x in [1, 2, 3]
true
This operator (which is a macro) simply translates to a call to
Enum.member?/2
. The example above would translate to:
Enum.member?([1, 2, 3], x)
Guards
The in/2
operator can be used in guard clauses as long as the
right-hand side is a range or a list. In such cases, Elixir will expand the
operator to a valid guard expression. For example:
when x in [1, 2, 3]
translates to:
when x === 1 or x === 2 or x === 3
When using ranges:
when x in 1..3
translates to:
when x >= 1 and x <= 3
Returns true
if term
is nil
, false
otherwise.
Allowed in guard clauses.
Examples
iex> is_nil(1)
false
iex> is_nil(nil)
true
A convenience macro that checks if the right side (an expression) matches the left side (a pattern).
Examples
iex> match?(1, 1)
true
iex> match?(1, 2)
false
iex> match?({1, _}, {1, 2})
true
iex> map = %{a: 1, b: 2}
iex> match?(%{a: _}, map)
true
iex> a = 1
iex> match?(^a, 1)
true
match?/2
is very useful when filtering of finding a value in an enumerable:
list = [{:a, 1}, {:b, 2}, {:a, 3}]
Enum.filter list, &match?({:a, _}, &1)
#=> [{:a, 1}, {:a, 3}]
Guard clauses can also be given to the match:
list = [{:a, 1}, {:b, 2}, {:a, 3}]
Enum.filter list, &match?({:a, x} when x < 2, &1)
#=> [{:a, 1}]
However, variables assigned in the match will not be available
outside of the function call (unlike regular pattern matching with the =
operator):
iex> match?(_x, 1)
true
iex> binding()
[]
Boolean or.
If the first argument is true
, true
is returned; otherwise, the second
argument is returned.
Requires only the first argument to be a boolean since it short-circuits.
If the first argument is not a boolean, an ArgumentError
exception is
raised.
Allowed in guard tests.
Examples
iex> true or false
true
iex> false or 42
42
Pops a key from the nested structure via the given path
.
This is similar to pop_in/2
, except the path is extracted via
a macro rather than passing a list. For example:
pop_in(opts[:foo][:bar])
Is equivalent to:
pop_in(opts, [:foo, :bar])
Note that in order for this macro to work, the complete path must always
be visible by this macro. For more information about the supported path
expressions, please check get_and_update_in/2
docs.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> pop_in(users["john"][:age])
{27, %{"john" => %{}, "meg" => %{age: 23}}}
iex> users = %{john: %{age: 27}, meg: %{age: 23}}
iex> pop_in(users.john[:age])
{27, %{john: %{}, meg: %{age: 23}}}
In case any entry returns nil
, its key will be removed
and the deletion will be considered a success.
Puts a value in a nested structure via the given path
.
This is similar to put_in/3
, except the path is extracted via
a macro rather than passing a list. For example:
put_in(opts[:foo][:bar], :baz)
Is equivalent to:
put_in(opts, [:foo, :bar], :baz)
Note that in order for this macro to work, the complete path must always
be visible by this macro. For more information about the supported path
expressions, please check get_and_update_in/2
docs.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> put_in(users["john"][:age], 28)
%{"john" => %{age: 28}, "meg" => %{age: 23}}
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> put_in(users["john"].age, 28)
%{"john" => %{age: 28}, "meg" => %{age: 23}}
Raises an exception.
If the argument msg
is a binary, it raises a RuntimeError
exception
using the given argument as message.
If msg
is an atom, it just calls raise/2
with the atom as the first
argument and []
as the second argument.
If msg
is anything else, raises an ArgumentError
exception.
Examples
iex> raise "oops"
** (RuntimeError) oops
try do
1 + :foo
rescue
x in [ArithmeticError] ->
IO.puts "that was expected"
raise x
end
Raises an exception.
Calls the exception/1
function on the given argument (which has to be a
module name like ArgumentError
or RuntimeError
passing attrs
as the
attributes in order to retrieve the exception struct.
Any module that contains a call to the defexception/1
macro automatically
implements the exception/1
callback expected by raise/2
. See the docs for
defexception/1
for more information.
Examples
iex> raise(ArgumentError, message: "Sample")
** (ArgumentError) Sample
Raises an exception preserving a previous stacktrace.
Works like raise/1
but does not generate a new stacktrace.
Notice that System.stacktrace/0
returns the stacktrace
of the last exception. That said, it is common to assign
the stacktrace as the first expression inside a rescue
clause as any other exception potentially raised (and
rescued) between the rescue clause and the raise call
may change the System.stacktrace/0
value.
Examples
try do
raise "oops"
rescue
exception ->
stacktrace = System.stacktrace
if Exception.message(exception) == "oops" do
reraise exception, stacktrace
end
end
Raises an exception preserving a previous stacktrace.
reraise/3
works like reraise/2
, except it passes arguments to the
exception/1
function like explained in raise/2
.
Examples
try do
raise "oops"
rescue
exception ->
stacktrace = System.stacktrace
reraise WrapperError, [exception: exception], stacktrace
end
Handles the sigil ~C
.
It simply returns a charlist without escaping characters and without interpolations.
Examples
iex> ~C(foo)
'foo'
iex> ~C(f#{o}o)
'f\#{o}o'
Handles the sigil ~D
for dates.
The lower case ~d
variant does not exist as interpolation
and escape characters are not useful for date sigils.
Examples
iex> ~D[2015-01-13]
~D[2015-01-13]
Handles the sigil ~N
for naive date times.
The lower case ~n
variant does not exist as interpolation
and escape characters are not useful for datetime sigils.
Examples
iex> ~N[2015-01-13 13:00:07]
~N[2015-01-13 13:00:07]
iex> ~N[2015-01-13T13:00:07.001]
~N[2015-01-13 13:00:07.001]
Handles the sigil ~R
.
It returns a regular expression pattern without escaping nor interpreting interpolations.
More information on regexes can be found in the Regex
module.
Examples
iex> Regex.match?(~R(f#{1,3}o), "f#o")
true
Handles the sigil ~S
.
It simply returns a string without escaping characters and without interpolations.
Examples
iex> ~S(foo)
"foo"
iex> ~S(f#{o}o)
"f\#{o}o"
Handles the sigil ~T
for times.
The lower case ~t
variant does not exist as interpolation
and escape characters are not useful for time sigils.
Examples
iex> ~T[13:00:07]
~T[13:00:07]
iex> ~T[13:00:07.001]
~T[13:00:07.001]
Handles the sigil ~W
.
It returns a list of “words” split by whitespace without escaping nor interpreting interpolations.
Modifiers
s
: words in the list are strings (default)a
: words in the list are atomsc
: words in the list are charlists
Examples
iex> ~W(foo #{bar} baz)
["foo", "\#{bar}", "baz"]
Handles the sigil ~c
.
It returns a charlist as if it were a single quoted string, unescaping characters and replacing interpolations.
Examples
iex> ~c(foo)
'foo'
iex> ~c(f#{:o}o)
'foo'
iex> ~c(f\#{:o}o)
'f\#{:o}o'
Handles the sigil ~r
.
It returns a regular expression pattern, unescaping characters and replacing interpolations.
More information on regexes can be found in the Regex
module.
Examples
iex> Regex.match?(~r(foo), "foo")
true
iex> Regex.match?(~r/abc/, "abc")
true
Handles the sigil ~s
.
It returns a string as if it was a double quoted string, unescaping characters and replacing interpolations.
Examples
iex> ~s(foo)
"foo"
iex> ~s(f#{:o}o)
"foo"
iex> ~s(f\#{:o}o)
"f\#{:o}o"
Handles the sigil ~w
.
It returns a list of “words” split by whitespace. Character unescaping and interpolation happens for each word.
Modifiers
s
: words in the list are strings (default)a
: words in the list are atomsc
: words in the list are charlists
Examples
iex> ~w(foo #{:bar} baz)
["foo", "bar", "baz"]
iex> ~w(foo #{" bar baz "})
["foo", "bar", "baz"]
iex> ~w(--source test/enum_test.exs)
["--source", "test/enum_test.exs"]
iex> ~w(foo bar baz)a
[:foo, :bar, :baz]
Converts the argument to a charlist according to the List.Chars
protocol.
Examples
iex> to_charlist(:foo)
'foo'
Converts the argument to a string according to the
String.Chars
protocol.
This is the function invoked when there is string interpolation.
Examples
iex> to_string(:foo)
"foo"
Provides an unless
macro.
This macro evaluates and returns the do
block passed in as the second
argument unless clause
evaluates to true
. Otherwise, it returns the value
of the else
block if present or nil
if not.
See also if/2
.
Examples
iex> unless(Enum.empty?([]), do: "Hello")
nil
iex> unless(Enum.empty?([1, 2, 3]), do: "Hello")
"Hello"
iex> unless Enum.sum([2, 2]) == 5 do
...> "Math still works"
...> else
...> "Math is broken"
...> end
"Math still works"
Updates a nested structure via the given path
.
This is similar to update_in/3
, except the path is extracted via
a macro rather than passing a list. For example:
update_in(opts[:foo][:bar], &(&1 + 1))
Is equivalent to:
update_in(opts, [:foo, :bar], &(&1 + 1))
Note that in order for this macro to work, the complete path must always
be visible by this macro. For more information about the supported path
expressions, please check get_and_update_in/2
docs.
Examples
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> update_in(users["john"][:age], &(&1 + 1))
%{"john" => %{age: 28}, "meg" => %{age: 23}}
iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> update_in(users["john"].age, &(&1 + 1))
%{"john" => %{age: 28}, "meg" => %{age: 23}}
Uses the given module in the current context.
Examples
For example, in order to write tests using the ExUnit framework,
a developer should use the ExUnit.Case
module:
defmodule AssertionTest do
use ExUnit.Case, async: true
test "always pass" do
assert true
end
end
By calling use/2
, a hook called __using__/1
will be invoked in
ExUnit.Case
which will then do the proper setup.
Simply put, use/2
translates to:
defmodule AssertionTest do
require ExUnit.Case
ExUnit.Case.__using__([async: true])
test "always pass" do
assert true
end
end
Where __using__/1
is just a regular macro that can be defined
in any module:
defmodule MyModule do
defmacro __using__(opts) do
quote do
# code that will run in the module that uses MyModule
end
end
end
Best practices
__using__/1
is typically used when there is a need to set some state
(via module attributes) or callbacks (like @before_compile
)
into the caller.
__using__/1
may also be used to alias, require or import functionality
from different modules:
defmodule MyModule do
defmacro __using__(opts) do
quote do
import MyModule.Foo
import MyModule.Bar
import MyModule.Baz
alias MyModule.Repo
end
end
end
However, do not provide __using__/1
if all it does is to import,
alias or require the module itself. For example, do not:
defmodule MyModule do
defmacro __using__(opts) do
quote do
import MyModule
end
end
end
In such cases, developers must just import or alias the module
directly, allowing developers to customize those as they wish,
without the indirection behind use/2
.
Finally, developers should also avoid defining functions inside
the __using__/1
callback, unless those functions are the default
implementation of a previously defined @callback
. In case you
want to provide some existing functionality to the user module,
please define it in a module which will be imported accordingly.
When used inside quoting, marks that the given variable should not be hygienized.
The argument can be either a variable unquoted or in standard tuple form
{name, meta, context}
.
Check Kernel.SpecialForms.quote/2
for more information.
Pipe operator.
This operator introduces the expression on the left-hand side as the first argument to the function call on the right-hand side.
Examples
iex> [1, [2], 3] |> List.flatten()
[1, 2, 3]
The example above is the same as calling List.flatten([1, [2], 3])
.
The |>
operator is mostly useful when there is a desire to execute a series
of operations resembling a pipeline:
iex> [1, [2], 3] |> List.flatten |> Enum.map(fn x -> x * 2 end)
[2, 4, 6]
In the example above, the list [1, [2], 3]
is passed as the first argument
to the List.flatten/1
function, then the flattened list is passed as the
first argument to the Enum.map/2
function which doubles each element of the
list.
In other words, the expression above simply translates to:
Enum.map(List.flatten([1, [2], 3]), fn x -> x * 2 end)
Pitfalls
There are two common pitfalls when using the pipe operator.
The first one is related to operator precedence. For example, the following expression:
String.graphemes "Hello" |> Enum.reverse
Translates to:
String.graphemes("Hello" |> Enum.reverse)
which results in an error as the Enumerable
protocol is not defined
for binaries. Adding explicit parentheses resolves the ambiguity:
String.graphemes("Hello") |> Enum.reverse
Or, even better:
"Hello" |> String.graphemes |> Enum.reverse
The second pitfall is that the |>
operator works on calls.
For example, when you write:
"Hello" |> some_function()
Elixir sees the right-hand side is a function call and pipes to it. This means that, if you want to pipe to an anonymous or captured function, it must also be explicitly called.
Given the anonymous function:
fun = fn x -> IO.puts(x) end
fun.("Hello")
This won’t work as it will rather try to invoke the local
function fun
:
"Hello" |> fun()
This works:
"Hello" |> fun.()
As you can see, the |>
operator retains the same semantics
as when the pipe is not used since both require the fun.(...)
notation.
Provides a short-circuit operator that evaluates and returns the second
expression only if the first one does not evaluate to true
(i.e., it
is either nil
or false
). Returns the first expression otherwise.
Not allowed in guard clauses.
Examples
iex> Enum.empty?([1]) || Enum.empty?([1])
false
iex> List.first([]) || true
true
iex> Enum.empty?([1]) || 1
1
iex> Enum.empty?([]) || throw(:bad)
true
Note that, unlike or/2
, this operator accepts any expression
as the first argument, not only booleans.


Liberty Vehicle Buyers
We are a San Leandro based Vehicle buying company. Serving all California areas
We purchase all vehicles in "as is" condition, cars, pickup trucks, minivans, SUVs, Company vehicles, boats, motorcycles, ATVs, jet skis etc.
any year, make or model.
Call us!
Email us!


Message Security Layer (MSL) is an extensible and flexible secure messaging protocol that can be used to transport data between two or more communicating entities. Data may also be associated with specific users, and treated as confidential or non-replayable if so desired.
This Javadoc is limited to the classes and interfaces used by an application to properly configure its MSL stack and to engage in MSL-based communication with other compatible applications. The application entry point is the MslControl class.
For more information refer to the Protocol documentation.


HASH
Section: Linux Programmer's Manual (3)
Updated: 2012-04-23
Index
Return to Main Contents
NAME
hash - hash database access method
SYNOPSIS
#include <sys/types.h>
#include <db.h>
DESCRIPTION
Note well:
This page documents interfaces provided in glibc up until version 2.1.
Since version 2.2, glibc no longer provides these interfaces.
Probably, you are looking for the APIs provided by the
libdb
library instead.
The routine
dbopen(3)
is the library interface to database files.
One of the supported file formats is hash files.
The general description of the database access methods is in
dbopen(3),
this manual page describes only the hash-specific information.
The hash data structure is an extensible, dynamic hashing scheme.
The access-method-specific data structure provided to
dbopen(3)
is defined in the
<db.h>
include file as follows:
typedef struct {
unsigned int bsize;
unsigned int ffactor;
unsigned int nelem;
unsigned int cachesize;
uint32_t (*hash)(const void *, size_t);
int lorder;
} HASHINFO;
The elements of this structure are as follows:
- bsize
-
defines the hash table bucket size, and is, by default, 256 bytes.
It may be preferable to increase the page size for disk-resident tables
and tables with large data items.
- ffactor
-
indicates a desired density within the hash table.
It is an approximation of the number of keys allowed to accumulate in any
one bucket, determining when the hash table grows or shrinks.
The default value is 8.
- nelem
-
is an estimate of the final size of the hash table.
If not set or set too low, hash tables will expand gracefully as keys
are entered, although a slight performance degradation may be noticed.
The default value is 1.
- cachesize
-
is the suggested maximum size, in bytes, of the memory cache.
This value is
only advisory,
and the access method will allocate more memory rather than fail.
- hash
-
is a user-defined hash function.
Since no hash function performs equally well on all possible data, the
user may find that the built-in hash function does poorly on a particular
data set.
A user-specified hash functions must take two arguments (a pointer to a byte
string and a length) and return a 32-bit quantity to be used as the hash
value.
- lorder
-
is the byte order for integers in the stored database metadata.
The number should represent the order as an integer; for example,
big endian order would be the number 4,321.
If
lorder
is 0 (no order is specified), the current host order is used.
If the file already exists, the specified value is ignored and the
value specified when the tree was created is used.
If the file already exists (and the
O_TRUNC
flag is not specified), the
values specified for
bsize,
ffactor,
lorder,
and
nelem
are
ignored and the values specified when the tree was created are used.
If a hash function is specified,
hash_open
will attempt to determine if the hash function specified is the same as
the one with which the database was created, and will fail if it is not.
Backward-compatible interfaces to the routines described in
dbm(3),
and
ndbm(3)
are provided, however these interfaces are not compatible with
previous file formats.
ERRORS
The
hash
access method routines may fail and set
errno
for any of the errors specified for the library routine
dbopen(3).

SEE ALSO
btree(3),
dbopen(3),
mpool(3),
recno(3)
Dynamic Hash Tables,
Per-Ake Larson, Communications of the ACM, April 1988.
A New Hash Package for UNIX,
Margo Seltzer, USENIX Proceedings, Winter 1991.
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- ERRORS
-
- BUGS
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: 02:55:08 GMT, September 18, 2014


Reconstructing cancer cell metastasis model in in-vitro
By well controled chemical gradients and ECM properties, we can construct invasion microenviroment in vitro to observe and study the invasion process in real time.
Physics of Cancer: The Impact of Heterogeneity
The review shows how the developing field of the physics of biological heterogeneity can help us understand and quanti- fy the emergent heterogeneity that makes cancer such a fundamental puzzle.
R-loops and nicks initiate DNA breakage and genome instability in non-growing Escherichia coli
The transcriptional RNA/DNA hybrids (R-loops) generate DNA ends that underlie stress-induced mutation and amplifi- cation.
US-CHINA PHYSICAL-SCIENCES ONCOLOGY ALLIANCE
There are 4 leading institutions, which build a US-China Physical-Sciences Oncology Alliance (US-China PS-OA).
BAYLOR COLLEGE OF MEDICINE
Physical-Sciences Oncology Alliance
Baylor College of Medicine, Houston, Texas
INSTITUTE OF PHYSICS CHINESE ACADEMY OF SCIENCES
Physical-Sciences Oncology Alliance
Institute of Physics Chinese Academy of Sciences ,beijing
A new experiment about cancer
he invasion process in real time.Here is a video from TED (Talk Every Day) , which describe a new experiment about cancer.It can help us to study cancer in an interesting way.
Yigong Shi gave an interview to Ivy Forum
Yigong Shi, the dean of School of Life Sciences of Tsinghua University. He received an interview from Ivy Forum. He talked about his experiment and research in this video.
Act Now Save Lives Stand Up To Cancer
The video shows that we will suffer a lot of pain if our rela- tives got cancer. Cancer may ruin an entire family, so we’d better act now save lives stand up to cancer.
Reconstructing cancer cell metastasis model in in-vitro
By well controled chemical gradients and ECM properties, we can construct invasion microenviroment in vitro to observe and study the invasion process in real time.
Physics of Cancer: The Impact of Heterogeneity
The review shows how the developing field of the physics of biological heterogeneity can help us understand and quanti- fy the emergent heterogeneity that makes cancer such a fundamental puzzle.
R-loops and nicks initiate DNA breakage and genome instability in non-growing Escherichia coli
The transcriptional RNA/DNA hybrids (R-loops) generate DNA ends that underlie stress-induced mutation and amplifi- cation.


{% extends "core/email/common.html" %}
{% block content %}
The build.image
config key on .readthedocs.yaml
has been deprecated, and will be removed on October 16, 2023.
We are sending weekly notifications about this issue to all impacted users,
as well as temporary build failures (brownouts) as the date approaches for those who haven't migrated their projects.
The timeline for this deprecation is as follows:
build.os
on your configuration file to ensure that they continue building successfully and to stop receiving these notifications.
If you want to opt-out from these emails, you can edit your preferences in your account settings.
For more information on how to use build.os
,
read our blog post
Get in touch with us via our support
and let us know if you are unable to use a configuration file for any reason.
{% endblock %}


---
layout: single
title: Survey About Crime Investigation Priority
date: '2012-08-09T20:36:00.000+09:00'
author: Joshua James
tags:
- Survey
- Research
modified_time: '2012-08-09T22:06:25.631+09:00'
blogger_id: tag:blogger.com,1999:blog-2701259639305045003.single-5131562961287602332
blogger_orig_url: http://www.cybercrimetech.com/2012/08/survey-about-crime-investigation.html
---