Darren New wrote:
> Orchid XP v8 wrote:
>> Oh, OK. It's actually all very readable on my screen; I guess it has a 
>> higher gamma or something.
> 
> I actually live where it's sunny during the daytime. ;-)
> 
> I have trouble with a lot of video games, too.

Ah, OK. My office at work [where I coded this program] has no sunlight. 
I don't even know if it's day or night or whatever. A bit like caving, 
actually... random...

As for my bedroom at home... I just close the curtains when I want to 
play HL2. ;-)

>> BTW, are you impressed that I got this to work? Somebody wrote a small 
>> Haskell library that invokes windows.h under Windoze or emits ANSI 
>> escape sequences on POSIX. Neat, eh? Also, notice the window title 
>> bar... ;-)
> 
> Yep. I'm impressed. :-)

Heh. Actually I wrote a small library of my own that calls windows.h 
directly. [You've seen the code, haven't you?] But somebody else came up 
with a nice library that works on Windoze *and* POSIX, so now I'm using 
that instead. So I really could compile my program for Linux or 
something if I want.

>> Since "+" isn't a valid token, 
> 
> Ah.
> 
>> This is one of the irritating things about Parsec. It can silently 
>> fail to parse all of the input. Like, if some prefix of the input is a 
>> valid expression but the rest isn't, it returns just the prefix. 
>> (Obviously it depends how you structure your parser.) I must figure 
>> out how to fix that...
> 
> Doesn't it also return the rest of the unparsed string? So if that isn't 
> empty, something failed?

Nope.

Remember, each "parser" can be combined with other parsers to make a 
larger parser at any time. And it might be that the parser is only 
*trying* to parse some prefix of the input.

I just asked about it, and some people recommended adding the "eof" 
parser to the top-level parser. (This causes the parser to fail if the 
entire input is not parsed. The error message is likely to be pretty 
opaque though...)

BTW, have you tried making the parser deliberately fail? It doesn't just 
crash the program, it actually reports a (moderately) friendly message 
to the user. It even hilights where in your input it's upset - in case 
you can't mentally work out where "column 28" is. Neat, eh? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> Hey people, check it out: Attached to this post is a small program I 
> wrote.

What does the result y <- #2 mean?

Try the two below:

@Element[x,{1,y}]
@Element[x,{y,1}]

The 2nd one contains the "y <- #2" result but the first one doesn't.

Also I agree with what Darren said, the dark blue used for the "<-" is a bit 
too dark (visible, but hard to see, how about dark red instead?).

Post a reply to this message

scott wrote:

> What does the result y <- #2 mean?
> 
> Try the two below:
> 
> @Element[x,{1,y}]
> @Element[x,{y,1}]
> 
> The 2nd one contains the "y <- #2" result but the first one doesn't.

Consider the expression "?x: y = x". This is read as "there exists an x 
such that y = x". What it "really" does is replace x with a unique 
variable name (in this case, "#1").

The only reason you would do this is if you're running a recursive 
predicate, so that successive recursions all get unique variable names. 
Internally, all of the predefined functions except @Empty are recursive 
and so use such variables.

Ordinarily, all these temporary variables either have nothing bound to 
them, or are bound to a specific value. But occasionally they do show up 
in the final result. In the example you give, "y <- #2" actually means 
nothing at all, so the program should probably elide that. (It means 
that y is equal to some temporary variable which itself doesn't have a 
defined value, and hence y has no defined value - which would be the 
same as the result set not mentioning y at all!)

See? This stuff is harder than it looks! ;-)

> Also I agree with what Darren said, the dark blue used for the "<-" is a 
> bit too dark (visible, but hard to see, how about dark red instead?).

Hmm, yes, that *is* a little dark...

Post a reply to this message

>> Everyone loves to design languages.  Parsec?
> 
> Yeah, Parsec. ;-)

Wanna see the code?

Post a reply to this message

Here it is, people: build #70.

Changes since the last released version:

- Fixed: Parser used to silently ignore invalid parts of the input, as 
long as some prefix of it is a valid expression. (E.g., "x = 1 + 1" 
would silently parse 'successfully' as "x = 1".) You should now get an 
error message instead.

- Changed "<-" from dark blue to dark cyan. (On my system, that shows up 
significantly brighter.)

Post a reply to this message

Attachments:
Download 'logic.exe.dat' (183 KB)

Well that didn't last long! Here's build #86. (I promise there won't be 
any more for a while yet...)

Changes:

- The predicate "?x: a = x & b = x" now yields "a <- b" as you'd expect. 
(It's a hack, so it doesn't always work.)

- Fixed a very evil bug where calling functions with certain variable 
names as arguments would cause bizare malfunctions. (Basically the 
variable names used inside the function clashing with the arguments 
passed in. This *should* be fixed now...)

- Functions are no longer hard-wired into the program; you can define 
your own! The Library.txt file (it must be called exactly that) contains 
the definitions. If this file doesn't exist or is not parsable, 
currently the situation isn't handled terribly gracefully.

I've included the hard-wired functions, but feel free to add your own!

Post a reply to this message

Attachments:
Download 'logic.exe.dat' (189 KB) Download 'us-ascii' (1 KB)

Nicolas Alvarez wrote:

> Will it solve simple stuff like "x + 1 = 3" in version 1.5? :)
> 
> (or does it already...?)

Actually... if you encode "numbers" as lists of 1s of the appropriate 
length, then the @Join[] function essentially implements addition and 
subtraction! o_O

@Join[{1, 1}, {1, 1}, z]
z <- {1, 1, 1, 1}

@Join[{1, 1, 1}, y, {1, 1, 1, 1, 1}]
y <- {1, 1}

etc.

Obviously this isn't an especially intuitive or efficient way to work, 
but hey - Peano integers FTW! :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> - Fixed a very evil bug where calling functions with certain variable 
> names as arguments would cause bizare malfunctions. (Basically the 
> variable names used inside the function clashing with the arguments 
> passed in. This *should* be fixed now...)

And you wondered why Lisp has that funky "gensym" function.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> - Fixed a very evil bug where calling functions with certain variable 
>> names as arguments would cause bizare malfunctions. (Basically the 
>> variable names used inside the function clashing with the arguments 
>> passed in. This *should* be fixed now...)
> 
> And you wondered why Lisp has that funky "gensym" function.

What is "gensym", and why does Lisp have it?

Post a reply to this message

Invisible wrote:
>>> - Fixed a very evil bug where calling functions with certain variable 
>>> names as arguments would cause bizare malfunctions. (Basically the 
>>> variable names used inside the function clashing with the arguments 
>>> passed in. This *should* be fixed now...)
>>
>> And you wondered why Lisp has that funky "gensym" function.
> 
> What is "gensym", and why does Lisp have it?

It creates a guaranteed-unique variable name that you can use as a local 
in a macro or a dynamically-scoped function.   What did you *think* it 
might be for, given the bit I quoted and the name of the LISP function?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message