headers
Thomas Leonard | 6 Oct 2011 12:35
Picon
Favicon
Gravatar

Interfaces / data types in E

We've got quite a few methods that take or return maps. e.g.

to purchase(customerDetails :Map[String,any]) {
   ... customerDetails["name"] ...
   ...
   if (problem) {
     notify(customerDetails["email"])
   }
   ...
}

The problem is that it's not obvious from the method signature what keys 
need to be present. Often someone fails to include a mapping, and the 
system only fails later in some case where it needed that value.

What I think I'd like to do is something like:

def CustomerDetails := makeNamedTuple([
	"name" => String,
	"email" => String,
])

...

to purchase(customerDetails :CustomerDetails]) {
   ... customerDetails["name"] ...
}

So that:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Reid | 6 Oct 2011 12:50
Favicon
Gravatar

Re: Interfaces / data types in E

On Oct 6, 2011, at 6:35, Thomas Leonard wrote:

> We've got quite a few methods that take or return maps. e.g.
> 
> to purchase(customerDetails :Map[String,any]) {
>   ... customerDetails["name"] ...
>   ...
>   if (problem) {
>     notify(customerDetails["email"])
>   }
>   ...
> }

When you say "We" do you mean the E project or one of yours?

> The problem is that it's not obvious from the method signature what keys 
> need to be present. Often someone fails to include a mapping, and the 
> system only fails later in some case where it needed that value.
> 
> What I think I'd like to do is something like:
> 
> def CustomerDetails := makeNamedTuple([
> 	"name" => String,
> 	"email" => String,
> ])
> 
> ...
> 
> to purchase(customerDetails :CustomerDetails]) {
>   ... customerDetails["name"] ...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Leonard | 6 Oct 2011 17:27
Picon
Favicon
Gravatar

Re: Interfaces / data types in E

On 2011-10-06 11:50, Kevin Reid wrote:
> On Oct 6, 2011, at 6:35, Thomas Leonard wrote:
>
>> We've got quite a few methods that take or return maps. e.g.
>>
>> to purchase(customerDetails :Map[String,any]) { ...
>> customerDetails["name"] ... ... if (problem) {
>> notify(customerDetails["email"]) } ... }
>
> When you say "We" do you mean the E project or one of yours?

One of mine.

>> The problem is that it's not obvious from the method signature what
>> keys need to be present. Often someone fails to include a mapping,
>> and the system only fails later in some case where it needed that
>> value.
>>
>> What I think I'd like to do is something like:
>>
>> def CustomerDetails := makeNamedTuple([ "name" =>  String, "email"
>> =>  String, ])
>>
>> ...
>>
>> to purchase(customerDetails :CustomerDetails]) { ...
>> customerDetails["name"] ... }
>
> I think this is a fine guard to have. For consistency with other
> parameterized guards, it should be written NamedTuple[[...]].
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Leonard | 20 Oct 2011 14:12
Picon
Favicon
Gravatar

easy-when-binds-return

People often try to use return inside when blocks. Currently, this just 
produces confusing "Ejector must be enabled" errors.

How about requiring the use of "return" to return a value from a when block?

There are a few places where this would be useful:

- Often you will move a whole block in to or out of a when() block. It's 
useful if you don't have to change all return lines when you do this.

- People sometimes don't notice that the value of the last expression is 
used, and put something after it.

e.g. they change

return when (foo) -> {
	foo.invoke()
}

to

return when (foo) -> {
	foo.invoke()
	traceln("here")
}

and then wonder why they're getting null pointer exceptions elsewhere.

- You can accidentally return a value, when all you intended was to tell 
the caller when you were done.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Reid | 20 Oct 2011 14:59
Favicon
Gravatar

Re: easy-when-binds-return

On Oct 20, 2011, at 8:12, Thomas Leonard wrote:

> People often try to use return inside when blocks. Currently, this just 
> produces confusing "Ejector must be enabled" errors.
> 
> How about requiring the use of "return" to return a value from a when block?

No.

We used to do that (along with otherwise treating the when-block more like a function), and decided it was
too heavyweight and confusing. This makes 'when' more like other control structures. In particular, it
is more like the user-defined control structures of the "lambda-args" pragma; we *expect* to find more
"eventual control structures" to want.

I will not support any change to 'when' which moves it farther from the semantics expressible by lambda-args.

I am also against making E more 'imperative style' given that it's not going to stop being a hybrid.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 21 Oct 2011 16:43
Picon
Favicon
Gravatar

for-must-match

Continuing with our experimental syntax changes to improve the 
reliability of E, here's a patch that adds a "for-must-match" feature.

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/3ad4f5c3072447647c617fdb56738bf929cb8a1a

(see also: http://wiki.erights.org/wiki/Surprise_list)

Normally in E, this silently skips the third item:

   for a:int in [1, 2, "hi"] {
     println(a)
   }

Now, it throws an exception:

   pragma.enable("for-must-match")

   for a:int in [1, 2, "hi"] {
     println(a)
   }

To make a loop that skips non-matching items as before, use the "match" 
keyword. e.g.

   pragma.enable("for-must-match")

   for match a:int in [1, 2, "hi"] {
     println(a)
   }
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thomas Leonard | 22 Oct 2011 14:17
Picon
Gravatar

Re: for-must-match

Here's a patch to add list comprehensions:

? def list := [1, 2, 3]
? [2 * x for x in list]
# value: [2, 4, 6]

http://gitorious.org/repo-roscidus/e-core/commit/9bfacc4f748b4ea6a7cf64dc40d7bc9dd1890d38

And for map comprehensions:

? def map := ["alice" => 50, "bob" => 60]
? [v => k for k => v in map]
# value: [50 => "alice", 60 => "bob"]

http://gitorious.org/repo-roscidus/e-core/commit/980c8c93d41a69f242acdb5b83c9faccf918f4c3

They don't currently support the 'match' keyword, so you can't use
them to filter (every item must be mapped to something).

--

-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
e-lang mailing list
e-lang <at> mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 5 comments |
headers
Kevin Reid | 22 Oct 2011 16:00
Favicon
Gravatar

Re: for-must-match

On Oct 22, 2011, at 8:17, Thomas Leonard wrote:

> Here's a patch to add list comprehensions:
> 
> ? def list := [1, 2, 3]
> ? [2 * x for x in list]
> # value: [2, 4, 6]
> 
> http://gitorious.org/repo-roscidus/e-core/commit/9bfacc4f748b4ea6a7cf64dc40d7bc9dd1890d38
> 
> And for map comprehensions:
> 
> ? def map := ["alice" => 50, "bob" => 60]
> ? [v => k for k => v in map]
> # value: [50 => "alice", 60 => "bob"]
> 
> http://gitorious.org/repo-roscidus/e-core/commit/980c8c93d41a69f242acdb5b83c9faccf918f4c3
> 
> They don't currently support the 'match' keyword, so you can't use
> them to filter (every item must be mapped to something).

I reject this proposal.

1. I am uncomfortable with it because I suspect it of violating E's syntactic conventions about scoping and
evaluation order, though I would have to consult MarkM to be more precise.

2. Furthermore, we already have the accumulator syntax which covers these use cases. I recognize that the
accumulator syntax is ugly; its problem is that it is both too general and not general enough. This
proposal is not general enough.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Leonard | 23 Oct 2011 12:41
Picon
Gravatar

Re: for-must-match

On 22 October 2011 15:00, Kevin Reid <kpreid <at> switchb.org> wrote:
> On Oct 22, 2011, at 8:17, Thomas Leonard wrote:
>
>> Here's a patch to add list comprehensions:
>>
>> ? def list := [1, 2, 3]
>> ? [2 * x for x in list]
>> # value: [2, 4, 6]
>>
>> http://gitorious.org/repo-roscidus/e-core/commit/9bfacc4f748b4ea6a7cf64dc40d7bc9dd1890d38
>>
>> And for map comprehensions:
>>
>> ? def map := ["alice" => 50, "bob" => 60]
>> ? [v => k for k => v in map]
>> # value: [50 => "alice", 60 => "bob"]
>>
>> http://gitorious.org/repo-roscidus/e-core/commit/980c8c93d41a69f242acdb5b83c9faccf918f4c3
>>
>> They don't currently support the 'match' keyword, so you can't use
>> them to filter (every item must be mapped to something).
>
>
> I reject this proposal.
>
> 1. I am uncomfortable with it because I suspect it of violating E's syntactic conventions about scoping
and evaluation order, though I would have to consult MarkM to be more precise.

It probably does. However, there's also consistency with other
languages to consider. The Wikipedia page has examples both ways,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Leonard | 24 Oct 2011 11:53
Picon
Gravatar

Re: for-must-match

On 22 October 2011 13:17, Thomas Leonard <talex5 <at> gmail.com> wrote:
> Here's a patch to add list comprehensions:
>
> ? def list := [1, 2, 3]
> ? [2 * x for x in list]
> # value: [2, 4, 6]
>
> http://gitorious.org/repo-roscidus/e-core/commit/9bfacc4f748b4ea6a7cf64dc40d7bc9dd1890d38
>
> And for map comprehensions:
>
> ? def map := ["alice" => 50, "bob" => 60]
> ? [v => k for k => v in map]
> # value: [50 => "alice", 60 => "bob"]
>
> http://gitorious.org/repo-roscidus/e-core/commit/980c8c93d41a69f242acdb5b83c9faccf918f4c3
>
> They don't currently support the 'match' keyword, so you can't use
> them to filter (every item must be mapped to something).

I've now added filtering:

http://gitorious.org/repo-roscidus/e-core/commit/b407e45a23ec942683fac84fc6156809321b805d

However, I didn't use the match syntax for this because, thinking
about it further, I don't think using pattern bindings is a good way
to test for a condition.

Consider a list of pairs [String,boolean] where we want to process all
the true values. With pattern matching (current E syntax), we'd write:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane