Thread: [pure-lang-svn] SF.net SVN: pure-lang: [23] pure/trunk/pure.1
Status: Beta
Brought to you by:
agraef
From: <ag...@us...> - 2008-05-02 05:00:23
|
Revision: 23 http://pure-lang.svn.sourceforge.net/pure-lang/?rev=23&view=rev Author: agraef Date: 2008-05-01 22:00:29 -0700 (Thu, 01 May 2008) Log Message: ----------- Fix typo. Modified Paths: -------------- pure/trunk/pure.1 Modified: pure/trunk/pure.1 =================================================================== --- pure/trunk/pure.1 2008-05-02 03:59:07 UTC (rev 22) +++ pure/trunk/pure.1 2008-05-02 05:00:29 UTC (rev 23) @@ -689,7 +689,7 @@ > fact n = n*fact (n-1) \fBif\fP n>1; > \fBlet\fP x = fact 10; x; 3628800 -> map fact (1..10) +> map fact (1..10); [1,2,6,24,120,720,5040,40320,362880,3628800] .fi .PP This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ag...@us...> - 2008-05-03 21:06:06
|
Revision: 39 http://pure-lang.svn.sourceforge.net/pure-lang/?rev=39&view=rev Author: agraef Date: 2008-05-03 14:06:12 -0700 (Sat, 03 May 2008) Log Message: ----------- Add some remarks about the syntax of list of tuples. Modified Paths: -------------- pure/trunk/pure.1 Modified: pure/trunk/pure.1 =================================================================== --- pure/trunk/pure.1 2008-05-03 12:28:44 UTC (rev 38) +++ pure/trunk/pure.1 2008-05-03 21:06:12 UTC (rev 39) @@ -240,16 +240,19 @@ syntactic sugar for list values in brackets, such as [x,y,z], which is exactly the same as x:y:z:[]. Moreover, the prelude also provides an infix `..' operator to denote arithmetic sequences such as 1..10 or 1.0,1.2..3.0. Pure's -tuples are a bit unusual, however, in that they abide by the mathematical -rules: They are constructed by just ``paring'' things using the `,' operator, -for which the empty tuple acts as a neutral element (i.e., (),x is just x, as -is x,()). The pairing operator is associative, which implies that tuples are -completely flat (i.e., x,(y,z) is just x,y,z, as is (x,y),z). This means that -there are no nested tuples (tuples of tuples), if you need such constructs -then you should use lists instead. Also note that the parentheses are -\fInot\fP part of the tuple syntax in Pure, although you \fIcan\fP use -parentheses, just as with any other expression, for the usual purpose of -grouping expressions and overriding default precedences and associativity. +tuples are a bit unusual, however: They are constructed by just ``paring'' +things using the `,' operator, for which the empty tuple acts as a neutral +element (i.e., (),x is just x, as is x,()). The pairing operator is +associative, which implies that tuples are completely flat (i.e., x,(y,z) is +just x,y,z, as is (x,y),z). This means that there are no nested tuples (tuples +of tuples), if you need such constructs then you should use lists +instead. Also note that the parentheses are \fInot\fP part of the tuple syntax +in Pure, although you \fIcan\fP use parentheses, just as with any other +expression, for the usual purpose of grouping expressions and overriding +default precedences and associativity. This means that a list of tuples will +be printed (and must also be entered) using the ``canonical'' representation +(x1,y1):(x2,y2):...:[] rather than [(x1,y1),(x2,y2),...] (which denotes just +[x1,y1,x2,y2,...]). .TP .B List comprehensions: \fR[x,y; x = 1..n; y = 1..m; x<y] Pure also has list comprehensions which generate lists from an expression and This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ag...@us...> - 2008-05-03 23:01:05
|
Revision: 42 http://pure-lang.svn.sourceforge.net/pure-lang/?rev=42&view=rev Author: agraef Date: 2008-05-03 16:01:13 -0700 (Sat, 03 May 2008) Log Message: ----------- Updated manpage. Modified Paths: -------------- pure/trunk/pure.1 Modified: pure/trunk/pure.1 =================================================================== --- pure/trunk/pure.1 2008-05-03 22:05:43 UTC (rev 41) +++ pure/trunk/pure.1 2008-05-03 23:01:13 UTC (rev 42) @@ -989,6 +989,33 @@ .B system standard library module) should be your friend. ;-) .PP +Please note that parentheses are really only used to group expressions and are +\fInot\fP part of the tuple syntax; tuples are in fact not really part of the +Pure language at all, but are implemented in the prelude. As you can see +there, the pairing operator `,' used to construct tuples is +(right-)associative. We call these the ``poor man's tuples'' since they are +always flat and thus there are no nested tuples (if you need this then you +should use lists instead). This also implies than an expression like +[(1,2),(3,4)] is in fact exactly the same as [1,2,3,4]. If you want to denote +a list of tuples, you must use the syntax (1,2):(3,4):[] instead; this is also +the notation used when the interpreter prints such objects. +.PP +The ``head = function'' rule means that the head symbol f of an application f +x1 ... xn occurring on (or inside) the left-hand side of an equation, pattern +binding, or pattern-matching lambda expression, is always interpreted as a +literal function symbol (not a variable). This implies that you cannot bind +the ``function'' component of a function application to a variable, and thus +you cannot directly define a generic function which operates on arbitrary +function applications. As a remedy, the prelude provides three operations to +handle such objects: +.BR applp , +a predicate which checks whether a given expression is a function application, +and +.B fun +and +.BR arg , +which determine the function and argument parts of such an expression. +.PP If possible, you should always decorate numeric variables on the left-hand sides of function definitions with the appropriate type tags, like .B ::int @@ -997,6 +1024,20 @@ This often helps the compiler to generate better code and makes your programs run faster. .PP +Talking about the built-in integer types, please note that +.B int +(the machine integers) and +.B bigint +(the GMP ``big'' integers) are really different kinds of objects, and thus if +you want to define a function operating on both kinds of integers, you'll also +have to provide equations for both. This also applies to equations matching +against constant values of these types; in particular, a small integer +constant like `0' only matches machine integers, not bigints. Unfortunately, +Pure currently doesn't provide any special notation for ``small bigints'', so +that there's no way to match a bigint against a small integer constant on the +left-hand side of an equation; instead you have to use explicit comparisons, +using guarded equations. +.PP The interpreter always takes your .B extern declarations of C routines at face value. It will not go and read any C header @@ -1004,15 +1045,14 @@ you have to be careful to give the proper declarations, otherwise your program will probably segfault calling the function. .PP -Talking about the C interface, you also have to be careful when passing -generic pointer values to external C routines, since currently there is no -type checking for these; any pointer type other than char* and expr* is -effectively treated as void*. This considerably simplifies lowlevel -programming and interfacing to C libraries, but also makes it very easy to -have your program segfault all over the place! Therefore it is highly -recommended that you wrap your lowlevel code in Pure routines and data -structures which do all the checks necessary to ensure that only the right -kind of data is passed to C routines. +You also have to be careful when passing generic pointer values to external C +routines, since currently there is no type checking for these; any pointer +type other than char* and expr* is effectively treated as void*. This +considerably simplifies lowlevel programming and interfacing to C libraries, +but also makes it very easy to have your program segfault all over the place! +Therefore it is highly recommended that you wrap your lowlevel code in Pure +routines and data structures which do all the checks necessary to ensure that +only the right kind of data is passed to C routines. .PP Pure programs may need a considerable amount of stack space to handle recursive function calls, and the interpreter itself also takes its toll. So @@ -1025,8 +1065,8 @@ limit. The value of .B PURE_STACK should be the maximum stack size in kilobytes. Please note that this is only -an advisory limit but does \fInot\fP change the program's physical stack size. -Your operating system should supply you with a command such as +an advisory limit which does \fInot\fP change the program's physical stack +size. Your operating system should supply you with a command such as .BR ulimit (1) to set the real process stack size. Also note that this feature isn't 100% foolproof yet, since for performance reasons the stack will be checked only on This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ag...@us...> - 2008-05-04 07:09:18
|
Revision: 44 http://pure-lang.svn.sourceforge.net/pure-lang/?rev=44&view=rev Author: agraef Date: 2008-05-04 00:09:25 -0700 (Sun, 04 May 2008) Log Message: ----------- Updated manpage. Modified Paths: -------------- pure/trunk/pure.1 Modified: pure/trunk/pure.1 =================================================================== --- pure/trunk/pure.1 2008-05-03 23:33:41 UTC (rev 43) +++ pure/trunk/pure.1 2008-05-04 07:09:25 UTC (rev 44) @@ -187,17 +187,25 @@ .PP Expressions consist of the following elements: .TP -.B Constants: \fR4711, 1.2e-3, \(dqHello,\ world!\en\(dq +.B Constants: \fR4711, 4711G, 1.2e-3, \(dqHello,\ world!\en\(dq The usual C'ish notations for integers (decimal, hexadecimal, octal), floating -point values and double-quoted strings are all provided. Actually, in Pure -character escapes have a more flexible syntax borrowed from the author's Q -language, which provides notations to specify any Unicode character. In -particular, the notation +point values and double-quoted strings are all provided, although the Pure +syntax differs in some minor ways, as discussed in the following. First, there +is a special notation for denoting bigints. Note that an integer constant that +is too large to fit into a machine integer will be interpreted as a bigint +automatically. Moreover, an integer literal immediately followed by the +uppercase letter ``G'' (mnemonic: ``biG'' or ``GMP'' integer) will always be +interpreted as a bigint constant, even if it fits into a machine integer. This +``big G'' notation is also used when printing bigint constants. Second, +character escapes in Pure strings have a more flexible syntax borrowed from +the author's Q language, which provides notations to specify any Unicode +character. In particular, the notation .BR \e\fIn\fP , -where \fIn\fP is an integer written in decimal, hexadecimal or octal notation, -denotes the Unicode character (code point) #\fIn\fP. Since these escapes may -consist of a varying number of digits, parentheses may be used for -disambiguation purposes; thus, e.g. +where \fIn\fP is an integer literal written in decimal (no prefix), +hexadecimal (`0x' prefix) or octal (`0' prefix) notation, denotes the Unicode +character (code point) #\fIn\fP. Since these escapes may consist of a varying +number of digits, parentheses may be used for disambiguation purposes; thus, +e.g. .B \(dq\e(123)4\(dq denotes character #123 followed by the character `4'. The usual C-like escapes for special non-printable characters such as @@ -208,6 +216,8 @@ where \fIname\fP is any of the XML single character entity names specified in the ``XML Entity definitions for Characters'', see .IR http://www.w3.org/TR/xml-entity-names/ . +Thus, e.g., \(dq\e©\(dq denotes the copyright character (code point +0x000A9). .TP .B Function and variable symbols: \fRfoo, foo_bar, BAR, bar2 These consist of the usual sequence of ASCII letters (including the @@ -983,39 +993,48 @@ > \fBunderride\fP .fi .SH CAVEATS AND NOTES +.B Debugging. There's no symbolic debugger yet. So .BR printf (3) (available in the .B system standard library module) should be your friend. ;-) .PP +.B Tuples and parentheses. Please note that parentheses are really only used to group expressions and are \fInot\fP part of the tuple syntax; tuples are in fact not really part of the Pure language at all, but are implemented in the prelude. As you can see there, the pairing operator `,' used to construct tuples is (right-)associative. We call these the ``poor man's tuples'' since they are always flat and thus there are no nested tuples (if you need this then you -should use lists instead). This also implies than an expression like +should use lists instead). This also implies that an expression like [(1,2),(3,4)] is in fact exactly the same as [1,2,3,4]. If you want to denote a list of tuples, you must use the syntax (1,2):(3,4):[] instead; this is also the notation used when the interpreter prints such objects. .PP +.B Manipulating function applications. The ``head = function'' rule means that the head symbol f of an application f x1 ... xn occurring on (or inside) the left-hand side of an equation, pattern binding, or pattern-matching lambda expression, is always interpreted as a -literal function symbol (not a variable). This implies that you cannot bind -the ``function'' component of a function application to a variable, and thus -you cannot directly define a generic function which operates on arbitrary -function applications. As a remedy, the prelude provides three operations to -handle such objects: +literal function symbol (not a variable). This implies that you cannot match +the ``function'' component of an application against a variable, and thus you +cannot directly define a generic function which operates on arbitrary function +applications. As a remedy, the prelude provides three operations to handle +such objects: .BR applp , a predicate which checks whether a given expression is a function application, and .B fun and .BR arg , -which determine the function and argument parts of such an expression. +which determine the function and argument parts of such an expression, +respectively. (This may seem a little awkward, but as a matter of fact the +``head = function'' rule is quite convenient since it covers the common cases +without forcing the programmer to declare ``constructor'' symbols (except +nullary symbols). Also note that in standard term rewriting you do not have +rules parameterizing over the head symbol of a function application either.) .PP +.B Numeric types. If possible, you should always decorate numeric variables on the left-hand sides of function definitions with the appropriate type tags, like .B ::int @@ -1024,7 +1043,7 @@ This often helps the compiler to generate better code and makes your programs run faster. .PP -Talking about the built-in integer types, please note that +Talking about the built-in types, please note that .B int (the machine integers) and .B bigint @@ -1032,12 +1051,10 @@ you want to define a function operating on both kinds of integers, you'll also have to provide equations for both. This also applies to equations matching against constant values of these types; in particular, a small integer -constant like `0' only matches machine integers, not bigints. Unfortunately, -Pure currently doesn't provide any special notation for ``small bigints'', so -that there's no way to match a bigint against a small integer constant on the -left-hand side of an equation; instead you have to use explicit comparisons, -using guarded equations. +constant like `0' only matches machine integers, not bigints; for the latter +you'll have to use the ``big G'' notation `0G'. .PP +.B External C functions. The interpreter always takes your .B extern declarations of C routines at face value. It will not go and read any C header @@ -1054,6 +1071,7 @@ routines and data structures which do all the checks necessary to ensure that only the right kind of data is passed to C routines. .PP +.B Stack size and tail recursion. Pure programs may need a considerable amount of stack space to handle recursive function calls, and the interpreter itself also takes its toll. So you may have to configure your system accordingly (8 MB of stack space is This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ag...@us...> - 2008-05-28 07:52:43
|
Revision: 157 http://pure-lang.svn.sourceforge.net/pure-lang/?rev=157&view=rev Author: agraef Date: 2008-05-28 00:52:52 -0700 (Wed, 28 May 2008) Log Message: ----------- Update manual. Modified Paths: -------------- pure/trunk/pure.1 Modified: pure/trunk/pure.1 =================================================================== --- pure/trunk/pure.1 2008-05-28 06:30:29 UTC (rev 156) +++ pure/trunk/pure.1 2008-05-28 07:52:52 UTC (rev 157) @@ -185,6 +185,15 @@ with external C functions). Truth values are encoded as machine integers (as you might expect, zero denotes ``false'' and any non-zero value ``true''). .PP +Expressions are generally evaluated from left to right, innermost expressions +first, i.e., using +.I call by value +semantics. Pure also has a few built-in special forms (most notably, +conditional expressions and the short-circuit logical connectives && and ||) +which take some of their arguments using +.I call by name +semantics. +.PP Expressions consist of the following elements: .TP .B Constants: \fR4711, 4711G, 1.2e-3, \(dqHello,\ world!\en\(dq @@ -282,7 +291,11 @@ .TP .B Conditional expressions: if\fR\ x\ \fBthen\fR\ y\ \fBelse\fR\ z Evaluates to y or z depending on whether x is ``true'' (i.e., a nonzero -integer). +integer). An exception is generated if the condition is not an +integer. Conditional expressions are special forms with call-by-name arguments +y and z; only one of the branches is actually evaluated. (The logical +operators && and || are treated in a similar fashion, in order to implement +short-circuit semantics.) .TP .B Lambdas: \fR\ex\ ->\ y These work pretty much like in Haskell. More than one variable may be bound @@ -372,6 +385,20 @@ causes the given value to be evaluated (and the result to be printed, when running in interactive mode). .PP +Expressions are parsed according to the following precedence rules: Lambda +binds most weakly, followed by +.BR when , +.B with +and +.BR case , +followed by conditional expressions (\fBif\fP-\fBthen\fP-\fBelse\fP), followed +by the ``simple'' expressions (i.e., all other kinds of expressions involving +operators, function applications, constants, symbols and other primary +expressions). Precedence and associativity of operator symbols are given by +their declarations (in the prelude or the user's program), and function +application binds stronger than all operators. Parentheses can be used to +override default precedences and associativities as usual. +.PP For instance, here are two more function definitions showing most of these elements in action: .sp @@ -439,8 +466,8 @@ the built-in special form .B catch with the exception handler (a function to be applied to the exception value) -as the first and the expression to be evaluated as the second argument. For -instance: +as the first and the expression to be evaluated as the second (call-by-name) +argument. For instance: .sp .nf > catch error (throw hello_world); @@ -592,17 +619,32 @@ .PP The interpreter makes sure that the parameters in a call match; if not, the call is treated as a normal form expression. The range of supported C types is -a bit limited right now (void, bool, char, int, double, as well as arbitrary -pointer types, i.e.: void*, char*, etc.), but in practice these should cover -most kinds of calls that need to be done when interfacing to C libraries. Note -that char* is for string arguments and return values which need translation -between Pure's internal utf-8 representation and the system encoding, while -void* is for any generic kind of pointer (including strings, which are -\fInot\fP translated when passed/returned as void*). Any other kind of pointer -(except expr*, see below), is effectively treated as void* right now, although -in a future version the interpreter may keep track of the type names for the -purpose of checking parameter types. +a bit limited right now (void, bool, char, short, int, long, double, as well +as arbitrary pointer types, i.e.: void*, char*, etc.), but in practice these +should cover most kinds of calls that need to be done when interfacing to C +libraries. .PP +Since Pure only has 32 bit machine integers and GMP bigints, a variety of C +integer types are provided which are converted from/to the Pure types in a +straightfoward way. The short type indicates 16 bit integers which are +converted from/to Pure machine ints using truncation and sign extension, +respectively. The long type +.I always +denotes 64 bit integers, even if the corresponding C type is actually 32 bit +(as it usually is on most contemporary systems). This type is to be used if a +C function takes or returns 64 bit integer values. For a long parameter you +can either pass a Pure machine int (which is sign-extended to 64 bit) or a +Pure bigint (which is truncated to 64 bit if necessary). 64 bit return values +are always converted to (signed) Pure bigints. +.PP +Concerning the pointer types, char* is for string arguments and return values +which need translation between Pure's internal utf-8 representation and the +system encoding, while void* is for any generic kind of pointer (including +strings, which are \fInot\fP translated when passed/returned as void*). Any +other kind of pointer (except expr*, see below) is effectively treated as +void* right now, although in a future version the interpreter may keep track +of the type names for the purpose of checking parameter types. +.PP The expr* pointer type is special; it indicates a Pure expression parameter or return value which is just passed through unchanged. All other types of values have to be ``unboxed'' when they are passed as arguments (i.e., from Pure to @@ -685,8 +727,8 @@ file for details on the provided operations. Also, the beginnings of a system interface can be found in the .B system.pure -module. In particular, this also includes operations to do basic I/O using -text files. More stuff will be provided in future releases. +module. In particular, this also includes operations to do basic I/O. More +stuff will be provided in future releases. .SH INTERACTIVE USAGE In interactive mode, the interpreter reads definitions and expressions and processes them as usual. The input language is just the same as for source @@ -1011,6 +1053,13 @@ a list of tuples, you must use the syntax (1,2):(3,4):[] instead; this is also the notation used when the interpreter prints such objects. .PP +.B Special forms. +Special forms are recognized at compile time only. Thus the catch function as +well as the short-circuit logical connectives && and || are only treated as +special forms in direct (saturated) calls. They can still be used if you pass +them around as function values or partial applications, but in this case they +lose all their special call-by-name argument processing. +.PP .B Manipulating function applications. The ``head = function'' rule means that the head symbol f of an application f x1 ... xn occurring on (or inside) the left-hand side of an equation, pattern @@ -1109,6 +1158,13 @@ without having to recompile the entire program.) However, mutual tail recursion does work with \fIlocal\fP functions, so it's easy to work around this limitation. +.PP +Scheme programmers should note that conditional expressions +(\fBif\fP-\fBthen\fP-\fBelse\fP) are tail-recursive in both branches, just +like in Scheme, while the logical operators && and || are +.I not +tail-recursive. This is because the logical operators always return a proper +truth value (0 or 1) which wouldn't be possible with tail call semantics. .SH FILES .TP .B ~/.pure_history This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |