Re: [Haskell-cafe] Haskell RPC
Thank you Bjorn! I'll take a look but it sounds like exactly what I'm looking for! On May 30, 2006, at 2:35 AM, Bjorn Bringert wrote: Hi Joel, the attached example is a simple RPC library. It uses show and read for serialization, and some type class tricks to allow functions with different arities. This is essentially the HaXR (http:// www.haskell.org/haxr/) API, but without the XML, HTTP and error reporting stuff. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LDIF output library
Hi, does anybody know of a library for writing LDIF files? If not, I may create one, and would be grateful for suggestions. Is it worth integrating with John Goerzen's LDAP binding, for example? -- Thanks, Feri. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On GADT, phantom types, etc. terminology
On Mon, May 29, 2006 at 07:49:20PM -0700, [EMAIL PROTECTED] wrote:
David Roundy wrote:
I want the return type d to be a phantom type of some sort (although
I'm not clear on the distinction between phantom and existential
types).
Well, they are, in a sense, dual to each other. [...]
Thanks for the explanation! :)
David Roundy wrote:
when I realized that the problem could be solved much more
elegantly using GADTs as a type witness (with unsafeCoerce#,
admittedly)
That is quite puzzling: the whole advantage of GADTs is that we don't
need to coerce values because type coercion, after checking the
run-time evidence (that is, successful pattern-match) is the very
essence of GADTs.
The coersion is needed in order to generate the runtime evidence. If
two patches (in identical context) are read from two repositories, we
need to compare them at runtime in order to determine if their types
are identical (which is the case if their contents are identical), so
we have a function like
data IsEq a b where
Eq :: IsEq a a
NotEq :: NotEq a b
(=\/=) :: Patch a b - Patch a c - IsEq b c
p1 =\/= p1 = if (check contents are equal) p1 p2
then unsafeCoerce# IsEq
else NotEq
which generates the runtime proof that the types b and c are actually
identical. We need to coerce the type in order to add an additional
constraint here. I don't think we can do this with only access to
constructors, because that would make the code fail to typecheck.
Which is the point, that with the above IsEq and phantom types, only
with unsafeCoerce# (or if the two types have a common origin) can you
generate evidence that two types are the same.
David Roundy wrote:
Can someone explain to me why this doesn't work?
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
module MPTC where
class C a b c d | a b c - d, a d c - b
instance (C a b c d) = C a d c b
data P a b = P deriving (Show)
data CommuteResult a b c where
CR :: C a b c d = (P a d, P d c) - CommuteResult a b c
When we abstract over |d|, there is generally no way to get the
original type back (short of various casts, which generally require
run-time evidence). One can think of it as upcast/downcast problem in
OO: we can always pretend that an object of the type A is an object of
a more general type ASuper (and any object is an object of the Top
type). However, downcasting from a value of a more general type to the
value of a more specific type requires some run-time evidence (even if
the more general value was obtained by the upcast from the desired
specific type). The nature of abstraction is to irreversibly forget --
hence the encapsulation guarantee. If that is not desired, we can use
some other translucent, type-preserving, ways. For example,
I generally understand, but would have thought that the class and its
functional dependencies would stand as proof that the two d's are
identical. I agree that we can't extract *what* the type d is, but
given the above FD, we should be able to know that if
(C a b c d) and (C a b c e)
then d and e are the same type. What else is the use of functional
dependencies?
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
module MPTC where
data P a b = P deriving (Show)
data CommuteResult a b c = forall d. CR (P a (d b), P (d b) c)
commute :: (P a (d b), P (d1 b) c) - CommuteResult a b c
commute (P, P) = CR (P, P)
test (x,y) = do CR (y',x') - return $ commute (x,y)
CR (y'', x'') - return $ commute (x,y)
CR (x''',y''') - return $ commute (y',x'')
return ()
which type-checks...
But with the above code,
test (x,y) = do CR (y',x') - return $ commute (x,y)
CR (y'', x'') - return $ commute (x,y)
CR (x''',y''') - return $ commute (x'',y')
return ()
also typechecks, which is to say that we've missed the point of the
exercise.
David Roundy wrote:
I guess what hasn't been addressed is the question I didn't know to ask...
It would help me personally to see the `ideal' code -- the code that
you wish to write and to typecheck. The code should be sufficiently
realistic (the IO can be stubbed though). I'll be out of town for a
week so unable to reply promptly.
Okay. qHere's my dream code. I've commented out and marked with
currently fails any tests that I can't already pass with my existing
GADT-based (no classes involved) code. Actually, there are more
properties that I'd like to implement, but this is a start, and just
being able to do this would still be very nice.
So the point is that all the currently fails code should typecheck
when uncommented, and the Must fail code must cause the typecheck to
fail.
module Main where
import PatchCode ( P ( P ), commute, CommuteResult ( CR ) )
main = test (P, P, P)
sametype :: a - a - IO ()
sametype _ _ = return ()
test
Re: [Haskell-cafe] String to binary tree
On 5/30/06, Thorkil Naur [EMAIL PROTECTED] wrote: Hello, It seems that what you need is the technique of evaluating an expression in reverse polish notation by using a stack. This technique is well known in subjects related to compiler construction. Basically, the expression (list of operands and operators) is processed sequentially from left to right. If an operand (in your case: A character c for which isNumber c is true) is encountered, it is pushed onto the stack. If an operator (in your case: A character c for which isLetter is true) is enountered, it pops its operands (one or more) from the top of the stack and pushes the result of applying the operator to the operands back onto the stack. The following code sketch uses this idea: ... import Char ... isNumber = isDigit isLetter = isAlpha cvBase stack c | isNumber c = Folha c:stack cvBase (tr:tl:stack) c | isLetter c = Node c tl tr : stack cv s = let [t] = foldl cvBase [] s in t Example using Hugs: Main cv 12H3V Node 'V' (Node 'H' (Folha '1') (Folha '2')) (Folha '3') Main A bit OT perhaps, but I'd just like to point out this wonderful little code snippet from the Haskell wiki-page that I've always liked, in case nobody's seen it: calc :: String - Float calc = foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs That's it. An RPN evaluator in a couple of lines. -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to binary tree
Hello, Both my Hugs and my GHCi report a type error when presented with this. A possible repaired version looks like this: calc :: String - Float calc = g . foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs g [r] = r Not as small, but still quite nice. Regards Thorkil On Tuesday 30 May 2006 15:10, Sebastian Sylvan wrote: A bit OT perhaps, but I'd just like to point out this wonderful little code snippet from the Haskell wiki-page that I've always liked, in case nobody's seen it: calc :: String - Float calc = foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs That's it. An RPN evaluator in a couple of lines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
Mathew Mills wrote:
With Haskell's lovely strong static typing, it is a crying shame we
don't have an editor with immediate feedback, ala Eclipse.
I've started writing an editor for Haskell. (It will be a commercial
product)
The first prototype was in C - now I'm re-writing from scratch in Haskell.
It is quite a tall order to provide immediate typed feedback of an edit
buffer that will in general be syntactically incomplete but this is my
eventual aim.
One issue in the area of immediate feedback is that Haskell's syntax is
troublesome in a few areas. Consider:
foo :: SomeClass a = a - a
when the user has just typed:
foo :: SomeClass a
should the editor assume SomeClass is a Tycon or a class name?
One idea I had to solve this problem was to change the syntax of Haskell
slightly so that constraints would be enclosed in {} instead of preceeding
= ie:
foo :: {SomeClass a} a-a
so that in
foo :: {SomeClass
it is already determined that SomeClass must be a class name.
Another thing which causes difficulty is the use of qualified operators, and
the fact that the qualification syntax is in the context free grammar
instead of being kept in the lexical syntax (where I think it belongs). For
example, afaiu according to H98 (but not GHCi) it is permissible to write:
a Prelude . + b
-- qvarsym - [ modid . ] varsym
whereas in my prototype I put all this into a level immediately above the
lexer but below the CFG so that no spaces are allowed thus:
a Prelude.+ b-- no spaces in the qvarsym
a `Prelude.(+)` b-- a little generalization
a `Prelude.(+) b-- no need for closing `
(The generalization above is intended for when you don't know whether or not
the function you're qualifying has been declared as an operator but you want
to use it as an operator eg if a pop-up list would appear after you typed
`Prelude. with entries such as (+) plus add etc)
With the above changes, it is possible to parse Haskell (or at least as much
as I got round to implementing in my C++ prototype) using a simple
deterministic recursive descent parser with only 1 token of lookahead.
(There is possibly some confusion in the H98 report about exactly how
ambiguous expressions involving typed case alternatives might be parsed eg x
:: a-b - if x 4 then ... but I'm hoping it will be ok to just fix the
syntax here by requiring extra brackets)
Anyway I suppose the point of this post is to see whether or not people feel
that such changes are acceptable in an editor, or whether an editor must
adhere exactly to the standard (or whether the standard can be changed to
enable the determinism and ease of parsing necessary for interactive editing
with immediate feedback)?
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
On Tuesday 30 May 2006 20:59, Brian Hulley wrote:
It is quite a tall order to provide immediate typed feedback of an
edit buffer that will in general be syntactically incomplete but this
is my eventual aim.
One issue in the area of immediate feedback is that Haskell's syntax
is troublesome in a few areas. Consider:
foo :: SomeClass a = a - a
when the user has just typed:
foo :: SomeClass a
should the editor assume SomeClass is a Tycon or a class name?
If SomeClass has been defined somewhere (in the same buffer or in some
imported module), the editor will know whether it is a class or a type
and can react accordingly (e.g. propose to insert '=' or use a special
color for 'SomeClass'). If not, then the editor should remain agnostic.
What is the problem here? No user will expect the editor to
unambigously parse /incomplete/ code, or will they?
One idea I had to solve this problem was to change the syntax of
Haskell slightly so that constraints would be enclosed in {} instead
of preceeding = ie:
foo :: {SomeClass a} a-a
so that in
foo :: {SomeClass
it is already determined that SomeClass must be a class name.
Another thing which causes difficulty is the use of qualified
operators, and the fact that the qualification syntax is in the
context free grammar instead of being kept in the lexical syntax
(where I think it belongs). For example, afaiu according to H98 (but
not GHCi) it is permissible to write:
a Prelude . + b
-- qvarsym - [ modid . ] varsym
whereas in my prototype I put all this into a level immediately above
the lexer but below the CFG so that no spaces are allowed thus:
a Prelude.+ b-- no spaces in the qvarsym
a `Prelude.(+)` b-- a little generalization
a `Prelude.(+) b-- no need for closing `
(The generalization above is intended for when you don't know whether
or not the function you're qualifying has been declared as an
operator but you want to use it as an operator eg if a pop-up list
would appear after you typed `Prelude. with entries such as (+) plus
add etc)
With the above changes, it is possible to parse Haskell (or at least
as much as I got round to implementing in my C++ prototype) using a
simple deterministic recursive descent parser with only 1 token of
lookahead.
(There is possibly some confusion in the H98 report about exactly how
ambiguous expressions involving typed case alternatives might be
parsed eg x
:: a-b - if x 4 then ... but I'm hoping it will be ok to just fix
:: the
syntax here by requiring extra brackets)
Anyway I suppose the point of this post is to see whether or not
people feel that such changes are acceptable in an editor, or whether
an editor must adhere exactly to the standard (or whether the
standard can be changed to enable the determinism and ease of parsing
necessary for interactive editing with immediate feedback)?
I would not like an editor that forces me to use a special coding style
(like using brackets where not strictly necessary). Even less would I
like to use one that introduces non-standard syntax.
My humble opinion is that you'll have to bite the bullet and implement
your syntax recognizer so that it conforms to Haskell'98 (including the
approved addenda) [and addtionally however many of the existing
extensions you'll manage to support]. It may be more difficult but in
the end will also be a lot more useful. And you'll have to find a way
to (unobtrusively!) let the user know whether some piece of code does
not yet have enough context to parse it unambigously.
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] changing out
hello, i want to change my input integers In 23 98 Out 98 23 I think its simple... sorry my first steps in Haskell thanks for solutions. -- View this message in context: http://www.nabble.com/changing+out-t1707014.html#a4634189 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to binary tree
On 5/30/06, Thorkil Naur [EMAIL PROTECTED] wrote: Hello, Both my Hugs and my GHCi report a type error when presented with this. A possible repaired version looks like this: calc :: String - Float calc = g . foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs g [r] = r Not as small, but still quite nice. ..or you could just have it return [Float], maybe that's the intention (you could do several computations). Or throw in a head in there instead of defining a new function. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] changing out
Hi, i want to change my input integers In 23 98 Out 98 23 Can you explain what the bigger goal behind this is? It really depends on exactly what you want to do, if you want a function that takes a pair of integers and flips the pair, that's easy enough: f (x,y) = (y,x) But I guess you have a bigger purpose? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
Benjamin Franksen wrote:
On Tuesday 30 May 2006 20:59, Brian Hulley wrote:
It is quite a tall order to provide immediate typed feedback of an
edit buffer that will in general be syntactically incomplete but this
is my eventual aim.
One issue in the area of immediate feedback is that Haskell's syntax
is troublesome in a few areas. Consider:
foo :: SomeClass a = a - a
when the user has just typed:
foo :: SomeClass a
should the editor assume SomeClass is a Tycon or a class name?
If SomeClass has been defined somewhere (in the same buffer or in some
imported module), the editor will know whether it is a class or a type
and can react accordingly (e.g. propose to insert '=' or use a
special color for 'SomeClass'). If not, then the editor should remain
agnostic. What is the problem here? No user will expect the editor to
unambigously parse /incomplete/ code, or will they?
But the buffer will nearly always be incomplete as you're editing it.
I was kind of hoping that the syntax of Haskell could be changed so that for
any sequence of characters there would be a unique parse that had a minimum
number of gaps inserted by the editor to create a complete parse tree, and
moreover that this parse could be found by deterministic LL1 recursive
descent.
Haskell already seems so very close to having this property - its a real
pity about =
The problem is: when Haskell was designed, no one seems to have thought
about the syntax from the point of view of making it easy to parse or
ensuring that it would have this nice property for editing.
foo :: {SomeClass a} a-a
a Prelude.+ b-- no spaces in the qvarsym
a `Prelude.(+)` b-- a little generalization
a `Prelude.(+) b-- no need for closing `
I would not like an editor that forces me to use a special coding
style (like using brackets where not strictly necessary). Even less
would I like to use one that introduces non-standard syntax.
My humble opinion is that you'll have to bite the bullet and implement
your syntax recognizer so that it conforms to Haskell'98 (including
the approved addenda) [and addtionally however many of the existing
extensions you'll manage to support]. It may be more difficult but in
the end will also be a lot more useful. And you'll have to find a way
to (unobtrusively!) let the user know whether some piece of code does
not yet have enough context to parse it unambigously.
Thanks for the feedback - I suppose I was being overly optimistic to think I
could just change the language to suit my editor ;-).
I'll have to find a balance between what I'm able to implement and what is
specified in Haskell98 (or Haskell' etc) - just as GHCi has done with
qvarsym, and perhaps have different levels of conformance to H98 so people
could choose their preferred balance between conformity and
instantaneousness of feedback (everything would of course still be
loaded/saved as H98).
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
On 2006 mei 30, at 17:33, Brian Hulley wrote:
But the buffer will nearly always be incomplete as you're editing it.
I was kind of hoping that the syntax of Haskell could be changed so
that for
any sequence of characters there would be a unique parse that had a
minimum
number of gaps inserted by the editor to create a complete parse
tree, and
moreover that this parse could be found by deterministic LL1 recursive
descent.
If you use my parsercombinators, and are willing to work on the
grammar I think this can in principle be done. The combinators
automatically correct incorrect (i.e. in this case incomplete)
input, but:
- you may really need some time to tune the grammar so the
corrections are what a user might expect (there are many hooks for
doing so, but it will takje some effort, since this s also a human
interface issue)
- making a Haskell grammar that parsers top-down is not an easy
task, and making it LL1 is definitely impossible, but also not needed
if you use my combinators
- we could in principle provide you with a complete parser for
Haskell using our combinators that was tested by replacing the GHC
parser with this parser, and that worked (contact [EMAIL PROTECTED] to
get a copy of his code)
- did you think about how to handle the offside rule? If not, the
good news is that we have combinators for that too.
Doaitse Swierstra
Haskell already seems so very close to having this property - its a
real
pity about =
Not only the =, but e.g. the commonality between patterns and
expressions makes left factorisation a not so simple task.
The problem is: when Haskell was designed, no one seems to have
thought
about the syntax from the point of view of making it easy to parse or
ensuring that it would have this nice property for editing.
foo :: {SomeClass a} a-a
a Prelude.+ b-- no spaces in the qvarsym
a `Prelude.(+)` b-- a little generalization
a `Prelude.(+) b-- no need for closing `
I would not like an editor that forces me to use a special coding
style (like using brackets where not strictly necessary). Even less
would I like to use one that introduces non-standard syntax.
My humble opinion is that you'll have to bite the bullet and
implement
your syntax recognizer so that it conforms to Haskell'98 (including
the approved addenda) [and addtionally however many of the existing
extensions you'll manage to support]. It may be more difficult but in
the end will also be a lot more useful. And you'll have to find a way
to (unobtrusively!) let the user know whether some piece of code does
not yet have enough context to parse it unambigously.
Thanks for the feedback - I suppose I was being overly optimistic
to think I
could just change the language to suit my editor ;-).
I'll have to find a balance between what I'm able to implement and
what is
specified in Haskell98 (or Haskell' etc) - just as GHCi has done with
qvarsym, and perhaps have different levels of conformance to H98 so
people
could choose their preferred balance between conformity and
instantaneousness of feedback (everything would of course still be
loaded/saved as H98).
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie: Applying Unknown Number Arguments to A Partial Function
Aditya Siram wrote:
] I am trying to write a function 'applyArguments' which takes a
] function and a list and recursively uses element each in the list as
] an argument to the function. I want to do this for any function taking
] any number of arguments.
]
] applyArgument f (arg) = f arg
] applyArgument f (arg:args) = applyArgument (f arg) args
]
] This has failed in Hugs, so my question is: Can I conceptually do
] this? If so, what is the type signature of this function?
OK, here's a program that is similar to your applyArgument. Instead
of the arguments in a list, it stores them in a nested tuple, so that we
can have different types of arguments. You'll have to use the -98
option when using Hugs. Also, it doesn't seem to interact well with
type inference, so I had to provide type signatures for the function f
and some of the parts of args. Anyone know of a better way to define
Apply so we could eliminate these type signatures?
{-# OPTIONS -fglasgow-exts #-}
class Apply x y z | x y - z where
apply :: x - y - z
instance Apply (a-b) a b where
apply f x = f x
instance Apply b as c = Apply (a-b) (a,as) c where
apply f (x,xs) = apply (f x) xs
f :: Int - Double - String - Bool - Int
f x y z True = x + floor y * length z
f x y z False= x * floor y + length z
args = (1::Int,(3.1415::Double,(flub,True)))
main = print $ apply f args
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
On Tue, May 30, 2006 at 10:33:05PM +0100, Brian Hulley wrote: I was kind of hoping that the syntax of Haskell could be changed so that for any sequence of characters there would be a unique parse that had a minimum number of gaps inserted by the editor to create a complete parse tree, and moreover that this parse could be found by deterministic LL1 recursive descent. a problem is that people don't write code like they write novels. At least I don't. I skip around, adding the beginning and ending of functions and going back and filling in the center, or writing the = first, then the type and going back and filling in the context. or taking existing code and changing it in pieces, deleting something there, adding it somewhere else, changing names, all of which leave intermediate states that arn't just truncated programs. I don't see such a property actually helping that much in terms of this problem. I think you have no choice but to use heuristics to decide what the user intends and try to limit the scope of potentially incomplete source souring later things typed. Although not as popular as they once were, error correcting parsers is a fairly advanced field in computer science, combined with the knowledge of what names are in scope, I think you can come up with fairly robust heuristics. It is by no means a trivial problem, but it is certainly a tractable one. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
Well, my thesis (many moons ago I assure you) was on syntax directed editors. I came to the conclusion that letting the user do what they want is a requirement, but that "heuristics" and other "smarts" were to be avoided on the grounds that at least for my implementation they were more trouble than they were worth. Thus I would avoid error correcting parsers unless you are very confident that the correction used is at least type-safe and that it is not "sticking things in" that are unwanted (or even more maddening removing what I just typed and which **was** what I wanted). So my recommendation is that pointing out where the syntax and typing errors are without having to leave the editor would be great. Then the time required to actually make the corrections is minimal in terms of overall development time. The "interesting" (graveyard laugh) problems revolve around editing a library and the program that uses it at the same time with a few obvious extensions. The "graveyard laugh" is because I rapidly found I needed transactions and as the implementation was in C++ it had some very nasty pointer issues going to and from disk. Performance was also an issue --- but that was a a pre-sparc SUN, M68020 w/ 4Meg of RAM if memory serves me correctly. Good Luck. John Meacham wrote: On Tue, May 30, 2006 at 10:33:05PM +0100, Brian Hulley wrote: I was kind of hoping that the syntax of Haskell could be changed so that for any sequence of characters there would be a unique parse that had a minimum number of "gaps" inserted by the editor to create a complete parse tree, and moreover that this parse could be found by deterministic LL1 recursive descent. a problem is that people don't write code like they write novels. At least I don't. I skip around, adding the beginning and ending of functions and going back and filling in the center, or writing the = first, then the type and going back and filling in the context. or taking existing code and changing it in pieces, deleting something there, adding it somewhere else, changing names, all of which leave intermediate states that arn't just truncated programs. I don't see such a property actually helping that much in terms of this problem. I think you have no choice but to use heuristics to decide what the user intends and try to limit the scope of potentially incomplete source souring later things typed. Although not as popular as they once were, error correcting parsers is a fairly advanced field in computer science, combined with the knowledge of what names are in scope, I think you can come up with fairly robust heuristics. It is by no means a trivial problem, but it is certainly a tractable one. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
On Wednesday 31 May 2006 11:32, George Beshers wrote: Well, my thesis (many moons ago I assure you) was on syntax directed editors. I came to the conclusion that letting the user do what they want is a requirement, but that heuristics and other smarts were to be avoided on the grounds that at least for my implementation they were more trouble than they were worth. Thus I would avoid error correcting parsers unless you are very confident that the correction used is at least type-safe and that it is not sticking things in that are unwanted (or even more maddening removing what I just typed and which **was** what I wanted). I certainly agree. I've ended up loathing any editor which unilaterally decides to change what I've typed. That _might_ be because they weren't done properly... maybe. So my recommendation is that pointing out where the syntax and typing errors are without having to leave the editor would be great. Then the time required to actually make the corrections is minimal in terms of overall development time. It might have been mentioned before but I think IntelliJ's 'Idea' does an excellent job as a java editor. It'd be worth looking at for... ideas, as it were. It doesn't automatically correct anything, when it detects an error it makes it obvious by highlighting the offending code, putting marks on the scrollbar and colouring an indicator. When the cursor is on an error you can hit a key-combo to bring up a list of potential remedial actions. The interesting (graveyard laugh) problems revolve around editing a library and the program that uses it at the same time with a few obvious extensions. The graveyard laugh is because I rapidly found I needed transactions and as the implementation was in C++ it had some very nasty pointer issues going to and from disk. Performance was also an issue --- but that was a a pre-sparc SUN, M68020 w/ 4Meg of RAM if memory serves me correctly. Idea is, more or less, transactional. It's 'refactorings' can affect multiple entities, and they're stored in a local history so you can rollback when you want to. I'm not sure it'd run too well on that sort of machine though. :) For what it's worth, I'd love a Haskell editor the likes of Idea (and better). Lots of refactory-goodness, auto-importing of functions, function suggestion from type, display of inferred types, etc, etc, etc Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editors for Haskell
On Wed, May 31, 2006 at 12:19:40PM +1200, Daniel McAllansmith wrote: On Wednesday 31 May 2006 11:32, George Beshers wrote: Well, my thesis (many moons ago I assure you) was on syntax directed editors. I came to the conclusion that letting the user do what they want is a requirement, but that heuristics and other smarts were to be avoided on the grounds that at least for my implementation they were more trouble than they were worth. Thus I would avoid error correcting parsers unless you are very confident that the correction used is at least type-safe and that it is not sticking things in that are unwanted (or even more maddening removing what I just typed and which **was** what I wanted). I certainly agree. I've ended up loathing any editor which unilaterally decides to change what I've typed. That _might_ be because they weren't done properly... maybe. Oh, I did not mean error correcting parsers as in something that would change what you wrote, I meant ones that can deal with parse errors in a local fashion without catastrophically failing to parse the whole program. Parsers that can recover from incomplete input. parser combinators might be a better solution as their grammer can actually be guided and changed by what is in scope rather than fixed at the parser generator phase. editors should never change what the person wrote in general without some prodding by the user IMHO. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to binary tree
Hello Nuno, Monday, May 29, 2006, 10:53:30 PM, you wrote: I have this type which represents polish expressions (floorplan representation): data PeAux a = Folha Char | Nodo Char (PeAux a) (PeAux a) deriving Show The reverse polish expression are the result of doing a post order visit to the tree to be exact, tree represents an expression itself while you can get _linear_ text from it in polish postfix/prefix or ordinary infix notation by applying various visiting strategies -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] State Variables
Hello Matthew, Monday, May 29, 2006, 10:54:36 PM, you wrote: If possible I'd like to memory manage on the Haskell side. All of the calls to BLAS and LAPACK that I'm aware of assume that all arrays are allocated outside of the C or Fortran that implement the matrix algorithms. They never return buffers to newly allocated arrays. So what I'd like to do is something like allocate an array in Haskell, freeze it and extract a pointer, send it to the C code, and then unfreeze it. That way I benefit from Haskell's garbage collector. Explicitly managing memory is a huge bug generator in C and C++. In fact I'd say it's number one on the list. So can I modify Foreign Array to achieve this, or do I just end up with essentially a Storable Array? you should use StorableArray. the speed drawbacks is larger overhead for each access to array in Haskell code, including uses of withStorableArray to call FFI operations. as far as most of your usage of these arrays is to pass their addresses to FFI calls that process many data (as opposite to FFI calls that process just several elements), you will see no much penalty Maybe it would be just easier to use 6.5, though heaven knows what sorts of bugs may be lurking there. I downloaded it already per your link. you can try to compile with it just to compare speed. then you will know how much you are lose (sorry for my awkward english) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
