Handling URLs

[charles-l]

URLs get parsed as commands (i.e. protocol://blahblah is interpreted as protocol (//blahblah)), which is a bit awkward when writing curl/git/ssh/scp commands. Is it reasonable to parse something like 'http://blahblahblah' as a symbol, and only make it a command when there's a space following the colon? i.e. 'http: //blahblahblah' uses a command called HTTP.

Alternatively, URLs could be matched as their own data type (which might be nice since oh has a stronger type system than most shells). Or the ':' shorthand could be replaced with another symbol like '$' a la ocaml or '@' a la haskell (though it would still have to be surrounded with spaces since scp/mail use @)?

I know that you can wrap it in quotes to make it a string, but URLs are extremely prevalent in shell commands, so wrapping them all in quotes can get tedious.

[michaelmacinnis]

Yeah, I've thought about allowing single colons inside symbols. I've also thought about removing the '@' operator (but keeping splice) and changing backtick to automatically splice. Doing that would allow URLs and email addresses to be entered without quotes. This would also mean that variadic methods would have to have a space following the colon in their parameter list. (Something I have not been consistent about). The drawback is a more complicated syntax with one more special case which is something oh has tried hard to avoid.

[eradman]

I think it's worth pointing out that URLs have to be quoted in BASH and probably any shell. URLs are common, but they also complex and they utilize a large number of special characters.

[michaelmacinnis]

I'm wondering if it's possible to build a sufficiently smart completer so that quotes can be added (suggested?) when they are needed in order to keep oh keystroke competitive without complicating oh as a language.

[michaelmacinnis]

I've been playing around with ways to reduce the differences between what needs to be quoted in oh vs other shells. In retrospect, I think : and :: were poor choices. Leading, trailing and interior colons can be found in many Unix shell commands. Double colons too and probably increasingly so with the rise of IPv6.

The current plan is to replace : with the single $. so instead of writing:

define r: cons () ()

we would write:

define r $ cons () ()

Using $ this way feels similar to the way it is used in regular expressions, vi, etc. "This sublist extends to the end of the current list". I believe Haskell does something similar.

The $ needs to appear on its own so the space after is required. I will probably put a space before (except after =) just to make them easier to spot. In my opinion, the colon looked nicer but using $ instead will reduce pointless differences between oh and other Unix shells.

Expressions of the form: a::b will be rewritten as {a}{b}. So instead of writing:

p::_reader_close_

we would write:

{p}{_reader_close_}

These changes will allow colons to appear unquoted.

The splice operator @ and the rarely used %a b% reference syntax will also be removed. _splice_ will still exist but there will be no shorthand syntax for it. References will be replaced by meta-commands that will have the form (|a b ...|). These changes will allow @ and % to appear unquoted.