I think Tilmann's way is the right way (because it is very clear when a
comma is missing since they align, unlike trailing commas), although the
original proposal is the popular way. I would rather get rid of commas
altogether (make them optional actually) and just have a newline +
consistent inden
sounds good. will there be a shadowing warning?
On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson
wrote:
> It's not often that one gets the chance to change something as
> fundamental as the scoping rules of a language. Nevertheless, I would
> like to propose a change to Haskell's scoping rule
I am starting up the proposal.
http://hackage.haskell.org/trac/haskell-prime/ticket/143
http://hackage.haskell.org/trac/haskell-prime/wiki/OpaqueText
Unfortunately I haven't had any time to work on this for the last week
and won't for 2 more weeks.
Your help is appreciated. I think the first step
Can the unicode experts here propose a Text API whose functions work
for all Unicode (start by removing list functions)? If there is such a
satisfactory API and it does not conflict with the Prelude we could
use it unqualified.
On Mon, Mar 26, 2012 at 10:21 AM, Johan Tibell wrote:
> On Mon, Mar 2
>>
>> I would like to get back to working on the proposal and determining
>> how Text can be added to the language.
>
> The discussion started because of the question of whether Text should
> support list processing functions at all, and if so how. That is a
> very legitimate
> question related to
lists are here to stay in Haskell.
I would like to get back to working on the proposal and determining
how Text can be added to the language.
Thank you,
Greg weber
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/lis
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis
wrote:
> On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson wrote:
>
>> In any case, this is hardly the place to to discuss how to best
>> teach Haskell or programming in general.
>
> Sure, I haven't seen any disagreement with that.
As interesting a
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
wrote:
> On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
>> Problem: we want to write beautiful (and possibly inefficient) code
>> that is easy to explain. If nothing else, this is pedagologically
>> important.
>>
# Switching to Text by default makes us embarrassed!
Problem: we want to write beautiful (and possibly inefficient) code
that is easy to explain. If nothing else, this is pedagologically
important.
The goals of this code are to:
* use list processing pattern matching and functions on a string ty
Can we all agree that
* Text can now demonstrate both CPU and RAM performance improvements
in benchmarks. Because Text is an opaque type it has a maximum
potential for future performance improvements. Declaring a String to
be a list limits performance improvements
* In a Unicode world, String = [C
> With regards to performance of fromString, I feel like if it was a
> serious problem (and how many really big strings are going to be built
> that way?) then an effort to do some special-case inlining (after all,
> the parameters are constant and specified at compile time) might be
> beneficial.
comparisons to
Perl 6 is not going to help move the discussion along!
On Fri, Mar 23, 2012 at 6:33 AM, Christian Siefkes
wrote:
> On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote:
>> 2012/3/22 Greg Weber :
>> But now we have at least two tasks to do before we can put up the
>>
Jean David
wrote:
> 2012/3/22 Greg Weber :
>> I am not trying to win an argument with anyone. Just trying to do what
>> is best for the community. Many others here have a better grasp of the
>> issue than me and can help answer questions and come up with a
>> solution.
ensure it can be implemented as smoothly as possible. It
does seem though that everyone thinks it is a good proposal.
On Thu, Mar 22, 2012 at 2:06 PM, ARJANEN Loïc Jean David
wrote:
> Le 22/03/2012 04:29, Greg Weber a écrit :
>
>> This proposal seems fairly uncontroversial at the mom
This proposal seems fairly uncontroversial at the moment. I would
really like it if someone more familiar with the proposal process can
take this proposal up and help make sure it gets in the next batch. I
can't even figure out how to create a wiki page for the proposal right
now :)
__
This is the best I can do with Bryan's blog posts, but none of the
graphs (which contain all the information) show up:
http://web.archive.org/web/20100222031602/http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/
If someone has some benchmarks that can be ran that would be help
I actually was not able to successfully google for Text vs. String
benchmarks. If someone can point one out that would be very helpful.
On Sat, Mar 17, 2012 at 1:52 AM, Christopher Done
wrote:
> On 17 March 2012 05:30, Tony Morris wrote:
>> Do you know if there is a good write-up of the benefits
the text library and Text data type have shown the worth in real world
Haskell usage with GHC.
I try to avoid String whenever possible, but I still have to deal with
conversions and other issues.
There is a lot of real work to be done to convert away from [Char],
but I think we need to take it out
with the
process for this mail-list and obviously led things in the wrong
direction.
On Sat, Feb 11, 2012 at 6:21 PM, Roman Leshchinskiy
wrote:
> On 12/02/2012, at 02:04, Greg Weber wrote:
>
>> I am sorry that I made the huge mistake in referencing future possible
>> proposals.
the one at hand.
Thank you!
Greg Weber
On Sat, Feb 11, 2012 at 5:39 PM, Roman Leshchinskiy
wrote:
> On 12/02/2012, at 01:29, Nate Soares wrote:
>
>> If -> was introduced for accessing fields, we'd have to discuss whether it
>> should have spaces around it. I'd
rns for now)? Or we
> could even keep (#) as a valid operator and just have it mean category/lens
> composition.
>
> Thanks,
> Dan
>
> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber wrote:
>>
>> Similar to proposal #20, which wants to remove it, but immediately
>&g
Similar to proposal #20, which wants to remove it, but immediately
less drastic, even though the long-term goal is the same.
This helps clear the way for the usage of the unspaced dot as a record
field selector as shown in proposal #129.
After this proposal shows clear signs of moving forward I wi
22 matches
Mail list logo
