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 :=
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 it to pick
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
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
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
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 would
[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
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
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
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 implements
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
is
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
[redirecting to haskell-cafe]
On 2/6/08, Barney Hilken [EMAIL PROTECTED] wrote:
This is what I was trying to do with the wiki page. I stopped because
the only other contributor decided he could no longer contribute, and
I felt I was talking to myself. If we want to be rational about the
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 records,
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
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 having
the
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 for
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
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
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
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 whatever
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 doesn't
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 appeal to me
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
24 matches
Mail list logo
