On Feb 5, 2008 4:24 AM, John Meacham <[EMAIL PROTECTED]> wrote:
> now when it came to record selection I was deciding between a couple.
>
> <...snip.../>
>
> ...declare that any identifier that _begins_ with ' always
> refers to a label selection function
>
> 'x point
Say we go with 'x and allow
On Feb 5, 2008 2:28 AM, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> this principle allows to build programs in quick and easy way: we just
> add to objects implementations of all the methods required:
>
> e = new Entry {label := "Hi",
>color := blue,
>getValue := ge
[hm. should this discussion move to -cafe?]
On Feb 8, 2008, at 20:15 , Jonathan Cast wrote:
On 8 Feb 2008, at 4:43 PM, Dan Weston wrote:
Ouch. How would a human parse [apple'*'pear]
In this context, `parse error, tricky syntax'.
I kinda have that problem anyway given ' being permitted in
On Fri, Feb 08, 2008 at 04:43:43PM -0800, Dan Weston wrote:
> Ouch. How would a human parse [apple'*'pear]
>
> If this doesn't immediately scan as [ (*') (apple') (pear) ] to you (it
> doesn't to me) then maybe allowing ' in infix operators may not be the best
> thing.
Oh, I was thinking they wo
On 8 Feb 2008, at 4:43 PM, Dan Weston wrote:
Ouch. How would a human parse [apple'*'pear]
In this context, `parse error, tricky syntax'.
In general? Not as sure.
jcc
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/list
Ouch. How would a human parse [apple'*'pear]
If this doesn't immediately scan as [ (*') (apple') (pear) ] to you (it
doesn't to me) then maybe allowing ' in infix operators may not be the
best thing.
John Meacham wrote:
On Tue, Feb 05, 2008 at 08:01:07AM -0500, Cale Gibbard wrote:
I also li
On Tue, Feb 05, 2008 at 08:01:07AM -0500, Cale Gibbard wrote:
> I also like this idea. Retaining the ability to treat selection as a
> function easily is quite important, and this meets that criterion
> nicely. Also, in which case does this cause a program to break? It
> seems that you're only rein
2. List the possible features that “records” might mean. For example:
· Anonymous records as a type. So {x::Int, y::Bool} is a
type. (In Haskell as it stands, records are always associated with
a named data type.
· Polymorphic field access. r.x accesses a field in any
On Feb 6, 2008 12:19 PM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>So to clarify that statement. Honestly the number one problem I have
> with the current records system is that labels share the same namespace.
> This makes interfacing with any C library using structs quite painful. This
So to clarify that statement. Honestly the number one problem I have with the
current records system is that labels share the same namespace. This makes
interfacing with any C library using structs quite painful. This is why I say
that I don't really care which gets implemented. The current syst
On Feb 6, 2008 11:33 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
>
> This sort of disagreement means that nothing gets done. After my
> experience with the wiki page, I don't believe anything will get done
> until one of the core ghc developers makes some arbitrary decisions
> and implemen
This sort of disagreement means that nothing gets done. After my
experience with the wiki page, I don't believe anything will get done
until one of the core ghc developers makes some arbitrary decisions
and implements whatever they want to, which will then eventually
become part of the standard by
new record (x = 3,y = 4)
subtraction \r -> ( x = 3 | r - x)
replacement \r -> (x := 3 | r) (equivalent to the above)
type (x::Int,y::Char)
degenerate cases:
empty record (|)
subtracting a label (| r - x)
a record can always be determined by the presence of a '|' within
parenthesis.
One of the
On 05/02/2008, John Meacham <[EMAIL PROTECTED]> wrote:
> choice 2: use ', declare that any identifier that _begins_ with ' always
> refers to a label selection function
>
> 'x point
>
> (snip)
>
> none are fully backwards compatible. I am still not sure which I like
> the best, ' has a lot of appe
On Tue, Feb 05, 2008 at 05:57:24AM -0500, Cale Gibbard wrote:
> On 05/02/2008, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> > saveToFile x = writeToFile "data" (show x.getValue)
>
> Heh, I had to read this a couple times to figure out that it wasn't
> just a blatant type error, and that (.) there
On Feb 5, 2008 11:08 AM, Barney Hilken <[EMAIL PROTECTED]> wrote:
>
> This sort of disagreement means that nothing gets done. After my
> experience with the wiki page, I don't believe anything will get done
> until one of the core ghc developers makes some arbitrary decisions
> and implements what
> Everyone wants to add extensible records to Haskell.
well ... sure records are better than tuples ...
but interfaces (uh, classes) are still better IMHO
but anyway, is it possible to steal the
design of C#'s anonymous types (classes)?
if not, then why? (this might help
to clarify what we wan
The scoped labels paper has an interesting feature in this regard:
labels with different names can be swapped at will, but labels having
the same name (which is allowed) maintain their order.
- Cale
Yes, I know. The problem is that there are TOO MANY proposals, and
they are all fundamental
On 05/02/2008, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> On 05/02/2008, Barney Hilken <[EMAIL PROTECTED]> wrote:
> >
> > Should {label := "Hi", color := blue} and {color := blue, label :=
> > "Hi"} have the same type?
> >
>
> The scoped labels paper has an interesting feature in this regard
On 05/02/2008, Barney Hilken <[EMAIL PROTECTED]> wrote:
>
> Should {label := "Hi", color := blue} and {color := blue, label :=
> "Hi"} have the same type?
>
The scoped labels paper has an interesting feature in this regard:
labels with different names can be swapped at will, but labels hav
Everyone wants to add extensible records to Haskell. The problem is
that, in a formally defined language like Haskell, we need to agree
how they should behave, and there are too many conflicting ideas.
I was involved recently in an attempt to try to sort out some of the
alternatives (record
On 05/02/2008, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> Personally, I think pt{x} for extracting the x field of pt seems
> not-so-unreasonable, and meshes
> well with the existing syntax for record updates.
I should clarify -- this is only if we can't somehow keep the existing
function syntax fo
On 05/02/2008, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> saveToFile x = writeToFile "data" (show x.getValue)
Heh, I had to read this a couple times to figure out that it wasn't
just a blatant type error, and that (.) there doesn't mean function
composition. :)
On the matter of extensible recor
Hello haskell,
the principle of duck typing used in dynamic OOP languages such as
Ruby and Python, is simple: if some object supports Quack method, then
it can be passed to any routine that expects an object of some Duck type
this principle allows to build programs in quick and easy way: we just
24 matches
Mail list logo
