Tried arclite and it, too, had problems with readline. However, its problem is that readline (and parse-format) depend upon readc, which is not defined.
These kinds of articles fascinate me for showing what is possible.
APL/K/J seem to epitomize this kind of code golf. Tried the J example on my phone and it worked. Don't have a clue as to how it works or what it is saying. From the comments on HN:
each column is a row number, and the integer is which column the queen is in, or vice versa on rows and columns.
,or print how many solutions
$queens
92 8
$ gives the 'shape' of the array, that is 92 rows (solutions) x 8 columns (8-queens problem).
I came to Arc because I wanted to use only the best language, and Arc was the only sign I saw that anyone was ambitious enough to try to build the best language today. I stayed with Arc for a while because I could make macro frameworks that explored new ways to program in Arc, without feeling like I was messing up the way anyone else was programming in Arc. Only when I came up with language ideas that couldn't work in Arc did I start to write my own languages.
Then I moved away from Arc mainly because I wanted to practice coding in JavaScript. That was because I wanted to be able to spend my time programming even if I was stranded at a computer that didn't have Arc installed. It was sort of a theoretical concern at the time, but then it came in handy for employment, where Arc was unlikely to be an employer's platform of choice. :)
That nice phenomenon I experienced in Arc, where I could experiment with new ways to program without leaving the language... I think that's the essence of Arc for me. Arc is conducive to Greenspunning new languages. Not only is Arc homoiconic, but it also has few pretensions of being perfect yet, and it's explicitly in the stage of soliciting new suggestions for the core operators (or at least it was). Using Arc, I felt welcome to Greenspun new sets of operators as I liked.
Usually when I have strong opinions about what Arc should become, I just pursue those opinions myself in my own languages. I even intend for my language Staccato to be conducive to Greenspunning; part of its design even involves an explicit "please put all your nonstandard Staccato implementation experiments here" zone. But Arc's lack of pretension is a quality of its community. It's something delicate that I won't necessarily succeed at in Staccato even if I have no regrets about the technical design.
---
If there's any language that has that quality of Arc, I would guess it's Agda. I've seen quite a few type system experiments that are developed as DSLs in Agda, so Agda seems to have the kind of culture that likes remixing the core operators. While Agda's syntax is not homoiconic, I think it's flexible enough to make these DSLs rather seamless.
If Arc has an edge over Agda for Greenspunning, it's that it's easier to Greenspun a new implementation of Arc than a new implementation of Agda. From what I hear, Agda's implementation involves a termination checker that's sophisticated enough that many users take advantage of it without knowing where its limits are. Those users probably aren't prepared to reimplement it themselves.
Incidentally, It's interesting that one of Paul Graham's reasons for not making Arc statically typed was that "static typing seems to preclude true macros" (http://www.paulgraham.com/hundred.html). Now that Haskell, Adga, and Idris all have macro systems, maybe that position should be revised. Or maybe these aren't true macros; I don't know them well enough to judge that.
In other words, it can be an integer, number, string, symbol, gensym, or list of Code.
Within the macro's body, you can pattern match on the Code, you can map/filter on it just like in Arc, you can dynamically return Code, etc.
In Nulan, this is made easy with the & syntax, which is just a shorthand for the Code type:
# These two are equivalent
&1
(*integer 1)
# These two are equivalent
&(foo 1 2)
(*list [ (*symbol "foo") (*integer 1) (*integer 2) ])
# These two are equivalent
&(foo ~a ~b)
(*list [ (*symbol "foo") a b ])
And the & syntax works when pattern matching as well:
# These two are equivalent
(MATCH foo
| &(foo 1 2)
...)
(MATCH foo
| (*list [ (*symbol "foo") (*integer 1) (*integer 2) ])
...)
# These two are equivalent
(MATCH foo
| &(foo ~a ~@b)
...)
(MATCH foo
| (*list [ (*symbol "foo") a @b ])
...)
As far as I can tell, this allows Nulan macros to do everything that Arc macros can do, even with a static type system.
Yeah! There's a certain way that it's really clear that macros and statically typed code can work together; just run the macros before interpreting the static types. Thanks for demonstrating that. I do think this can do everything Arc can do, like you say.
There are a couple of ways I think that can get more complicated:
In languages that resolve overloaded names in a type-directed way, I think the reconciling of static types and macros gets quite a bit more challenging due to the underlying challenge of reconciling name resolution with macros.
For instance, I think Idris has different meanings for the name (,) depending on if it occurs as a value of type (Type -> Type -> Type) or a value of type (a -> b -> (a, b)). In one case it's a constructor of tuple types (a, b), and in another case it's a constructor of tuple values (a, b).
Idris's macro system actually seems to have some special support for invoking the typechecker explicitly from macro code, which I think helps resolve names like those. I haven't actually succeeded in writing macros in Idris yet, and it seems to be a complicated system, so I'm not sure about what I'm saying.
Secondly, one potential goal of a macro system is that all the language's existing primitive syntaxes can turn out to be macros. That way, future versions of the language don't have to inherit all the crufty syntaxes of the versions before; they can stuff those into an optional library. If the language has sophisticated compile-time systems for type inference, term elaboration, name resolution, syntax highlighting, autocompletion, etc., then hopefully the macro system is expressive enough that the built-in syntaxes are indistinguishable from well-written macros.
Arc already gives us things like (macex ...) that can distinguish macros from built-in special forms, so maybe seamlessness isn't a priority in Arc. But if it were, and Arc had static types, we would probably want Arc to have type inference as well, which could complicate the macro system.
A lot depends on what Paul Graham expects from "true macros."
It doesn't care what the type is, or the meaning, or anything like that. In some cases, the macro doesn't even know whether the symbol is bound or not!
Basically, I view type inference/checking/overloading occurring in a phase after macro expansion.
Is there any benefit to mixing the type overloading phase and the macro expansion phase?
----
It occurs to me that you might not be referring to a macro which expands to syntax, but instead using the syntax within the macro body itself.
In Nulan, that isn't a problem either. A macro is essentially a function from Code to Code, so the macro body is compiled/macro expanded/type checked just as if it were a function.
Thus any type overloading will happen inside the macro body, before the macro is ever run.
That does mean that the type checker must be able to overload based solely on the types found within the macro body. In other words, it cannot dynamically dispatch.
----
I don't think it's possible for the primitives to be macros, for the simple reason that the language needs axioms.
If you mean that the primitives should appear to be macros (even though they're implemented with compiler magic), then I agree with you.
"Macros deal with things at the syntax level, far earlier than any kind of type overloading."
If the macro itself is being referred to by an overloaded name, then the name needs to be resolved before we know which macro to call.
(I'm not sure if macros' names can be overloaded in Idris; I'm just guessing. Actually, I don't know if Idris lets users define overloaded names. I just know a few built-in
names like (,) are overloaded.)
---
"If you mean that the primitives should appear to be macros (even though they're implemented with compiler magic), then I agree with you."
You're right, if you allow for users to overload multiple macros onto the same name based upon type, then it gets very messy.
But I think if your language allows for that, it's inconsistent with the way that macros work.
If you want powerful Arc-style macros, then the macro must be run before any types are known.
Any system which allows for that kind of type-based dispatch is different from a Lisp-style macro system, and is probably less powerful.
For example, you won't be able to create macros which create new variable bindings (like "let", "with", etc.) because the type of the variable is not known until after the macro is run.
I'm not sure what a system like that would look like, or if I would even call it a macro system.
I think it makes more sense to have two separate systems: a macro system that deals with syntax only, and an overloading system that deals with types. That's what Nulan does.
But perhaps there is room for a third system, somewhere in between the two: that third system could do type-directed syntax manipulation.
I have no experience with Idris or dependent types, so I may be completely wrong.
But from my understanding, a dependent type system allows for types to include values (which are evaluated at compile-time).
If so, then you might not even need macros at all to create the "," behavior.
Instead, you create a typeclass which will dispatch to the appropriate behavior:
data Pair a b = pair a b
interface Comma a b c where
comma : a -> b -> c
Comma Type Type Type where
comma = Pair
Comma a b (Pair a b) where
comma = pair
Now whenever you use the "comma" function, it will dispatch depending on whether its arguments are Types or not:
And since types may include arbitrary expressions, you can of course use the "comma" function inside of a type:
foo : a -> b -> (comma a b)
Note: all of the above code is completely untested and probably wrong, but you get the idea.
Basically, your language needs first-class types, and the ability to run arbitrary expressions at compile-time (even within types), and then you can use an ordinary typeclass to get the desired type dispatch. No macros needed.
"If so, then you might not even need macros at all to create the "," behavior."
I never said the overloading of "," was accomplished with macros.
The example I gave was of a macro whose name was overloaded in a type-directed way, similarly to the way "," is overloaded in Idris. (Maybe the macro itself is named ",".) My point is that if the macro system is designed to support that kind of overloading, then sometimes a macro call will depend on intermediate results obtained by the typechecker, so we can't run the macroexpander in a phase of its own.
---
For the sake of remembering Idris more accurately, I checked out the Idris docs to look for the particular "macro system" I was dealing with.
It turns out what I mean by the "macro system" in Idris is its system of elaborator extensions (http://docs.idris-lang.org/en/latest/reference/elaborator-re...). The elaborator's purpose is to fill in holes in the program, like the holes that remain when someone calls a function without supplying its implicit arguments.[1]
It's pretty natural to handle name overloading in the same phase as implicit arguments, because it's effectively a special case. Thanks to dependent types and implicit arguments, instead of having two differently typed functions named (,), you could have one function that implicitly takes a boolean:
(,) : {isType : Bool} ->
if isType then (... -> Type) else (... -> (a, b))
(,) = ...
The elaborator phase is complex enough that I don't understand how to use it yet, but I think almost all that complexity belongs to implicit arguments. Name overloading is probably seamless relative to that.
Another "macro system" I encountered in the docs was Idris's system of syntax extensions (http://docs.idris-lang.org/en/latest/tutorial/syntax.html). As far as I can tell, these apply before the elaborator and typechecker, but they might not be able to run arbitrary code or break hygiene. Maybe someday they'll gain those abilities and become a Nulan-like macro system.
[1] Implicit arguments effectively generalize type classes. Idris still has something like type class declarations, which it calls "interfaces," but I bet this is primarily so a programmer can define the interface type and the method lookup functions together in one fell swoop.
Are you familiar with continuations? Continuations are essentially snapshots of the call stack. By calling (ccc ...), you take a snapshot. By calling the snapshot with a value, you jump back to that old stack -- right at the position of the (cc ...) call -- and return a different return value than before.
This is a pretty weird behavior, but it can useful for avoiding the inversion of control dilemma in imperative code. That is, if code A and B need to communicate, should code A call code B, or should code B call code A? Sometimes the callee side becomes a mess of callbacks, rather than a direct imperative style. With continuations, both sides can be the caller, and neither side needs to be the callee: When A calls B with a value, we resume B's earlier call to A using that value as the result. This approach doesn't make it straightforward to design communication paths that work like this, but it is a building block.
Unfortunately, jumping around with continuations messes up another common imperative coding technique. If people write code to set up and tear down a resource, they often like to write all the code in the middle in a way that assumes that resource is already available. With continuations, that assumption can be incorrect: If you jump out of the code in the middle, you may have just skipped the tear-down code entirely. If you jump into the middle, you may have just skipped the setup code.
Dynamic-wind makes up for that shortcoming by letting you write a structured code block that always executes its setup and tear-down sections, even if it's entered or exited using a continuation jump. So when you do a jump, you might actually go through a few dynamic-wind handlers before you reach your destination.
If you're more familiar with exceptions, continuations and dynamic-wind can be seen as a companion of exceptions and "try { ... } finally { ... }" blocks. An exception throw is a jump to an outer level of the stack, but the jump may stop to execute a few "finally" sections before it reaches its destination.
In Arc (and Scheme), continuations and exceptions are supported in the same language. They're both the same kind of jump, executing all the same handlers in between; the "finally" handlers and "tear-down" handlers are basically the same kind of handler. In Arc, unless you write custom Racket code to invoke Racket's dynamic-wind directly, Arc has no way to write a setup handler, but there is an (after ...) construct for writing a finally/tear-down handler.
I think what I've called "setup" and "tear-down" are more commonly called winding and unwinding handlers, or before and after sections. I picked the terms "setup" and "tear-down" just in the hopes of painting a more concrete picture of why they're useful.
This has still been a pretty quick explanation relative to the complexity of the topic, and I haven't included even a single example. If you still have unresolved questions, that's absolutely understandable. :)
KILL ARR FOR I=1:1 READ !,X:5 QUIT:'$TEST SET ARR(I)=X
(Press Shift-Insert or Ctr-V or whatever to insert buffer)
PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG
N ARR,FND,I,RSD,RTN,STOP,TXT
W !!,"PASTE"
F R !,X:15 Q:'$T S ARR($I(ARR))=X
K RSDS
S STOP=0,I=1 F S RTN=$P(ARR(I),".") D Q:STOP
. F S I=$O(ARR(I)) S:I="" STOP=1 Q:STOP Q:ARR(I)?1.AN1".".E D
. . S TXT=ARR(I),FND=$F(TXT,"RSD ")
. . I FND D
. . . S RSD=$P($E(TXT,FND,999)," ")
. . . S RSDS(RSD,RTN_"^"_$P(TXT,"+"))=""
W !!
S RSD=""
F S RSD=$O(RSDS(RSD)) Q:RSD="" D
. W !!,RSD
. S RTN=""
. F S RTN=$O(RSDS(RSD,RTN)) Q:RTN="" D
. . W !?5,RTN
Q
;
FIND ;
N CTR,I,RTN,STR,TAG,TXT
R !!,"STRING: ",STR Q:STR=""
R !,"ROUTINE: ",RTN Q:RTN=""
F I=1:1 S TXT=$T(+I^@RTN) Q:TXT="" D
. I TXT?1(1AN,1"%").E D
. . S TAG=$P($P($P(TXT," "),$C(9)),"("),CTR=0
. E D
. . S CTR=CTR+1
. I TXT[STR W !,TAG W:CTR "+",CTR W ?14,TXT
Q
;
Entering the next line will show the contents of the array:
ZWRITE ARR
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
ARR(6)=" S STOP=0,I=1 F S RTN=$P(ARR(I),".") D Q:STOP"
ARR(7)=" . F S I=$O(ARR(I)) S:I="" STOP=1 Q:STOP Q:ARR(I)?1.AN1".".E D"
ARR(8)=" . . S TXT=ARR(I),FND=$F(TXT,"RSD ")"
ARR(9)=" . . I FND D"
ARR(10)=" . . . S RSD=$P($E(TXT,FND,999)," ")"
ARR(11)=" . . . S RSDS(RSD,RTN_"^"_$P(TXT,"+"))="""
ARR(12)=" W !!"
ARR(13)=" S RSD="""
ARR(14)=" F S RSD=$O(RSDS(RSD)) Q:RSD="" D"
ARR(15)=" . W !!,RSD"
ARR(16)=" . S RTN="""
ARR(17)=" . F S RTN=$O(RSDS(RSD,RTN)) Q:RTN="" D"
ARR(18)=" . . W !?5,RTN"
ARR(19)=" Q"
ARR(20)=" ;"
ARR(21)="FIND ;"
ARR(22)=" N CTR,I,RTN,STR,TAG,TXT"
ARR(23)=" R !!,"STRING: ",STR Q:STR="""
ARR(24)=" R !,"ROUTINE: ",RTN Q:RTN="""
ARR(25)=" F I=1:1 S TXT=$T(+I^@RTN) Q:TXT="" D"
ARR(26)=" . I TXT?1(1AN,1"%").E D"
ARR(27)=" . . S TAG=$P($P($P(TXT," "),$C(9)),"("),CTR=0"
ARR(28)=" . E D"
ARR(29)=" . . S CTR=CTR+1"
ARR(30)=" . I TXT[STR W !,TAG W:CTR "+",CTR W ?14,TXT"
ARR(31)=" Q"
ARR(32)=" ;"
This is the functionality I wish to clone. Doesn't amtter to me if lists are used instead of arrays.
I'm still not following what your program does. (Can you describe its inputs and how it transforms them in english?)
I remember you asked a similar question last year: http://arclanguage.org/item?id=19109. Perhaps it would help to connect up how your question here relates to that thread?
Here's how you run the code in that thread for reading lines from a file with anarki:
$ cat x
ab
cd ef
ghi
$ cat x.arc
(write:w/infile file "x"
(drain (readline file)))
$ ./arc x.arc
("ab" "cd ef" "ghi")
#t
Here is a follow on problem as I'm going through the tutorial: obj does not work and the error message seems to access memory not involved with the obj.
arc> (printlst alist)
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
""
arc> (= codes (obj "Boston" 'bos "San Francisco" 'sfo "Paris" 'cdg))
Error: "list-ref: contract violation\n expected: exact-nonnegative-integer?\n given: '(((codes (obj \"Boston\" (quote bos . nil) \"San Francisco\" (quote sfo . nil) \"Paris\" (quote cdg . nil) . nil) . nil) . nil))\n argument position: 2nd\n other arguments...:\n '(\"\\nARR(1)=\\\"PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG\\\"\" \"\\nARR(2)=\\\" N ARR,FND,I,RSD,RTN,STOP,TXT\\\"\" \"\\nARR(3)=\\\" W !!,\\\"PASTE\\\"\\\"\" \"\\nARR(4)=\\\" F R !,X:15 Q:'$T S ARR($I(ARR))=X\\\"\" \"\\nARR(5)=\\\" K RSDS\\..."
arc>
Judging by that error message, it looks like the variable "=" or one of its dependencies might have been reassigned somewhere along the line. The second argument in that error message indicates that = is getting hold of your read-in data somehow, so it might be something you've defined for processing this data.
The dependencies of = include expand=list, expand=, map, pair, and setforms (among others), so if any of these has been overwritten, it might do something like what you're seeing.
By the way, I think if you're not using Anarki, there's a known bug in (readline ...) where it will spuriously combine each empty line with the following line (https://sites.google.com/site/arclanguagewiki/arc-3_1/known-...). Maybe this could explain the extra \n you're getting.
Hmm, not sure what happened. Not sure what you mean by memory problems, but I've never seen flakiness in a session this short. Perhaps something in your earlier session was accidentally a control character or something. Keep an eye out for it and I will too.
Here's a full session I tried out on linux:
$ arc
arc> (def printlst (thelist) (if (is thelist nil) (prn "") (do (prn (car thelist)) (printlst (cdr thelist)))))
#<procedure: printlst>
arc> (def readit () (drain (readline (stdin))))
#<procedure: readit>
arc> (= alist (readit))
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
("" "ARR(1)=\"PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG\"" "" "ARR(2)=\" N ARR,FND,I,RSD,RTN,STOP,TXT\"" "" "ARR(3)=\" W !!,\"PASTE\"\"" "" "ARR(4)=\" F R !,X:15 Q:'$T S ARR($I(ARR))=X\"" "" "ARR(5)=\" K RSDS\"")
arc> (printlst alist)
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
""
arc> (= codes (obj "Boston" 'bos "San Francisco" 'sfo "Paris" 'cdg))
#hash(("Boston" . bos) ("Paris" . cdg) ("San Francisco" . sfo))
arc>
So I tried again with arc running on Racket under Linux. Here's what I found:
arc> (def readit () (drain (readline (stdin))))
#<procedure: readit>
arc> (readit)
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
("\nARR(1)=\"PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG\"" "\nARR(2)=\" N ARR,FND,I,RSD,RTN,STOP,TXT\"" "\nARR(3)=\" W !!,\"PASTE\"\"" "\nARR(4)=\" F R !,X:15 Q:'$T S ARR($I(ARR))=X\"" "\nARR(5)=\" K RSDS\"" "\n")
arc> (= alist (readit))
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
("\nARR(1)=\"PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG\"" "\nARR(2)=\" N ARR,FND,I,RSD,RTN,STOP,TXT\"" "\nARR(3)=\" W !!,\"PASTE\"\"" "\nARR(4)=\" F R !,X:15 Q:'$T S ARR($I(ARR))=X\"" "\nARR(5)=\" K RSDS\"" "\n")
arc> alist
("\nARR(1)=\"PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG\"" "\nARR(2)=\" N ARR,FND,I,RSD,RTN,STOP,TXT\"" "\nARR(3)=\" W !!,\"PASTE\"\"" "\nARR(4)=\" F R !,X:15 Q:'$T S ARR($I(ARR))=X\"" "\nARR(5)=\" K RSDS\"" "\n")
arc> (len alist)
6
arc> (def printlst (thelist) (if (is thelist nil) (prn "") (do (prn (car thelist)) (printlst (cdr thelist)))))
#<procedure: printlst>
arc> (printlst alist)
ARR(1)="PARSE ; PARSE OUTPUT OF ^%RFIND INTO RSD/RTN/TAG"
ARR(2)=" N ARR,FND,I,RSD,RTN,STOP,TXT"
ARR(3)=" W !!,"PASTE""
ARR(4)=" F R !,X:15 Q:'$T S ARR($I(ARR))=X"
ARR(5)=" K RSDS"
""
arc>
I think the issue with the \n is sending data between Windows and Linux.
I did have to key in Ctrl-D twice to actually get the function to finish reading. Is there a better way to do this?
This probably seems weird, but I capture the data on a Windows system, then e-mail the data to a Linux system which is where arc resides. I assume Windows and Linux have different line endings.
Perhaps I need to check out the community version of arc?
Has anyone figured out a way to compile an arc routine? I saw an earlier thread on it, but no resolution.
(def read ((o x (stdin)) (o eof nil))
(if (isa x 'string) (readstring1 x eof) (sread x eof)))
; inconsistency between names of readfile[1] and writefile
(def readfile (name) (w/infile s name (drain (read s))))
(def readfile1 (name) (w/infile s name (read s)))
(def readall (src (o eof nil))
((afn (i)
(let x (read i eof)
(if (is x eof)
nil
(cons x (self i)))))
(if (isa src 'string) (instring src) src)))
I've seen this before. What's happening, somehow, is that every time you write more than one line in a definition at the REPL in a Windows prompt, a capital R is being inserted at each newline. Arc compiles this to the Racket code _R, and when Racket executes this, it can't find the _R variable.
I seem to remember I used work around this by always pasting my multi-line definitions from a text editor rather than writing them directly at the REPL.
Oh, sorry. Now that I test it, I realize I remembered incorrectly.
The only time I get those spurious R characters is when I paste code into the REPL and then press enter manually. I don't get them when typing multi-line definitions directly at the REPL, and I don't get them if the code I'm pasting already has a line break at the end.
So the habit I've formed is to make sure the code I'm pasting already has a line break at the end.
I notice this issue also happens on Racket 5.3.3 -- I'm a few versions behind -- and it does not happen in the REPLs for Node.js or Clojure. It's some kind of bug in Racket. (Hmm... Racket's port.c has a bunch of spaghetti code for CRLF processing. Maybe the bug's in there somewhere.)
My money's on the first or last one working. (Obviously this assumes you _have_ a `C:\users` directory) I would similarly bet that you might need to capitalize the drive, even though Windows drive letters are case insensitive (https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...). So if it doesn't work with lowercase letters, try it as above.
Can you try it without the drain, just read the first line from the file?
Edit 10 minutes later: here's a few things I would try:
; a relative path with no slashes/backslashes
(read-all "mccf2.txt")
; inline read-all
(w/infile file "mccf2.txt" (drain (readline file)))
; try reading just the first line
(w/infile file "mccf2.txt" (readline file))
So it looks like the inlined version works, but wrapping it in a function doesn't? Very strange. Paste these lines one at a time into a fresh arc session and show me what you get in response to each line.
(w/infile file "Log.txt" (drain (readline file))) ; just to set a baseline
(def foo (filename) (prn "AAA") (w/infile f filename (prn "BBB") (drain (do1 (readline f) (prn "CCC")))))
(foo "Log.txt")
(def foo (filename) (prn "AAA") (w/infile f filename (prn "BBB") (readline f)))
(foo "Log.txt")
I think rocketnia has figured it out. Does rocketnia's comment http://arclanguage.org/item?id=19137 make sense? Basically you shouldn't get an error if you type in this expression character by character, but you should if you paste it into an arc session without a trailing <enter>.
I've mainly just been learning the language. Working through some tutorials, reading books/articles, coding, etc. Did a few Project Euler problems, and now I'm working through SICP.
I burned a lot of time looking for my (not "the") perfect language, and finally settled on Racket for the dynamic language and OCaml for the statically typed language.
Now I'm trying see which problems are best suited to each of them.
Clojure has a lot of good things, but I've never been able to get past the dependency on the JVM, lack of tail calls, etc., but it's pretty darn concise.
