Re: [Haskell-cafe] Hacking Hawk
You may wish to read http://www.haskell.org/haskellwiki/Arrays which is quite a good tutorial on how the various array types and classes work. - Cale On 01/03/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hawk didn't updated from GHC v4.04. It does contain dependencies on > functions that are present in my current (6.04) GHC distribution, but > they are not documented. > > Those functions and constructors are (just a error log from ghc): > --- > AQ.lhs:17:16: Not in scope: type constructor or class `STArray' > > AQ.lhs:82:14: Not in scope: `newSTArray' > > AQ.lhs:92:21: Not in scope: `writeSTArray' > > AQ.lhs:258:27: Not in scope: `readSTArray' > > AQ.lhs:262:27: Not in scope: `writeSTArray' > --- > > They are in GHC.Arr module now. I found that googling for their name. > > They also changed their types so that they are not compatible with > Control.Monad.ST (previous versions were compatible with LazyST). > > What does they do? > > Is it possible to rewrite them for current version of ghc? > > ___ > 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] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote:
> However I think there is an error in the description of this in
> section 2.7 of the Haskell98 report, which states:
>
> "If the indentation of the non-brace lexeme immediately following a
> where, let, do or of is less than or equal to the current indentation
> level, then instead of starting a layout, an empty list "{}" is
> inserted, and layout processing occurs for the current level ..."
>
> I dispute the "or equal" in the above statement, since it seems to be
> clearly in contradiction to what is actually being done.
Section 2.7 does say that it is an informal description, so although it
is correct, it is not complete. In the case of the module header, the
question is really "what is the current indentation level?" (that we
must be strictly greater than). The answer can be found in the formal
definition of the layout rule in section 9.3. At the beginning of the
module, there is _no_ current indentation level - thus the fourth
equation of L applies.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Am Montag, 6. März 2006 12:30 schrieb Malcolm Wallace:
> Brian Hulley wrote:
> > However I think there is an error in the description of this in
> > section 2.7 of the Haskell98 report, which states:
> >
> > "If the indentation of the non-brace lexeme immediately following a
> > where, let, do or of is less than or equal to the current indentation
> > level, then instead of starting a layout, an empty list "{}" is
> > inserted, and layout processing occurs for the current level ..."
> >
> > I dispute the "or equal" in the above statement, since it seems to be
> > clearly in contradiction to what is actually being done.
>
> Section 2.7 does say that it is an informal description, so although it
> is correct, it is not complete. In the case of the module header, the
> question is really "what is the current indentation level?" (that we
> must be strictly greater than). The answer can be found in the formal
> definition of the layout rule in section 9.3. At the beginning of the
> module, there is _no_ current indentation level - thus the fourth
> equation of L applies.
>
> Regards,
> Malcolm
I think, the third from last equation of L applies, since
"If the first lexeme of a module is _not_ { or module, then it is preceded by
{n} where n is the indentation of the lexeme.", so we start L with
L ('module':ts) [].
Another thing that irritates me:
in section 9.5, we have the production
body-> { impdecls; topdecls }
| { impdecls }
| { topdecls }
The first line seems to suggest that import declaraions were admissible also
after topdecls, but any attempt to place an impdecl after a topdecl leads
--fortunately-- to a parse error in hugs and ghc, shouldn't the production be
body-> { impdecls }; { topdecls } ?
Cheers,
Daniel
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Credit Card Authorization code
On Thu, 02 Mar 2006, "S. Alexander Jacobson" <[EMAIL PROTECTED]> wrote: > I am looking for Haskell code that does credit card authorization? > e.g. paypal website pro does not supply a Haskell lib. I think that WASH/CGI contains code for doing some sort of checksum check on credit card numbers: http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/#washcgi -- /NAD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Daniel Fischer <[EMAIL PROTECTED]> wrote:
> > At the beginning of the module, there is _no_ current indentation
> > level - thus the fourth equation of L applies.
>
> I think, the third from last equation of L applies, since
> "If the first lexeme of a module is _not_ { or module, then it is
> preceded by {n} where n is the indentation of the lexeme.", so we
> start L with L ('module':ts) [].
Indeed, and thus, when we get to the end of the first 'where' token, the
stack of indentation contexts is still empty. Hence my remark about the
fourth equation.
> body -> { impdecls; topdecls }
> | { impdecls }
> | { topdecls }
>
> The first line seems to suggest that import declaraions were
> admissible also after topdecls, but any attempt to place an impdecl
> after a topdecl leads --fortunately-- to a parse error in hugs and
> ghc, shouldn't the production be
>
> body -> { impdecls }; { topdecls } ?
I think you have mis-read the brace characters as if they were the EBNF
meta symbols for repetition. They do in fact mean the literal brace
symbol, which may be explicitly present in the source, or inserted by
the layout rule. Thus, topdecls must follow impdecls, and be at the
same indentation level if layout matters.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Malcolm Wallace wrote:
Brian Hulley wrote:
However I think there is an error in the description of this in
section 2.7 of the Haskell98 report, which states:
"If the indentation of the non-brace lexeme immediately following a
where, let, do or of is less than or equal to the current
indentation level, then instead of starting a layout, an empty list
"{}" is inserted, and layout processing occurs for the current
level ..."
I dispute the "or equal" in the above statement, since it seems to be
clearly in contradiction to what is actually being done.
Section 2.7 does say that it is an informal description, so although
it is correct, it is not complete. In the case of the module header,
the question is really "what is the current indentation level?" (that
we must be strictly greater than). The answer can be found in the
formal definition of the layout rule in section 9.3. At the
beginning of the module, there is _no_ current indentation level -
thus the fourth equation of L applies.
Thanks. However I do think the fact that there is a special case for the
module head would merit a mention in section 2.7, because at the moment it's
a bit like looking at a stack of chocolate cookies and defining the top one
to be vanilla - it works but who'd ever have thought of it for themselves
just looking at the visual indentation on the screen?
On the subject of 9.3, I'm puzzled by:
"For the purposes of the layout rule, Unicode characters in a source program
are considered to be of the same, fixed, width as an ASCII character.
However, to avoid visual confusion, programmers should avoid writing
programs in which the meaning of implicit layout depends on the width of
non-space characters."
Surely almost all Haskell programs rely on the width of every non-space
character to be the same as the width of a space (ie monospaced font where
one character == one glyph) as in
let a = 3
b = 5
I'd suggest that the word "non-space" should be replaced by "multi-glyph"
and perhaps there could be a recommendation to avoid the use of multi-glyph
characters in the first place (otherwise an editor would have to be smart
enough to maintain the correct multi-glyph spaces in the columns under
them...)
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Comparing programs
This is more of an algorithm question than a language question, but any
insights would be much appreciated.
The problem is to input a series of programs and find previous
occurrences of the same algorithm.
The programs consist of a set of input parameters (a, b, c, ...), and a
set of side-effect-free functions (f, g, h, ...). Since the functions
are side-effect-free, they can be reordered without changing the
algorithm ("f(a), g(b)" is the same as "g(b), f(a)"). Subsequent calls
of the same function with the same parameters have no effect ("f(a),
f(a)" is the same as "f(a)"); in fact, you can assume duplicates have
been removed in earlier processing.
But here's the thing that makes it hard (at least for me): two programs
are considered the same if they can be made to match by rearranging the
order of the input parameters. I.e., "f(a), g(b)" is the same as "f(b),
g(a)". Although parameters can be reordered, they cannot be substituted
("f(a), g(b)" is _not_ the same as "f(a), g(a)").
Example: "f(a), g(b), h(a, b)" is the same as "f(b), g(a), h(b, a)" but
_not_ the same as "f(a), g(b), h(b, a)".
I need a way to compare the input programs, and preferably to order them.
In Haskell terms, given the programs are represented by a type Prog, I
want Prog to be a member of class Ord, letting me use tools like
Data.Map to look up information about previous instances.
I can do a brute-force compare by trying all the parameter permutations,
but that only gives me Eq, not Ord, and seems terribly inelegant as well.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparing programs
On Mar 6, 2006, at 1:05 PM, Harry Chesley wrote:
This is more of an algorithm question than a language question, but
any insights would be much appreciated.
The problem is to input a series of programs and find previous
occurrences of the same algorithm.
The programs consist of a set of input parameters (a, b, c, ...),
and a set of side-effect-free functions (f, g, h, ...). Since the
functions are side-effect-free, they can be reordered without
changing the algorithm ("f(a), g(b)" is the same as "g(b), f(a)").
Subsequent calls of the same function with the same parameters have
no effect ("f(a), f(a)" is the same as "f(a)"); in fact, you can
assume duplicates have been removed in earlier processing.
But here's the thing that makes it hard (at least for me): two
programs are considered the same if they can be made to match by
rearranging the order of the input parameters. I.e., "f(a), g(b)"
is the same as "f(b), g(a)". Although parameters can be reordered,
they cannot be substituted ("f(a), g(b)" is _not_ the same as "f
(a), g(a)").
Example: "f(a), g(b), h(a, b)" is the same as "f(b), g(a), h(b, a)"
but _not_ the same as "f(a), g(b), h(b, a)".
I need a way to compare the input programs, and preferably to order
them.
In Haskell terms, given the programs are represented by a type
Prog, I want Prog to be a member of class Ord, letting me use tools
like Data.Map to look up information about previous instances.
One thing you could try is to develop a "canonical representation",
ie, an exemplar from the equivalence class which can be calculated
from any member of that class. You could define a lexicographical
order for variables and define the canonical representation such that
the first occurrence of each variable occurs in lexicographical
order. Then you define an ordering based on the canonical
representation. If your representation of programs is simple enough,
you can probably just use the derived Ord instance and just make sure
to always use the canonical representation.
I can do a brute-force compare by trying all the parameter
permutations, but that only gives me Eq, not Ord, and seems
terribly inelegant as well.
It's hard to be more specific without more details about the language
and the problem. Your comments make it sound like you are dealing
with an imperative language, but it's hard to tell. In some cases,
language analysis is easier if you do a dataflow analysis first and
then do your manipulations on the resulting graphs; you might try
taking that tack.
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparing programs
I believe you might be able to use (commutative) anti-unification, also
known as "generalization" for this task.
Jacques
Harry Chesley wrote:
This is more of an algorithm question than a language question, but
any insights would be much appreciated.
The problem is to input a series of programs and find previous
occurrences of the same algorithm.
The programs consist of a set of input parameters (a, b, c, ...), and
a set of side-effect-free functions (f, g, h, ...). Since the
functions are side-effect-free, they can be reordered without changing
the algorithm ("f(a), g(b)" is the same as "g(b), f(a)"). Subsequent
calls of the same function with the same parameters have no effect
("f(a), f(a)" is the same as "f(a)"); in fact, you can assume
duplicates have been removed in earlier processing.
But here's the thing that makes it hard (at least for me): two
programs are considered the same if they can be made to match by
rearranging the order of the input parameters. I.e., "f(a), g(b)" is
the same as "f(b), g(a)". Although parameters can be reordered, they
cannot be substituted ("f(a), g(b)" is _not_ the same as "f(a), g(a)").
Example: "f(a), g(b), h(a, b)" is the same as "f(b), g(a), h(b, a)"
but _not_ the same as "f(a), g(b), h(b, a)".
I need a way to compare the input programs, and preferably to order them.
In Haskell terms, given the programs are represented by a type Prog, I
want Prog to be a member of class Ord, letting me use tools like
Data.Map to look up information about previous instances.
I can do a brute-force compare by trying all the parameter
permutations, but that only gives me Eq, not Ord, and seems terribly
inelegant as well.
___
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] Comparing programs
Harry Chesley wrote:
But here's the thing that makes it hard (at least for me): two
programs are considered the same if they can be made to match by
rearranging the order of the input parameters. I.e., "f(a), g(b)" is
the same as "f(b), g(a)". Although parameters can be reordered, they
cannot be substituted ("f(a), g(b)" is _not_ the same as "f(a),
g(a)").
Are you sure you've got this right? I'd have thought that "rearranging the
order of input parameters" just means that if you have h(a,b) == h'(b,a) for
some h and h' then you are allowed to substitute h' for h as long as you
also swap the params around.
f(b),g(a) can only be obtained from f(a),g(b) by substituting the params for
f and g respectively, which is not the same as rearranging the order of f
and g's params, and which as you've said, is not allowed.
Also, what is the meaning of "f(a), g(b)"? If f and g are just side
effect-free functions, is this not equivalent to just g(b)?
I'd suggest the first step is to define a formal semantics for the meaning
of the programs to help illuminate what is/isn't equivalent, then think
about rewrite rules/ search strategies/heuristics etc, and only at the very
end try to work out how to code it in Haskell. (Of course the problem of
comparing two functions in a TM-complete language is undecidable so unless
your functional language is very restricted no such algorithm will work for
every input)
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] |> vs. $ (was: request for code review)
By the way, thanks for everyone's comments so far! They're very helpful! > Also, most haskell programs use $ instead of |> > > > -- For convenience: > > currTokType :: ParseContext -> TokenType > > currTokType ctx = ctx |> currTok |> tokenType > > this could be written as: > tokenType $ currTok $ ctx Concerning: -- |> is like a UNIX pipe. infixl 9 |> x |> f = f x I find "ctx |> currTok |> tokenType" to be more readable than "tokenType $ currTok $ ctx" because you're not reading the code in reverse. That's my primary complaint with "." and "$". That's especially the case when I'm spreading the code over multiple lines: -- Translate a C type declaration into English. translate :: String -> String translate s = s |> createParseContext |> readToFirstIdentifier |> dealWithDeclarator |> consolidateOutput I prefer |> for readability, but I understand that it can be bad to spring new constructs on programmers in the middle of a program, and I'm totally in favor of following standard Haskell idioms. Does anyone else have strong opinions one way or the other? It seems like most of my program is centered around pipes of "|>", so it's an important issue. Thanks! -jj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] |> vs. $ (was: request for code review)
Shannon -jj Behrens wrote: I find "ctx |> currTok |> tokenType" to be more readable than "tokenType $ currTok $ ctx" because you're not reading the code in reverse. That's my primary complaint with "." and "$". That's especially the case when I'm spreading the code over multiple lines: -- Translate a C type declaration into English. translate :: String -> String translate s = s |> createParseContext |> readToFirstIdentifier |> dealWithDeclarator |> consolidateOutput If you were wanting to be able to deal with exceptions/ errors etc during the translation process, you'd usually use a monad (Haskell's version of a pipe), in which case the operations could still be read left to right eg: translate :: (Monad m) => String -> m String translate = do createParseContext readToFirstIdentifier dealWithDeclarator consolidateOutput So while . and $ are useful for combining functions together in parts of a program, and are consistent with the idea that the function always comes first followed by its argument, the top level (at least) would usually be monadic and hence not require |> to get left-to-right readability. I've copied the links on monads below from a previous post by Jared: http://www.nomaware.com/monads/html/ http://haskell.org/hawiki/Monad Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] |> vs. $ (was: request for code review)
Shannon -jj Behrens wrote: > I find "ctx |> currTok |> tokenType" to be more readable than > "tokenType $ currTok $ ctx" because you're not reading the code in > reverse. That's my primary complaint with "." and "$". Seconded. That's why I'd like to see the arguments to (.) swapped, but it's too late for that. A useable replacement is (>>>) from the Arrow instance for (->), which gives: > translate :: String -> String > translate = > createParseContext >>> > readToFirstIdentifier >>> > dealWithDeclarator >>> > consolidateOutput It reads from left to right and it promotes a more functional style. The operator could be a bit easier on the eyes, though. Udo. -- Always call a spade a spade, except in classes that both dig holes and play bridge. -- a guideline for Eiffel programmers signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mediawiki syntax highlighting plugins
Johannes Ahlmann wrote: an alternative would be geshi (http://qbnz.com/highlighter/) for which a mediawiki plugin also exists (http://meta.wikimedia.org/wiki/GeSHiHighlight), but it says on the geshi site "GeSHi supports PHP5 and Windows". and i'm not clear whether they mean it _also_ supports those options or exclusively. it would be cool if one of the wiki maintainers could look into this matter and possibly install/setup one of the above extensions. I'll look into GeSHi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] |> vs. $ (was: request for code review)
On Mon, 2006-03-06 at 11:25 -0800, Shannon -jj Behrens wrote: . . . > I find "ctx |> currTok |> tokenType" to be more readable than > "tokenType $ currTok $ ctx" because you're not reading the code in > reverse. That's my primary complaint with "." and "$". That's > especially the case when I'm spreading the code over multiple lines: (Just my $0.02 worth; no flames please :-) I notice that all but the last of your four functions read like commands in English. It seems natural to write a sequence of commands left-to-right in the order they are to be performed, so "|>" seem natural and "$" and "." seem backward. However, if the chain "f $ g $ h x" is read something like "the result of applying f to the result of applying g to the result of applying h to x" then the usual order seems more natural. And my preferences differ from Udo's -- I would not like to see the order of args to "." and "$" reversed *unless* the arg was written to the left of the chain, ala "x h $ g $ f", as is done by some algebraists. It does seem that the whole controversy boils down to how the writer thinks of the chain -- as a sequence of actions or as the evolution of a value. Neither one is "the One True View"; they're just different. -- Bill Wood ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
