Re: [elixir-core:7919] Re: [Proposal] Create maybe(t) typespec

[Andrea Leopardi]

I second what Ben said. {:ok, t} | :error isn't doable as it isn't
"universal", sometimes you have just :ok and sometimes just :error for
example. I think both as far as clarity goes as well as as far as
conciseness goes the best solution is to use nil | t.

On Tue, 27 Feb 2018 at 13:31, Ben Wilson  wrote:

> maybe(t) is traditionally `Some(t) | None`, which isn't really the same as
> `nil | t`. The closest analogue would seem to me to be `{:ok, t} | :error`
> although that doesn't quite communicate the same thing.
>
>
> On Tuesday, February 27, 2018 at 7:11:39 AM UTC-5, Yordis Prieto wrote:
>>
>> Introducing `maybe(t)` it will reduce the boilerplate code for `nil |
>> something`
>>
>> It is more convenience to write it this way, at least for me.
>>
>> What are your thoughts about it?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/3b39e876-4286-4602-955a-de513d4dfc27%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Andrea Leopardi
an.leopa...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJ6O%2BVyhYiOtZrChW5%2ByB2TLK10EHS9s0Lw1qrGqzJYbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7919] Re: [Proposal] Create maybe(t) typespec

[Ben Wilson]

maybe(t) is traditionally `Some(t) | None`, which isn't really the same as 
`nil | t`. The closest analogue would seem to me to be `{:ok, t} | :error` 
although that doesn't quite communicate the same thing.

On Tuesday, February 27, 2018 at 7:11:39 AM UTC-5, Yordis Prieto wrote:
>
> Introducing `maybe(t)` it will reduce the boilerplate code for `nil | 
> something` 
>
> It is more convenience to write it this way, at least for me.
>
> What are your thoughts about it?  
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/3b39e876-4286-4602-955a-de513d4dfc27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7918] [Proposal] Create maybe(t) typespec

[Yordis Prieto]

Introducing `maybe(t)` it will reduce the boilerplate code for `nil | 
something` 

It is more convenience to write it this way, at least for me.

What are your thoughts about it?  

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/419ed2ec-5fad-41d6-851c-11b3386e4f32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7917] Enhancement request: parse character offsets for AST node

[Serge Smetana]

Hi,

Sounds reasonable but may not work as good. This may change a lot of user 
formatted code and produce extra diffs in tests. If we could only reformat 
a part of the AST (one function call in our case) this would be ideal.

Thanks,
Serge.

On Monday, February 26, 2018 at 2:31:01 PM UTC+2, Louis Pop wrote:
>
> Hi there
>
> Given we have the formatter now I would be tempted to avoid editing 
> strings and instead update the AST of the file, render that to a string, 
> format it and write it back to the file. Would be more reliable.
>
> Cheers,
> Louis
>
> On Mon, 26 Feb 2018, 12:11 Serge Smetana,  > wrote:
>
>> Hi,
>>
>> I would like Elixir AST nodes to include begin and end parse character 
>> offsets.
>> This would make it easier to write refactoring tools that modify parts of
>> Elixir source files.
>>
>> Usecase:
>>
>> We have a library https://github.com/assert-value/assert_value_elixir 
>> that is
>> able to create and update expected values in tests. For example, given the
>> following:
>>
>> assert_value 2 + 2 == 2 + 3
>>
>> our code will find the location of `2 + 3` and replace it with `4`:
>>
>> assert_value 2 + 2 == 4
>>
>> Today determining the location of `2 + 3` in the source file is 
>> difficult.  For
>> now, we use a custom-made parser which processes code char by char until 
>> it gets
>> value matching AST:
>>
>> https://github.com/assert-value/assert_value_elixir/blob/master/lib/assert_value/parser.ex
>> But if we had the parse offsets it would be much easier.
>>
>> Proposed interface:
>>
>> Probably need two sets of offsets, exclusive and inclusive of children.  
>> For
>> each probably best to store beginning offset and length. Will need 
>> reasonable
>> handling for parentheses and other tokens that do not make it into AST.
>>
>> Existing implementation:
>>
>> Elixir AST nodes do have useful info on this already. We use the "line:" 
>> which
>> is very helpful. We don't use "column:", it did not seem useful given our
>> implementation.  We may be missing something obvious here.
>>
>> Details:
>>
>> In Elixir 1.6 compiled code AST has only function line number in meta. 
>> Even
>> "columns: true" in Code.string_to_quoted gives only function starting 
>> column
>> without information about arguments.
>>
>> Consider the following code:
>>
>> Code.string_to_quoted!("(41.00 == 42.)", columns: true)
>> #=> {:==, [line: 1, column: 8], [41.0, 42.0]}
>>
>> From the AST you don't know where to find 41.00 and 42. in a code.
>> Column information does not help. AST values of 41.0 and 42.0 don't have
>> information about how original values were formatted.
>>
>> Thanks,
>> Serge
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/4dbc37cc-6630-4989-acc0-c4acfd719a5b%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/644251b6-8b27-4836-98a3-a9feddcc29ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.