[ ghc-Bugs-954378 ] getFileStatus does not include the file name in IO-Error
Bugs item #954378, was opened at 2004-05-15 02:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=954378group_id=8032 Category: libraries/unix Group: 6.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: getFileStatus does not include the file name in IO-Error Initial Comment: Hi. When applied to a dangling symlink, then System.Posix.Files.getFileStatus produces an IO-Error. But it doesn't include the path of the symlink (to be accessed with ioeGetFileName) in the exception. My email address: [EMAIL PROTECTED] Bye. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=954378group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [ ghc-Bugs-954378 ] getFileStatus does not include the file name in IO-Error
In local.glasgow-haskell-bugs, you wrote: Summary: getFileStatus does not include the file name in IO-Error Hm, it looks like none of the functions in there return a hint as to which argument caused the error. All of them should probably include filenames etc into exceptions. Volker -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
A wise man once said, release early and release often. We're obviously not very wise... ;) === Announcing HaRP 0.1 === HaRP is a Haskell extension that extends the normal pattern matching facility with the power of regular expressions. This expressive power is highly useful in a wide range of areas, including text parsing and XML processing [1]. Regular expression patterns in HaRP work over ordinary Haskell lists ([]) of arbitrary type. We have implemented HaRP as a pre-processor to ordinary Haskell. Where to get it: HaRP can be downloaded from http://www.dtek.chalmers.se/~d00nibro/harp/ along with notes on installation and usage. Description: Simple pattern matching on concrete, fully specified lists can be done in Haskell as so: foo [Foo, Bar, Baz] = ... We add an extension of this, regular pattern matching, an example: foo [/ Foo Bar* Baz /] = ... The intuition of the above is that we get a match for any list that starts with a Foo, ends with a Baz, and has zero or more Bar in between. If you have used regular expressions in any other language, this should not be new to you. Regular patterns that can be used are: * - match zero or more + - match one or more ? - match zero or one a | b - match a or b (/ a b /) - match the sequence of a, then b (this is also implicit in the top level [/ ... /]). For the three first, there is also the option of adding a ? afterwords to make the match non-greedy (the default is greedy). This means that p* tries to match p as many times as possible while still satisfying the whole pattern, whereas p*? tries to match p as few times as possible. Introducing regular expressions into the pattern matching facility gives some extra nice features. One is that the regular patterns are type safe, i.e. they are not encoded in strings. Another is that identifiers can be named and bound inside regular patterns, examples: foo [/ _* a /] = ... = a is bound to the last element of the list foo [/ a@(/ _ _ /) _* /] = ... = a is bound to the list containing the first two elements foo [/ (/ a _ /)* /] = ... = a is bound to the list of the first, third, fifth etc elements of a list of even length Note that binding variables implicitly (i.e. without using @) is context dependent in regular patterns. This is because for some variables appearing in certain contexts, we cannot know the number of times that particular variable will be matched. Looking at the last example above, we see that the varible a appears inside the context of a *, meaning it can be matched zero or more times. A variable bound in such a context will contain the list of all values matched to it, whereas a normal linear variable is bound to exactly the value it matches, like the a in the first example above. Patterns that introduce non-linear contexts are *, +, ? (and the non-greedy versions), and | (union). For explicitly bound variables (i.e. variables bound using @) we must also look at types of matched sub-patterns. In the example foo [/ a@(/ _ _ /) _* /] = ... = a is bound to the list containing the first two elements we clearly see that the sequencing sub-pattern has a list type. The types of sub-patterns are as follows (a :: a, b :: b): a* = [a] a+ = [a] a? = Maybe a (/ ... /) = [e], where e is the type of the elements in the list matched, regardless of sub-patterns ( a | b ) = Either a b We also introduce an explicit binding operator for non-linear bindings, called @: (read as-cons or accumulating as), which adds each match of its associated pattern to a list of matches. An example: foo [/ (_ a@:(/ _ _ /))* /] = ... = a is bound to a list of lists (exactly what the elements will be is left as an exercise to the reader ;) A more complete example using all the presented features: foo [/ _ [EMAIL PROTECTED] b [EMAIL PROTECTED] 4+ [EMAIL PROTECTED] e@(/ f@:6 g /)* h@( 8 | (/ 9 i /) ) /] = (a,b,c,d,e,f,g,h,i) Assuming all the numerical literals are of type Int, foo will have the following type: foo :: [Int] - (Int, Int, [Int], Maybe Int, [[Int]], [Int], [Int], Either Int [Int], [Int]) Examples of applying foo to some lists: (NOTE, show is generally not defined over tuples this large, so to test these examples you need to do some trick, either define an instance for show or simply nest the tuples so that each is no larger than what can be shown) ? foo [0,1,2,3,4,5,6,7,8] (1, 2, [3], Just 5, [[6,7]], [6], [7], Left 8, []) ? foo [0,1,2,3,3,3,4,6,0,6,1,6,2,9,10] (1,2,[3,3,3], Nothing, [[6,0],[6,1],[6,2]], [6,6,6], [0,1,2], Right [9,10], [10]) Discussion of each variable in detail: a :: Int - a binds to a single element at top level (top level meaning it is bound outside any numerating pattern). b :: Int - b binds to a single element at top level. c :: [Int] - c is bound to a zero-or-many pattern, and it will contain all the matches of the sub-pattern, in this case all matches of 3. d :: Maybe Int - d is bound to a
Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
This looks very interesting! I sometimes wish Haskell had more powerful binding facilities, so that things like this don't need to be extensions to the language. (But I'm not sure exactly what I'm wishing for...) On Sat, May 15, 2004 at 12:08:53PM +, Niklas Broberg wrote: Introducing regular expressions into the pattern matching facility gives some extra nice features. One is that the regular patterns are type safe, i.e. they are not encoded in strings. Another is that identifiers can be named and bound inside regular patterns, examples: foo [/ _* a /] = ... = a is bound to the last element of the list foo [/ a@(/ _ _ /) _* /] = ... = a is bound to the list containing the first two elements foo [/ (/ a _ /)* /] = ... = a is bound to the list of the first, third, fifth etc elements of a list of even length What about foo [/ (/ 2 (/ a _ /)* 3 /)* /] = a ? What is the type of a here? I think it should be [[Int]]. And then which special syntax for implicit binding am I supposed to use? Is it foo [/ (/ 2 (/ a@:(/_ _/) _ /)* 3 /)* /] = a or maybe foo [/ (/ 2 (/ a@::(/_ _/) _ /)* 3 /)* /] = a ? And what's the type? [[[Int]]]? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: hs-plugins-0.9.2 - dynamically loaded plugins
== hs-plugins-0.09.2, dynamically loaded plugins in Haskell ==
Release early, release often is the way to go.
This is the first src release of hs-plugins, a library for
compiling and loading Haskell plugins in Haskell.
http://www.cse.unsw.edu.au/~dons/hs-plugins/
The library allows an application to compile and load a Haskell source
file, and then run the code therein. The inspiration and foundation of
hs-plugins based on Andre Pang's original runtime_loader code and GHCi
binding. hs-plugins provides this functionality, along with layers of
abstraction on top, as well as a 'make' mechanism to recompile plugins
whose source has changed, and the following features:
- runtime compilation and re-compilation of plugins
- runtime loading of object files
- automatic *dependency* loading of object files, based on .hi info
- unload/reloading of object files
- a mechanism to merge the abstract syntax of a plugin with a
syntax stub, to factor out common/necessary declarations. This
is to help out EDSL programmers
- many examples, and a simple build system
An example plugin, potentially written by a non-programmer:
resource = plugin {
function = reverse
}
An example application:
import Plugins
import API
main = do
make Plugin.hs []
(m,v) - load Plugins.o . resource
putStrLn $ (function v) hello
will print olleh
You'll probably need GHC 6.2 or greater. This is a GHCi specific
library, and will only work on platforms with a functional GHCi
implementation. It is also BSD make friendly ;)
The original inspiration was to provide a typesafe config language to
replace configuration files for new applications (a muttrc and vimrc
killer...) Haskell EDSLs and dynloaded plugins suit this quite fine,
and the library is suited for EDSL purposes in general, I think.
Feedback *very* welcome.
Enjoy!
-- Don
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
What about foo [/ (/ 2 (/ a _ /)* 3 /)* /] = a ? What is the type of a here? I think it should be [[Int]]. Not quite, the type of a will be [Int]. The only context dependency of variable types is the difference between linear and non-linear contexts. In linear context, variables have the types you would normally expect in standard Haskell. In non-linear context, the type is a list of what it would otherwise be, regardless of what and how many enclosing non-linear regular pattern operators. If you want a full trace of where the items in a come from, you need to do it in several steps: foo [/ (/ 2 b@:(/ _ _ /)* 3 /)* /] = map (map bar) b -- here b :: [[[Int]]] where bar [a, _] = a The reason for b having type [[[Int]]] is that it binds to a pattern of type [[Int]] (a repeating * enclosing a sequence). In general: binding explicitly preserves the trace of the pattern it binds to; binding implicitly preserves no trace at all. To see why this is so, consider the following analogy: bar :: Maybe (Maybe (Maybe Int)) - (Maybe (Maybe Int), Maybe Int, Int) bar (Just a@(Just b@(Just c))) = (a,b,c) When binding a , you look at the type of the subpattern it binds to. When looking at the value held by a on the right hand side, there is no way to trace the context it appeared in before the pattern match. When binding c, you also look at the subpattern it binds to, i.e. the pattern c is equivalent to the pattern [EMAIL PROTECTED] There is no trace of where it comes from. Now look at this regular pattern: foo [/ a@:(/ _ b@:(/ _ c /) /) /] = (a,b,c) What is the type of foo? Well, the type of c is whatever it binds to, which is just an element of the list (assuming Int). But since it is bound in non-linear context, its type will be [Int]. This form of context dependence is the only one we ever need to consider, where a variable is bound implicitly. And the only question is, does it have a list type or not? Another way to look at it is to see that c is equivalent to c@:_ in non-linear context and [EMAIL PROTECTED] in linear context. b is bound explicitly using the @: operator, so the type of b is a list of whatever it binds to. No context dependence. What it binds to is a a sequence, i.e. a list, so the type of b will be [[Int]]. a is bound explicitly using the @: operator, so the type of a is a list of what it binds to. No context dependece here either. It too binds to a list, so its type will be [[Int]]. Thus, foo :: ([[Int]], [[Int]], [Int]) And then which special syntax for implicit binding am I supposed to use? Is it foo [/ (/ 2 (/ a@:(/_ _/) _ /)* 3 /)* /] = a or maybe foo [/ (/ 2 (/ a@::(/_ _/) _ /)* 3 /)* /] = a The former. We have added the @: operator as a a non-linear counterpart of the linear @. Adding more : won't add more levels of lists... ? And what's the type? [[[Int]]]? Not quite right here either, the type will be [[Int]]. The first enclosing list comes from the fact that the subsequence (/ ... /) has type list (whatever will be matched against it is a sequence of items), and the second enclosing list comes from the use of the non-linear binding operator @:. Hopefully I make sense (more than before?). I'm starting to think maybe our context dependent approach to implicit bindings isn't very good after all since it seems to confuse a lot of people. Perhaps variables bound inside regular patterns should always be non-linear... of course that would still be context dependent when compared to normal Haskell patterns, but perhaps still less confusing? Anyway, thanks for the interest and the comments =) /Niklas _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: cpphs-0.2
cpphs-0.2 - Cpphs is a re-implementation (in Haskell) of the C pre-processor. Version 0.1 dealt only with conditional compilation (#if and friends) and file inclusion (#include). Version 0.2 now also implements the rest of cpp's functionality, namely in-line symbol replacement and macro expansion (#define and friends). I believe this to be a reasonably complete and correct implementation, and have tested it on some non-trivial examples from the standard libraries (e.g. Foreign.Storable and HOpenGL). Nevertheless, there will be bugs and I encourage you to find them and report them. http://www.cs.york.ac.uk/fp/cpphs/ Why re-implement cpp? Rightly or wrongly, the C pre-processor is widely used in Haskell source code. It enables conditional compilation for different compilers, different versions of the same compiler, and different OS platforms. It is also occasionally used for its macro language, which can enable certain forms of platform-specific detail-filling, such as the tedious boilerplate generation of instance definitions and FFI declarations. However, there are two problems with cpp, aside from the obvious aesthetic ones: * For some Haskell systems, notably Hugs on Windows, a true cpp is not available by default. * Even for the other Haskell systems, the common cpp provided by the gcc 3.x series is changing subtly in ways that are incompatible with Haskell's syntax. There have always been problems with, for instance, string gaps, and prime characters in identifiers. These problems are only going to get worse. So, it seemed right to attempt to provide an alternative to cpp, both more compatible with Haskell, and itself written in Haskell so that it can be distributed with compilers. Share and Enjoy, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
On Sat, May 15, 2004 at 04:42:03PM +, Niklas Broberg wrote: In non-linear context, the type is a list of what it would otherwise be, regardless of what and how many enclosing non-linear regular pattern operators. So I guess that in foo [/ a? 2 b /] = (a,b) the type of a is '[Int]', not 'Maybe Int', right? Hopefully I make sense (more than before?). Yes, I think that's clearer. I'm starting to think maybe our context dependent approach to implicit bindings isn't very good after all since it seems to confuse a lot of people. Perhaps variables bound inside regular patterns should always be non-linear... of course that would still be context dependent when compared to normal Haskell patterns, but perhaps still less confusing? Alternatively, you could forbid the use of simple variables nonlinearly, since there's an alternative way to write it. Or, you could make variables (and other pattern binding) more context dependent, recording all the relevant parts of the context (and not just whether the context is linear or not), if that makes sense. Interesting issues, anyway! By the way, are nested regular expression matches allowed? Something like: foo :: [[Int]] - Int foo [/ _* [/ 5* a 6* /] _* /] = a ? If so, what is the type of a in foo [/ _* [/ 5* a* /]* _* /] ? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] auto-qualification of identifiers in Haddock
Hello,
take the following module:
module InfiniteList where
import Prelude hiding (repeat)
data InfiniteList e = InfiniteList e (InfiniteList e)
{-|
Essentially the same as 'Prelude.repeat'.
-}
repeat :: e - InfiniteList e
repeat e = l where l = InfiniteList e l
If I feed Haddock with this module, the resulting HTML page reads
Essentially the same as repeat.
at the end. But since repeat is also an identifier of the current module,
this is IMO misleading.
Maybe Haddock should produce the string
Essentially the same as Prelude.repeat.
instead of the abovenot because the source code comment says Prelude.repeat
(Source code spelling depends on the exact form of import declarations(?)
and is therefore not always suited for Haddock output.) but just because it's
the Prelude version of repeat what's mentioned here.
What do others think about this issue?
Wolfgang
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] GHC and libc
When I compile my haskell program (on a linux machine) with GHC and send it to a colleague he can't run it because he has a somewhat older version of libc. Is there a GHC switch that I have missed that enables you to statically link the parts of libc that is used by the haskell program? Alternatively have someone other tips for solving this problem? (I'm reluctant to force all my colleagues to install GHC, because of the size and long installation time, and I can't let them use Hugs because I've used some GHC-only features in my program.) Per Larsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC and libc
On Sat, 2004-05-15 at 16:08, Per Larsson wrote: When I compile my haskell program (on a linux machine) with GHC and send it to a colleague he can't run it because he has a somewhat older version of libc. Is there a GHC switch that I have missed that enables you to statically link the parts of libc that is used by the haskell program? On linux, just give ghc the switch -optl-static which passes -static to the linker. That will link statically with all libs, not just libc. Duncan ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC and libc
Per Larsson wrote: [...] Is there a GHC switch that I have missed that enables you to statically link the parts of libc that is used by the haskell program? [...] Passing -static to the GNU linker results in a, well, statically linked program. :-) Using -optl -static with GHC does what you want, see: http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#FORCING-OPTIONS-THROUGH And here the proof: [EMAIL PROTECTED]: ghc --make -optl -static Main.hs Chasing modules from: Main.hs Compiling Main ( Main.hs, Main.o ) Linking ... [EMAIL PROTECTED]: file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, statically linked, not stripped [EMAIL PROTECTED]: ldd a.out not a dynamic executable For non-GNU linkers consult the man pages for ld, differing linking techniques are one of the most annoying incompatibilities between different *nices IMHO. Cheers, S. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC and libc
Thanks Duncan and Sven for your helpful answers. Per Larsson P.S Now everything seems to work, except that I get the compiler message: /usr/local/lib/ghc-6.2/libHSunix.a(User__17.o)(.text+0x160): In function 'SystemziPosixziUser_getUserEntryForName_entry': : Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking This seems to indicate that there are a few functions (probably in the Posix package) which can't be can't be statically linked? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Syntax macros
We have all the machinery available. See: http://www.cs.uu.nl/groups/ST/Center/SyntaxMacros It will be part of the UtrechtHaskellCompiler (UHC), that is being constructed with our toolset, and which recently strated to produce running code. You get the syntax macros almost for free if you build your parser with the UtrechtParserCombinators (UPC). You can experiment with it yourself for your own language. The probem we are still working on is to handle left-recursive extensions being made by the user. We are well on our way with that. In principle we also know how to provide feedback to the user in terms of the extended input language, but unfortuantely the implementation is rather cumbersome. Doaitse On 2004 mei 15, at 17:49, Per Larsson wrote: I have recently made a small detour into ocaml programming and I'm rather impressed with the generic preprocessor 'camlp4' for ocaml. Camlp4 allows the programmer to (i) interact with the ocaml parser and lexer to extend the concrete grammar with new syntax and (ii) to directly define the translation of such new syntax forms in terms of ocaml abstract syntax. Haskell programmers (at least in GHC) can also manipulate abstract syntax with the Template Haskell extension and the Language.Haskell.THSyntax library, but to my knowing there is no haskell compiler which supports the inclusion of new syntax forms. Wouldn't such a tool be cool? In the haskell community there are a number of handmade preprocesserors (DrIFT, Generic Haskell, HaRP, ...) which are both cumbersome to write, because the authors must write a (partial) haskell parser for every small extension, but also cumbersome to use because of increasing complexity to your makefiles and different standards for error reporting. Also, experimental extensions could quickly be written and evaluated by the haskell users, decreasing the dependency on the compiler maintainers. Per Larsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
