rinarakaki

TODO

• New type pattern
• Box, Arc, Rc, Vec, Option
  • FromIterator cannot be implemented for Option<T> so #[knuffel(child, unwrap(_))] approach can't be used
• Semantic difference between structs with and without fields (unit/tuple structs)
  • Enum variants with single Decode element without attribute vs variants with single scalar element with attribute
  • Do we need arguments/properties/children? Is there a case where a type can be used for both patterns?
  • Lack of documentation about tuple structs
• #[knuffel(child, unwrap(children(name)))] plugins: Vec instead of Vec doesn't work?

rinarakaki

Summary

Modify syntax to let you put mut in right hands when you instantiate structs to refine its mutability.

Syntax

Mutability of a itself but not a.*s.

let mut a = A { x: 0, y: 1 };

rinarakaki

Rules

Quantifier

We only use [ ] as quantifier not { } like [n], [m,n]. In expression [m,n], m or n can be omitted like [,n], [m,]. And you can't use *, +, and ? as quantifier anymore (first restriction).

Star

* is used as any single character with quantifier instead of .. For example *[1]hoge matches ahoge, bhoge, choge. Without quantifier, * operates as a wildcard, which means it is interpreted as *[0,] rather than *[1], so you can express partial matches like *hoge*, hoge*(forward match) and *hoge(backward match). Now you can't express them like ^hoge and hoge$ anymore (second restriction).

rinarakaki

Contents

• Install Haskell
• Install PostgreSQL

.bash_profile

export LC_ALL=C.UTF-8
export LANG=C.UTF-8

rinarakaki

I bring a strong proposal that is prematurely rejected but indeed the most likely to be accepted to our community. That is to select as spelling not :=, and modify with and except semantics at the same time. For that, we need to investigate what will be derived from the change throughly and here are the results.

Note

This alternative has already been out of consideration, PEP 572 says, but is still here because many Python developers are wondering if as spelling can go and there are few discussions about the way of modifing the two semantics. Even PEP 572 shows little attension to this possibility.

as semantics

https://docs.python.org/3/reference/grammar.html

rinarakaki

Type

# 'none' is a value
none of None

# 'True' and 'False' are higher-order exists
True is not False
False is not True
# TODO 'True or False' looks evaluation. Can this be a justification of 'type' keyword?