Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse, Don't Validate (2019)

lexi-lambda.github.io

Post reply on HN
Print view View original

281–288 of 288 posts

Re: Parse, Don't Validate (2019)

#281

Post by ukj »

wabain wrote: post #277
ukj wrote: post #269

Earlier quoted context omitted.

>But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the rou…

I mean, there's ample evidence on this thread to suggest we're not going to reach a productive conclusion here but I guess I'll keep biting. It's not clear to me if you are suggesting that a dynamic routing table with different kinds of routes cannot be implemented in a type-safe manner in a statically typed language, or if you're working with an analogy where a routing table is like a dynamic programming language at…

> I can't think of an instance where an operation would fundamentally require a fixed relation in the concrete types of different routes. For instance, when routes overlap you can derive a priority value for each one to decide which one to use, rather than directly implementing some kind of function whichIsBetter(a, b) which relies on knowing what concrete route kinds a and b are.

Any routing logic which makes routing decisions based on information nested arbitrarily deep into your packets.

Is this an IP packet containing data; or an IP packet containing an HTTP GET request to www.google.com?

You have to do arbitrarily deep type inference in real time.

The the data has no semantic content until you infer some! Is just a bitstream!

Re: Parse, Don't Validate (2019)

#282

Post by ukj »

wabain wrote: post #277
ukj wrote: post #269

Earlier quoted context omitted.

>But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the rou…

I mean, there's ample evidence on this thread to suggest we're not going to reach a productive conclusion here but I guess I'll keep biting. It's not clear to me if you are suggesting that a dynamic routing table with different kinds of routes cannot be implemented in a type-safe manner in a statically typed language, or if you're working with an analogy where a routing table is like a dynamic programming language at…

>If it's the latter I'm not really sure how the analogy works—if programming languages are to routers as types are to routing entries, what in a router is analogous to a value of a given type?

It's not an analogy. Programming languages and routers are particular instances of computable functions. "dispatching" and "routing" are just another example of us using different English words to describe the exact same computation: M:N mapping function.

Whether the input is mapped to an IP address or a memory address - boring implementation details.

Nothing in a router is analogous to a value of a type because there is no such thing as "types" at runtime unless you infer them! Types exist only at compile time. Types are semantic annotations of data. You are helping the compiler help you by telling it what you know about the data you are handling.

This blob encodes a Number. That blob encodes a String.

If you don't want any help from your compiler, you don't have to tell it the types of anything - just manipulate the data directly!

That's precisely what an Assembly language do. Everything is untyped.

Re: Parse, Don't Validate (2019)

#283

Post by ukj »

wabain wrote: post #277
ukj wrote: post #269

Earlier quoted context omitted.

>But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the rou…

I mean, there's ample evidence on this thread to suggest we're not going to reach a productive conclusion here but I guess I'll keep biting. It's not clear to me if you are suggesting that a dynamic routing table with different kinds of routes cannot be implemented in a type-safe manner in a statically typed language, or if you're working with an analogy where a routing table is like a dynamic programming language at…

>Where special behavior is needed for routes of different kinds, that behavior can be implemented by using dynamic dispatch in the sense it's usually used.

How? A routing function is precisely a M:N mapping with untyped input.

It's just some data somebody sent you! Route it.

Unless you can infer more about the meaning of those bits the only strategies possible are static(M), round-robin(M) or random(M).

Re: Parse, Don't Validate (2019)

#284

Post by ukj »

wabain wrote: post #277
ukj wrote: post #269

Earlier quoted context omitted.

>But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the rou…

I mean, there's ample evidence on this thread to suggest we're not going to reach a productive conclusion here but I guess I'll keep biting. It's not clear to me if you are suggesting that a dynamic routing table with different kinds of routes cannot be implemented in a type-safe manner in a statically typed language, or if you're working with an analogy where a routing table is like a dynamic programming language at…

Here! Here! Angry downvoter. Don’t leave this post out.

Smash that button.

Re: Parse, Don't Validate (2019)

#285

Post by mirekrusin »

uryga wrote: post #34
lloydatkinson wrote: post #26

Earlier quoted context omitted.

I wish it had actual proper examples. I've no idea how to use that.

from a look at the readme, you combine those `$.TYPE` things to build a validation function that checks if its argument matches some pattern (and throws an exception if it doesn't). import * as $ from '@appliedblockchain/assert-combinators' const validateFooBar = ( $.object({ foo: $.string, bar: $.boolean }) ) // probably roughly equivalent to /* const validateFooBar = (x) => { console.assert( typeof x === 'object' &…

Yes, the difference between console.assert and assert-combinators is that assert combinators return well typed ts result (and are more terse/minimal).

Re: Parse, Don't Validate (2019)

#286

Post by dnadler »

theptip wrote: post #140
dnadler wrote: post #107

Earlier quoted context omitted.

We've had a similar experience using pydantic. We integrated it quite tightly with a django project and it's been awesome.

Where did you find it valuable to wire in to Django?

We effectively use them as serializers, and also as a way to allow users to interact with the models in a controlled manner.

In our app, django essentially sits between a compute cluster and a front end. The pydantic objects are used to define the work to be done on the compute cluster.

Re: Parse, Don't Validate (2019)

#288

Post by jhgb »

ukj wrote: post #195
codetrotter wrote: post #76

Earlier quoted context omitted.

But I’m not talking about compilers here

Why not? Compilers are computable functions. If “Parsing is validation, but validation is not parsing” is true then it is also true about compilers.

> If “Parsing is validation, but validation is not parsing” is true then it is also true about compilers.

This is a false statement, considering that the cases where something is validation but not parsing may very well lie in the complement of the set of compilers to the set of all computable functions. The converse statement that if this were true about the smaller set (of compilers), it would also be true about the larger set (of all programs) would on the other hand be correct.

Post reply on HN